I would like to see the 'domify adapter' portion as a component.
The Apache Xang project was based on a similar concept - a virtual DOM.

The Xang servlet used the request path to navigate down a virtual DOM based on the values of the 'name' attributes of whatever element it found. At any point an 'xlink' that referenced some java could 'drift' into another virtual DOM. Something like <foo xml:link="java" factory="org.apache.xang.xml.plugin" />

I had some in-house code to do this for RDBMS data sources, but couldn't release it. Having an open source DOM datasource would be nice.


Mike

> -----Original Message-----
> From: Jeff Schnitzer [mailto:jeff@infohazard.org]
> Sent: Saturday, June 09, 2001 1:20 AM
> To: general@xml.apache.org
> Cc: scotthernandez@hotmail.com
> Subject: RE: MVC (Servlet-->JSP) to XSLT delegation example or
> framework?
>
>
> This is probably a good time to bring up a project that a friend and I
> have been working on and are hoping to get adopted into the Apache XML
> project some day:
>
> http://mav.sourceforge.net
>
> Maverick is a simple, lightweight MVC web application framework which
> allows you to use XSLT directly for view templating.  The MVC
> separation
> is similar to Struts or WebWork, but in addition:
>
> . Your JavaBeans models are automagically adapted (using Java
> reflection) to a DOM representation for use by the XSLT engine.  There
> is no need for intermediate templating languages like JSP or XSP, and
> the overhead of generating and parsing XML is eliminated.
>
> . You can configure an arbitrary number of successive transformations
> for each view.
>
> . You can halt the transformation proccess at any step and
> output static
> XML for designers to work with.  Just add a special request
> parameter to
> the URL.
>
> . Static content is seamlessly integrated, offering the same
> transformation pipeline options.
>
> It also works well with JSP templating, either for producing
> XML or for
> rendering HTML directly.  In fact, even without XSLT, Maverick makes a
> pretty good MVC framework - you can mix and match templating engines,
> allowing XSLT to be introduced over time.
>
> Here is a short snippet of a sample Maverick configuration file, which
> should give a pretty good idea how it works:
>
>   <command id="runQuery">
>     <controller type="org.infohazard.example.controller.RunQuery" />
>              
>     <view id="success">
>       <source-model node="result"/>
>       <pipeline>
>         <transform src="queryResult.xsl" />
>         <transform src="lookAndFeel.xsl" />
>       </pipeline>
>     </view>
>
>     <view id="error">
>       <source-model node="error"/>
>       <pipeline>
>         <transform src="queryFailed.xsl" />
>         <transform src="lookAndFeel.xsl" />
>       </pipeline>
>     </view>
>   </command>
>
> This pattern (which uses the "domify" adapter) allows JSP and
> custom tag
> libraries to be wholly replaced with XSLT's much more elegant (IMHO)
> syntax.  Note that the adapter only calls methods on the
> JavaBeans model
> as the transform engine navigates the DOM, so unqueried parts of the
> bean graph are never touched.
>
>
> Regarding the need to provide different types of content (HTML, WML,
> etc):  There are a couple approaches one could take.  One would be to
> have "runQueryHTML" and "runQueryWML" commands whose views run though
> different transformations.  Alternatively you could have the
> controller
> detect the agent and then forward to "successHTML" or
> "successWML"; this
> logic could even be put in a controller base class.
>
>
>
> Who can I talk to about offering this to the ASF?  I realize
> that there
> is significant overlap with Cocoon, but Jakarta has both Struts and
> Turbine, so maybe the XML project is underrepresented by web
> publishing
> frameworks :-)
>
> The reasons I think Maverick would make a good Apache project:
>
> . The "domify" adapter is useful by itself and can be broken
> out into a
> common project.  Cocoon (and other projects) may want to use it.
>
> . The MVC framework can use just about any templating engine either to
> produce XML or for direct output.  This provides another framework
> option for Velocity users.
>
> . Maverick should be familiar to users of Struts, but has much, much
> more comprehensive support for XSLT.
>
> . Maverick offers a second option for XSLT web publishing to all the
> people that are scared off by the sophistication/complexity of Cocoon.
>
> . It's pretty much release-quality.
>
>
> Is this something that would be of interest to the Apache community,
> either now or in the future?
>
> Jeff Schnitzer
> jeff@infohazard.org
>
>
> > -----Original Message-----
> > From: Curt Smith [mailto:smithc04@dcor.state.ga.us]
> > Sent: Friday, June 08, 2001 10:42 AM
> > To: general@xml.apache.org
> > Subject: MVC (Servlet-->JSP) to XSLT delegation example or
> framework?
> >
> >
> > Greetings,
> >
> > I'm needing to assemble a best of bread server side
> > architecture to support multple
> > client types (HTML, VXML, WML).
> >
> > The appserver vendors have their wireless/mobile framworks
> > that are a range of
> > proprietary and not-well designed frameworks.   The Bluestone
> > wireless framework
> > is MVC at least.  But I'd prefer source with the framework
> > since the controller Servlet
> > usually needs custom domain specific code.
> >
> > I'm looking for any subcomponent or whole parts of the
> > framework that delagates
> > from the View JSP to XSLT to form the final output stream.
> >
> > How about an example of how a JSP delegates to Xalan. 
> > There's a sample
> > servlet but not how a JSP might delegate it's output to an
> > XSLT input and the
> > transformed output being sent to the http.response stream??
> >
> > Thanks for any helps.
> >
> > curt
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > In case of troubles, e-mail:     webmaster@xml.apache.org
> > To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> > For additional commands, e-mail: general-help@xml.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>