forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: svn commit: r423454 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
Date Fri, 21 Jul 2006 09:34:24 GMT
El vie, 21-07-2006 a las 10:25 +0200, Cyriaque Dupoirieux escribió:
> le 19/07/2006 15:37 Thorsten Scherler a écrit :
> > El mié, 19-07-2006 a las 13:01 +0000, cdupoirieux@apache.org escribió:
> >   
> >> Author: cdupoirieux
> >> Date: Wed Jul 19 06:01:17 2006
> >> New Revision: 423454
> >>
> >> URL: http://svn.apache.org/viewvc?rev=423454&view=rev
> >> Log:
> >> FOR-893 - We have encountered a strange problem with the pattern 'resolve.structurer.**'.
> >> The {1} sometimes matches nothing, whereas {../1} is OK.
> >> On the contrary, the {../1} sometimes matches nothing, whereas {1} is OK.
> >> As a temporary workaround, we put {../1}{1} which covers all the cases.
> >>
> >> Modified:
> >>     forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> >>
> >> Modified: forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
> >> URL: http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml?rev=423454&r1=423453&r2=423454&view=diff
> >> ==============================================================================
> >> --- forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
(original)
> >> +++ forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
Wed Jul 19 06:01:17 2006
> >>     
> >
> > ...
> >   
> >> @@ -142,18 +150,18 @@
> >>        <select type="exists">
> >>          <!-- project-based 
> >>            url-based (url location) -->
> >> -        <location src="{project:resources}/structurer/url/{1}{project:theme-ext}"
/>
> >> +	  <location src="{project:resources}/structurer/url/{../1}{1}{project:theme-ext}"
/>
> >>  
> >>     
> >
> > I think we should not apply the workaround to locations that are not
> > effected by this weirdness. 
> >   
> Why do you think that I should not apply the workaround here also ?

Because this works fine with {1}. Further you applied it only in some in
others not. Later this will raise the question why. If we only apply the
workaround for the effected code then we know later on which code we
need to fix.

see:
> > The problem occurs only in actions that have an xpath like
> > select/action/parameter. 
> >
> > For example the select/action[@type='sourcetype'] is working like a
> > charm with {1} in @src.
> >
> > Maybe it would be the best to adjust the
> > action[@type='resourceTypeAction'] and
> > action[@type='RecursiveDirectoryTraversalAction'] to add a @src='{1}'
> > and change the processing in the java to use the @src instead of the
> > <parameter value="{../1}" name="request"/>.
> >   
> Where is the stylesheet (or java class) making this xpath selection ?

That is in the actions (and there is no xsl involved). There is no
method to convert this automatic, it is more a design decission.
e.g. resourceTypeAction could be changed like 
locationmap.xml:
<act type="resourceTypeAction" src="{1}">
ResourceTypeAction.java
String uri = this.getProjectDir() + source
                + this.getMetaExtension();

What we are doing here is as well a workaround and IMO it would be
better to fix the real issue.

> If you tell me, I may have the time to see what's the problem.
> (Or we can do what I have done with the php plugin : <map:match 
> type="regexp" pattern="^resolve.structurer.(.*?)([^/]*)$"> ? and use {1}{2})

You can try but I expect that will not change anything, since the {1} vs
{../1} has IMO nothing do with this match. Anyway it is definitely worth
a try.

http://cocoon.apache.org/2.1/userdocs/default/wildcarduri-matcher.html
"In case of nested matchers, or actions the parent Map entries are
referencable by using ../ prefix. Thus referencing the first wildcard
matched value of a parent matcher in a child matcher it is expressed as
{../1}."

I think more it is a usecase specific problem and it would be good to
attach the usecase to the FOR. It seems to me that the context map is
changing in the loctionmap for internal calls, but cannot explain it
(yet) myself why. 

> > However the whole issue smells really fishy and we need to get to the
> > bottom of this issue.
> >
> > My problem is that I need to setup a test project to *see* the bug.
> >
> > Maybe you can attach a small project to the issue that I can test?
> >   
> I will try next week...

Ok, please do (I may try it myself but it would save me time if you can
do this).

BTW I noticed that your IDE seems to be miss-configured. Since this
commit the locationmap.xml has tabs but we use spaces. Please update
your configuration. 

TIA

salu2 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message