On Wed, 20 Jun 2001, Christian Haul wrote:
> Hi all.
>
> The attached patch adds the ability to specify a "target" in a
> <map:redirect-to resource=""> tag. The "target" is available as "{1}"
> in the resource specification.
Why not as "{target}"? And why not substitutable?
>
>
> Example
>
> <map:resources>
> <map:resource name="simple-page">
> <map:generate type="serverpages" src="test/{1}.xsp"/>
> <map:transform src="stylesheets/presentation.xsl"/>
> <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> <map:serialize/>
> </map:resource>
> </map:resources>
>
>
> <map:pipelines>
> <map:pipeline>
>
> <map:match pattern="test">
> <map:act type="form-validator">
> <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> <map:parameter name="validate-set" value="user-input"/>
> <map:redirect-to resource="simple-page" target="OK"/>
> </map:act>
> <map:redirect-to resource="simple-page" target="ERROR"/>
> </map:match>
>
> </map:pipeline>
> </map:pipelines>
>
> This way it is only necessary to specify required transformation steps
> only in one place. A redirection to a URL wouldn't work here as that
> would create a new request object which discards some values. In
> addition resources are not accessible from outside.
>
>
> Implementation
>
> Since maps (listOfMaps) is handed to resources, a new map is added to
> the listOfMaps with just one entry ("1","@target").
>
>
>
> Rationale
>
> A thing called "flowmap" has been discussed on this list for a long
> time. Recently I felt the need for such a thing as well. Anyway, it
> was not clear enough for me in which aspects a flowmap will differ from
> the sitemap. All in all I believe all the functionality for a flowmap
> is already present in the sitemap concept.
>
> As far as I am concerned, a sitemap would care about the URI mapping
> and transformation steps. A flowmap would be a XML representation of a
> state chart with states, sub states, transitions, triggers, guards and
> actions.
Yes, as Berin once stated the sitemap represents the "resources" and the
flowmap the "directed graphs" between them.
>
> States can be represented by matchers, sub states by nested
> matchers. Triggers are requests (request parameters) which could be
> represented by selectors. Transitions are allowed paths to other URIs
> or resources, guards can be realized by cocoon-actions with nested
> content and actions, well be be realized by cocoon-actions.
>
> This way every resource would need a separate definition.
>
> The patch allows to redirect to a common definition for
> transformation. So those two different concerns are separated, even if
> they live in the same file. Since resources from ancestor sitemaps can
> be accessed, this could be split up to that resources are only defined
> in the top level sitemap.
I don't like the fact that sub sitemap refers to parent ones.
Admittedly sub sitemap already refers to
sitemap components defined in the parent sitemap. But also Berin
proposed to move them out of the sitemap right into the cocoon.xconf
file (where all components are collected anyway).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
