> Say, you want to insert data to a database. Some data stems from request
> parameters, some from the session and some from request attributes set
> by another action. In order to make this possible, the database action
> needs to be flexible enough to do this. It used to read from request
> parameters only.
In our case, the XSLT has access to all the data in the request and the
session. If it's going to be round tripped, then we do so, but the action
doesn't need to determine where a particular value came from. The original
XSLT took care of determining that. If you're handling a lot of data in
this manner then doing round trips obviously doesn't make sense, but we'll
get to that in a bit...
> Say, you want to chose your pipeline in sitemap depending on some
> request parameter value, or a request header, or the current time
> of the day. You need to code an action to export this value to as
> sitemap parameter. With InputModules you can just say <map:generate
> src="context://docs/{request:/parameters/foo}.xml"/> or <map:generate
> src="context://docs/list-{date:now}.xml"/>
>
> Think of the various matchers and selectors in cocoon. What if you
> could just plug-in the data source? There wouldn't be sources * match
> type matchers.
This gets me to a pet issue of mine: If I ever get the time I'd really like
to build a version of the site map pipeline handler based XSLT that has all
context information available to it as XML; the request variables, session
data, etc. The XSLT could either act as a filter to some SAX event handler
or you could use XSLT extensions to invoke the Cocoon components directly or
you could use some form of import mechanism to invoke the Cocoon components.
The first is perhaps more pure to XSLT, but it could have strange
transformation/filtering requirements and be a little opaque to those not
comfortable with XSLT ;-) More on imports in a moment...
Using XSLT in such a way seems cleaner than constantly inventing new site
map semantics and parameters. Of course the performance of such a beast
might be sub-optimal. Then again, there's likely a lot of Cocoon overhead
that would be eliminated; you essentially end up with a master transform
that invokes other transforms. As such, XSLT import semantics might be a
reasonable way to go, but I doubt you could use them in native form since
some Cocoon components seem orthogonal to the transform process? However,
for the normal case you might have to instantiate parsing and transformation
many fewer times.
> Say, you want to use the skin specified in a session attribute, if not
> present a system default or if present a request parameter. That's what
> the DefaultsMetaModule does (well, only default and one source as of now).
> Plug-in the source and you're happy.
>
> Another advantage: If you have used your personal instances of these
> modules (highly advisable!), you could change the storage easily. So,
> you don't like to read the data from request parameters, a session is
> more secure? Well just switch to another InputModule.
But none of this has any advantage over examining the same data in an XML
tree via XSLT?
> JXPath comes into this, as for the request you may want to access
> parameters, attributes, headers, &c. In addition, I needed to access
> values from a java.util.Map. So, why have a request-attributes module
> and a request-parameters module if JXPath would provide this almost for
> free with a consistent interface that everyone is familiar with?
Yes, that certainly makes sense, you're extending the sitemap capabilities
to build in some of the capabilities of XSLT: but just the XPath portion. I
guess what I'd rather see (now that I understand what you're trying to do),
is a sitemap pipeline parser that was XSLT transform driven (user definable
of course). It likely wouldn't replace all of the sitemap, but rather would
be aimed at replacing just the pipeline handling. Ultimately my reason for
doing this is that the sitemap pipeline (as it exists today) ends up
encoding a lot of business and presentation rules. I want to have these
rules be configurable from a database (of some form). As such, I want to be
able to generate XML (from my database) that invokes rules, which are
written in XSLT. You're getting a long way there, but XPath by itself isn't
sufficient for all types of rule handling.
> XSP is completely absent from this picture. Actually, there's no
> support to use it from XSP as of today.
If I understand you're essentially creating many components reusable from
the pipeline and trying to have a single set of semantics to extract data
from these components into the pipeline? I'd guess the XSP folks would want
similar capabilities, but I can see why that's not your concern!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
