I'm a student learning PHP. I basically make the stuff work, but never wondered about how the php.exe(on windows) works.
Does it compile the stuff it has to handle or not?
Reason I'm asking is because someone told me that ASP.NET has to compile all website-dependant data is has/receives, like everything that gets uploaded through a form.
He claimed that PHP is faster on that subject, since it does not have to compile anything.
I can't find any good information on either subjects, so I'm asking here.
PHP is a scripting language, and so is not compiled as such. It is parsed into an interal representation which is in turn "run" by the PHP runtime.
Your friend is correct in so far as that ASP.NET is compiled. However, it's only the actual program instructions that are compiled, not data. The way PHP and ASP.NET treat incoming (and outgoing) data are pretty similar in principle. If anything, ASP.NET will be faster than PHP because it is compiled, since compiled code generally runs faster.
As #chaos has said, ASP.NET does not "compile" data received through a form.
Most likely what your associate is referring to is called ViewState in ASP.NET, and if that's that he's talking about, he's correct, although he mislabeled it as "compiling". ViewState does encode and store the state of the form and the server does need to decode this data and apply it to the object model. It uses this information to raise events that programmers can hook server-side, providing a much richer model for programming.
And, yes, this is a performance hit. PHP can be faster than ASP.NET; I've worked as a PHP developer and as an ASP.NET developer and I can attest to this.
But performance is not everything--more time is spent in data transit than it is in processing on a web server for all but a very few niche cases. And there are other aspects of your system that matter more than raw pushing power. ASP.NET trades that raw performance for other things.
This is where ASP.NET shines and PHP fails horribly. PHP cannot offer nearly the capability of ASP.NET for things like modularity, maintainability, security, re-usability, and general base library capability. Yes, PHP can be faster than ASP.NET. But ASP.NET is still superior.
Of course, ASP.NET sucks, too, IMO, but that's more because of some design decisions that I frankly disagree with. But I'd much rather use it that PHP any day of the week.
Neither PHP nor ASP.NET normally compile (interpret as program instructions and convert to executable code) data received through forms.
Possibly your associate may be confused about the difference between compilation and data sanitization, or something. I really don't know.
No. The type of data you are talking about is passed through to PHP as environment data from Apache. You can do it yourself with command line options to php.exe if you want.
Data is rarely compiled unless it is part of a resource for a program.
PHP itself is an interpreted language, which means that the code is never compiled into a machine-friendly format, it is simply scanned and parsed by the interpreter in order to be executed.
Tor Haugen is right, PHP is an interpreted language meaning the files remain as plain text on the sever and are interpreted as they are requested. ASP.Net is a bit of a hybrid because the *.aspx, *.ashx, *.ascx, etc. files are all interpreted while external libraries are compiled into DLL files that are then linked in like a normal desktop application. So if you have, for instance, several projects, one of which is an ASP.Net web application that relies on several class libraries, you would have several plain text files (web app files) and several DLL files that are generated and used by the server. You can use DLL files which PHP but it isn't as seamless. Usually such "class libraries" would simply be "included" as additional plain text files
Related
Guys recently I decided to go back to PHP and do some more complex stuff than a simple log in page. For 3 years I've been programming with Java/JavaEE and have a good understanding of the architecture of of Java Applications. Basically, a virtual machine ( a simple OS process ) that runs compiled code called byte code. a simple Java web server is basically a java application that listens on provided TCP port for Http requests and responds accordingly of course it is more complicated than that but this is its initial work.
Now, what about PHP ? How does it work ? What, in a nutshell, is its architecture.
I googled about this question but in 90% the articles explain how to implement and construct a web application with PHP which is not what I am looking for.
The biggest difference between a Java web server and PHP is that PHP doesn't have its own built-in web server. (Well, newer versions do, but it's supposed to be for testing only, it's not a production ready web server.) PHP itself is basically one executable which reads in a source code file of PHP code and interprets/executes the commands written in that file. That's it. That's PHP's architecture in a nutshell.
That executable supports a default API which the userland PHP code can call, and it's possible to add extensions to provide more APIs. Those extensions are typically written in C and compiled together with the PHP executable at install time. Some extensions can only be added by recompiling PHP with additional flags, others can be compiled against a PHP install and activated via a configuration file after the fact. PHP offers the PEAR and PECL side projects as an effort to standardise and ease such after-the-fact installs. Userland PHP code will often also include additional third party libraries simply written in PHP code. The advantage of C extensions is their execution speed and low-level system access, the advantage of userland code libraries is their trivial inclusion. If you're administering your own PHP install, it's often simple enough to add new PHP extensions; however on the very popular shared-host model there's often a tension between what the host wants to install and what the developer needs.
In practice a web service written in PHP runs on a third party web server, very often Apache, which handles any incoming requests and invokes the PHP interpreter with the given requested PHP source code file as argument, then delivers any output of that process back to the HTTP client. This also means there's no persistent PHP process running at all times with a persistent state, like Java typically does, but each request is handled by starting up and then tearing down a new PHP instance.
While Java simply saves persistent data in memory, data persistence between requests in PHP is handled via a number of methods like memcache, sessions, databases, files etc.; depending on the specific needs of the situation. PHP does have opcode cache addons, which kind of work like Java byte code, simply so PHP doesn't have to repeat the same parse and compile process every single time it's executing the same file.
Do keep in mind that it's entirely feasible to write a persistent PHP program which keeps running just like Java, it's simply not PHP's default modus operandi. Personally I'm quite a fan of writing workers for specific tasks on Gearman or ZMQ which run persistently, and have some ephemeral scripts running on the web server as "frontend" which delegate work to those workers as needed.
If this sounds like a typical PHP app is much more of a glued-together accumulation of several disparate components, you'd be correct. Java is pretty self-contained, except for external products like RDBMS servers. PHP on the other hand often tends to rely on a bunch of third party products; which can work to its advantage in the sense that you can use best-of-breed products for specific tasks, but also requires more overhead of dealing with different systems.
This is how does PHP work:
(one of the best over the Internet)
In general terms, PHP as an engine interprets the content of PHP files (typically *.php, although alternative extensions are used occasionally) into an abstract syntax tree. The PHP engine then processes the translated AST and then returns the result given whatever inputs and processing are required.
Below image will depict more information
Source: freecodecamp.org
There have been great things happening in the Haskell web development world, and some of the available frameworks (Yesod and Snap server) seem quite mature. However the learning curve can be a bit steep, and perhaps building web apps cannot quite be considered Haskell's forte.
The answer to another SO question of mine indicates that writing PHP extensions in Haskell should be possible. Infact I'm currently in the process of trying to convert a small Haskell program to a PHP extension as a proof of concept.
So, the question is - is there a case for creating a Haskell web framework that is meant to be run as a PHP extension and leaves all the request/response / cookies etc. handling to PHP?
What would be the design decisions involved in creating such a framework? Right now, the only thing I can think of is that it would probably expose an XML/JSON API accessible by the PHP pages using GET and SET function calls.
I can't think of a use case where this makes any sense. If you want something else to handle the HTTP request/response, you'd be better off writing to the Apache API directly.
Introducing PHP gives you argument parsing and cookie handling but also introduces a lot of other silliness. Not only are many of the common practices very unsafe or insecure, but you are limited to content generation -- if you want to dispatch to other parts of code based on the URL you have to write all that yourself. Many mature PHP programs end up just having one "start" PHP script. You also will have problems if you want to do anything interesting with uploaded files, because PHP handles that in a suboptimal way.
You could theoretically do something very processor intensive in your Haskell extension, but you might as well just write a C extension for PHP in that case. And PHP invocations are never supposed to hang around for very long anyway.
Seems like you are limiting yourself to PHP's brain-damaged model of a web application for the very trivial benefit of argument and header parsing.
Writing a Haskell interface to the Apache API could potentially be liberating. You could rely on a battle-tested web server, and also hook into every phase of the Apache request cycle. Apache's way of preforking and killing children every now and then might be a way of dealing with Haskell space leaks, although it's a sledgehammer approach.
I need to create a web application that tars files on a remote server then moves those files to another server. I am new to scripting languages and was wondering if there are advantages to php or perl for this type of application.
Not really. Both will get the job done just as good as the other. The bottleneck of both will be connecting to the remote server.
PHP was originally derived from Perl, so the syntax between the two are very similar. It's all a matter of taste.
PHP is nice because many Apache servers are setup to allow you to embed PHP code inside your HTML pages. This makes PHP very popular in building things like CMS systems and bulletin boards.
I personally think that the PHP syntax is sloppy. There's way too many specific functions and they're not clearly thought out. The syntax changes from one function to another. I guess it's part of PHP's group based philosophy where a lot of people add a lot of features. I also like Perl's use strict and use warnings pragmas which I find save me a lot of grief.
But, as I said, when it comes to webpage development, PHP is ahead of Perl.
(Yes, I know about modperl, but that's not usually installed in most Apache servers).
I'd say to go ahead and learn both. I believe the Perl books are some of the best written programming guides I've seen. I haven't been too thrilled with the PHP ones. Maybe its because Perl is just more established, so the documentation has been better defined.
Then again, if you're going to learn something, maybe you should try Python. I'm not a fan of Python, but its the up and coming language that most people are learning these days. Google uses Python extensively. And, don't forget Ruby which has the webbased Rails platform that's very popular.
By the way, what you want to do isn't part of the default language, but most languages have modules that are easily installable. For example, you'll need Archive::Tar and LWP for Perl. These can be downloaded from the CPAN module archive.
It's going to take you a while to pick up enough of any language to do what you want, so be patient and have fun.
You need this ssh extension http://php.net/manual/en/book.ssh2.php
It support calling ssh using ssh2_connect.
And you can bundle with tar, scp, or even rsync
I'd like to be able to run JavaScript and get the results with PHP and is wondering if there is a library for PHP that allows me to parse it out. My first thought was to use node.js, but since node.js has access to sockets, files and things I think I'd prefer to avoid that.
Rationale: I'm doing screen scraping in PHP and have encountered many scenarios where the data is being produced by JavaScript on the frontend, and I would like to avoid writing specialized filtering functions to act on the JavaScript on a per-case basis since that takes a lot of time. The more general case would be to parse the JavaScript directly.
Downvoting: I don't really see what's so controversial about this question, modern web crawlers are known to do it, the only difference is that they tend to not be written in PHP. [1]
[1] http://blogs.forbes.com/velocity/2010/06/25/google-isnt-just-reading-your-links-its-now-running-your-code/
It's an interesting question and the down-voters are being unimaginative about potential use-cases. Page archiving tools, printing scripts, preview images - all valid reasons to want to manipulate a document with the JavaScript included within the page.
I'm not aware of any existing PHP implementations, but you could probably adapt Mozilla's SpiderMonkey as a PHP module, or as a standalone tool to manipulate a DOMDocument and return the result.
I haven't had experience with server-side JavaScript, but some issues that I believe might need to be dealt with:
Host objects like document and window are not part of the ECMAScript specification (these are objects provided by the implementing browser) so you need to make sure that the library provides equivalent host objects.
You might have security issues around executing client side scripts within a server side environment. This is a lot like allowing the user to submit a PHP script to be evaluation, so you need to make sure the security sandbox is tight.
Another (perhaps) safer and easier to implement option might be to use a modified FireFox or WebKit instance that runs as a browser, loading up the target pages and returning the modified source to your application.
From PHP 5.3 you can use V8JS extention from PHP. It's a native library that uses the new Google V8 Javascript engine to execute JS and return the result.
It's good because you can pass vars in PHP arrays and are interpreted very well
NodeJS (or some other derivative of google's v8) might actually be the best way to go here. If you're concerned about the various things nodejs can do (eg. sockets, etc), you can probably "strip it down" by removing modules and/or addons -- I think even the built in stuff is ultimately implemented in such a way that it could be stripped out fairly easily.
An alternate approach might be to simply replace, override, or remove the require function from node.js.
There's also envjs which should make it easier to run js that was designed to run the browser.
I am primarily a PHP developer, and I have been browsing the source code of a few open-source applications recently(Mozilla Bespin in particular), to find that some of them use a Python "back-end." I was just wondering what the purpose of this back-end is. I am assuming it is the same thing as the model in an MVC framework and is used to interface with the database, but I'm unsure. If I'm right and the back-end is used to simply interface with the database, is the sqlite/mysql server included in the backend, because I didn't see any database config information in the install directions?
A "Python backend" is simply server-side software written in Python, no different in general terms than server-side software written in PHP. It does all the same things, just with a different programming language.
It looks like Bespin uses Python in the same way it would use PHP, if the autors chose PHP and not Python.
If you are a PHP developer, you already are a "back-end" programmer and you already know what it does, the only difference is the programming language that was used to do that.
Some web sites, mostly the huge ones like Facebook or Twitter, consist of more layers than the usual MVC ones. If you look at Facebook, you can see PHP scripts that generate HTML and AJAX responses as the "front-end" and high-performance databases, storage, computation cluster, application servers etc. as the "back-end" (where PHP is rarely used). So what is considered "front-end" and what "back-end" may also depend on how you look at it.