Return-Path: Delivered-To: apmail-xml-general-archive@xml.apache.org Received: (qmail 24897 invoked by uid 500); 18 Jun 2001 16:48:02 -0000 Mailing-List: contact general-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: general@xml.apache.org Delivered-To: mailing list general@xml.apache.org Received: (qmail 24787 invoked from network); 18 Jun 2001 16:47:43 -0000 Message-ID: <8E864C73E16B864BB594712EDB3C89A0015C45D8@belmail2.datachannel.com> From: Mike Dierken To: "'general@xml.apache.org'" Cc: scotthernandez@hotmail.com Subject: RE: MVC (Servlet-->JSP) to XSLT delegation example or framework? Date: Mon, 18 Jun 2001 09:47:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F816.5A229A40" X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N ------_=_NextPart_001_01C0F816.5A229A40 Content-Type: text/plain; charset="iso-8859-1" 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 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: > > > > > > > > > > > > > > > > > > > > > > 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 > ------_=_NextPart_001_01C0F816.5A229A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: MVC (Servlet-->JSP) to XSLT delegation example or = framework?

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=3D"java" = factory=3D"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=3D"runQuery">
>     <controller = type=3D"org.infohazard.example.controller.RunQuery" = />
>       =        
>     <view = id=3D"success">
>       = <source-model node=3D"result"/>
>       = <pipeline>
>         = <transform src=3D"queryResult.xsl" />
>         = <transform src=3D"lookAndFeel.xsl" />
>       = </pipeline>
>     </view>
>
>     <view = id=3D"error">
>       = <source-model node=3D"error"/>
>       = <pipeline>
>         = <transform src=3D"queryFailed.xsl" />
>         = <transform src=3D"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
>

------_=_NextPart_001_01C0F816.5A229A40--