struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: [Proposal] Consolidate extras, EL, taglibs, and faces under 'action' (was Maven groupId and svn repo structure)
Date Mon, 20 Mar 2006 17:46:27 GMT
On 3/20/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > On 3/20/06, Frank W. Zammetti <fzlists@omnytex.com> wrote:
> >> You know, I was looking at the Struts front page a few minutes ago,
> >> specifically the "Extensions", which are the seven dwarfs IIRC.  The
> one
> >> that sticks out for me as a "problem", if that's the right word, is the
> >> JSP Taglib.
> >
> >
> > I suspect that Struts users who abhor JSP, but like things like
> Velocity,
> > would not agree with you :-).
>
> Hehe, probably right :)
>
> > Indeed, if you're using Struts as the server end of AJAX transactions,
> you
> > don't need this library even if you do happen to use JSP for the human
> user
> > interface portion of your application (perhaps using a different
> framework).
> >
> > I think it's fair to say that the majority of Struts developers consider
> >> the Struts tags to be intrinsically part of the Struts Action Framework
> >> (SAF).  Except for me who rarely uses them! :)
> >>
> >> The analogy I would use us the component kit you use in a JSF app...
> >> *can* you build a JSF app with no component kit at all?
> >
> >
> > You bet you can.
>
> Do you have any feel for how common it is though?  My guess is that it
> isn't very common, but your certainly in a better position to tell then
> I am.  It just doesn't *feel* like something I would expect to find to
> be common, just like not using the Struts taglibs probably isn't the
> most common usage pattern.


Common now?  Probably ot very ... especially if you point someone at the
current website documentaton for this feature[1]  :-).  You need to peruse
the Javadocs, and ask questions on the list, to get very far right at the
moment.  And, most people who evaluate JSF never seem to look at the
underlying infrastructure ... they get obsessed with the components and
either like or dislike it on that basis.

Common in the future?  That's the plan ... it's especially designed for
folks who want to create the server side of AJAX interactions, plus people
who want to write AJAX-enabled components.  The power of expression
evaluation, plus the "basic dependency injection" capabilities of managed
beans, are just too much goodness to pass up.  JSF's fundamental front
controller architecture is plenty of power for this sort of use case.  With
Shale Remoting, you can plug in (out of the box) a call to any arbitrary
method (it maps based on the request URL), or to any Commons Chain command
or chain implementation.  Adding support to map to an XWork (the underlying
framework that WebWork is based on) interceptor chain is on my list of
things to add, but it's going to be really easy.  Also, something to think
about for the future ... in JSF 1.2 and JSP 2.1, the expression language
APIs and implementation got factored into their own spec document, which
*might* ultimately be a candidate for inclusion in the JDK.  It turns out
that a common expression evaluation library is pretty handy in simplifying
quite a few use cases.  For example, anything that Commons BeanUtils can do
is *much* more elegantly handled with EL expressions and a few appropriate
complementary classes (like converters).

We (Sun) are using this library in the next version of the demo AJAX
components that you can get with Java Studio Creator 2 [2].  Doing so cut
the number of lines of code per component down dramatically (besides the
fact that the original approach didn't take advantage of browser caching,
required you to use "/faces/*" mapping, yadda yadda).  More importantly, it
got rid of the approach that was used in the initial prototyping of these
components (a separate PhaseListener per component for serving up static
resources and responding to AJAX requests), which is not a particularly
scalable design :-).

> Come to think of it ... there's even a 40kb standalone jar file (
> > shale-remoting.jar) that does exactly this kind of thing, with no
> > dependencies on the UI components part of JSF, or even on the rest of
> Shale
> > :-).
>
> Cute :-)
>
> > Craig
>
> Frank


Craig

[1] http://struts.apache.org/struts-shale/features-remoting.html
[2] http://developers.sun.com/jscreator/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message