forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyriaque Dupoirieux <Cyriaque.Dupoiri...@pcotech.fr>
Subject Re: svn commit: r423454 - /forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/locationmap.xml
Date Fri, 21 Jul 2006 10:37:08 GMT
le 21/07/2006 11:34 Thorsten Scherler a écrit :
> 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}.
If you are sure...
>  Further you applied it only in some in
> others not.
I believed I had applied for the whole pattern.
>  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.
>   
Ok, Do I remove it from the sourceType and ResourceTypeAction ?
> 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. 
>
>   
Just few lines were changed with tabs, not the whole file, isn't it ?
> TIA
>
> salu2 
>   
Salutations,

Mime
View raw message