> -----Original Message-----
> From: giacomo [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, June 20, 2001 15:26
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Patch][C2.1] sitemap redirections + target spec
>
>
> 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?
I would not say why not to use <map:parameters> as elsewhere else...
Like:
<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">
<map:parameter name="target" value="OK"/>
</map:redirect-to>
</map:act>
<map:redirect-to resource="simple-page">
<map:parameter name="target" value="ERROR"/>
</map:redirect-to>
</map:match>
This would be much more consistent.
Vadim
>
> >
> >
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
