You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Rob Jellinghaus <ro...@unrealities.com> on 2002/04/11 22:15:06 UTC

[Resend] Struts, view-framework pluggability, XSLT, and Maverick

[I sent this to struts-dev a couple of days ago.  So far, no 
response.  Gonna try once more, to struts-user and struts-dev together.  If 
no response *this* time, then I'll assume the Struts community is pretty 
much uninterested in this idea.]

One of the difficult things in open source development is getting a sense 
of where a project is headed... todo information tends to only slightly 
capture what a given group of hackers is really focused on, and it's hard 
to glean total insight from the mailing lists.

So:  I am spinning up on open-source Java web app frameworks.  The main 
contenders seem to be Cocoon, Struts, and Maverick.

Cocoon (http://xml.apache.org/cocoon) looked really good (especially its 
focus on efficient SAX processing), but it seems that Cocoon started from a 
document processing orientation (publishing content in lots of different 
ways) rather than from an interactive application orientation (supporting 
control flow throughout an interactive web app).  Cocoon has support for 
interaction but it is hard to see how to use it, especially once I started 
looking at Struts where it couldn't be clearer.  So I have (with some 
regret) backed off of Cocoon.

Struts (http://jakarta.apache.org/struts, of course) has a very 
straightforward concept of action mapping and website interaction, which I 
like a lot.  Its documentation is also in very good shape, and its 
developer community seems to be thriving.  However, Struts is currently 
fairly wedded to JSP, at least in its 1.0.2 and 1.1-beta distributions; 
there seems to be no integrated support for using non-JSP 
presentations.  Especially when compared to:

Maverick (http://mav.sourceforge.net) has (on cursory examination) a clean 
ability to plug in different presentation frameworks.  (JSP, XSLT, or 
Velocity at the moment.)  It also seems to share Struts' ease of 
interaction configurability.  However, it also is a lot younger than 
Struts, and it lacks the mass of Struts examples and documentation.

In an email thread discussing the Model 2X Javaworld article 
(http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html), 
Ted Husted and Jeff Schnitzer seemed to agree that Struts and Maverick had 
a lot in common, and that it might make sense to merge the projects, or at 
least to continue moving Struts in the direction of making it easier to 
plug in alternate presentation frameworks:

   http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22749.html
   http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22760.html

My questions are really for Struts developers (and Maverick developers):

Is there consensus that making Struts more presentation-pluggable, or in 
some other way more amenable to using other presentation frameworks, is the 
direction Struts should go?

If so, is there any plan for doing the work?  Is anyone doing active 
development in this area right now?  I have seen various references (the 
code linked from the above Model 2X article; Ted Husted's "Velocity 
servlet") that indicate that people have done some work in this area 
already, but it certainly hasn't made it into the Struts mainline.  Will 
it?  How?

I am very motivated to help make this happen... unfortunately I'm 
time-constrained.  But having a clearer picture of whether others are 
moving in this direction could help me (and others?) understand eactly 
where to pitch in to move this forwards.

Your thoughts?
Cheers,
Rob Jellinghaus
(committer on the Axis project)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [Resend] Struts, view-framework pluggability, XSLT, and Maverick

Posted by Dennis Doubleday <de...@righthandmanager.com>.
There has been a lot of activity over on the Velocity list for the past
couple of months working on a Velocity/Struts integration. Some people
are already using it, but it isn't released yet. They have been working
on Struts API to the presentation layer as part of the effort to allow
for plugging in other front ends.

> -----Original Message-----
> From: Marcelo Vanzin [mailto:vanza@rededc.com.br] 
> Sent: Thursday, April 11, 2002 3:16 PM
> To: Struts Users Mailing List
> Subject: Re: [Resend] Struts, view-framework pluggability, 
> XSLT, and Maverick
> 
> 
> Rob Jellinghaus wrote:
>  > Is there consensus that making Struts more 
> presentation-pluggable, or  > in some other way more amenable 
> to using other presentation  > frameworks, is the direction 
> Struts should go?
> 
> 	From my point of view, Struts is not that much tied 
> into JSP than it 
> seems. Actually, plugging in another view manager seems pretty 
> straight-forward.
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [Resend] Struts, view-framework pluggability, XSLT, and Maverick

Posted by Marcelo Vanzin <va...@rededc.com.br>.
Rob Jellinghaus wrote:
 > Is there consensus that making Struts more presentation-pluggable, or
 > in some other way more amenable to using other presentation
 > frameworks, is the direction Struts should go?

	From my point of view, Struts is not that much tied into JSP than it 
seems. Actually, plugging in another view manager seems pretty 
straight-forward.

	Let's look at Velocity for example: instead of forwarding to a ".jsp" 
from withing actions, forward to a ".vm". Have a servlet mapping that 
sends all ".vm" requests to a "VelocityServlet" that prepares the 
context and loads the template.

	Actually, I've actually seen a .war around (I think it was in one of the 
lists) that shows the Struts example application (from 1.0) working with 
Velocity templates instead of JSP.

	Struts has a lot of funcionality implemented if you want to use JSP (look 
at all the tags, for example), but that does not mean it is tied to JSP 
and cannot be used with anything else currently. Plugging a new view 
engine is quite simple, taking the Velocity example as a starting point.

-- 
[]'s
Marcelo Vanzin
Touch Tecnologia
vanza@rededc.com.br
"Life is too short to drink cheap beer"


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [Resend] Struts, view-framework pluggability, XSLT, and Maverick

Posted by Jeff Pennal <je...@openroad.ca>.
Hi Rob,

Based on this posting, you may be interested in my project to 
incorporate XML/XSL into Struts called stxx 
(http://www.openroad.ca/opencode/stxx). I started this project because I 
did not like the tight linkage between struts and JSP and I wanted to 
implement an XML/XSLT solution with the strong backend of struts.

The implementation is simple enough, it is (mostly) a matter of added a 
new tag into your struts-config.xml file under the <forward> tag called 
<transform> which allows you to define zero to many different XSL files 
to transform the forward with. The Action classes in this case are 
expected to produce an XML document that the XSL can be transformed against.

All existing struts functionality will still work, stxx just add the 
ability to do XSL transformations.

Rob Jellinghaus wrote:
> [I sent this to struts-dev a couple of days ago.  So far, no response.  
> Gonna try once more, to struts-user and struts-dev together.  If no 
> response *this* time, then I'll assume the Struts community is pretty 
> much uninterested in this idea.]
> 
> One of the difficult things in open source development is getting a 
> sense of where a project is headed... todo information tends to only 
> slightly capture what a given group of hackers is really focused on, and 
> it's hard to glean total insight from the mailing lists.
> 
> So:  I am spinning up on open-source Java web app frameworks.  The main 
> contenders seem to be Cocoon, Struts, and Maverick.
> 
> Cocoon (http://xml.apache.org/cocoon) looked really good (especially its 
> focus on efficient SAX processing), but it seems that Cocoon started 
> from a document processing orientation (publishing content in lots of 
> different ways) rather than from an interactive application orientation 
> (supporting control flow throughout an interactive web app).  Cocoon has 
> support for interaction but it is hard to see how to use it, especially 
> once I started looking at Struts where it couldn't be clearer.  So I 
> have (with some regret) backed off of Cocoon.
> 
> Struts (http://jakarta.apache.org/struts, of course) has a very 
> straightforward concept of action mapping and website interaction, which 
> I like a lot.  Its documentation is also in very good shape, and its 
> developer community seems to be thriving.  However, Struts is currently 
> fairly wedded to JSP, at least in its 1.0.2 and 1.1-beta distributions; 
> there seems to be no integrated support for using non-JSP 
> presentations.  Especially when compared to:
> 
> Maverick (http://mav.sourceforge.net) has (on cursory examination) a 
> clean ability to plug in different presentation frameworks.  (JSP, XSLT, 
> or Velocity at the moment.)  It also seems to share Struts' ease of 
> interaction configurability.  However, it also is a lot younger than 
> Struts, and it lacks the mass of Struts examples and documentation.
> 
> In an email thread discussing the Model 2X Javaworld article 
> (http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html), 
> Ted Husted and Jeff Schnitzer seemed to agree that Struts and Maverick 
> had a lot in common, and that it might make sense to merge the projects, 
> or at least to continue moving Struts in the direction of making it 
> easier to plug in alternate presentation frameworks:
> 
>   http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22749.html
>   http://www.mail-archive.com/struts-user@jakarta.apache.org/msg22760.html
> 
> My questions are really for Struts developers (and Maverick developers):
> 
> Is there consensus that making Struts more presentation-pluggable, or in 
> some other way more amenable to using other presentation frameworks, is 
> the direction Struts should go?
> 
> If so, is there any plan for doing the work?  Is anyone doing active 
> development in this area right now?  I have seen various references (the 
> code linked from the above Model 2X article; Ted Husted's "Velocity 
> servlet") that indicate that people have done some work in this area 
> already, but it certainly hasn't made it into the Struts mainline.  Will 
> it?  How?
> 
> I am very motivated to help make this happen... unfortunately I'm 
> time-constrained.  But having a clearer picture of whether others are 
> moving in this direction could help me (and others?) understand eactly 
> where to pitch in to move this forwards.
> 
> Your thoughts?
> Cheers,
> Rob Jellinghaus
> (committer on the Axis project)
> 
> 
> -- 
> To unsubscribe, e-mail:   
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: 
> <ma...@jakarta.apache.org>
> 




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [Resend] Struts, view-framework pluggability, XSLT, and Maverick

Posted by "Roman V. Petrov" <po...@actimind.com>.
RJ> [I sent this to struts-dev a couple of days ago.  So far, no
RJ> response.  Gonna try once more, to struts-user and struts-dev together.  If 
RJ> no response *this* time, then I'll assume the Struts community is pretty 
RJ> much uninterested in this idea.]

I told here that I don't agree with JSP orientation of the Struts.
However I think there are many Struts users use this way and
it is not so easy to migrate to another approach.
My opinion Maverick is more progressive framework in the View part.
You just can use and support framework you wish.

                     Sincerely yours, Roman Petrov

</></></></></></></></></></></></></></></></></></></></>
Software Engineer                    Actimind, Inc.
Software Development Department      http://www.actimind.com
E-mail: poma@actimind.com            Saint-Petersburg, Russia


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>