[EMAIL PROTECTED] wrote:
> Reading inputs is fair enough. However reading random pipelines is > also possible. with 'oxf:/...'. The only drawback here is that you > have to design these pipes to be without input parameters.
You can call random pipelines from an XPL pipeline, but you cannot
call a pipeline from XSLT at this point! If from XSLT you write
document('oxf:/my-pipeline.xpl'), you will get back the source code of
the pipeline (i.e. the XPL file).> One way to do that (In German we would say: rueckwaerts durch die > Brust ins Auge = from behind through the chest into the eye) could > be to write all parameters needed into the session and have the > session processor retrieve them from there.
Not very elegant, I fear...
Still thinking about what's the best way to do this (this = some kind of pull approach to pipelines) based on the previous discussion on this list. To summarize, we have so far:
o The suggestion for a Cocoon-like "cocoon:" protocol, that we could call "pipeline:" or something. Benefit: you can call pipelines through URLs, a functionality currently missing. Drawback: if this must not be a hack, you have to think about how you are going to pass and return documents to and from the pipeline's outputs.
o The suggestion for a PFC protocol able to access the output of pages declared in the Page Flow configuration.
o The suggestion for functions in XSLT to call random pipelines.
o On top of that, better support for implementing what I call "tag libraries" that does not require the user to use XSLT to dynamically generate pipelines.
> Hhm once we touch resource-managers could we come up with a portal > compliant resource manager? I analyzed IBM portal and what they do > is actually clever. They retrieve a) the browser b) the language c) > the theme (via cookie) and search for the most specific > resource. (They do it in JSP only <find-in-resource id="logo.gif" > />). SO it searches for /resources/spring/moz7/en/logo.gif then > /resources/spring/moz7/logo.gif then /resources/spring/logo.gif then > /resources/logo.gif. The first match is retrieved and cached.... > This way broser specifics (mostly JavaScript and CSS) and Themes > could be implemented with a blink.
My only worry would be to consider how such a mechanism could be made generic. Retrieving the resource depends on certain parameters, but which ones? Do you hardcode the fact that it looks for the browser and the language?
-Erik
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ orbeon-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/orbeon-user
