cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@hns.com>
Subject RE: [Patch][C2.1] sitemap redirections + target spec
Date Wed, 20 Jun 2001 20:20:03 GMT
> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Wednesday, June 20, 2001 15:26
> To: cocoon-dev@xml.apache.org; haul@informatik.tu-darmstadt.de
> Cc: dims@yahoo.com
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message