You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2001/06/27 16:35:04 UTC
[C2] docs: draft on matchers and selectors
Hi.
I have written down what I was able to figure out on matchers and
selectors. Please comment. Especially, if you happen to have
implemented this stuff :-)
I will XMLize it to match the other docs after the first round of
comments. (no comments, no XML ;-)
Speaking of comments, there are currently two of my patches still
neither commented, rejected nor applied. And I'm sitting on two more...
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [C2] docs: draft on matchers and selectors
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 28.Jun.2001 -- 08:06 AM, Carsten Ziegeler wrote:
> 1.) In the second chapter you have this example:
> <map:match pattern="*/*/*?user=*">
> As the WildcardURIMatcher does only match against the url
> without the parameter that match doesn't work. This match
Changed to:
[...]
the key is arbitrary and set by the matcher. If you had supplied a
more complex pattern, there would be others. For example <map:match
pattern="*/*/*/*/report.html"> would result in keys "1", "2", "3", and
"4" being defined, corresponding to the "*"s in the pattern.
BTW you cannot access those maps from your XSP. Use parameters to the
generator to explicitly send them. On your XSP you can access them
through an object called "parameters". Example
<map:match pattern="*/*/*/*/report.html">
<map:generate type="serverpages" src="docs/getPostcodeData.xsp">
<parameter name="postcode" value="{1}{2} {3}{4}"/>
</map:generate>
<map:transform src="stylesheets/html/report.xsl"/>
<map:serialize/>
</map:match>
On your XSP do
<xsp:expr>parameters.getParameter("postcode")</xsp:expr>
> 2.) Second chapter:
> > Actions should be used to "do" something, not to chose between
> > different sub pipelines. That should be done only, if an error occurred
> > and you cannot continue the regular pipeline.
> I think this is to restrictive. For example an authentication action
> tests if the current client is authenticated and decides what to do.
> If you are not authenticated, the "sub pipeline" is not invoked, but
> I won't call this an error.
Well, certainly not an error that occurred during the processing but
existed before. So how about:
Actions should be used to "do" something, not to chose between
different sub pipelines. That should be done only, if an error
occurred and you cannot continue the regular pipeline. Of course this
is a fuzzy criterion and using an action to chose between exacty two
sub pipelines is a very common task i.e. for authentication. Also,
often actions have no nested elements and the further processing
is not affected by the result of the action.
I believe one problem to understand this stuff is, actions could do
everything matchers or selectors can do. The same is true for
matchers. Therefore two of these constructs are not necessary, you
could do easily without them, just with matchers or actions. So I
though this was a good rule of thumb.
> 3.)
> > If you would like to do global configuration for your matcher, it has
> > to implement the
> No, Configurable is only needed if your component has a configuration,
> like the browser selector. Component is needed as this is an Avalon
> component.
You're right. I did some experiments yesterday that were successful
only ofter implementing all three interfaces, but I must have made
an error since today Configurable is sufficiant (Component wasn't
sensible anyway since Matcher is a specialization of Component).
BrowserSelector is no good example since it is a factory. Currently,
only factories accept global parameters.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 27.Jun.2001 -- 12:20 PM, Seth Ladd wrote:
> I have a quick question. Can XSP pages see and take advantage of the Map
> that is returned from the Action? This concept of the Map (and the
> objectModel) is some of the last pieces that I'm still trying to wrap my
> head around.
No, you can't AFAIK. But see below
"Giacomo Pati" wrote:
> "Morrison, John" wrote:
> >
> > How do I can I use wildcard matching in the path and pass the results to an
> > xsp page as a parameter?
>
> Use:
>
> <map:match pattern="*/*/*/*/report.html">
> <map:generate type="serverpages" src="docs/getPostcodeData.xsp">
> <parameter name="postcode" value="{1}{2} {3}{4}"/>
> </map:generate>
> <map:transform src="stylesheets/html/report.xsl"/>
> <map:serialize/>
> </map:match>
>
> The parameters are accessible in your xsp page as
>
> org.apache.avalon.Parameters parameters;
Then you can use <xsp:expr>parameters.getParameter("postcode")</xsp:expr>
Other solutions would be:
* request attributes
* session attributes
Map is usually java.util.HashMap. It it used to store an arbitrary
number of return parameters from actions, matchers &c. They are
organised hierarchically and accessed through a X-Path like
syntax. New maps are added at a lower level.
objectModel keeps some of the environment and is created in
org.apache.cocoon.environment.http.HttpEnvironment for HTTP and for
commandline in a similar class.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] docs: draft on matchers and selectors
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi Christian,
I just looked through your draft and think it is really a very good
documentation for beginners.
Here are some comments, so that we get the XML version ;-)
1.) In the second chapter you have this example:
<map:match pattern="*/*/*?user=*">
As the WildcardURIMatcher does only match against the url
without the parameter that match doesn't work. This match
does not match for any request as the '?' is not a
character allowed in the url.
For matching parameters you should use other matchers.
2.) Second chapter:
> Actions should be used to "do" something, not to chose between
> different sub pipelines. That should be done only, if an error occurred
> and you cannot continue the regular pipeline.
I think this is to restrictive. For example an authentication action
tests if the current client is authenticated and decides what to do.
If you are not authenticated, the "sub pipeline" is not invoked, but
I won't call this an error.
3.)
> If you would like to do global configuration for your matcher, it has
> to implement the
> org.apache.avalon.framework.configuration.Configurable,
> org.apache.avalon.framework.thread.ThreadSafe, and
> org.apache.avalon.framework.component.Component interfaces.
>
> (not sure about this, is it really necessary to implement all three of
> them?)
No, Configurable is only needed if your component has a configuration,
like the browser selector. Component is needed as this is an Avalon
component.
I am not sure quiet sure if ThreadSafe is required for matchers and
selectors. It is required for Actions. ThreadSafe indicates that
this component can be used parallel by several threads.
(For more information on these interfaces refer to the avalon site).
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> -----Ursprungliche Nachricht-----
> Von: Christian Haul [mailto:haul@dvs1.informatik.tu-darmstadt.de]
> Gesendet: Mittwoch, 27. Juni 2001 16:35
> An: cocoon-dev@xml.apache.org
> Betreff: [C2] docs: draft on matchers and selectors
>
>
> Hi.
>
> I have written down what I was able to figure out on matchers and
> selectors. Please comment. Especially, if you happen to have
> implemented this stuff :-)
>
> I will XMLize it to match the other docs after the first round of
> comments. (no comments, no XML ;-)
>
> Speaking of comments, there are currently two of my patches still
> neither commented, rejected nor applied. And I'm sitting on two more...
>
> Chris.
>
> --
> C h r i s t i a n H a u l
> haul@informatik.tu-darmstadt.de
> fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 27.Jun.2001 -- 09:18 PM, giacomo wrote:
> On Wed, 27 Jun 2001, Christian Haul wrote:
>
> > On 27.Jun.2001 -- 01:43 PM, Donald Ball wrote:
> > > On Wed, 27 Jun 2001, giacomo wrote:
> > >
> > > > Sorry, Chritian, not having picked up your patches so far. I'm a little
> > > > bit under deadline pressure from projects I'm working on. If some of the
> > > > other Cocoon developpers have the time to check the patches and apply
> > > > them, good, else I'll review them at a later point.
> >
> > You've been forgiven ;-) I'm a bit of the impatient kind and like to
> > remind outstanding patches from time to time.
> >
> > > you know what we need? we need a patch queue so that people can submit
> > > patches and they'll sit in the queue until flagged patched or rejected.
> > > does bugzilla have any support for such a notion?
> >
> > Well, there's "Severity: Enhancement". That could be used for a patch
> > queue.
>
> And put the patches into the description box?
Yes. Even better, put a description and a URL to the patch in
there. Afterall, there're so many free (beer) webspace providers, that
most could do with such a solution. Well, and those that don't have
any free space could still put the patches in the description
field. But I guess it's easier for you to get URLs.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by giacomo <gi...@apache.org>.
On Wed, 27 Jun 2001, Christian Haul wrote:
> On 27.Jun.2001 -- 01:43 PM, Donald Ball wrote:
> > On Wed, 27 Jun 2001, giacomo wrote:
> >
> > > Sorry, Chritian, not having picked up your patches so far. I'm a little
> > > bit under deadline pressure from projects I'm working on. If some of the
> > > other Cocoon developpers have the time to check the patches and apply
> > > them, good, else I'll review them at a later point.
>
> You've been forgiven ;-) I'm a bit of the impatient kind and like to
> remind outstanding patches from time to time.
>
> > you know what we need? we need a patch queue so that people can submit
> > patches and they'll sit in the queue until flagged patched or rejected.
> > does bugzilla have any support for such a notion?
>
> Well, there's "Severity: Enhancement". That could be used for a patch
> queue.
And put the patches into the description box?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 27.Jun.2001 -- 01:43 PM, Donald Ball wrote:
> On Wed, 27 Jun 2001, giacomo wrote:
>
> > Sorry, Chritian, not having picked up your patches so far. I'm a little
> > bit under deadline pressure from projects I'm working on. If some of the
> > other Cocoon developpers have the time to check the patches and apply
> > them, good, else I'll review them at a later point.
You've been forgiven ;-) I'm a bit of the impatient kind and like to
remind outstanding patches from time to time.
> you know what we need? we need a patch queue so that people can submit
> patches and they'll sit in the queue until flagged patched or rejected.
> does bugzilla have any support for such a notion?
Well, there's "Severity: Enhancement". That could be used for a patch
queue.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by giacomo <gi...@apache.org>.
On Wed, 27 Jun 2001, Donald Ball wrote:
> On Wed, 27 Jun 2001, giacomo wrote:
>
> > Sorry, Chritian, not having picked up your patches so far. I'm a little
> > bit under deadline pressure from projects I'm working on. If some of the
> > other Cocoon developpers have the time to check the patches and apply
> > them, good, else I'll review them at a later point.
>
> you know what we need? we need a patch queue so that people can submit
> patches and they'll sit in the queue until flagged patched or rejected.
> does bugzilla have any support for such a notion?
I had a look into bugzilla for the last 20 minutes but havent found such
an option. Pier, is there some tools which can be used as a patch quere?
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 27 Jun 2001, giacomo wrote:
> Sorry, Chritian, not having picked up your patches so far. I'm a little
> bit under deadline pressure from projects I'm working on. If some of the
> other Cocoon developpers have the time to check the patches and apply
> them, good, else I'll review them at a later point.
you know what we need? we need a patch queue so that people can submit
patches and they'll sit in the queue until flagged patched or rejected.
does bugzilla have any support for such a notion?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] docs: draft on matchers and selectors
Posted by giacomo <gi...@apache.org>.
On Wed, 27 Jun 2001, Christian Haul wrote:
Sorry, Chritian, not having picked up your patches so far. I'm a little
bit under deadline pressure from projects I'm working on. If some of the
other Cocoon developpers have the time to check the patches and apply
them, good, else I'll review them at a later point.
Giacomo
> Hi.
>
> I have written down what I was able to figure out on matchers and
> selectors. Please comment. Especially, if you happen to have
> implemented this stuff :-)
>
> I will XMLize it to match the other docs after the first round of
> comments. (no comments, no XML ;-)
>
> Speaking of comments, there are currently two of my patches still
> neither commented, rejected nor applied. And I'm sitting on two more...
>
> Chris.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2] docs: draft on matchers and selectors
Posted by giacomo <gi...@apache.org>.
On Wed, 27 Jun 2001, Seth Ladd wrote:
> > I have written down what I was able to figure out on matchers and
> > selectors. Please comment. Especially, if you happen to have
> > implemented this stuff :-)
>
> Thanks very much! I've been spending the last few days researching all of
> this in preparation for implementation. I think what we want is a
> combination of Actions (to generate more values in the Map) and XSP for
> generation.
>
> I have a quick question. Can XSP pages see and take advantage of the Map
> that is returned from the Action?
No, they can't, except you know whats in the Map so you can pass the
values as parameters to the XSP page.
Giacomo
> This concept of the Map (and the
> objectModel) is some of the last pieces that I'm still trying to wrap my
> head around.
The objectModel is used to pass environmental specific component/objects
to the sitemap components (Actions, Genrators, Transformer, Matcher,
Selectors). This way any Environment could be implemented and pass
specific stuff down to the sitemap components.
Giacomo
>
> Thanks again, your document really helped.
> Seth
>
>
> ---------------------------------------------------------------------
> 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
RE: [C2] docs: draft on matchers and selectors
Posted by Seth Ladd <se...@brivo.com>.
> I have written down what I was able to figure out on matchers and
> selectors. Please comment. Especially, if you happen to have
> implemented this stuff :-)
Thanks very much! I've been spending the last few days researching all of
this in preparation for implementation. I think what we want is a
combination of Actions (to generate more values in the Map) and XSP for
generation.
I have a quick question. Can XSP pages see and take advantage of the Map
that is returned from the Action? This concept of the Map (and the
objectModel) is some of the last pieces that I'm still trying to wrap my
head around.
Thanks again, your document really helped.
Seth
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org