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?
Related
This is just a question as to find out what and how people do this, but
Say a user adds something to a list, when it's done, it runs the ajax below and updates the .user-stream-list
$.ajax({
url: "user-stream-list.php",
success: function(data){
$(".user-stream-list").html(data);
}
});
but the user-stream-list.phpresponse for example is
<li class='feed'><a href='http://www.theverge.com/rss/index.xml' data-fid='13' data-uid='15'><img class='favicon' src='https://www.google.com/s2/favicons?domain=www.theverge.com'><span class='title'>The Verge - All Posts</span><span class='options'><span class='addcat' data-fid='13'>+</span><span class='delete'>×</span></span></a></li>
Would this be acceptable in web development? Or should I really be passing it through as json and sort it into html afterwards?
Do what works for your particular problem. Good design finds compromise between the trade-offs. If you are on a tight deadline and you need something that works and it is easier to return HTML from PHP do it.
That said, you are generating the HTML programmatically on the server. You have same job if you pass JSON, the difference being the client generates the HTML. That is far more flexible for you, as you can generate different HTML in different contexts. Or not even HTML at all.
Designing to return a flexible data structure loosely couples your application components by affording reuse: the data structure remains agnostic to the caller's environment and the target presentation. This flexibility will serve your application well as it grows, and - in my opinion - the effort to design such an API early on is worth it.
I agree with bishop's answer, i think it depends on the architectural design of your system. If for example you want to use a js templating system, create a mobile device system, serve your data to other systems or something else that communicate with your back end then it is best to serve json from your server.
However even if you choose to prepare HTML server side using php, which is very common and acceptable as others noted in this thread, it is best to separate the entities creating the data and the ones creating the html code/template in order to be flexible and have the best of both worlds in the future.
If I understand you right you are worried if you should pass complete HTML code from the server or simple just the data. Well both approaches are good. It all depends on your needs and implementation.
For example you may want to add some inline styles to certain items in your list. You can generate that on the server side which would be much easier and send the whole HTML code. You may also want to add some microdata. Passing each of this parts separate as JSON would be unnecessary.
On the other hand you may already have premade HTML code and you only want to insert data into it. In this case passing the whole tag would be a waste of bandwidth.
There are also other factors you need to consider like: would it be faster to compile the data on server side or on the client side, do I need to save bandwidth or can I allow myself to send as long messages as I want?
In general try avoiding 2 things: sending large chunks of data and doing the same job twice.
Answers to this question could be broad, and are very opinion based, however I'll give my 2 cents.
Since you tagged the question as PHP, I assume your application is primarily PHP based for the server side code. Since all of your views will be generated by PHP, I'd keep all templating on PHP's side. Why? Maintainability and clarity. Having to chase down different sources of view generation is time consuming and misleading. IMHO it's better to keep all of the logic in on one side/language, and something like client-side JavaScript should be used for things a server side language cannot do (AJAX, transitions etc.).
This approach will allow for a smarter (IMO) view generating, its also very clear and makes it easy to alter your templates/views (remember, you should be writing code with other people in mind).
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.
My question might not be understandable enough, so let me explain the situation :
I'm working on a big ajax webApp built, server side, with PHP using CodeIgniter. This framework saperates clearly models, controllers and views. The view files are rendered in HTML and then sent to the client that does some js treatments on it (like attaching events).
This way of working seems strange to me, as it separates the view between the server side and the client side.
I was thinking about moving all the View treatments to the client part that will build dynamically its html in js. The server side will then send only raw data.
I worked this way on smaller projects, and I was really happy with the result (easily understandable, portable and reusable).
Is it a right way to implement an MVC app ? Any advices around that reflexion ?
I've done pretty much what you are describing on a fairly large data services app as an internal application. In my case I was using ExtJS for the client-side rendering/views, and was communicating to a C# WCF endpoint exposed on the web server. Essentially requests were made/submitted and responses were serialized to/from JSON. It ran very smooth, once some kinks were worked out. The original author had written a custom serializer to do direct results from their data layer directly... this leads to a lot of extra data going down the pipe. As long as you are judicious with your payload data it can be very effective.
Some caveats though...
You should probably avoid this if you expect users without javascript enabled to be able to access the site (anything involving money transactions from external users).
You will want to document your methodology as clearly as possible.
Finding developers for maintenance tasks after you have implemented your application will be very difficult. (many server-side devs are shy of, scared of, or just plain inneffective with JS skills.
For the most part it's a toss up, I find that most people at least have JS enabled, but may have other things blocked off. AJAX/XmlHttpRequest supports is nearly universal at this point.
As to templating for client-side display, there are a few options there (but that's a separate discussion).
Building JavaScript views works fine within the MVC pattern, since your view is not mixed in with your business logic or model.
However, there are a couple drawbacks to using full javascript views. Mainly it eliminates the ability for graceful degradation if the client has javascript turned off. Also, some browsers (IE) don't have a very fast javascript engine, which will make your page load more slowly. It is true that some of the view is separated between the client and the server, but it kind of makes sense when you think about it.
In most cases the HTML that you send to clients is the same for everyone (unless you are doing browser detection on the server side). However the JavaScript routines are different. If you are using a library like JQuery, this will be hidden from you, but the code that is running on each client may differ greatly. One example of this would be the XMLHttpRequest that is used by firefox/webkit etc browser and the active x control that is used by IE. Since the html portion of the content is the same for everyone it makes sense to build on the server, and since the JavaScript portion of the view may differ, it make sense that it is built on the client side.
HTH
I started using the same approach: JavaScript for the user interface layer and PHP for the database access layer. I'm using AJAX to pass all the data back and forth between the 2 layers. So far, AJAX has occasionally frozen on me, but it has been speedy enough most of the time. So I guess it'll work well enough.
(The result is that my code has gone from 90% PHP with 10% JavaScript...to 65% JavaScript with 35% PHP.)
I've also separated the code for my page views from the code for my triggered event action functions. So I like to think that I have an MVC arrangement now (even though I'm not using an off-the-shelf MVC framework like Backbone.js).
I'm not using HTML templates, though. I don't think it feels natural to have 100% separation between HTML and programming. I think simple programming loops, conditional statements, and JavaScript triggers all go nicely with HTML.
If you will think it in the way that there is the main view that creates the html/js engine and couple of ajax views with the data streams - it will be quite OK in MVC terms imo.
Is there anything more dynamic going on on the site itself? Does it do more AJAXy things, dynamically refresh parts of the site etc.? If so, it may be reasonable to have a Javascript-only site.
Since this is not how the web traditionally works though, sending HTML from the server is still the baseline. If your pages are basically static, if you want to serve older clients, an audience that may have disabled Javascript, an audience that may have accessibility problems with Javascript-only pages, alternative clients that cannot understand Javascript or search engines, you should serve HTML pages from the server. There's nothing wrong with it, it's straight forward, simple and foolproof. There are many things to consider when reinventing the wheel in Javascript on the client side. Unless you have a good use for the potential this offers (see for example the highly dynamic Facebook or Twitter pages), it may be more trouble than it's worth to your users.
It sounds like you are one step away from going from the MVC pattern to the MVVM pattern.
MVVM is ideal for complex user interfaces (which is exactly what you would be creating with all the AJAX and JavaScript and whatnot) because in this case your HTML view will be able to act as the controller via JavaScript. There is a library (warning: I've never used it but it looks promising) for this called Knockout JS.
I'm developing a web application and I'm using PHP and Javascript. Today, I'm starting to draw all the design class diagrams, but I don't know exactly how to mix both technologies.
I think that something like the following should be good:
But, really, I'm not sure if typing the .php extension in the class name is sufficiently clear, or what I need is to separate diagrams in two: one for Javascript classes and another one for PHP classes.
I'm using CodeIgniter (MVC pattern) and Javascript. Any suggestion will be really appreciated.
Thanks!
Usually, you don't want to do this. It's a problem of latency when viewing the web page in a browser. Each separate javascript file defeats caching and requires additional transfer time before a page can load. It's commonly advised to combine JS files wherever possible and practical to better take advantage of browser caching. So my first suggestion is to not arbitrarily split up your JS for architectural reasons...
Now, with that said, to answer you question in entirety, I think it depends on how you view JS. If you're looking at it form the perspective that it enhances your PHP application, then dividing it up along side your views is not bad (the above suggestion not withstanding).
However, I usually see JS as a separate application layer on top of the PHP application. The JS interacts with the PHP layer through defined APIs. So it's basically just a full blown GUI application that just so happens to use the API defined by the PHP application. So with that in mind, I usually build the JS application with its own architecture that's more dependent on itself then the PHP application. So in other words, just because a piece of the JS application interacts with PHP doesn't mean that the piece of code belongs with the PHP application.
Does that make sense?
Trying to put all your classes (even within one application - you have two: a PHP applicatoin and a JS application) on one UML diagram is pretty much a way to waste a lot of time and gain nothing.
Use UML to show dependecies within a package or a group of classes working together, but don't try to do it for a whole app.
I don't know the way you do things usually but in my projects, I tend to separate PHP and JS. First of all, its easier to develop and debug if you go that way, secondly, if you treat javascript as a second layer instead of being on the same level of programming as PHP you will get a working fallback in the case that your JS doesn't work, or the user of your web app have javascript disabled.
I tend to make everything work in PHP and later on I override some actions with javascript to get them working through ajax instead of the traditionnal way of working in old school Web.
--- Revision following first comment ---
Then, you might want to treat the PHP and the Javascript part as separates applications. The first system (PHP) generate the initial state. Upon user action the second system (JS) makes a query to the first one and wait for the answer, this way, you will setup some sort of API that will standardise your transactions.
I used to work with design information specialists and they often refer to Jesse James Garrett as a "Guru" in that field of expertise, you might want to check his site (there are premade stencils for omnigraffle, visio and few others).
Through his writing and example you might be able to find the right symbols and elements to represent your system.
Jesse James Garrett's website
I'm starting to architect a quite complex web application. The implementation is probably going to be done in PHP, though if there are impressive reasons to choose a different environment I might be convinced.
I've looked at tools like Symfony and CakePHP. The problem is that it feels like they're relatively low level for a modern Web 2.0 application. They handle the basic things like MVC and scaffolding, but not the more advanced UI elements that I'm looking for. Here are some of my requirements:
Single page architecture. With minor exceptions, there should be no page refresh. All actions are done via ajax, the way it's done in gmail, and to a lesser extent in Facebook.
Ajax layout and widget handling. Not only the application doesn't refresh the page, but the developer can specify the layout and load various widgets into different parts of the page. This is somewhat like iGoogle, but should be better integrated.
Support both on the client side and server side for AJAX widgets. It should be trivial to display the result of a select statement in an AJAX table/array like http://developer.yahoo.com/yui/datatable/. This should also apply to other widgets including
Trees
Menus
Forms
Speaking of forms, there should be easy integration with client side validation
Signup/Authentication/Authorization. Including all the housekeeping things like forgot my password, CAPTCHAs, etc.
There's more, but I think I've given enough details so that you get an idea for what I'm looking for. Basically, I'd like to engineer a modern Web 2.0 app and skip writing, testing, debugging things that most web applications need to do. And yes, I know I can take YUI or jQuery and slap it on top of one of the regular platforms, but then I'd have to write all the glue. Now if there are modules that do this, that would be interesting.
So if you say, take Symfony + modules xyz + jQuery and there's your answer, I'd be happy to hear that.
Finally, in terms of priority, I'm looking for something that's scalable, reliable, well engineered more than something that's easy to learn and deploy.
Since you are looking for all things AJAX, why not try GWT? Its not PHP I agree, but it makes writing AJAX applications easy for developers.
I agree with #Iznogood. What your looking for is not actually a framework but a talent.You can make any framework as "igoogle-ish" as possible if you know what your doing.
I suggest look for a framework with a huge and active community like, CI, Cake and Jquery. Search/ask the community for the specific things you need. Plug it in and Presto!
But I'm afraid you'll have to write some of it.
If you don't mind using Java, there is ZK:
http://www.zkoss.org/
I'd prefer using this over GWT.
In php, you might want to consider Cjax http://cjax.sourceforge.net/.
It is MVC oriented, and has a very generic API, with full support for customization, including the development of plugins (There is a full Plugin API available, including documentation, Plugins can be built in PHP and JavaScript in combination -- see uploadify and validate plugins).
It can access all JavaScript functions, Objects and proprieties, and elements properties and functions from PHP server side, with one line of code.
In Cjax,
you can execute ajax actions, inside controllers (ajax requests) - without a line of JavaScript. this allows you to fully function without refreshing the page. It also allows you to access all Js objects from PHP. A good sample that reflects this is the "recursive ajax request" see that demo. The API can be used on page load, when the page first loads, and within every single ajax request.
Do take a look at the documentation and to the 20+ demos included, and no where you will see a single line of JavaScript. It allows you to manipulate elements, containers, request ajax, submit ajax forms, creates overlays, upload files through ajax, all from the server side. Take a glace at the API Table.
It has support for both, server side ajax, and client side, (see plugins JavaScript Documentation)
It plays nice with jQuery - the validation plugin in jquery is full executable in PHP without a line of JavaScript (see http://cjax.sourceforge.net/examples/plugin_validate.php without any custom line of Jquery inside the framework, it's all plugin's work). Ajax Responses from Jquery also get processed by this framework automatically, so using Jquery's Ajax function API wise, is the same as if you were using the Framework's Plugin's JavaScript Ajax Functions.
And you would just have to take your time learning more about it, because it has quite a few more tools that I am sure you'd find useful.
Currently there are two official releases, the generic release and
there is an official release for CodeIgnater of this framework (and it is the leading ajax option for codeignater) , and works great in conjunction other PHP Frameworks and without them.
Signup/Authentication/Authorization. Including all the housekeeping
things like forgot my password, CAPTCHAs, etc.
This is something that you can build within an ajax controller, the framework itself its meant to be a generic "AJAX" framework, so if you are looking for none ajax features, you will need to build them or integrate other PHP Framework with Cjax (such as Codeignater).
I do not know if this matches all of your criteria, or if you ever will find one. However, I like the Zend Framework myself.
As for the UI and AJAX portions - the server side technology matters little, and it's more about browser-side technology and interaction mechanisms, as well as DOM manipulation.
jQuery is my favorite for that. As for the PHP back-end, I tend to develop it with my own codebase that's grown with me over the years.
But all this takes a lot of practice, knowledge, education, research, reading, and posting questions on StackOverflow.com ;)
I would recommend symfony PHP framework since it has very good support for every feature you mentioned, and it can be easily integrated with Zend Framework - as of version 2.0 coming this year it would be integrated in the package. You can easily set symfony to handle AJAX requests so that it would be perfect transparent layer handling server side.
For me, if you look at THAT heavy AJAX, I would recommend searching for some good JavaScript framework - such as Ext.JS - that would handle all client side functionalities.
For the front-end part of your app, you might want to have a look at SproutCore ( http://www.sproutcore.com/ ).
Building a Web application with SproutCore feels more like configuring components than writing code.
There is no glue code.
On the backend all you have to do is accept and emit JSON.
Depends what sort of level you're looking at. If by 'framework' you mean something like Zend or Symphony, then to be honest all the big ones are about as good as each other. They all have strong points and weak points, but none will really meet your criteria.
But your question implies you're looking for something more than that kind of framework. Maybe you're looking for a full-blown CMS platform like Drupal, Joomla or Wordpress?
In that case, again, you need to consider your needs verses the capabilities and pitfalls of each system.
Drupal, for example, has masses of modules, is very powerful, and easy to write your own modules, but isn't object-oriented and doesn't really do MVC, so if that's your bag then you may find it hard to get on with. Wordpress is much easier to get going quickly but is less flexible once you start getting deeper into it.
But again, they all have strengths and weaknesses. If one was clearly the best, it would be an easy choice. But at the end of day perhaps it's better to have several good quality options to choose from.
Have a look at Ext JS, it is pretty good. If it is a commercial project you are doing it isn't free but not too expensive either. It also has a GWT version if you prefer that.
This is only for the front end but it is not too complicated to use any backend that can emit json.
CakePHP is pretty good