> But how well does it work with Facelets? The tool integration is all > about the JSP view. Use a non-JSP view and most of the utility of the > tools dissappears.
You're right I was only referring to JSF support in jsps. Also, the plugin for JSF in WSAD does something that is often counter-productive. When you add a UI component to a jsp the plugin automatically adds a getter method to the backing java class. This leads to alot of useless code clutter and is one reason why the tapestry portlets were much cleaner. This of course is the tool and not JSF. > Let's say everything you say might happen does come about. Well, then > your Tapestry skills will translate directly into JSF/Facelet skills, > and porting your application will be easy. Alternately, getting people > with JSF/Facelet skills will be easy, and they'll quickly adapt to the > "identical" Tapestry environment. I am actually evaluating frameworks now because this project used/uses an in-house web framework very similiar to Struts. It adds a DAO layer and some other stuff but it's basically Struts. New developers complained because they couldn't use it on a resume. It's a shame sometimes what people put in a name. > Tapestry is so rich that, at first glance, Facelets does appear to > steal some of its better ideas. However, once you use Tapestry a bit > longer, you realize that the core strengths are not limited to the > templates. The injection model in 4.0 (which could be "faked" in > 3.0), the extensibility via HiveMind, the JavaScript generation, the > localization support, and the whole approach at all levels to managing > state .... these are very much part of Tapestry too, and harder to > grasp immediately, and harder for JSF to replicate. I know there's a ton of great stuff in Tapestry. This will become more apparent as the documentation evolves for 4.0. I really like the injection model. I have not grasped the benefits of tapestry's state management. This is just because I don't fully understand it. I guess keeping the least amount of information is HttpSession as possible is good. But this can be accomplished through good coding practice. What else? Also, I think for me it's the little things, having a table component that supports paging and sorting out of the box. JSF doesn't have. Plus, DirectLink passing parameters directly to listener methods. JSF to my knowledge only supports no arg listeners for CommandLinks (then you take the data out of the request - ugly). And finally my favorite - being able to return an actual java object representing the page to go to next! I really like page injection. Ryan ======================================= Ryan Wynn Websphere Portal Developer IBM Business Consulting Services - Public Sector Reston Office: 703-668-2478 Cell: 703-622-1977 [EMAIL PROTECTED] Howard Lewis Ship <[EMAIL PROTECTED]> 08/15/2005 02:49 PM Please respond to "Tapestry users" To Tapestry users <[email protected]> cc Subject Re: Choosing Tapestry On 8/15/05, Ryan Wynn <[EMAIL PROTECTED]> wrote: > I have been using Tapestry 4.0 for 2 weeks now for portlet development and > I can say my experience has been very positive. I have found that my > tapestry portlets have come out much much cleaner than their JSF > counterparts. Thanks! And thanks to McKesson Provider Technologies for funding this aspect of Tapestry 4.0. > I think the ability to inject pages and hivemend services > really makes for an elegant design. Not only that but the line precise > error reporting probably saved me hours of debugging (My mistakes in JSF > JSPs get wrapped in very obscure ClassCastExceptions in the logs). > > However, I am tasked with choosing a framework for my client and although > Tapestry appeals to me it may not be right for this project. It seems to > me that with Facelets JSF is transforming more and more into Tapestry. JSF > tooling in WSAD (which is the project IDE) comes out of the box and is > further along than Spindle in the portlet arena. But how well does it work with Facelets? The tool integration is all about the JSP view. Use a non-JSP view and most of the utility of the tools dissappears. > Also, the project uses > applets quite extensively. From what I have read about Facelets I can > leverage JSF outside of a web container with Swing or SWT. Tapestry is so rich that, at first glance, Facelets does appear to steal some of its better ideas. However, once you use Tapestry a bit longer, you realize that the core strengths are not limited to the templates. The injection model in 4.0 (which could be "faked" in 3.0), the extensibility via HiveMind, the JavaScript generation, the localization support, and the whole approach at all levels to managing state .... these are very much part of Tapestry too, and harder to grasp immediately, and harder for JSF to replicate. > > Is there anything fundamentally stopping JSF (the "standard" + all that > standard implies, e.g. it's not hard to hire a Struts expert) from > stealing the best parts of Tapestry (line precise error/templating to > start) and making me look like a fool for choosing Tapestry a couple years > from now? Let's say everything you say might happen does come about. Well, then your Tapestry skills will translate directly into JSF/Facelet skills, and porting your application will be easy. Alternately, getting people with JSF/Facelet skills will be easy, and they'll quickly adapt to the "identical" Tapestry environment. > > Thanks, > Ryan > > ======================================= > Ryan Wynn > Websphere Portal Developer > IBM Business Consulting Services - Public Sector > Reston Office: 703-668-2478 > Cell: 703-622-1977 > [EMAIL PROTECTED] > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
