For the record, Tapestry can serve more than just HTML. There is a suite of WML components built into the Tapestry framework already. So in this respect, JSF doesn't have an advantage. The JSF thinking of having renderers that can be toggled so the same view can be swapped between HTML, WML, XML, etc is a bit silly IMO. Each device deserves a custom interface, not just a morphing of a common one.

I'll be speaking on Tapestry (3 hour tutorial-style building an application on the fly presentation) at the upcoming NFJS symposium in the Triangle area in a few weeks:

        http://www.nofluffjuststuff.com/2004-06-raleighdurham/index.jsp

David Geary (Mr. JSF) will be there too. For fun, put us in a room together and ask about this very topic :)) Should we take the gloves off? ;)

        Erik



On May 19, 2004, at 10:10 AM, [EMAIL PROTECTED] wrote:
Tapestry is AWESOME for HTML/HTTP. It removes a great deal of the suck, but
it is still a kludge around the HTML/HTTP model. We need to move the
non-critical session back where it belongs, on the client.



[...]

I don't think Tapestry has to die under this model, but evolve to use more
than HTML. JSF has a minor advantage in this area, but at what cost? With
EJB3 simplifying and removing XML configuration/meta data do I really want
to maximize it on the front end? In the age of Eclipse and the post-boom do
I really want to go back to 3-5k per seat tools above massive abstractions
that leak? Its time to standardize on simplistic programming models, not
build large cathedrals on complex ones. The foundation of JSF is shaky, EJB
1-2.x proved that. The idea might be nice but the implementation...well go
look at that and tell me if you really want to meta-code that way.


_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org

Reply via email to