Maybe this is gonna sound naive and all, but is there something even remotely close to a php crawler for ajax based websites?
The problem is that vanilla PHP doesn't understand how to parse JavaScript, generate the JavaScript environment, and interact with everything. In order to theoretically do it, you would have to extend PHP via the C API and interface it with a JavaScript library. The scale of this is quite large depending on how many resources you have.
Not automatic crawlers, because they would need to understand the javascript code and need to know what's going on.
What they could do is use the same calls as the ajax enabled script would do, so you can get at the raw data.
But this would mean you need to have a very good understanding of the webpage and which url's it's calling, and is quite labour intensive.
So the answer is: No, as far as I know, they don't exist.
you can use the phantomjs library to excute js.
https://github.com/ariya/phantomjs/blob/master/examples/waitfor.js
Related
I have a PHP class/object which acts as the primary data source for my webpage. I'm using jQuery/Javascript to provide a dynamic interactive experience for the user. Both parts work independently really well.
I'm now trying to find an elegant and clean way for the javascript library I've written to access and update data stored in the PHP object.
Communication Javascript -> PHP: I've previously always created a PHP wrapper that takes input over the GET/POST and routes the data to the appropriate PHP function. This works well enough but surely there is a cleaner way to interface from javascript to PHP?
Communicating PHP -> Javascript: Previous websites I've written have seen communication from javascript to PHP only. The PHP would output HTML which Javascript would place in a container (Standard javascript usage I guess). However, in this website, the Javascript library I've written requires structured data in return which it processes to perform multiple UI updates. It seems that looking into JSON would be the right thing here but there seem to be a variety of options.
I would love the advice on the best way to get your PHP and Javascript communicating in both directions is a clean and elegant way.
Thanks!
I want to try creating a canvas were multiple users can type and edit for brainstorming etc. I am thinking of php as backend. What are the technique used for it? For example, lets say its
pure text. How do we update the text like in the google wave(b4) and in google doc?
Is it just using websocket(or js pooling) and updating the text file? or are there any
better logical way to solve this issue?
Well, its not as easy as it is said in Brad's answer but he is partially right. You will definitely need WebSockets today to make it happen. But logically, it is not that simple to create a collaborative environment. There are issues like broadcasting changes of every user to every other user viewing the same document. Then you will have to make sure that every user gets to see exactly the same thing no matter who changes what and when. This gets difficult when multiple users are working on the same document collaboratively. There can be conflicts while merging changes of one another.
As far as PHP is concerned, language is not really a problem. Its how you handle the above stated problem.
Google released its research and engineering details on Google Wave (I guess after abandoning the project). This link might be some help to you: http://www.waveprotocol.org/whitepapers/
Websockets are the way to go for this. However, they are difficult to implement in PHP, and not supported by many browsers as of yet. You can do long-polling of AJAX requests pretty easily with PHP, but it can be quite a waste of resources.
This might not be what you are looking for, but I'd suggest changing your server-side technology. You can use Node.js with Socket.IO to easily use Websockets (or seemlessly emulate them for browsers that don't support them). This will provide the fastest method for pushing data to your users.
I've now got some very good understanding of (X)HTML and CSS, and plan to move on. My next choices are PHP and JS (and don't know if I'll ever end up learning one of them, but I would love to).
So, I need to choose one of them. I have learnt that PHP is server-side programming and JavaScript is client-side programming, and I am NOT asking you to compare the two of them for me. What I would like to know is, can I do anything (or most of) in PHP that can be done with JS? (or put it this way, can do everything people use JS for, on the server-side with PHP?)
Instances include, using PHP instead of JS in web themes, real-time content display (as in live blogging, live comments etc), effects etc.
This might seem dumb, and there's definitely a reason why people use JS in all the above instances, but since I cannot (really) learn the two of them, thought I should ask for some advise here.
EDIT: Would it be possible to reload only a part of a web page (not the entire web page) every few seconds with PHP? That should be good enough for the real-time application that I am planning.
If you absolutely don't want to learn both, then learn Javascript. There are possibilities to implement a Javascript-based backend with node.js.
I advise you to at least try PHP since it is widely used - maybe even at your company.
For nice user experience (dynamic menu, ajax, effects, ... ) you need client-side programming and for dynamic content you (almost always) need server-side programming.
In short, you need both.
PHP and JavaScript cannot really be compared in the way you're asking...
Both are powerful in what they've ment for and they have a very similar syntax. If you can't absolutely study more than one of them, learn PHP in my opinion. I coded with PHP for almost 10 years before really getting into JS. I would say PHP is the food and JS is the spice.
In order to create AJAX web apps Javascript AND a server-side language is required.
No, you can't. PHP only works on the server side. Once you've delivered content to the client, PHP can't do anything until the page reloads or the user loads a new page. If you want to do anything client-side in between, you need JavaScript (this includes loading content in real-time, doing a lot of modern UI stuff, etc).
Either learn both PHP and JS or use a blogging CMS and use a minimal amount of both.
If you put enough effort into it, you can do almost anything server-side using lots and lots of page reloads. You can also generate arbitrarily complex dynamic content using Javascript.
But it's a lot easier to do minor changes to a page's content from Javascript, it's only possible to do animations and effects from Javascript. It's also much easier to directly access the database from server-side code – there might be pure-javascript drivers for SQL databases, and you could use a NoSQL databases that's accessed using web services, but both are relatively uncommon techniques.
I have a thought regarding your original question/situation. I know this is about four years tardy, but I thought I should throw in my two cents for people who are looking back on this conversation as a reference from Google like I am. In your situation, because you are a blogger who is trying to save time when it comes to programming, I would recommend looking into WordPress (the .org version, not the .com). It is a sort of marriage of WYSIWYG blogging/website creation and programming. It takes care a lot of the back end stuff (including Javascript, PHP, and more), but also leaves it open for you to edit if you so desire. You probably could get away with using Wordpress as a total non-coder, but with HTML and CSS, you're already off to a great start. WordPress is super simple to learn and amazingly powerful. If you do take this route, I would suggest learning PHP as an asset because that is the language that WordPress runs off of. If you know PHP and are using WordPress, you have vast potential, not to mention that speedy blogging is a snap. If you don't feel the need to have whipped everything up from scratch and want to work faster, give WP & PHP a try. They'll take you a long ways.
I've been asked to help a friend's company to bring up a web application. I have very limited time and I reluctantly accepted the request, at one condition. As most of the logic goes on in the back-end, I suggested that I would finish the complete back-end only, allowing a front-end developer to simply interface with my backend.
I plan to do the back-end in Java EE or Python (with Pylons). It does not really matter at this point. I plan to have my back-end completely ready and unit-tested, so that my input will hardly be needed after my work is done.
I know they have a PHP programmer, but as far as I could tell he is a real rookie. I want him to basically interface with my backend's services in the easiest possible way, with no way of him "stuffing" it up. It's basically a CRUD-only application.
I could implement the backend as accessible through a webservice such as XML-RPC or SOAP. Even a RESTful API could be possible.
However, my main objective is to make something that complete "noob" PHP programmer can easily interface with without getting confused. Preferably I do not even want to talk to him because I generally have an extremely busy schedule, and doing "support calls" is not something I am willing to do. Which approach should I choose? I would welcome any suggestions and inputs!
I would personally choose a REST API, probably with a JSON response. SOAP and XML can be a bit heavy-handed for simple services, and even the most novice web developer understands the concept of accessing a basic URL, even if they don't grok the overall concept of REST. There are myriads of ways to work with URLs in PHP, so I'm sure they'd be able to come up with something, even if it was a hack job instead of a nice client package.
I would also likely choose JSON encoding and decoding, as it's generally fairly straightforward, while XML parsing can be a bit more daunting.
I would also write up at least some basic documentation on the service, no matter what formats you choose. Otherwise there's no way you will escape support calls. Your target consumer must have a reference of the remote actions available to him, or a method to discover those actions. It would probably take you 10 minutes to whip up some example code when it's ready, and those 10 minutes could save you a lot of emailing.
Definitly go with a rest-like implementation, and return query string formatted output.
Just remember that php will turn array like variables into an array on the php side.
Take a query string for your parameters
Input:
p1=v1&p2=v2....
Output:
output1=var1&output[0]=var2;output[2]=var3
Accessing this in php is then a simple as
<?
$request['myparam1'] = param;
...
$webService ="http://path.to.service?".http_build_query($request);
parse_str(file_get_contents($webService),$response);
// response is now an array with you response parameters in it
// $response['responseParam1'], reponse['responseParam1'] etc
?>
parse_str
http_build_query
Been there, done that.
Backend in Django, frontend in PHP by a 'we do pages' contractor. i whipped up a REST-like API using JSON, provided them with a couple of 5-line PHP functions to access my service as a key-value store.
After a couple of false starts (where they tried a contrived and redirections scheme instead of using the functions i sent them), they got it and everything went smoothly after that.
I've noticed that a PHP frameworks; Zend, Cake, and Symfony; seem to either generate JavaScript or allow it to be embedded as a string into the PHP itself. Is this a good idea? From people who've used these frameworks/libraries, what has been your experience working with the Ajax and JavaScript helpers? Has it been easy to maintain? Does it cut down on development time?
No it is a bad idea,
Generated javascript usually means that the site won't even function without it (like many asp.net sites). If you want to do more complex things or want to enhance accesibility there is no other way around than clearly seperating HTML from CSS and Javascript.
Seperating Javascript also makes your code more maintainable as you do not need to have your client side frontend developers mess with your PHP code and the other way around.
The best way to use Javascript is to first let php generate your html, then at the bottom of that page include your javascript files and use functionality like onDomReady. This also doesn't force you to use a particular library just because your framework is using that as base for its generated Javascript.
This is quite a subjective question, but personally, I wouldn't want a back-end framework to do this for me. It's better to keep a clean seperation between business logic, presentation, and client-side UI behaviours for a number of reasons:
More maintainable applications.
Easier to test individual components.
Easier collaboration. Different skill-sets can work on different areas.
Should help ensure your application does not rely on JavaScript in the end users environment.
Personally, I like to write my Javascript by hand, unobtrusively so that i just have to add an extra event to document.domReady with for example the correct parameters. That little trigger function then gets the ball rolling.
Best practice of the day:
Keep frontend-code and backend code
untangled as much as you can
I would say it depends, like anything. There is certainly some value in having "smart" server side widgets. For example, a widget that "knows" how to update itself through AJAX, or a form which can handle client side, and server side validation. The latter is an example of which it would be costly and time consuming and error prone to rewrite boring validation code in the client. It doesn't require rocket-science javascript, so as long as your framework can handle it unobtrusively, I would actually advise this route.
Additionally, framework code that will handle GUI stuff also (a la ext or something similar), is also not a bad a idea.
However, anything more complicated than that, please use Javascript itself.
I personally love writing my own Javascript so I don't really want it written for me, but I don't see it as being particularly 'dangerous' or 'harmful' to have frameworks that do it for you, as long as it is properly done. My biggest problem with them is that most of them will work as long as you want the standard behavior of a feature, but as soon as you want something a little different to meet your project's needs better it takes so much work to customize it you would have been better served to do it yourself. At least that was my experience with CakePHP's javascript automation.
My experience with the Javascript and Ajax helpers in CakePHP has been very positive.
They have allowed server-side developers to prototype and build features that otherwise would require someone with real client-side experience to do, all without having worry about the quality of the javascript code they "write" and leaving the real front-end engineers free to focus on the advanced client-side features.
It's not a good idea for the PHP to generate Javascript. The only javascript I would recommend exporting is simple JSON assignments like the following:
<script type="text/javascript"><!--
var MyNamespace.info = <?php echo json_encode($info_array) ?>
// --></script>
This is the easiest way to sanitize PHP information and let it be accessible to javascript on the client. However, anything else should be written in actual JAVASCRIPT FILES that are referenced with tags at the head of the document. The only other appearance of Javascript from server-side files, that I would say is alright, is stuff placed into "onclick" and other such attributes.
The rationale for this is that the Javascript should be written and maintained by front-end people who know Javascript, and the site should be able to work (at least partially) without javascript. There is no reason to generate spaghetti Javascript inline.
Check out my PHP framework, PHP On Pie (http://phponpie.com) for an example of how to implement this properly. It keeps the JS and PHP separate, except when exporting JSON as shown above. However it also provides conventions for easy interoperation between the client and server via AJAX.
I believe you should keep languages apart. Even though they can complement each other. That way you can pick the implementation of said language and create a mix that fits you perfect.
I think there is definitely a place for generated javascript. (1)
The number one reason for generated javascript is ease of maintenance. Any dependencies are explicitly encoded and configured from the framework (PHP, ruby, scala, python) itself. For instance if you move your assets or change the upload directory, just update the configuration and watch things Just Work.
Need client side input validation to take some load off your server? (2) Let the framework generate correct validation code derived directly from your data model for you. With generated, javascripted population your framework can serve pre-rendered, static HTML forms from the cache. This could be a huge win if your forms contain lots of selects and options.
1) Assuming that the client has decided that it's OK for the site to depend (more or less) on javascript, with all the caveats that entails. Graceful degradation may or may not be possible or desirable.
2) You need server side side validation too, but you knew that, right?