Comments interspersed. On 6/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
Craig, thanks for your honesty and candor. I know this is a delicate topic, and I appreciate you approaching the topic openly.
LIkewise ... I may have sounded a bit grumpy in my response, but I don't ascribe any malicious intent to your proposal. A couple of clarifications:
1. I'm not proposing Shale _ever_ depend on Action 2, only that they should work well together. In fact, I mean to start including Shale in Action 2's web examples.
In principle, that should work already for some things like ViewController, (but, if I read the current navigation handler right, you're not delegating so the "dialog" facility of Shale will not operate correctly at the moment). Proof is in the pudding of course, by actually writing such a sample app. 2. In a "pure JSF" environment, don't you think there is value in
using an Action 2 controller to handle things like JSON/XML remote services? I'm finding more and more my Struts Actions return JSON rather than HTML. This is how I see us working together even if you don't use Action 2's JSF support.
Two separate thoughts on this: * Technically, having an Action2 type handler for these things is certainly feasible, but not required. Shale Remoting does the same sorts of things for resource access, and supports dynamically mapping dynamic requests to an arbitrary method on a managed bean (i.e. it gets instantiated on demand and dependency injected), using standard JSF facilities, already. And it takes zero configuration if you like the default mapping algorithm. (Adding xwork interceptor chains around the call to the dynamic handler methods will be an easy add-on to this, for those who like that approach to providing services to the handler.) * 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. That's why Shale does things like using method binding expressions to configure actions in the dialog subsystem ... binding an asynchronous callback is done exactly the same as binding a submit button to an action method (execute() in action framework terminology). Nothing new to learn. Leverages the managed beans facility exactly the same way. Easily usable by a JSF component itself that wants to encapsulate AJAX behavior or by client side JavaScript provided by the application. 3. Overlap areas like navigation, validation, messages, etc., are only
waiting on attention to be resolved. When using the Action 2 navigation, it is my intention that the default configuration removes overlap as much as possible. You'd use Action 2 navigation rather than the NavigationHandler. Validations could be defined in the page or could automatically be created from existing Action 2 validations (XML or annotations), similarly to how Seam creates validations from annotations. Messages integration is easily resolved by creating a backing bean that provides messages using Action 2 apis. I fully believe it is possible to merge Action 2 and JSF into a web application in a seamless manner.
There is a lot of space for implementing common frameworks we can share for doing things like validation -- for example, at JavaOne we talked a bit about a "Commons Validator 2.0" that could derive validation rules from annotations. But, at the end of the day, you still need different mechanisms to embed the particular annotations into the UI toolkit you're using (the UI tags in SAF, or the component tags in JSF). 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. 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). I guess what I'm saying is you could view this "overlap" in a negative
or positive light. I think the Struts project should put forth a "preferred" approach, used in our quickstarts and tutorials. However, that doesn't mean that we should force developers into our way of thinking. Having options isn't necessarily bad. At this point, I really don't see a valid either/or framework approach debate: - If your application needs to be built by tool-dependent programmers, pure JSF is definitely the way to go. - If you prefer the pure JSF approach for other reasons, use a pure JSF framework, but perhaps use Action 2 to organize and deliver JSON/XML services. - If your application has a lot of Struts developers or stateless pages that need pure speed, but in sections you want to use fancy JSF components, use Action 2 as the controller and sprinkle in JSF where needed. - If you like Action-based approaches and don't need/like JSF components, just use Action 2. I hope we can agree that each of the above situations and solutions is valid, and make that our common ground. You may prefer the first couple, others the latter two. As a Struts project, we need to be of one mind in at least some things, and it is my hope Action 2's recent JSF integration attempts can help get us there. I put this proposal out to help bring us together, not precipitate a "divorce" :)
Doesn't it really come down to which front controller you choose as the primary foundation of your architecture? Nearly every existing framework that has added JSF integration has kept their original basic architecture, and thought of JSF primarily as a library of UI widgets. Shale (and Seam) take a different viewpoint -- utilize the front controller built in to JSF instead, and decorate around the edges to add features and ease of use. If you take that approach, you discover a very capable framework, usable for server generated markup or AJAX callbacks or any other sort of HTTP request, with basic IoC-ish bean instantiation and dependency injection built in, along with an expression language that can be used to bind components to model data, but can also be used programmatically by an application framework itself. 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. Don Craig
