61–70 of 103 posts
Earlier quoted context omitted.
Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.
PHP has session variables to put state objects into which are persisted between requests. Right?
Earlier quoted context omitted.
Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.
PHP has session variables to put state objects into which are persisted between requests. Right?
Earlier quoted context omitted.
Yes. PHP does the same thing. Actually, most frameworks do that; very few keep state within the application server between requests. Statelessness, in that respect, improves scalability.
...while reducing perfomance...
Nice collection of web tools. Especially ready made libraries for validation, captcha etc and a built-in template engine. But I am not convinced with 'on the fly' compilation because most editors already do a better job there and refreshing the web page to look for compilation errors does not look productive.
Earlier quoted context omitted.
If you are a one man show maybe, but if you are a team it is far more maintainable because each concern is clearly delineated. JSP is not easier for a HTML designer nor is ASP or PHP it is an amalgamation of languages composites into a document. It is only easier for a code developer and that it the crux. Usually a company starts out as a one man shop with a code developer and then graduates to a team. Having to teac…
I typically work with largish teams on very large websites (cingular.com, jcrew.com, ulta.com, pcavote.com, etc...). With good frameworks most JSPs are very close to normal HTML and we actually usually have: designers/UX folks who provide PS docs/images/etc..., front end devs (JSP/JS/AJAX impl folks) who take those and make real working JSP pages out of them, and back-end devs who write the Java backing components. Y…
As well, I am not proposing anything any more non standard than say JSP or Struts and Tiles. Their are plenty of AJAX frameworks that provide all of the bolts to erect this style of system without building and in-house system. Further, JSP is only standard for web development it does not take into account the variety of UI possibilities and that is the point of the matter. The UI much like the database is only a portion of an overall system. Just as you would not write you data-storage in your logic tier you should not be coupling the UI tier to your business logic.
There are plenty of sites that use this development methodology. Pick almost any mature "Web 2.0" site and they will be somewhere along in this evolution. Google, Amazon, Yahoo et. al.
I apologize in advance for being vague, but I would prefer to not loose my anonymity on this site and referencing my work would do so.
Earlier quoted context omitted.
If you are a one man show maybe, but if you are a team it is far more maintainable because each concern is clearly delineated. JSP is not easier for a HTML designer nor is ASP or PHP it is an amalgamation of languages composites into a document. It is only easier for a code developer and that it the crux. Usually a company starts out as a one man shop with a code developer and then graduates to a team. Having to teac…
I typically work with largish teams on very large websites (cingular.com, jcrew.com, ulta.com, pcavote.com, etc...). With good frameworks most JSPs are very close to normal HTML and we actually usually have: designers/UX folks who provide PS docs/images/etc..., front end devs (JSP/JS/AJAX impl folks) who take those and make real working JSP pages out of them, and back-end devs who write the Java backing components. Y…
Sorry I missed hitting on this one. I do not expect a designer to be doing service calls that is the point. You can write a JavaScript controller that grabs reference to any UI components that it needs, you do not write JavaScript in the HTML, the designer is then working in pure HTML CSS. The JavaScript developer is the one orchestrating the work-flow logic in a code-behind manner. Each person has their domain and once a developer feels comfortable they can graduate to the next domain. Just as I don't expect a HTML designer to have to know Java constructs I don't expect a Objective-C developer to know HTML constructs. It's not about constraining people, it's about re-usability of reusable components and isolating non-reusable components.
Hmm, too much code in the template library, too much magic in general. I do like the general packacking, the automatic compilation and the snazzy error and testing interfaces. Seems a bit hard to change from their Groovy template system to something like StringTemplate, though.
Although I think that the built-in template system is very very nice, it would be really easy to write a play module that provide any template engine you want.
I'll have to dive deeper into play to see how much more I would have to do in the Controller part to prepare the output for the template...
Earlier quoted context omitted.
PHP has session variables to put state objects into which are persisted between requests. Right?
Yes, but most people who make serious use of them hook up a custom session handler that writes session information out to the database (the default implementation that ships with PHP uses the file system). Sessions that are stored in memory by the application server instantly prevent you from load balancing requests across multiple servers and hence kill your scalability - unless you implement sticky sessions which a…
"The Play framework makes it easier to build Web applications with Java" Maybe you should not be building web applications with Java or C# or . Maybe you should be building web services with these languages and using AJAX, a client side toolkit, Javscript, HTML and CSS to build a UI that communicates with said services. Maybe this decouples your UI implementation from your business logic implementation so you can go…
The "way we've always done it" in my brain does not like the thought of putting all the client stuff in, well, the client. I'd like to hear more about this style of development. Do you have examples of this being done, postmortems, blogs espousing this, more info, etc?
Earlier quoted context omitted.
Because this is a premature optimization. I've seen companies falling at the other extreme ... making the interface "totally" decoupled, so that they could replace the UI anytime they wanted. That's why monstrosities like XSLT appeared. But I haven't seen any example of a good application yet that does this successfully, because whether you like it or not, the web UI will require backend logic that your iPhone app do…
No XSLT was an attempt to make the UI generic, either you accept that UI are a custom tailored to be optimized for the platform or you accept the dumb terminal philosophy where you try to generalize the UI to adapt to all platforms. The fact remains that human preference is for tailored UI and not until AJAX took hold was the desktops dominance as a platform threatened. Time and time again, tailored UI's are preferre…
I know that they are using lots of web services, but the assembly is still mostly done on their servers (not in the browser), and you're talking about something else (or have I understood you wrong?).
I've seen a talk from an Amazon fellow. They are using web services for parallel processing ... their frontend servers are sending asynchronous requests to those services, which is a huge win.
But in a browser, for an Ajax frontend that happens to periodically request updates, one thing that happens is that the number of requests made from a single client is a lot larger. Surely it doesn't reload all the static files, but those are non-issues even for a reasonable high-traffic website ... just put something like Varnish to serve them and make sure they have expiration headers in the future.
My company did consultancy work in matters of scalability for http://www.erepublik.com/ and after we placed a Varnish in front (that also functions as a load-balancer for Apache servers) it could handle thousands of concurrent requests to static files. And their biggest problem was definitely not the load on their Apache servers (it was MySql).
And this is mostly what I was thinking about.