--
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.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
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.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
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.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
>> > > 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
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
> 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.
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.
Heri
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
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
--
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.
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.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
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.
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
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.