forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [jira] Commenté: (FOR-893) wildcard matcher such as **.xml when used in lm actions like {1} are not rewritten
Date Wed, 12 Jul 2006 10:55:55 GMT
El mié, 12-07-2006 a las 11:15 +0200, Cyriaque Dupoirieux escribió:
> le 12/07/2006 10:55 Thorsten Scherler a écrit :
> > El mié, 12-07-2006 a las 07:46 +0000, Cyriaque Dupoirieux (JIRA)
> > escribió:
> >   
> >>     [ http://issues.apache.org/jira/browse/FOR-893?page=comments#action_12420539
] 
> >>
> >> Cyriaque Dupoirieux commented on FOR-893:
> >> -----------------------------------------
> >>
> >> I have a big problem with this FOR, and I think it is why my motivation decrease...
> >>     
> >
> > So let us get you motivated again and try to fix it. ;)
> >
> >   
> >> Since the  update of the locationmap.xml between revision 390856 and revision
390882, the dispatcher does not take into account specific fv files in subdirs. (Either in
structurer/url nor in xdocs...)
> >>
> >>     
> >
> > Regrading this observation, so you are doing 
> > svn up -r390856 locationmap.xml
> > ...and everything is working?
> >
> > You are only updating this file right, nothing more?
> >   
> Nothing more, cf. 
> http://marc.theaimsgroup.com/?l=forrest-dev&m=114891085211800&w=2

Ok, I was not sure, thanks for clarifying. 

> >   
> >> Can someone explain the <match pattern="resolve.structurer.**"> so that
I can investigate.
> >>     
> >
> > as soon something is requesting "resolve.structurer.something/bla" then
> > this match is acting. Where in "normal" sitemap behavior ** is in this
> > example "something/bla" and can be matched with {1}.
> >
> > David gave a tip to try with {../1} which would normally match the
> > parent match. Like having
> > <map:match pattern="resolve.**">
> >  <map:match pattern="resolve.structurer.**">
> > ...
> >  </map:match>
> > </map:match>
> >
> > So in our example {../1} would give structurer.something/bla out of
> > pattern="resolve.**". 
> >   
> Ok, here is my concerns :
> 
>     <match pattern="resolve.structurer.**">
>       <select type="exists">
>         <!-- project-based
>           url-based (url location) -->
>         <location 
> src="{project:resources}/structurer/url/{1}{project:theme-ext}" />
>         <!-- project-based
>           url-based (xdocs location)  [depreciated]-->
>         <location src="{project:content.xdocs}{1}{project:theme-ext}" />
> 
> Abovee we have to location tags under the exists test. What does it 
> means ? Do both must exist ?

No, the exist selector is doing the same thing like in the sitemap. 
http://cocoon.apache.org/2.1/userdocs/resourceexists-selector.html
"The ResourceExistsSelector selects the first of a set of Resources
(usually files) that exists in the context."

The only difference is that in the lm you does not need the <map:when/>.


> 
>         <act type="sourcetype" src="{project:content.xdocs}{1}.xml">
>           <!-- Sourcetype based
>           http://forrest.apache.org/docs/cap.html-->
>           <location 
> src="lm://dispatcher.structurer.resourceType.{sourcetype}"
>             />
>         </act>
> What does the previous tag ?

previous tag? 
You mean the action? 
See the link in the comment for what this special action does. 
"SourceTypeAction assigns a "type" (a string) to an XML file. This is
done based on information occuring in the header of the XML file, up to
the document (root) element. This type is then returned to the sitemap
as a variable with the name 'sourcetype'. If no matching sourcetype
could be be found, null is returned and thus the contents of the action
element will not be executed."

In our case it is not the sitemap but the locationmap.

You ask further down what the act in general is doing, the same as in
the sitemap a map:action.
http://cocoon.apache.org/2.1/userdocs/concepts/actions.html
"The quick and dirty definition of an Action is "a Sitemap Component
that manipulates runtime parameters". Actions must be ThreadSafe and
they can be as complex as you need. The Action is the proper place to
handle form processing and even dynamic navigation. The Action is
differentiated from the other sitemap components (Generator,
Transformer, Serializer and Reader) primarily by the fact that it does
not produce any display data."

> 
>         <act type="resourceTypeAction">
>           <parameter value="{1}" name="request"/>
>           <parameter value="{project:content.xdocs}" name="projectDir"/>
>           <parameter value="lm://dispatcher.structurer.resourceType." 
> name="resourceTypeBase"/>
>           <parameter value=".xml.meta" name="metaExtension"/>
>           <parameter value="resourceType" name="resourceTypeElement"/>
>           <parameter 
> value="http://apache.org/cocoon/lenya/page-envelope/1.0" 
> name="resourceTypeElementNS"/>
>           <!--  Meta data based -->
>           <location src="{uri}" />
>         </act>
> And what does this one ?

Wee bit similar to the type="sourcetype" but using meta data instead of
the document. The example is for lenya.

> 
>         <act type="RecursiveDirectoryTraversalAction">
>           <parameter value="{1}" name="request"/>
>           <parameter value="{project:theme}" name="projectFallback"/>
>           <parameter value="{project:theme-ext}" name="projectExtension"/>
>           <parameter value="{project:resources}/structurer/url" 
> name="projectDir"/>
>           <!--  url
>             project-based theme-based = directory-based / 
> parent-directory based (recursively) -->
>           <location src="{uri}" />
>         </act>
> What does this ?

That is an faq. 
http://svn.apache.org/viewvc/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/acting/RecursiveDirectoryTraversalAction.java?view=markup
/**
     * @param resolver
     * @param uri
     *            *viewSelector* project-xdocs will return which view is
     *            responsible for the requested path. If no view
     *            (choice|fallback) could be found the template will return the
     *            viewFallback (resources/views/default.fv).
     * 
     * ex.: 1.request: index First choice: index.fv First/last fallback:
     * default.fv
     * 
     * 2.request: sample/index First choice: sample/index.fv First fallback:
     * sample/default.fv Last fallback: default.fv
     * 
     * 3.request: sample/subdir/index First choice: sample/subdir/index.fv First
     * fallback: sample/subdir/default.fv Second fallback: sample/default.fv
     * Last fallback: default.fv
     * 
     * ...
     * 
     * des.: The parent view (root-view) inherits to its children until a child
     * is overriding this view. This override can be used for directories
     * (default.fv) and/or files (*.fv). That means that the root view is the
     * default view as long no other view can be found in the requested child.
     * @throws IOException
     * @throws MalformedURLException
     *  
     */

Whoops we need to update this.

> 
>         <act type="RecursiveDirectoryTraversalAction">
>           <parameter value="{1}" name="request"/>
>           <parameter value="{project:theme}" name="projectFallback"/>
>           <parameter value="{project:theme-ext}" name="projectExtension"/>
>           <parameter value="{project:content.xdocs}" name="projectDir"/>
>           <!--  xdocs  [depreciated]
>             project-based theme-based = directory-based / 
> parent-directory based (recursively) -->
>           <location src="{uri}" />
>         </act>
> In fact, what does a Act tag ...

The same as above but this time for the legacy location.

> 
> And finally, I don't understand the meanning of the following location 
> tags...

This is answered by Ross, I guess. 

> 
>         <!-- themes-dir: project-application-based theme-dir-based -->
>         <location
>           
> src="{lm:themer.project.dir}/{project:theme}{project:theme-ext}" />
>         <!-- themer: project-application-based theme-based -->
>         <location
>           src="{project:themer}/themes/{project:theme}{project:theme-ext}"
>           />
>         <!-- themes-dir: project-application-based default -->
>         <location
>           
> src="{lm:themer.project.dir}/{defaults:theme}{defaults:theme-ext}" />
>         <!-- themer: project-application-based default -->
>         <location
>           
> src="{project:themer}/themes/{defaults:theme}{defaults:theme-ext}"
>           />
>         <!-- themer: forrest-application-based theme-based -->
>         <location
>           src="{defaults:themer}/themes/{project:theme}{project:theme-ext}"
>           />
>         <!-- themer: forrest-application-based default -->
>         <location
>           
> src="{defaults:themer}/themes/{defaults:theme}{defaults:theme-ext}"
>           />
>       </select>
>     </match>
> 
> Ok, I agree with you - because I can hear you think - I nearly don't 
> understand anything in locationmaps, but I practice :-)  !
> 

jeje

no worries. Thanks for asking for clarifications (go on if the above is
to short).

salu2

> Salutations,
> Cyriaque,
> 
> > salu2
> >
> >   
> >> Thanks,
> >>
> >>     
> >>> wildcard matcher such as **.xml when used in lm actions like {1} are not
rewritten
> >>> ----------------------------------------------------------------------------------
> >>>
> >>>          Key: FOR-893
> >>>          URL: http://issues.apache.org/jira/browse/FOR-893
> >>>      Project: Forrest
> >>>         Type: Bug
> >>>       
> >>>   Components: Locationmap, Dispatcher (aka views)
> >>>     Reporter: Thorsten Scherler
> >>>  Attachments: lm.log.xml
> >>>
> >>> In the thread http://marc.theaimsgroup.com/?t=114682704400003&r=1&w=2
I found out the following.
> >>> I did a debug session with the RecursiveDirectoryTraversalAction and I
> >>> figured out that the {1} in the lm is not probably resolved (it is
> >>> always "").
> >>> <match pattern="resolve.structurer.**">
> >>> ...
> >>>  <act type="RecursiveDirectoryTraversalAction">
> >>>   <parameter value="{1}" name="request"/>
> >>> It seems to happen in all lm actions, I debugged the resourceTypeAction
> >>> and the same problem can be seen.
> >>> I attached the result of 
> >>> svn log . -v --xml >~/src/apache/forrest/trunk/lm.log.xml
> >>>       
> >
> >   
-- 
thorsten

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


Mime
View raw message