Your message is very timely, because I'm currently doing the same sort
of research.  I wrote my site ( www.similarity.com
<http://www.similarity.com> , an amusing basement project) using Rickard
Oberg's WebWork MVC framework to produce HTML directly, but now my team
and I are exploring more sophisticated options.
 
My desire is for an MVC framework which generates XML.  The XML would
then be transformed with XSLT on the way out by a filter.  Orion already
does this transformation if your output is XML; take a look at
$ORION_HOME/default-web-app/examples/xsl.  So it really doesn't matter
what MVC/templating framework you use as long as you generate XML;
Struts would work fine.
 
In fact, yesterday we wrote a spike solution using Struts (which now
works out-of-the-box with Orion 1.4.8) to generate XML and transform it
using the stylesheet tag in the XML document.  It works great.
 
I've been spending a lot of time researching MVC frameworks, and I'm
happy to offer my thoughts so far:
 
In the pure form, there are three stages we wish to isolate in building
our html (or wml, or whatever) pages:  Logic (the algorithmic world of
code), Content (the meaninful information which may be static or may
have been generated by logic), and Presentation (content transformed
into html, wml, pdf, or whatever can be attractively rendered for
display).
 
MVC frameworks like Struts and WebWork do not distinguish between
Content and Presentation.   Really the "MVC Framework" just covers the
first two phases of a "Web Publishing Framework".  The third phase is
covered by XSLT transforming filters applied to the View after
generation.  Orion provides this automatically.
 
Within the MVC process, however, there is another
templating/transformation process to build the Content from the Logic.
Some frameworks (Struts and WebWork) use JSP optionally with custom tag
libraries.  Some frameworks (Turbine) allow you to plug in a variety of
templating systems, such as Velocity.  Cocoon uses XSP (Xml Server
Pages).  This is entirely independent from the Content to Presentation
transformation process which occurs later using XSLT.
 
It sounds like Tim has a homebrew system for going directly from Logic
to Presentation.  My team has been thinking of eventually writing a
wrapper to expose JavaBeans (the model) as a DOM using reflection so you
could still have a pull-based system rather than having to build the
full tree ahead of time.  I'm not sure it's ultimately desirable to skip
the Logic->Content step, although it would improve performance.
 
As far as specific frameworks go:
 
Cocoon is the most comprehensive solution.  Cocoon2 sounds like it's
going to be even better.  I'm not too fond of this framework though
because you have to be able to stomach XSP.  The syntax isn't very
elegant, IMHO.  I didn't look too closely at how their controller system
works.
 
Struts is pretty complicated, but it has a large support community and a
lot of developers working on it.  For a templating system you can use
either straight JSP or their elaborate set of taglibs.  It provides good
delineation of M, V, and C but it feels like you're programming fairly
close to the servlet api.  I'm sure this is easily avoided with a few
support classes.  Struts seems to be the favorite framwork of the Sun
blueprints authors, which gives it a lot of longevity.
 
WebWork is very much like Struts, but simpler (good), less mature (bad),
and lacking a development community (fatal).  The author is a smart guy,
but he's just one guy, and he doesn't seem interested in moving the
project towards a "community development" process.  One thing I *don't*
like about WebWork is that it tries to abstract the MVC system away from
servlets so that it could conceivably be used with Swing as well.  This
makes doing simple things like issuing redirects rather than forwards
very painful.  Also, WebWork has a novel but nonstandard way of getting
beans into the views, so tasks that aren't covered by the WebWork tag
library result in very ugly JSP scriptlets.
 
Turbine I've looked at the least, other than in the context of admiring
the Velocity template language (Velocity integrates well with Turbine).
I'd like to hear from anyone who has experience with Turbine and can
comment on its upsides and downsides.  I really like the elegance of
Velocity, but I suspect that I'm going to stick with JSP because that's
what I've been using so far.  And despite being a poor standard, JSP is
still a standard :-)
 
One option that should not be overlooked is writing your own simplified
MVC framework.  The "controllers" would be JSP pages which simply create
Action beans and do <jsp:setProperty> to populate them.  The controller
JSP would then forward to each view (or issue a redirect to another
controller JSP).  The only pain is when you have code you want to share
among the controller JSPs; the solution is to push as much of the logic
as possible into the Action bean.  I'm seriously considering this
approach beacuse it's so lightweight and noninvasive compared to Struts;
no worries that Struts might not install on platform X (such as Orion <
1.4.8 :-( ).
 
Good luck,
Jeff Schnitzer
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> 
http://www.similarity.com <http://www.similarity.com> 

-----Original Message-----
From: Vic Cekvenich [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 26, 2001 11:53 AM
To: Orion-Interest
Subject: MVC/XML Framework Comments please



We are bout to pick a a framework, and I am looking for are comments or 
recommendation on a frameworks, other than Struts. (Don't want to be 
HTML/JSP centric) Any feedback on your experience with a framework, or
do 
you know of web sites in production that are using a certain frame work,
or 
do you know of friend or someone who has used one. 

I would like it to be XML centric, and MVC. For example, the V should
apply 
the XSL to XML, to make it HTML. It should do standard session tracking.
It 
should do standard data manager, so that Java Beans do the SQL (the M).
A 
minor plus is form entry management and a bit of image/content
management. 
It should be a single rich framework. Here are a few we are considering:


http://www.jcorporate.com/html/products/productsfm.html
<http://www.jcorporate.com/html/products/productsfm.html>  

http://jakarta.apache.org/jetspeed/site/index.html
<http://jakarta.apache.org/jetspeed/site/index.html>  

and all the ones under Jakarta. 

We need to pick one soon. Any comments and feedback welcome on 
frameworks/class libraries. 

Thanks, [EMAIL PROTECTED] 


Reply via email to