The problem is that there is no common ground. Pretence is great, but not really effective. It will bit you in the butt later.
On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
You make a lot of good points, and a strong argument for rallying around the JSF flag. To this end, Shale is a great idea and provides a nice realization of this approach. Undoubtedly, there are many developers who think similarly and may not ever be interested in the Action 2 controller, and Shale should always be there to make their lives easier. Others, however, may find uses for an Action 2 controller in a pure JSF application: * AJAX services that return JSON/XML - The Action 2 controller separates the rendering of the result from the method, so the method can return objects, and the configurable Result can handle the JSON or XML serialization. * Public high-load browsing pages - The Action 2 controller provides minimal overhead and the possibly of completely stateless, sessionless operation. Web designers can use Velocity, JSP, Freemarker, etc to create the pages. * Generated images - An application may have need to create charts, graphs, or other generated images. Action 2 provides a framework to separate the logic from the rendering, and even has built-in support for JFreeChart. * PDF reports - Likewise, there may be a need for generated PDF reports. Action 2 also has support for Jasper Reports, although any reporting engine can be easily plugged in. * Alternate view technologies - A section of the team may already be familiar with Velocity, Freemarker, or even XSLT and want to use that for the view. Finally, the Action 2 dispatcher is actually a ServletFilter, so it is very easy to have both controllers work side-by-side, even in the same request. Not every JSF application will have a need for Action 2, but putting them together in the same Struts 2.0 release provides a single place for the developer to learn about their options and see what fits best where. > * Philosophically, a framework built around JSF should encourage the > developer > to use facilities that are already there, so he or she will not need to > learn > new concepts. I agree common standards are important, and that is why we are looking to see how we can leverage standards like EL and JSF where we can. However, there are cases where the standard may be lacking and it is necessary to use a replacement (Freemarker/Velocity, OGNL, Spring, etc). > For navigation, "you'd use Action 2 navigation rather than navigation > handler" means that you're giving up on the tools around for JSF > navigation, > and forcing a beginner that is reading a JSF book to ignore that chapter > and learn something different. We'll want to look at how the existing SAF2 > navigation handler can delegate for scenarios where the developer wants to > use JSF navigation for some namespaces. True, but so does Clay, Facelets, and Shale dialogs change a "pure" JSF app, but as long as it is optional, it shouldn't be a big deal. That said, I really like your idea for delegation and am very open to putting that into Action 2. > It's definitely possible to merge Action 2 and JSF in an application -- > you've already done that. That's a tremendous benefit for the migration > use > cases, or those that just want to sprinkle some components without > migrating. For a new application, though, I don't care for the result, > because it adds complexity (over pure JSF based solutions), and requires > deveopers to deal with additional concepts and configuration files, without > enough corresonding benefits to make it worth it (IMHO, of course). But you really can't have it both ways - either you replace existing functionality or you have duplication. I think this is a problem even for Shale - duplicating resource loading, navigation, view templating, etc. > Doesn't it really come down to which front controller you choose as the > primary foundation of your architecture? Yes, but in making that decision, all things equal, you should choose the more generic/flexible one in front. Still, I hold to the argument that the the decision is invalid as there is a middle ground in using both. > Personally, I want to get out of the front controller business :-), and > leave that problem to the MyFaces and RI teams to compete on quality and > features. I'd rather add value by leveraging concepts that a JSF-oriented > developer already has to know about, rather than adding abstraction layers > so I can be agnostic about the front controller that is under the covers. And this is why Shale needs to continue, and I'd argue, continue to exist as part of the larger Struts community, and a step further, under a larger "Struts 2.0" product. I think despite providing multiple alternatives and solutions, there is a common narrative we can weave to create a unified Struts project. Don > > Don > > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
