You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xsp-dev@xml.apache.org by Matt Sergeant <ma...@sergeant.org> on 2001/03/05 11:16:18 UTC
Re-using XSP internally in Cocoon (was Re: [RT] Rationalizing XSP
(was: XSP and aspects))
On Fri, 2 Mar 2001, Ricardo Rocha wrote:
> 3) Refactoring the XSP implementation to avoid redundance
>
> Currently, there are 2 overlapping, redundant "markup languages" in
> Cocoon2: XSP for server pages and XSP for the sitemap. Allan Erskine
> also mentions a possible "flowmap" which (in the current setup) would
> require the creation of a third MarkupLanguage implementation.
>
> Historically, the MarkupLanguage abstraction was meant to signify
> different code generation tagsets, namely: XSP (<xsp:logic>, <xsp:expr>)
> and JSP (<jsp:scriptlet>, <jsp:expr>). Admittedly, even for this case it
> was unnecessary: it would be much simpler to translate JSP code
> generation tags into their XSP counterparts without the need to
> introduce the notion of a code-generation markup language (SOM!)
>
> When the need for sitemap compilation was perceived and its
> implementation pursued, "MarkupLanguage" was understood as what I've
> called above the "program unit skeleton" so a new MarkupLanguage
> (pirated from the server pages XSP implementation) was created:
> SitemapMarkupLanguage.
>
> In fact, this was the only possible workaround that allowed the existing
> XSP code generation framework to be reused.
>
> Should I have timely decoupled the code generation engine from the
> target program type, we wouldn't have a separate sitemap MarkupLanguage
> today. Again:SOM! :-(
>
> Fortunately, the solution is obvious: deprecating MarkupLanguage and
> adding a separate program skeleton logicsheet step in the XSP code
> generation pipeline.
>
> This way, both the sitemap and server pages can reuse the code
> generation machinery without redundance.
>
> This is also true for "new" program types such as Transformers and, yes,
> Allan's flowmap.
This is a cocoon issue and should probably not have been included in this
RT to xsp-dev.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\