> > This is likely an issue you're going to run into also; mapping XPath to
> > random session objects might be possible, but I suspect the two domains
> > aren't perfectly isomorphic :-(
>
> Yes, but since we don't need to work on strings, less so. All these
> modules work on Objects and only on some occasions you really want
> strings.
I still think you'll have the problem. Suppose for example an object
contains a vector of other objects and it's really some value in the other
objects that you are interested in. In general, in such cases you may not
know the class of the Vector elements. Eg;
foo/patient/patient_number
where patient inherits from person, might not work if the Vector happens to
have a mix of both cases (not all people are patients). Of course you can
handle this, but you're either going to have to demand that your audience
have good knowledge of the possible session objects or you're going to have
to have very robust (and meaningful) error handling.
> > No more matchers, no more selectors; just XSLT templates ;-)...
Seriously,
> > once (if?) XSLT 2 gains regex capabilities I can't really see why a pure
> > XSLT pipeline couldn't do everything that matchers and selectors do,
therby
> > eliminating huge chunks of the current Cocoon code base?
>
> Maybe, maybe not. One would need to use a lot extension functions to
> achieve similar things (e.g. j2ee, databases and stuff) but that might
> be portable to other pipeline systems (?). OTOH Apache Cocoon a lot
> about SoC and it will need to be seen if that works as well with your
> suggested approach.
Much of the interfaces to external systems would become, in effect,
generators. These would be invoked dependant on context. However, if you
want to avoid extensions and do that intelligently you could use a two pass
approach:
1) a tree structure giving the hierarchy of the context's in scope for the
current request (ie the output of a modified request generator). This would
be filtered by an XSLT to generate the list of contexts required for the
current request.
2) the tree structure from the requested contexts would be generated and fed
to the second XSLT.
It's really the first thing that's replacing the matchers/selectors in the
pipeline. The second thing is essentially generation and aggregation as
currently done by the pipeline handling. This suggests that the whole thing
could be implemented by a new pipeline component -- some kind of context
selector generator (need a name that's not going to collide too much with
existing Cocoon components) -- that is also a generator. A pipeline using
such an approach might then become something like:
<map:match pattern="**">
<map:context-selector-generator-thingy
filter="businessfilter.xsl">
<map:transform src="mypath/business-logic.xsl"/>
<map:context-selector-generator-thingy
filter="presentationfilter.xsl">
<map:transform src="mypath/presentation-logic.xsl"/>
</map:context-selector-generator-thingy>
</map:context-selector-generator-thingy>
<map:serialize .../>
</map:match>
If you didn't specify a filter you'd get the identity transform and all
information available from the current context would be generated for the
next step. Normally, I doubt that you'd chain the thing as I've done above
(context should be context for any given request?), but there should be no
reason it wouldn't be possible; some dynamic presentation methodologies
might want to substitute new information once context results are better
understood or you may not want to retrieve and forward all data unless
needed (ie; large data set sizes). (In such a case you may really want two
business logic passes.)
> I believe, many would be interested in your approach. I hope you find
> the time to work on it.
I think this is almost a requirement for where we want to go with our
project. Tentatively we would begin work on such a beast next spring or
early summer.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
