Grokbase Groups Struts dev June 2006
The "Front Controller" is not really a controller. It is a child's tool for
people who are challenged by OOP and need tool help.
On 6/21/06, Craig McClanahan wrote:

Comments interspersed.
On 6/21/06, Don Brown 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
(but, if I read the current navigation handler right, you're not
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
feasible, but not required. Shale Remoting does the same sorts of
for resource access, and supports dynamically mapping dynamic requests
to an arbitrary method on a managed bean (i.e. it gets instantiated on
and dependency injected), using standard JSF facilities, already. And
takes zero configuration if you like the default mapping algorithm.
xwork interceptor chains around the call to the dynamic handler methods
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
to use facilities that are already there, so he or she will not need to
new concepts. That's why Shale does things like using method
binding expressions to configure actions in the dialog subsystem ...
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
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
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
and forcing a beginner that is reading a JSF book to ignore that chapter
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
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,
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

- 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

- 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

- 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
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
or any other sort of HTTP request, with basic IoC-ish bean instantiation
dependency injection built in, along with an expression language that can
used to bind components to model data, but can also be used
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.



"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase