Stephan Coboos <[EMAIL PROTECTED]> writes:
>
> Christopher Oliver wrote:
>
> > Um, how much harder is this:
> >
> > <map:match pattern="listProducts">
> > <map:generate type="file" src="products.xml"/>
> > <map:call function="readProductBeans"/>
> > </map:match>
> >
> > <map:match pattern="listProducts-result-pipeline">
> > <map:generate type="jxt"/>
> > <map:transform type="xslt"/>
> > <map:serialize/>
> > </map:match>
>
>
> Yes we had tried this solution, too. But we have much more
> flowscripts
> than only readProductBeans and for each one we have to split our
> pipeline.
Well there's one problem, if you look through the archives you'll see
that you can do at least half of this generically:
<map:match pattern="*/**">
<map:call function="main">
<map:parameter name="p1" value="{1}"/>
<map:parameter name="p2" value="{2}"/>
</map:call>
</map:match>
Though I prefer the more general pattern that also selects on the
request method and calls the continuation on POST. That aside, your
flowscript then can do things like:
function main( source, screen ) // p1, p2 from sitemap...
{
/*
Apply any screen specific overrides
*/
var sFunc = this[ screen ];
if ( sFunc != undefined )
{
var args = new Array( source, screen );
sFunc.apply( this, args );
}
else
{
while ( true )
{
if ( _sendPageAndValidate( "run/_page/" + screen, source
) )
_performAction( );
}
}
}
}
function readProductBeans( source, screen ) // Page specific logic
{
.
.
.
}
It might not be possible for all your returns into the sitemap to be
generic, 80% of our pages are handled by a pipeline that resembles:
<map:match pattern="*/_page/**">
<map:call resource="default"/>
<map:act set="default">
<map:transform
src="stylesheets/resolveobjectswithdata.xsl"/>
<map:transform src="stylesheets/renderhtml.xsl">
<map:parameter name="dataId" value="{dataId}"/>
<map:parameter name="parentId" value="{parentId}"/>
<map:parameter name="refId" value="{refId}"/>
</map:transform>
<map:serialize/>
</map:act>
</map:match>
However, in some cases the page specific logic calls other sitemap
patterns.
> Therefore the sitemap will become a unreadable
> size. The other
> point is, if you (as designer or htmler) dont know, what function
> readProductBeans does you cant decide which pipeline will be called
> next. In you example, it is easy. In real projects it is possible to
> become a terrible find action. It would be more understanding for the
> html-designer if you can say: Here are your templates and
> with this call
> you can get all your data you need. Do it.
>
> We want to creat a more generic way in which the
> html-designer is able
> to plug-in his on pipelines. No we are doing something like
> this and I
> think this is not the best solution:
>
> <map:match pattern="listProducts">
> <map:generate type="file"/>
> <map:act type="listProductAction"/>
> <map:transform type="xslt"/>
> <map:serialize/>
> </map:match>
>
I think if you're creating many different sitemap matches your
application logic is not generalized enough. Actions, flowscript, XSLT
and every component of Cocoon that I can think of can all be parameter
driven, there should be no reason to have dozens of page specific
matchers in the pipeline.
Part of the trick here is not to directly use XSLT to build pages but
rather to render templates to build pages. You turn your html design
process into a process of describing templates that are turned into HTML
by an XSLT. Desigerns add generic logic to the XSLT to get new page
design elements and then add new elements to the templates to invoke
these elements, but all design elements are available to all pages and
specific page logic isn't needed.
