Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Play framework for Java - a radical rethink of Java web app development?

playframework.org

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Play framework for Java - a radical rethink of Java web app development?

#81

Post by kls »

jshen wrote: post #77
kls wrote: post #41

Earlier quoted context omitted.

http://googlewebmastercentral.blogspot.com/2009/10/proposal-... Most people are already doing it.

Most people are doing what exactly? I think there are two important points here. First, that is at best a beta level proposal, and I wouldn't bet the well being of my family on it. I'll be very happy when it stabilizes, but I'd stick to outputting plain html for the engines. Second, this sounds far more complicated than simply outputting html from your web app. This thread is about decoupling UI from the backend for…

If you are doing a web client, that is dynamic, correctly, you should already be reflecting a distinct UI by a URL fragment. having a web proxy run on a seperate box than you production server and routing request for a search bot is not that difficult. There is no custom logic involved you are just proxing through a headless browser. It's not beta it is just that Google is trying to standerdize the practice. Where you get in trouble is if your proxy is giving something different to the bot than the end user is getting. It really is a simple as if a request comes from a bot agent service it from the proxy box, it's a router rule.

Re: Play framework for Java - a radical rethink of Java web app development?

#82

Post by fizx »

fizx wrote: post #48
cschneid wrote: post #22

Side question: is there a CPAN or Gems repository for similar open-source Java libraries? I know that Apache has lots of Java libs, but beyond that, I have no idea where to look.

Look into Maven.

If you install Maven support for Eclipse, you get a Maven search engine:

http://docs.codehaus.org/display/M2ECLIPSE/Quick+Search

Here's a big list of mavenized projects:

http://repo1.maven.org/maven2/

Re: Play framework for Java - a radical rethink of Java web app development?

#83

Post by beamso »

I just watched the screencast. I'm sure that the static methods on the controllers and the public attributes will drive purists up the wall, but the speed of development appears excellent. Looks most definitely faster than running glassfish in debug mode and reloading classes/redeploying all the time.

Re: Play framework for Java - a radical rethink of Java web app development?

#84

Post by brianm »

strlen wrote: post #78
cschneid wrote: post #72

Earlier quoted context omitted.

From what I understand, Maven is a build dependency manager, but not a package manager the way CPAN is. I'm looking for a central place to find packages that do everything. "ohh you need to interact with AWS, here's the package" type stuff.

There's a bunch of maven repositories (usually googling '+"library name" +"maven" +"pom.xml" works), but I haven't yet found anything like CPAN's search website. mvn:create can bring up an interface that's very smilar to CPAN's shell. What needs to be done is a shell that allows functionality such as "search /amazon/" or "search guice, jersey" or "info google-collections". Scala would be a great choice to make sort o…

best way to find maven repo info for open source java stuff, that I know of, is with http://repository.sonatype.org/

Re: Play framework for Java - a radical rethink of Java web app development?

#85

Post by jshen »

kls wrote: post #81
jshen wrote: post #77

Earlier quoted context omitted.

Most people are doing what exactly? I think there are two important points here. First, that is at best a beta level proposal, and I wouldn't bet the well being of my family on it. I'll be very happy when it stabilizes, but I'd stick to outputting plain html for the engines. Second, this sounds far more complicated than simply outputting html from your web app. This thread is about decoupling UI from the backend for…

If you are doing a web client, that is dynamic, correctly, you should already be reflecting a distinct UI by a URL fragment. having a web proxy run on a seperate box than you production server and routing request for a search bot is not that difficult. There is no custom logic involved you are just proxing through a headless browser. It's not beta it is just that Google is trying to standerdize the practice. Where yo…

you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.

Re: Play framework for Java - a radical rethink of Java web app development?

#87

Post by kls »

jshen wrote: post #85
kls wrote: post #81

Earlier quoted context omitted.

If you are doing a web client, that is dynamic, correctly, you should already be reflecting a distinct UI by a URL fragment. having a web proxy run on a seperate box than you production server and routing request for a search bot is not that difficult. There is no custom logic involved you are just proxing through a headless browser. It's not beta it is just that Google is trying to standerdize the practice. Where yo…

you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.

Not if you are supporting multipal clients and want to seperate out your concerns. The point is that the UI should be decoupled from your core application logic. The advantages that brings, negates the few hours one will spend setting up an out of the box server and proxy to support SEO. There are many web apps that don't even have SEO as a problem domain.

Re: Play framework for Java - a radical rethink of Java web app development?

#88

Post by hernan7 »

kls wrote: post #76
hernan7 wrote: post #74

Earlier quoted context omitted.

Hi, which client-side toolkits would you recommend? I haven't programmed JS in a while...

The majority prefer JQuery, I will try to not impose my bias on you but to answer you question as best I can, I prefer Dojo. Out off all of them, I would say try both of these and see which one is for you. Given my preference for a decoupled UI, Dojo provides the complete box, but JQuery is far easier to learn. Their is an elegance to both so I urge you to do the due diligence and at least spend a week working with b…

Thanks, will do.

Re: Play framework for Java - a radical rethink of Java web app development?

#89

Post by simonw »

modoc wrote: post #68
simonw wrote: post #62

Earlier quoted context omitted.

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…

Interesting. I mostly build J2EE apps and sticky sessions support is built in. Complex apps require a fair bit of session state (user profile, shopping cart, custom catalog, breadcrumbs, user promos, etc...) in general and the idea of having to persist and reload that data over a network (db or memcached) for each request would absolutely kill page response times. I guess it depends on how heavy the session data is f…

I'm quite surprised - I've never even considered building a stateful web app that doesn't talk to a database or caching layer at all for most requests. It's fascinating to me how different the approaches taken in the Java world are from the LAMP world I'm accustomed to.

Re: Play framework for Java - a radical rethink of Java web app development?

#90

Post by jshen »

kls wrote: post #87
jshen wrote: post #85

Earlier quoted context omitted.

you have to setup and maintain this separate proxy and headless browser. This is surely more complicated than outputting html from your web app.

Not if you are supporting multipal clients and want to seperate out your concerns. The point is that the UI should be decoupled from your core application logic. The advantages that brings, negates the few hours one will spend setting up an out of the box server and proxy to support SEO. There are many web apps that don't even have SEO as a problem domain.

You are arguing that this approach is better, therefor it isn't more complicated. You realize that isn't valid logic, right?
Post reply on HN