Great framework but hard to use in a business environment

[orefalo]

I really like Play. It's simple, ez to install, fast...etc
In fact its biggest strength also happens to be its main short coming:
the lack of J2EE compliance. Let me explain.

By getting out of the standard J2EE API model, play comes with an
elegant way to build applications. The issue comes when you try to
integrate with J2EE technology. Ever though about using a JSF/JSF2
widget in your template (primefaces, richfaces) ? Want to use EJB for
clustering ? Want to use the great packtag taglib (http://
www.galan.de/projects/packtag) ?

Well it appears that you will need to spend hours of development
rewriting most of these great tools. Hard to convince an organization
to switch to a great framework with so many side effects, right ?


I was wondering if I was completely mislead or if these is actually a
way to get an adaptor layer that we could use in our apps.

Kind regards,
Olivier

[Julien Tournay]

Hi,

Well, yes when you're using Play!, you're not using JSF, so you can't use JSF components.

That's true with any fwk. If you're using Wicket, you can't use JSF components.

If you enjoy Richfaces, then you should use JSF, not Play, not Spring MVC, not Wicket, not Tapestry...

Play! is about getting things done, in a HTTP compliant way, not in a JEE compliant way.

It's not a java framework, it's a web framework based on Java.

In my experience, it takes a lot more code (and time) to do a web app in JSF than in Play!, even using high level components,

(and btw you'll have to learn how to use those components, which takes hours too), and you'll probably end up with an app that sucks.

jto.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

--
Real Programmers don't need comments-- the code is obvious.

[Pascal Voitot Dev]

I've heard the same kind of arguments 4 or 5 years ago when I was trying to explain the advantages of Spring (the one 4 years ago, not the one now) against JEE, trying to tell them it was the natural and logical evolution and not something antagonist.

Just think what you can do without JEE and JSF trapping your mind behind the "industrial & standard" argument (which is too often a false argument).
When you build web interfaces, you need to feel free in the choice of the tools, to be quick and efficient and to build in an iterative way: JEE is not really the best expression of this.

Anyway, I can understand the need to interface to existing JEE servers and infrastructure. But what prevents you from presenting your beans as real services? There are so many ways in Java to talk to a service from different layers and to cluster all of this stuff.

If they tell you that they already invested money on JSF and don't want to invest in a new techno, I can understand that. But they may change their mind in a few months or years as it always happens! Meanwhile go on making tools such as Play! better and more efficient and people will come to it naturally when they feel it's mature for their business!

But you're right asking the kind of questions ;)
Just give Play! a chance and make your mind by yourself!

regards
Pascal

On Fri, Nov 5, 2010 at 9:47 PM, orefalo <ore...@yahoo.com> wrote:

[orefalo]

I see lots of good arguments in your answer, but also misleading
information.

Spring and Struts, the two major MVC frameworks today DO support JSF
(which is a framework by itself). My point is not too much about the
framework itself... it's more about the library of components. JSF
components are much easier to integrate in an app, than a typical
jQuery UI (or alike) library. They minimize the need for javascript
resources and overall speedup development. -> Please consider this
sentence in its appropriate context: "Enterprise environment"

I guess my point is that there is no doubt Play is faster and easier
to code, but if it takes a complete rewrite to rebuild the app, plus
the effort to get jQuery UI/YUI in the mix, it's worthless. Way too
much time and $$$.

For Play to succeed, it will take an integration layer to easy
migration from "retarded" technologies.

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

[orefalo]

Please define "presenting your beans as real services"... I don't get
it.

Let me give you a real life example, I have an application built over
a period of 5 years by 30 developers: this should give you an idea
about its complexity. It uses Spring, Hibernate and JSF (mostly ui
components). How do I convert it to Play without breaking the bank ?

My point is.. there is no transition path... it requires a rewrite.


On Nov 5, 5:57 pm, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

[João Pereira]

I work for a BIG company, building a very BIG system with BIG team with 500+ developers around the world and we're using JSF with EJBs and all that stuff... It's a pain working with JSF and all that stuff, it's slowing us down a lot. Maybe if we're using Play! and other not-so-enterprise-technologies there wasn't the need of such a big team of developers.... Probably at this point of development it will be very expensive, in the short term, to switch the web layer to Play!, but from the little experience I have from Play! it would pay off in the long run. Of course this is my opinion based on my own reality and making my own assumptions on my architecture and I don't know about yours. Enterprise has the tendency to complicate simple things just because they have to have BIG things, though it doesn't mean they have functional, productive and quality software... 

I also programmed in RoR and loved the simplicity and productivity. Play! is great because it has the simplicity and productivity from RoR and the power of Java. 

 

Probably you have to make some more in depth analysis of costs and benefits of switching to Play! and then decide based on that.

JP

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[Pascal Voitot Dev]

just a precision: I'm not a Play! developer and I'm a user and supporter of Play!
So, I'm not trying to defend my own stuff here... I just use Play! because it's the best web solution I found respecting those 2 points: 1)Java world, 2)lightweight&efficient

On Sat, Nov 6, 2010 at 12:29 AM, orefalo <ore...@yahoo.com> wrote:

I see lots of good arguments in your answer, but also misleading
information.

Spring and Struts, the two major MVC frameworks today DO support JSF
(which is a framework by itself). My point is not too much about the
framework itself... it's more about the library of components. JSF
components are much easier to integrate in an app, than a typical
jQuery UI (or alike) library. They minimize the need for javascript
resources and overall speedup development. -> Please consider this
sentence in its appropriate context: "Enterprise environment"

JSF stuff is not easy to integrate... Nobody can say that... even frameworks such as Seam that should help you are so complicated that it's a great effort doing even an helloworld... I don't say it's completely bad, I say it's far too much complicated in the great majority of the cases and new tools are much more efficient nowadays...
The only advantage of JSF is the standard and a standard is meant to last a few years. But it is also meant to change when something new appears but generally it takes lots of time...
JSF has become mature 4 years after Struts (too late?) and even now lots of people are reluctant using it because they don't really see what it brings more than Struts. I know lots of people in the industry that still use and love Struts because it works and they have too heavy inheritance with it so why should they spend time to change for JSF?
But if your solution becomes obsolete and you need to rebuild it (not just adding a new page or a new DAO), you might not use again Struts and JSF, you should think about something a bit more efficient technically speaking (if it exists and I think it exists). If people had not gone this way with Hibernate and Spring (the IOC container only:)), we would still be using EJB with the infamous interfaces implementations that require deploying your helloworld in a server and after 30seconds of crazy computation you finally see "hello world" on you screen.

 

I guess my point is that there is no doubt Play is faster and easier
to code, but if it takes a complete rewrite to rebuild the app, plus
the effort to get jQuery UI/YUI in the mix, it's worthless. Way too
much time and $$$.

the $$$ issue is the Great argument and I hear it every day! It is often true and reasonable but sometimes it's worth thinking a bit. Evaluate how much you need to manage your technical inheritance with old technologies that require lots of effort for anything. Then you compare how much it would cost just to keep some crucial parts of your solution such as business parts and rewrite the surrounding parts (such as Web layers) with efficient technologies. Then you also evaluate the tiredness of your technical teams using those technologies after years of effort and estimate the pleasure, the gain of inspiration and productivity you would get by bringing a breath of air in their everyday life. I know this argument is not an argument a manager can accept but it is a fact until we are replaced by robots for coding! After that, some people will take courage in both hands and will be crazy enough to try a new technology just because they believe if it can do better... maybe Play!, maybe something else...
 
Concerning the JQuery/YUI aspect, I agree it's not so easier yet to write clean JS applications... Anyway, I don't think it's much more complicated than writing JSF applications and the result is so far better... You can use GWT also or ExtJS/SmartClient to reassure people etc...
It depends on your needs and on your projects...

For Play to succeed, it will take an integration layer to easy
migration from "retarded" technologies.

I agree with you... But Play! doesn't have to be compliant with everything... Some technologies are not compatible with its approach and some are not needed also... People will express their needs while using the framework IMO!
 

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[Pascal Voitot Dev]

On Sat, Nov 6, 2010 at 12:33 AM, orefalo <ore...@yahoo.com> wrote:

Please define "presenting your beans as real services"... I don't get
it.

Think SOA (or even ESB if you're crazy) (for buzzwords that can bring more troubles than advantages if you don't use them reasonably :D)... You isolate your business layers and you expose your services using the techno you like... REST, WS, JMS, mail, FTP, traveling pigeons etc... Then from your web layer, you get the information you require from those services and you present it.

Have a look at Spring Surf used intensively in Alfresco... Alfresco exposes everything as Rest services... and the web layer is JS on server side that calls those REST services and formats information using templating... I'm not sure the realization is the best solution (a bit too heavy to do simple things) but the idea is interesting!


 

Let me give you a real life example, I have an application built over
a period of 5 years by 30 developers: this should give you an idea
about its complexity. It uses Spring, Hibernate and JSF (mostly ui
components). How do I convert it to Play without breaking the bank ?

My point is.. there is no transition path... it requires a rewrite.

 

Ok this is not easy :)
But your Spring can be integrated with Play! directly... hibernate also... the only thing you have to rewrite is the web layer... and you're going to tell me that your application is just a web application and 90% of the code is JSF... ok, ok :)... anyway, just take a few minutes thinking about using Play!... maybe in your future projects or just for having fun at home ;D

Pascal
 

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[Federico Tolomei]

I think I'm not the only one who rant about the lack of SOAP support. My2c.

>> > > play-framewor...@googlegroups.com<play-framework%2Bunsu...@googlegroups.com>

>> <play-framework%2Bunsubscribe@go oglegroups.com>
>> > > .
>> > > For more options, visit this group at
>> > >http://groups.google.com/group/play-framework?hl=en.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "play-framework" group.
>> To post to this group, send email to play-fr...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> play-framewor...@googlegroups.com<play-framework%2Bunsu...@googlegroups.com>

>> .
>> For more options, visit this group at
>> http://groups.google.com/group/play-framework?hl=en.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.
>
>

--
http://lupulu.li
skype: effe.to

[Guillaume Bort]

> My point is.. there is no transition path... it requires a rewrite.

There is always a transition path. Typically if your business layer
already exist you can always reuse it from a new web application
written with Play. I've done that several times, including with
business tiers running on old CICS mainframes.

On Sat, Nov 6, 2010 at 12:33 AM, orefalo <ore...@yahoo.com> wrote:

> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,
write guillau...@gmail.com

[Pascal Voitot Dev]

On Sat, Nov 6, 2010 at 12:28 PM, Guillaume Bort <guillau...@gmail.com> wrote:

> My point is.. there is no transition path... it requires a rewrite.

There is always a transition path. Typically if your business layer
already exist you can always reuse it from a new web application
written with Play. I've done that several times, including with
business tiers running on old CICS mainframes.

fully agree even if I don't have your experience ;)
 

[Julien Tournay]

Using JSF for the presentation layer in Play! you be a nonsense. Many features of play! rely on it's stateless model.

JSF is completely stateful. Mixin the 2 would be a challenge, and would just give you a monster that have the drawbacks of JSF AND the drawbacks of Play!

"JSF components are much easier to integrate in an app, than a typical jQuery UI (or alike) library."

It's just your opinion. I personally think that JSF components are awful. You also don't need Jquery UI or any JS components most of the time.

"They minimize the need for javascript

resources and overall speedup development. -> Please consider this
sentence in its appropriate context: "Enterprise environment"

Just because you don't need to write JS doesn't mean you'll get things done faster or better. Javascript is a pretty good, and simple language, and there's awesome libraries like jQuery that will handle the "cross-browser" problem for you.

Concerning the "Enterprise Env, well most of the time, from the features point of view "Enterprise" apps are *REALLY* simple. I've never seen something more trivial than a bank web app. It's always just simple html pages, with forms and validation. The complexity is not the presentation layer, it's the business, handled by cobol code. So it doesn't change anything to use Play!, JSF or anything else, as soon as you can communicate with mainframes in some way.

jto.

[heri16]

Actually, I feel that this subject should be treated more carefully.
We should approach it from both a technical aspect and a CIO/
managerial aspect.

Indeed enterprise people want J2EE stuff, as it has Sun's/Oracles
backing.
That's the reason why I certified myself in J2EE, and so would many
others.

Indeed Play! is beautiful in it's own aspect, but openness and variety
always breeds a better ecosystem.
It's like arguing whether JSP or Scala or some other DSL would make a
better templating system.
Just by figuring out the many ways Play! might run on google apps
engine, one would already see certain Non-Relational abstraction vs
Direct-adapter models and paradigms.

From my experience of mixing in Java and JRuby, and also Spring MVC
and Rails, I don't see why this (J2EE interoperability) cannot be
done.
What is required is careful planning on how things should be
architected.
Even today, the play-engine can run behind Tomcat, and thus can hook
certain servlet states & requests.

Of course, there won't be full JSF-support, but then again, to use JSF
is to give up control over certain things.
Just compare the old ASP.NET with the new ASP.NET MVC. Microsoft did a
beautiful job (this time) mixing-in the 2 styles (web-components/forms
vs the new stateless MVC paradigm).
Some pages run on web-forms, while others run on abstracted jquery-
components, but yet they can share objects and state models.

When some speak about stateless vs stateful, they tend to miss out on
the underlying philosophy that all web frameworks run on stateless
http, and thus have to build some form state on top of it. Some do it
in pre-defined ways you cannot control, while others (like Stripes
Framework) allow you to build your own state model from POJOs. The
Netty Engine itself which powers Play! is popular and famous, because
it gives full flexibility of how to think about and handle state. I
discovered this while looking under the hood while trying to create
Websocket support in Play! The interesting thing is that Websockets
are both stateless and stateful.

So in conclusion, supporting JavaBeans and JSF outright in Play! would
be difficult and counter-productive, but it does not mean that letting
them interoperate would not be possible, because all of them still use
Java after all. Because this is a real business concern in the
enterprise world, I suggest we write a guide on how best to structure
things out to achieve something workable.

For example, from my understanding of the IT enterprise world, apps
are written under the umbrella of a change-project. This single app is
written as a response to fulfill a business-user's new requirement.
The specifications are drafted, and a team of technical staff is
assembled to work on new-code development, while another team is on
standby to offer "surfaces/adaptors/protocols" to existing systems/
databases. Most likely the programmers in the project team do not
completely know the inner workings or structure of all the external/
existing data sources in the enterprise. In many bigger enterprises,
new projects might even run on new programming languages (or switch
between two: .NET or Java, or an ancient language in banks). The code
is developed through iterations until test users in the relevant
departments are satisfied. Only thereafter comes the "enterprise-
integration" part.

In this sense, Play! could be used for the rapid prototyping stage, or
the experimental web-facing component. This is similar to how some IT
startups have managed to promote & sell Ruby-on-Rails to the
enterprise. They can do it 2 to 5 times faster than the internal
staff, because they are not bogged down by old paradigms. They simply
export out data, run it on their new app, and present to the bosses.
The benefits of Play! over Ruby-on-Rails in this sense would be you
could reuse a LOT of code, when redeveloping the real thing. Either
java methods/functions can be copied over wholesale, or the whole
Play! app itself could read & manipulate data from backend middlewares/
databases.

I think the agility of Play! would genuinely surprise you, in a way
that the benefits would exceed the initial learning curve.
Use it on small internal-use-only projects (with clear inbound &
outbound pathways of data), where speed of development is a bigger
concern, rather than just "doing things right" or "by the lifecycle
rulebook".
I believe this it will in turn provide greater satisfaction to your
business-users (who daily scream down your neck), because you can now
delight them with these new "mini-apps" (built rapidly on Play!).

Heri

> pascal.voitot....@gmail.com> wrote:

>
> > On Sat, Nov 6, 2010 at 12:28 PM, Guillaume Bort <guillaume.b...@gmail.com>wrote:
>
> >> > My point is.. there is no transition path... it requires a rewrite.
>
> >> There is always a transition path. Typically if your business layer
> >> already exist you can always reuse it from a new web application
> >> written with Play. I've done that several times, including with
> >> business tiers running on old CICS mainframes.
>
> > fully agree even if I don't have your experience ;)
>

> >> Guillaume Bort,http://guillaume.bort.fr

>
> >> For anything work-related, use g...@zenexity.fr; for everything else,

> >> write guillaume.b...@gmail.com

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "play-framework" group.
> >> To post to this group, send email to play-fr...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/play-framework?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-fr...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/play-framework?hl=en.
>
> --

[Pascal Voitot Dev]

On Sat, Nov 6, 2010 at 6:08 PM, heri16 <her...@gmail.com> wrote:

Actually, I feel that this subject should be treated more carefully.
We should approach it from both a technical aspect and a CIO/
managerial aspect.

yes both aspects, not only one and not only the second one that is often the only one in action :D
 

Indeed enterprise people want J2EE stuff, as it has Sun's/Oracles
backing.
That's the reason why I certified myself in J2EE, and so would many
others.

Oracle backing is great for CIO but from the pure technical point of view, it is a big big question mark...
Where is going Java now and how???... the incoming fight about patents in the mobile world will be very instructive and will give some ideas about their intents!

Indeed Play! is beautiful in it's own aspect, but openness and variety
always breeds a better ecosystem.
It's like arguing whether JSP or Scala or some other DSL would make a
better templating system.
Just by figuring out the many ways Play! might run on google apps
engine, one would already see certain Non-Relational abstraction vs
Direct-adapter models and paradigms.

From my experience of mixing in Java and JRuby, and also Spring MVC
and Rails, I don't see why this (J2EE interoperability) cannot be
done.
What is required is careful planning on how things should be
architected.
Even today, the play-engine can run behind Tomcat, and thus can hook
certain servlet states & requests.

Of course, there won't be full JSF-support, but then again, to use JSF
is to give up control over certain things.
Just compare the old ASP.NET with the new ASP.NET MVC. Microsoft did a
beautiful job (this time) mixing-in the 2 styles (web-components/forms
vs the new stateless MVC paradigm).
Some pages run on web-forms, while others run on abstracted jquery-
components, but yet they can share objects and state models.

 

My question is "Is there a real case where stateful objects in the only and best solution in a web model?"... Each time I thought it would help me, It brought some many counter-effects that I'm no more sure it's useful somewhere :)
 

and many mini-apps become a bigger app ;)... but please don't reproduce the portlet horror :D
 

Heri

great comments Heri ;)
thks

Pascal
 

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[orefalo]

First thank you all for your feedback.

Ever if my question didn't get a firm answer it certainly helped me
understand why Play is not for everybody. Not sure if it's technically
possible to do, but building an transition layer to help J2EE projects
move to Play would certainly help sell the concepts.

To the ones comparing JSF with Play, I think these two are not playing
in the same area. JSF is competing with GWT.
To the ones saying that JSF components are not powerful, I would
recommend looking at primefaces http://www.primefaces.org/
To the ones saying that JSF is sluggish to develop with - I can build
a JSF 2 ajax table in 2 seconds with a simple tag - correct me if I am
wrong, but it would take more much more effort to build it with play
+jquery
To the one stating that jQuery and JS are great, I would say: not
every developer is as bright as you are. my point: the less JS/CSS you
touch, the more productive you are.

I would like to thank the gentleman who referenced Spring Surf, didn't
know about this project and wit ill certainly help the Model layer
refactoring.

However... I am still stuck with my Views which are built with JSF
components. Switching to Play would require to rebuild all the UI
elements with jQuery - not even sure if that's possible: jQuery
doesn't have all the widgets I need - plus they will need to be
changed to support Ajax functionality.
Most important, it would now require to have Javascript experts, which
we don't require at this point. -> Read cost implications here.

Again, thank you all for your feedback
Olivier Refalo

[Pascal Voitot Dev]

On Mon, Nov 8, 2010 at 1:36 AM, orefalo <ore...@yahoo.com> wrote:

First thank you all for your feedback.

Ever if my question didn't get a firm answer it certainly helped me
understand why Play is not for everybody. Not sure if it's technically
possible to do, but building an transition layer to help J2EE projects
move to Play would certainly help sell the concepts.

just one comment while reading... from java code, what prevents you from calling any spring or JEE stuff? play! is java code so you can do it...
 

To the ones comparing JSF with Play, I think these two are not playing
in the same area. JSF is competing with GWT.
To the ones saying that JSF components are not powerful, I would
recommend looking at primefaces http://www.primefaces.org/
To the ones saying that JSF is sluggish to develop with - I can build
a JSF 2 ajax table in 2 seconds with a simple tag - correct me if I am
wrong, but it would take more much more effort to build it with play
+jquery
To the one stating that jQuery and JS are great, I would say: not
every developer is as bright as you are. my point: the less JS/CSS you
touch, the more productive you are.

I would like to thank the gentleman who referenced Spring Surf, didn't
know about this project and wit ill certainly help the Model layer
refactoring.

However... I am still stuck with my Views which are built with JSF
components. Switching to Play would require to rebuild all the UI
elements with jQuery - not even sure if that's possible: jQuery
doesn't have all the widgets I need - plus they will need to be
changed to support Ajax functionality.
Most important, it would now require to have Javascript experts, which
we don't require at this point. -> Read cost implications here.

Again, thank you all for your feedback
Olivier Refalo

--

[Julien Tournay]

Hi,

I'm sorry, but you don't get my point.

- No, you don't need to be "brillant" to write a, ajax table with just HTML + JS + play!

I've already compared the code needed to to this exact thing with JSF vs Play! + jQuery, And it's MUCH more simple with just HTML + JS + Any rest fwk, even for a JS beginner. Doing an ajax call with jQuery is a one liner. Btw the end code will be much more maintanable.

- And yes you need to learn HTML and JS to do a web app, even if you're using JSF. At some point you'll have to write custom components, so you'll write HTML and JS.

And again, if you want do use JSF components, it's fine,but then just use JSF. I can't see any gain in making JSF works in Play! you'll basically lose all the advantages of Play! by doing so.

More technically, there's absolutely no "Session" (like in JEE Session), in Play!

Nothing is stored on the server, so JSF (which store pretty much everything in session) just can't work in a Play! server (at least without hacking the server).

You could probably manage to run Play! + JSF in a JEE container, but then, you're doing JEE, so it's not Play! anymore, and in that case, it's easier to just use JEE. 

jto.

[Ω Alisson]

JSF is a fucking trap.

At the beginning, it looks productive, but once you need to understand the lifecycle of JSF components, you're damned.

Have you ever seen the spec for custom javascript integration on JSF 2.0? It's hell!

It's easy to implement a ajax table component, but once you need something unusual you're stuck for hours, days, when you could just write a little piece of JS to get your feature working.

Something is really wrong with the assumption of ignoring the standard browser stack(HTML + CSS + JS) = productive :(

And here is a suggestion to people who would like to write RIA with clean JS, checkout http://knockoutjs.com (your head will explode with the simplicity and cleverness of this lib)

[Daniel Guryca]

Knockout is a pretty damn cool stuff.

Daniel

2010/11/8 Ω Alisson <thelin...@gmail.com>:

[Pascal Voitot Dev]

just discover this... really interesting!
I was using google closure integrated with play for my JS templating but knockout goes a bit further with the MVVC model...

pascal

[dirk]

However... I am still stuck with my Views which are built with JSF
components. Switching to Play would require to rebuild all the UI
elements with jQuery - not even sure if that's possible: jQuery
doesn't have all the widgets I need - plus they will need to be
changed to support Ajax functionality.

Regarding UIs in jQuery, I would recommend jQuery tools as a starting point:
http://flowplayer.org/tools/index.html

[orefalo]

Alisson,

I can only agree: trying to build your own components with JSF is
complex.
But you have to put my initial comment in its appropriate context:
enterprise environment.

A corporation doesn't need fancy animations, they mainly run table
driven apps which only require ajax forms and tables.
The JSF component libraries we have today provide all the features
they need.

I will stop defending JSF, because I may sound like an J2EE advocate,
which I am not.

Just trying to make my point on this forum. It's not ez to migrate
from JSF to Play.

Sincerely,
Olivier

On Nov 8, 6:24 am, Ω Alisson <thelinuxl...@gmail.com> wrote:
> JSF is a fucking trap.
> At the beginning, it looks productive, but once you need to understand the
> lifecycle of JSF components, you're damned.
> Have you ever seen the spec for custom javascript integration on JSF 2.0?
> It's hell!
> It's easy to implement a ajax table component, but once you need something
> unusual you're stuck for hours, days, when you could just write a little
> piece of JS to get your feature working.
>
> Something is really wrong with the assumption of ignoring the standard
> browser stack(HTML + CSS + JS) = productive :(
>
> And here is a suggestion to people who would like to write RIA with clean

> JS, checkouthttp://knockoutjs.com(your head will explode with the

> > pascal.voitot....@gmail.com> wrote:

>
> >> On Mon, Nov 8, 2010 at 1:36 AM, orefalo <oref...@yahoo.com> wrote:
>
> >>> First thank you all for your feedback.
>
> >>> Ever if my question didn't get a firm answer it certainly helped me
> >>> understand why Play is not for everybody. Not sure if it's technically
> >>> possible to do, but building an transition layer to help J2EE projects
> >>> move to Play would certainly help sell the concepts.
>
> >> just one comment while reading... from java code, what prevents you from
> >> calling any spring or JEE stuff? play! is java code so you can do it...
>
> >>> To the ones comparing JSF with Play, I think these two are not playing
> >>> in the same area. JSF is competing with GWT.
> >>> To the ones saying that JSF components are not powerful, I would

> >>> recommend looking at primefaceshttp://www.primefaces.org/

> >>> To the ones saying that JSF is sluggish to develop with - I can build
> >>> a JSF 2 ajax table in 2 seconds with a simple tag - correct me if I am
> >>> wrong, but it would take more much more effort to build it with play
> >>> +jquery
> >>> To the one stating that jQuery and JS are great, I would say: not
> >>> every developer is as bright as you are. my point: the less JS/CSS you
> >>> touch, the more productive you are.
>
> >>> I would like to thank the gentleman who referenced Spring Surf, didn't
> >>> know about this project and wit ill certainly help the Model layer
> >>> refactoring.
>
> >>> However... I am still stuck with my Views which are built with JSF
> >>> components. Switching to Play would require to rebuild all the UI
> >>> elements with jQuery - not even sure if that's possible: jQuery
> >>> doesn't have all the widgets I need - plus they will need to be
> >>> changed to support Ajax functionality.
> >>> Most important, it would now require to have Javascript experts, which
> >>> we don't require at this point. -> Read cost implications here.
>
> >>> Again, thank you all for your feedback
> >>> Olivier Refalo
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "play-framework" group.
> >>> To post to this group, send email to play-fr...@googlegroups.com.
> >>> To unsubscribe from this group, send email to

> >>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >>> .

> >>> For more options, visit this group at
> >>>http://groups.google.com/group/play-framework?hl=en.
>
> >>  --
> >> You received this message because you are subscribed to the Google Groups
> >> "play-framework" group.
> >> To post to this group, send email to play-fr...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >> .

> >> For more options, visit this group at
> >>http://groups.google.com/group/play-framework?hl=en.
>
> > --
> > Real Programmers don't need comments-- the code is obvious.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-fr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

[Pascal Voitot Dev]

2010/11/8 orefalo <ore...@yahoo.com>

Alisson,

I can only agree: trying to build your own components with JSF is
complex.
But you have to put my initial comment in its appropriate context:
enterprise environment.

A corporation doesn't need fancy animations, they mainly run table
driven apps which only require ajax forms and tables.
The JSF component libraries we have today provide all the features
they need.

I will stop defending JSF, because I may sound like an J2EE advocate,
which I am not.

J2EE advocate is a tough job nowadays :)
 

Just trying to make my point on this forum. It's not ez to migrate
from JSF to Play.

but you can give it a try and participate to the improvement of Play so that it becomes better and more practical ;);)... "fitter, happier, more productive" as Radiohead sings ;)
 

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[peter hausel]

web framework migration is never easy (especially if you want to
switch from a component driven approach to a request driven one) but
usually it's very straightforward.

What I would suggest is to try to build a prototype with play for a
project which is fairly isolated and see how it feels.

HTH
Peter

On Nov 8, 10:56 am, orefalo <oref...@yahoo.com> wrote:
> Alisson,
>
> I can only agree: trying to build your own components with JSF is
> complex.
> But you have to put my initial comment in its appropriate context:
> enterprise environment.
>
> A corporation doesn't need fancy animations, they mainly run table
> driven apps which only require ajax forms and tables.
> The JSF component libraries we have today provide all the features
> they need.
>
> I will stop defending JSF, because I may sound like an J2EE advocate,
> which I am not.
>
> Just trying to make my point on this forum. It's not ez to migrate
> from JSF to Play.
>
> Sincerely,
> Olivier
>

> On Nov 8, 6:24 am, Ù Alisson <thelinuxl...@gmail.com> wrote:
>
>
>
>
>
>
>
> > JSF is a fucking trap.
> > At the beginning, it looks productive, but once you need to understand the
> > lifecycle of JSF components, you're damned.
> > Have you ever seen the spec for custom javascript integration on JSF 2.0?
> > It's hell!
> > It's easy to implement a ajax table component, but once you need something
> > unusual you're stuck for hours, days, when you could just write a little
> > piece of JS to get your feature working.
>
> > Something is really wrong with the assumption of ignoring the standard
> > browser stack(HTML + CSS + JS) = productive :(
>
> > And here is a suggestion to people who would like to write RIA with clean

> > JS, checkouthttp://knockoutjs.com(yourhead will explode with the

[Daniel Guryca]

Well, our experience was same.
It's very difficult (lot of $) to migrate old running and working
projects to a new framework.
So we did not do it. Our all old projects stayed untouched and run as
they are ... till they die.

BUT all new ones we create with Play !!!
I would never want to create any new app in a beast framework we were
using for years before.

Cheers
Daniel

> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[jprudent]

I'm a rookie developer and I used to hate JS.
Each time I saw a JS fix in a JSF view I used to think it's a dirty
workaround I don't want to look at because:
1) JS is messy gadget language
2) the developer (comprise myself) did it because of his lack of
knowledge of the underlying framework.

But, since I tried UI development with 99% of the XHTML+JS+CSS, I know
I was absolutely wrong:

1) JS is not a messy gadget language. It's just another language. I
had to learn it properly, understand his strength and how to write
code with it. Recently I wrote a lot of JS (of course not so good code
because I'm still in learning process) and it's not bloated, it even
readable. Mastering JS means mastering the client side and it's worth
the effort of learning JS. While doing my small app with web-browser
standards, my webapp tends automatically to a full Json enabled
application (so an android, iphone, or whatever port of my client
would just be another independent lightweight stack to develop)

2) Frameworks like JSF try to hide his JS side behind an bunch of
tags. That's great 99% of the time but like Alisson states, when I
have to hack something, I'll get lost for hours in a maze like life
cycle (that's the way I felt it) and sometimes too bored to do things
the right way I will surprise myself writing some ugly fix in JS or
Java. Maybe I'm not a good developer, but I think the 1% remaining
where JSF doesn't suit your need should be given to a JSF guru who
likes to whip himself reciting a chapter of JSF spec before going to
sleep. But, yes, if I was told what framework I would use for your
boring B2B banking webapp, I would take JSF in consideration since
developer team is Java fluent and JSF suit 99% of the need and we are
in JEE environment and we have a JSF guru that will last all the
project long.

So, your point was: how to interface play with JEE standard?
For the JSF part I think we shouldn't, it's another world. But for
other server side technologies some may be usable.

My last thought is to let JEE independent project being built with new
ideas like play! and let the banking system gets stuck with a FULL Jee
stack (they don't want to change and that's how I earn my money)

On 9 nov, 01:16, Daniel Guryca <dun...@gmail.com> wrote:
> Well, our experience was same.
> It's very difficult (lot of $) to migrate old running and working
> projects to a new framework.
> So we did not do it. Our all old projects stayed untouched and run as
> they are ... till they die.
>
> BUT all new ones we create with Play !!!
> I would never want to create any new app in a beast framework we were
> using for years before.
>
> Cheers
> Daniel
>

> >> > JS, checkouthttp://knockoutjs.com(yourheadwill explode with the

[heri16]

Knockout has really interesting ideas.
Declarative-Data-Binding & Event-tiggers & Auto-UI-refresh can indeed
become a really useful pattern, especially used alongside Play!'s MVC.
Reminds me of Adobe Flex 3, very useful for RIAs.
"When a condition is hit, auto-submit to a few fields server." can now
be done in a slightly more elegant way.

I feel it is a must for us to showcase this in the getting-started
tutorials, as both combined together allows people to avoid a lot of
javascript and be more productive, giving a more seamless Play!
experience.

Heri

On Nov 8, 9:41 pm, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:

> just discover this... really interesting!
> I was using google closure integrated with play for my JS templating but
> knockout goes a bit further with the MVVC model...
>
> pascal
>
>
>
> On Mon, Nov 8, 2010 at 12:58 PM, Daniel Guryca <dun...@gmail.com> wrote:
> > Knockout is a pretty damn cool stuff.
>
> > Daniel
>

> > 2010/11/8 Ω Alisson <thelinuxl...@gmail.com>:

> > > JSF is a fucking trap.
> > > At the beginning, it looks productive, but once you need to understand
> > the
> > > lifecycle of JSF components, you're damned.
> > > Have you ever seen the spec for custom javascript integration on JSF 2.0?
> > > It's hell!
> > > It's easy to implement a ajax table component, but once you need
> > something
> > > unusual you're stuck for hours, days, when you could just write a little
> > > piece of JS to get your feature working.
> > > Something is really wrong with the assumption of ignoring the standard
> > > browser stack(HTML + CSS + JS) = productive :(
> > > And here is a suggestion to people who would like to write RIA with clean

> > > JS, checkouthttp://knockoutjs.com(your head will explode with the

> > > simplicity and cleverness of this lib)
>

> > > On Mon, Nov 8, 2010 at 7:24 AM, Julien Tournay <boudhe...@gmail.com>

> > >> <pascal.voitot....@gmail.com> wrote:

>
> > >>> On Mon, Nov 8, 2010 at 1:36 AM, orefalo <oref...@yahoo.com> wrote:
>
> > >>>> First thank you all for your feedback.
>
> > >>>> Ever if my question didn't get a firm answer it certainly helped me
> > >>>> understand why Play is not for everybody. Not sure if it's technically
> > >>>> possible to do, but building an transition layer to help J2EE projects
> > >>>> move to Play would certainly help sell the concepts.
>
> > >>> just one comment while reading... from java code, what prevents you
> > from
> > >>> calling any spring or JEE stuff? play! is java code so you can do it...
>
> > >>>> To the ones comparing JSF with Play, I think these two are not playing
> > >>>> in the same area. JSF is competing with GWT.
> > >>>> To the ones saying that JSF components are not powerful, I would

> > >>>> recommend looking at primefaceshttp://www.primefaces.org/

> > >>>> To the ones saying that JSF is sluggish to develop with - I can build
> > >>>> a JSF 2 ajax table in 2 seconds with a simple tag - correct me if I am
> > >>>> wrong, but it would take more much more effort to build it with play
> > >>>> +jquery
> > >>>> To the one stating that jQuery and JS are great, I would say: not
> > >>>> every developer is as bright as you are. my point: the less JS/CSS you
> > >>>> touch, the more productive you are.
>
> > >>>> I would like to thank the gentleman who referenced Spring Surf, didn't
> > >>>> know about this project and wit ill certainly help the Model layer
> > >>>> refactoring.
>
> > >>>> However... I am still stuck with my Views which are built with JSF
> > >>>> components. Switching to Play would require to rebuild all the UI
> > >>>> elements with jQuery - not even sure if that's possible: jQuery
> > >>>> doesn't have all the widgets I need - plus they will need to be
> > >>>> changed to support Ajax functionality.
> > >>>> Most important, it would now require to have Javascript experts, which
> > >>>> we don't require at this point. -> Read cost implications here.
>
> > >>>> Again, thank you all for your feedback
> > >>>> Olivier Refalo
>
> > >>>> --
> > >>>> You received this message because you are subscribed to the Google
> > >>>> Groups "play-framework" group.
> > >>>> To post to this group, send email to play-fr...@googlegroups.com.
> > >>>> To unsubscribe from this group, send email to

> > >>>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

> > >>>> For more options, visit this group at
> > >>>>http://groups.google.com/group/play-framework?hl=en.
>
> > >>> --
> > >>> You received this message because you are subscribed to the Google
> > Groups
> > >>> "play-framework" group.
> > >>> To post to this group, send email to play-fr...@googlegroups.com.
> > >>> To unsubscribe from this group, send email to

> > >>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

> > >>> For more options, visit this group at
> > >>>http://groups.google.com/group/play-framework?hl=en.
>
> > >> --
> > >> Real Programmers don't need comments-- the code is obvious.
>
> > >> --
> > >> You received this message because you are subscribed to the Google
> > Groups
> > >> "play-framework" group.
> > >> To post to this group, send email to play-fr...@googlegroups.com.
> > >> To unsubscribe from this group, send email to

> > >> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

> > >> For more options, visit this group at
> > >>http://groups.google.com/group/play-framework?hl=en.
>
> > > --
> > > You received this message because you are subscribed to the Google Groups
> > > "play-framework" group.
> > > To post to this group, send email to play-fr...@googlegroups.com.
> > > To unsubscribe from this group, send email to

> > > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

> > > For more options, visit this group at
> > >http://groups.google.com/group/play-framework?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "play-framework" group.
> > To post to this group, send email to play-fr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> > .

[Pascal Voitot Dev]

2010/11/12 heri16 <her...@gmail.com>

Knockout has really interesting ideas.
Declarative-Data-Binding & Event-tiggers & Auto-UI-refresh can indeed
become a really useful pattern, especially used alongside Play!'s MVC.
Reminds me of Adobe Flex 3, very useful for RIAs.
"When a condition is hit, auto-submit to a few fields server." can now
be done in a slightly more elegant way.

I feel it is a must for us to showcase this in the getting-started
tutorials, as both combined together allows people to avoid a lot of
javascript and be more productive, giving a more seamless Play!
experience.

Heri

 

and concerning performances ? Is it good? No too much overhead on top of the remaining stuff?
That's why I was using Google Closure: it generates JS at build time but it's really efficient at runtime..
 
Pascal

To unsubscribe from this group, send email to play-framewor...@googlegroups.com.