21–30 of 103 posts
"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…
Groovy is used cause it has closures (java doesn't) and is simpler and easier than Scala.
A difference is that the routes, model, controller and template/renderer are in separate directories. It's a bit awkward for the simple project of the one in the video, but essential for more complicated projects.
It even includes a captcha generator, and their examples seem to be of real (though very simple) applications - as opposed to toy academic ones. I get the feeling that its developers are very familiar with the real needs and problems of actual web development.
It almost makes me want to get into web development! The only thing is that combining HTML, Groovy templating, Javascript and JQuery looks a little complex - but they're probably very straightforward for common tasks.
"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…
And that's with LAN based WS calls. I can't imaging doing that over the internet. You have a page that has 20 independent dynamic blocks, you really want to make 20 HTTP request/response calls over a 60+ ms latency connection? You really want your server cluster to have to handle 20 connections instead of one?
Maybe for a simple and/or low traffic site, but for a moderately complex website/webapp, you're better off serving out a single page.
"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…
A web service isn't a web application?
Java has real lightweight threads, so what's the advantage of "shared nothing" here? Extra memory usage and less speed?
They are faster than forking processes though, but Java applications (because they share state between threads) are less scalable.
What is the virtue of developing a web application in Java instead of a scripting language like Jython (aside from execution speed obviously)?
Well, at my day job, not having to throw out 10 years worth of legacy code would be considered "a bit of a plus". We also have 1,200 employees and precisely two engineers who have ever done a Rails application more complicated than the 15-minute-blog demo. I think we have one guy who coded a Python app once. Our favorite contractors and outsourcing providers also have (comparatively speaking) deep skills in Java and…
When I worked at ITA Software which writes much of their stuff in Lisp (not the web stuff though), there was often worry that it meant new programmers would have to learn the language and so wouldn't be productive at first. But learning the code base takes a lot longer than learning the language, at least enough of the language to get significant stuff done.
If you have 10 years worth of legacy code written by 12,000 employees, I assume you're in the same boat.
Java has real lightweight threads, so what's the advantage of "shared nothing" here? Extra memory usage and less speed?
It seems to refer to this: > "Play is designed to operate in a ‘share nothing’ architecture. The idea is to keep the application completely stateless. By doing this you will allow your application to run on as many server nodes as needed at the same time. >What are the common traps you should avoid to keep the model stateless? Do not store any object on the Java heap for multiple requests" If that's all they're talki…
Do you write/read all that into the db/memcached for each request?
"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…
In my experience breaking everything down into a bunch of uncoupled services, ala SOA, adds a significant amount of performance overhead making all these web service calls to build up a semi-complex page. Performing all the logic within a single process/JVM is MUCH more efficient. And that's with LAN based WS calls. I can't imaging doing that over the internet. You have a page that has 20 independent dynamic blocks,…
As well another common mistake I see is services calling services to build a composite service. If at all possible services should be the facade into the system with logic wrapped up in a jar, DLL, etc. All services if possible should rely on said library and not rely on loosely coupled services for composting, inter-system communication is different than disparate system communication.