cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [C2] Protected area app
Date Mon, 23 Apr 2001 20:01:07 GMT


On Mon, 23 Apr 2001, Allan Erskine wrote:

> > No, the {1} references the nearest parent and {../1} his parent so on.
>
> ahh - ok.  This is much better...
>
> Does the same go for nested actions?

Yes, you can mix them and get to the next upper Map by a new ../.

> (For sequential actions the returned
> maps are composed, right?)

Not sure what you mean by "sequential actions". If you put your
"sequential actions" into a "action-set" than yes otherwise not.

Giacomo

>
> Allan
>
> ----- Original Message -----
> From: "giacomo" <giacomo@apache.org>
> To: "cocoon-dev" <cocoon-dev@xml.apache.org>
> Sent: Monday, April 23, 2001 6:13 AM
> Subject: Re: [C2] Protected area app
>
>
> >
> >
> > On Mon, 23 Apr 2001, Allan Erskine wrote:
> >
> > > session validation in every map:match fragment?  I haven't thought of
> one
> > > myself, but if you could be assured that the following sort of fragment
> > > > > >
> > > > > > <map:match pattern="protected**">
> > > > > >     <session validator action>
> > > > > >         <any protected content generated/>
> > > > > >     </session validator action>
> > > > > >     <action failed>
> > > > > >         <back to login/>
> > > > > >     </action failed>
> > > > > > </map:match>
> > > > > >
> > > > > > were always evaluated before any protected content, surely this
> would
> > > be all it would take?  I'm probably missing something....
> > > > > No problem. Replace the <any protected content.../> above with
a
> <mount>
> > > > > element.
> > > > >
> > > >
> > > > wow, even me when designing these actions I haven thought about this
> and
> > > now I
> > > > found it very promissing :))
> > >
> > > Another approach you could try is just with nested matchers
> > >
> > > <map:match pattern="protected**">
> > >      <session validator action>
> > >         <map:match pattern="protected/page1">
> > >
> > >         </map:match>
> > >
> > >         <map:match pattern="protected/page2">
> > >
> > >         </map:match>
> > >
> > >      </session validator action>
> > >      <action failed>
> > >         <back to login/>
> > >      </action failed>
> > > </map:match>
> > >
> > > Seems to work quite well....one thing I'm unsure of though is what
> happens
> > > to values from matchers...if an internal wildcard matcher also matched
> **,
> > > I'm banking on {1} being temporarily overridden for the scope of the
> > > matcher, the same going for an action's map values...... this belief is
> pure
> > > faith on my part though - I haven't researched it... hope I'm right!
> >
> > No, the {1} references the nearest parent and {../1} his parent so on.
> >
> > Giacomo
> >
> > >
> > > Allan
> > >
> > >
> > > ----- Original Message -----
> > > From: "Martin Man" <Martin.Man@seznam.cz>
> > > To: <cocoon-dev@xml.apache.org>
> > > Sent: Friday, April 20, 2001 8:11 PM
> > > Subject: Re: [C2] Protected area app
> > >
> > >
> > > > On Thu, Apr 19, 2001 at 07:05:53AM +0200, giacomo wrote:
> > > > >
> > > > >
> > > > > On Thu, 19 Apr 2001, Allan Erskine wrote:
> > > > >
> > > > > > Regarding Martin's comment inside the protected area (it's been
a
> > > useful example for me - thanks!!), is there no clever way a matcher or
> > > selector can capture the aspect of repeated session validation in every
> > > map:match fragment?  I haven't thought of one myself, but if you could
> be
> > > assured that the following sort of fragment
> > > > > >
> > > > > > <map:match pattern="protected**">
> > > > > >     <session validator action>
> > > > > >         <any protected content generated/>
> > > > > >     </session validator action>
> > > > > >     <action failed>
> > > > > >         <back to login/>
> > > > > >     </action failed>
> > > > > > </map:match>
> > > > > >
> > > > > > were always evaluated before any protected content, surely this
> would
> > > be all it would take?  I'm probably missing something....
> > > > > >
> > > > > > For instance how about mounting a sitemap that doesn't care
about
> > > security, only if the validation on a security checking sitemap is
> > > passed....?
> > > > >
> > > > > No problem. Replace the <any protected content.../> above with
a
> <mount>
> > > > > element.
> > > > >
> > > >
> > > > wow, even me when designing these actions I haven thought about this
> and
> > > now I
> > > > found it very promissing :))
> > > >
> > > > > Giacomo
> > > > >
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > > >
> > > >
> > > > --
> > >
> > --------------------------------------------------------------------------
> > > -----
> > > > "Only dead fish swims with a stream"
> > > > gpg_key_available: http://globales.cz/~mman/martin.man.gpg
> > > > gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06
> 0223
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
>
>


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


Mime
View raw message