Don Brown wrote:
Yeah, I read that post, and while interesting, I'm not sure it would
hold much value, particularly for Action 2 applications.
Basically, the approach intercepts the usual Faces processing at the
start, turning the lifecycle into one used by Action 1. Action 2,
based on WebWork, doesn't have a predefined workflow process, leaving
that job up to interceptor chains. This allows you to customize the
completely workflow for a single action or groups of actions (called
packages). In fact, you could argue that perhaps JSF should be
implemented as Action 2 interceptors :)
That's one of the things that I wish the original JSF 1.0 API would've
done instead of before/after. Probably just a continuation of the JSP
stuff that no one likes (which also screwed up JSF's UIComponent API).
Hopefully in JSF 2.0, we can move to the filter/interceptor pattern with
phaselisteners (equiv WebWork interceptors).
The two advantages mentioned, navigation and EL, are debatable.
Action 2 uses Results, allowing for each action to specify one or more
results which could be a simple JSP forward, a Velocity template, or
even a Jasper reports. As I understand JSF navigation, the results
are simple request dispatches, harking back to Action 1-type
functionality.
The NavigationHandler has that default behavior. But much like WebWork
allows the pluggable ActionMapper, all parts of JSF are pluggable in
that manner. Seam and SWF are two examples of plugging in alternate
logic for navigation handling. So the emphasis is put on the API, not
the implementation.
Using EL, on the other hand, I personally don't see as a great
benefit. The new unified EL lacks many of the key features that makes
EL and OGNL in particular, so attractive. For example, OGNL supports
method invocation, type conversion, and projection, features, AFAICT,
aren't supported by EL and won't ever be. Still, one of our goals in
Action 2 is to make the EL pluggable, so in the future, developers can
choose between the unified EL and OGNL, and perhaps other options.
I've been trying to get everyone behind the EL-API. The 'traditional'
EL implementation provided in the spec is, again, only one
implementation. The JEXL implementation of the EL-API would be a piece
of cake, OGNL wouldn't be that hard either if they would use JavaCC with
the visitor=true when compiling the grammar.
So when you say '... aren't supported by EL and won't ever be.' that's a
lot of smoke up .... Anyways, the EL-API is what counts here and just
like JSE 6 has that Script API, JEE has the EL API with semantics that
fit event based frameworks, such as UIs. MethodExpressions are a great
example, along with EL's pluggable ELResolver system such that any
custom type, converter, logic, etc, can be plugged in to resolve the
behavior of a.b or a[b]. In terms of OGNL or JEXL, you can go one step
further and produce a OgnlExpressionFactory or JexlExpressionFactory, as
so *many* frameworks can take advantage of a common API. There's also
talk of having an EL JSR that will roll in everything else people are
looking for.
The only advantage I can see of this approach is to allow developers
to write backing beans, using the same FacesContext as other pages
that fully use JSF, but even then, Action 2 actions are POJO's and
support arbitrary method invocation already, so the remaining
advantage would be the FacesContext consistency.
I'm not a JSF expert, so perhaps I'm missing something big. I still
see the areas ripe for collaboration are annotations and efforts to
make JSF backing beans and Action 2 Actions useable in both
frameworks. Also, I was only half kidding about implementing JSF as
Action 2 Interceptors... ;)
That's exactly what I'm hoping for with the EL API-- such that we can
share ELResolvers for handling common validation/converter metadata.
I'll agree that if JSF's controller wasn't bound to the concept of a
stateful component model, that it would make a lot more sense as a
common platform for frameworks. In JSF 2.0, I hope to introduce the
idea of a common controller that will support model 1 and model 2 by
putting the view/state into a facade. This facade can be implemented as
a Action in WW terms or a UIComponent tree in JSF terms. Even if we do
correct the model 1 in a hybrid implementation, there will always be a
need for true model 2 support, it's just a matter of how efficiently we
can integrate the two into a common mind share within JEE.
-- Jacob
Don
Sean Schofield wrote:
[Moving this aspect of the discussion from myfaces to struts list ...]
On 4/7/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
Covered here a bit:
http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html
@Jacob:
Great blog entry!
@ Struts Dev:
I recommend you check this out. Jacob outlines how its possible to
create a simple action oriented framework on top of the JSF API
without fussing with components. You really get a sense for how
powerful (and pluggable) the API really is.
Maybe this a possible Action/Shale/MyFaces cooperation opportunity?
Maybe the Webwork stuff could take advantage of the EL and
NavigationHandler? Its not 100% JSF but it would bring the
Action/Shale frameworks a little closer together.
Back at ApacheCon USA we talked about trying to work more closely
between the two frameworks. To me, this idea has some interesting
possibilities. I know there was some interest in the Shale dialog
stuff but why not get the impressive navigation and EL capabilities of
JSF for free?
Sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
