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
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
