On 01.Oct.2002 -- 01:20 PM, Hunsberger, Peter wrote:
> >> I've been following this discussion for the last week or so and suddenly
> >> this morning I had to start questioning exactly what the true purpose of
> all
> >> this is? The idea of being able to dig out a value based on a precedence
> >> hierarchy makes sense, but XML and XSLT already have very good mechanisms
> >> for doing this (and Cocoon provides perfectly adequate ways of building
> XML
> >> and running XSLT!). Consider, for instance:
> >
> > You are absolutely right. It's just that these InputModules serve the
> purpose
> > of returning small values, and that often multiple times from the same
> source.
> > The DatabaseActions make use of this heavily. I wouldn't want to use
> pipelines
> > for obtaining 30 values through the use of the request generator and some
> xslt
> > resulting in 30 executions of this pipeline.
>
> I guess, that's part of the problem I have with this: I'm much more
> comfortable with producing XML directly as database output and using it
> directly in XSLT than I am in using the half procedural half functional XSP
> model (though perhaps you're using this some other way?). If you have an
> XML dataset and XSLT processing you usually don't need to reference a value
> multiple times (you use XSL keys, parameters or variables if you do). If
> you aggregate all your XML sources you don't need multiple processing steps
> (except as desired to separate business logic from presentation logic). So,
> once more I'm still wondering about exactly what the conceptual problem is
> that all of this is really supposed to solve?
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.
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.
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.
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?
XSP is completely absent from this picture. Actually, there's no
support to use it from XSP as of today.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
