I don't know if this is too much of a switch for you, but you could
also use flow. (Javaflow or flowscript) I have found that Javaflow
is supported much better across web application servers than
flowscript. If you only have to run in tomcat, no big deal. In
there, you can definitely take parameters, etc at run time that affect
processing. Plus, you have the benefit that you are already in java,
so you might be able to get more benefits than just this. This is
psuedo code I:
public void doTextPresentation(){
Document dataObject = processToDOM( bibliographies );
getRequest().setAttribute( "dataObject", dataObject );
if( dataObject.getChild( "myParameter" ) ){
sendPage( "text2ei" );
}
else {
sendPage( "text2html" );
}
}
You would then have 3 pipelines, one for just generating the xml for
the bibliographies (you already have the generator, just serialize as
xml), and 2 other ones for styling the bibliographies. In their
generators, you can use the xmodule with a file generator:
<map:match pattern="text2ei">
<map:generate type="file" src="xmodule:request-attr:dataObject"/>
<map:transform type="xslt" src="styles/text2ei.xsl"/>
<map:serialize type="html"/>
</map:match>
This actually breaks things up a little nicer, a little more fine
grained. It opens the possibility of being able to create the
bibliographies from other mechanisms (like as XML input). It also
doesn't incur really any large performance penalties. (Of course
ignoring if you turned off caching and didn't buffer output if you had
extremely large bibliograhpies)
You might also find that if you are in javaflow like this, you might
be able to even do different things to produce your bibliographies
(like not needing a pipeline, etc) I don't know exactly what your
generators do.
Irv
On 8/29/05, Nick Goupinets <[EMAIL PROTECTED]> wrote:
> Hi Irv, Eric,
>
> Thank you very much for your replies. I guess I need to explain what I
> am trying to achieve. There is a Bibliography object that encapsulates
> an xml document (meta information about a text) together with its
> presentation type (xml, html, tei, dublin core, etc.). Both are defined
> by the user. There are style sheets for each of the presentation types.
>
> I created a generator that gets the xml for bibliographies. Now the only
> thing that's left is to convert the generic text meta-data into
> appropriate format. I can easily do that by creating an action that
> would return the presentation type:
>
> <map:act type="text-presentation">
> <map:parameter name="bibliography" value="{request-param:biblId}"/>
> <map:generate type="bibliographies" src="{request-param:biblId}"/>
> <map:select type="parameter">
> <map:parameter name="parameter-selector-test"
> value="{presentation}"/>
> <map:when test="tei">
> <map:transform src="styles/text2tei.xsl"/>
> <map:serialize type="xml"/>
> </map:when>
> <map:when test="html">
> <map:transform src="styles/text2html.xsl"/>
> <map:serialize type="html"/>
> </map:when>
> ....
> </map:select>
> </map:act>
>
> So in this case the action gets the bibl id, reads the bibl from the
> back end, and returns its type to the sitemap (available as
> {presentation}). The generator then reads the same object based on bibl
> id and generates the SAX event for the xml stored in it. Now, based on
> the parameter retrieved by the action, appropriate xsl is selected.
>
> Sure enough it's possible to include the parameter into the XML produced
> by the generator, but in that case I will need to use cincludes to get
> the content that I want based on that parameter (AFAIK, SAX events can't
> affect the pipeline processing). It's an excellent idea, however, I will
> definitely apply it sometime later.
>
> I really hoped that it is possible to send a param from a generator to
> the sitemap, this way I can save one db access and a few lines in the
> sitemap. If that is not possible, I guess, I will end up implementing
> what I just described here.
>
> Thank you very much once again.
>
> Sincerely,
> Nick.
>
> Irv Salisbury wrote:
> > I think the other problem you are going to have in getting a solution
> > to this is that the parameters, actions, etc are all evaluated before
> > your sitemap is actually processed. So, I can't think of a way to
> > accomplish exactly what you are looking for.
> >
> >
> >
> > On 8/27/05, Eric Boisvert <[EMAIL PROTECTED]> wrote:
> >
> >>it's probably a dumb question but... why don't you include this parameter
> >>directly in the xml generated by the generator ?
> >>
> >>maybe you have a good reason or some sort of limitation .. just a though.
> >>
> >>Cheers
> >>Eric Boisvert
> >>
> >>
> >>>-----Message d'origine-----
> >>>De : Nick Goupinets [mailto:[EMAIL PROTECTED]
> >>>Envoyé : 27 août, 2005 16:50
> >>>À : users@cocoon.apache.org
> >>>Objet : Pass a parameter from generator/transformer to the sitemap
> >>>
> >>>
> >>>Hi everybody,
> >>>
> >>>I am trying to find out how to pass a parameter from generator /
> >>>transformer code to the sitemap. Ultimately, I would want something like
> >>>
> >>>this:
> >>>
> >>><map:generate type="my-generator"/>
> >>><map:transform type="some.xsl">
> >>> <map:parameter name="param" value="{param-created-by-my-generator}"/>
> >>></map:transform>
> >>><map:serialize/>
> >>>
> >>>That's pretty easy with actions (just get a HashMap returned), but how
> >>>can this be achieved with generators/transformers? I guess there are
> >>>always hacks with request/session attributes, but there must be a more
> >>>elegant way.
> >>>
> >>>Thank you very much for your help.
> >>>
> >>>Best regards,
> >>>Nick Goupinets.
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
