le 17/07/2006 10:46 Thorsten Scherler a écrit :
El lun, 17-07-2006 a las 01:18 -0700, Cyriaque Dupoirieux (JIRA)
escribió:
[ http://issues.apache.org/jira/browse/FOR-893?page=comments#action_12421554 ]
Cyriaque Dupoirieux commented on FOR-893:
-----------------------------------------
This still does not work with me...
In the following thread :
http://marc.theaimsgroup.com/?t=115269589100002&r=1&w=2
I explained that my specific fv files were found (still in xdocs directory...) if I inverted
the two <act type="RecursiveDirectoryTraversalAction"> tags.
I had no problem with the {1}...
Now, If I invert the two tags, it does not work anymore.
Did you updated the locationmap of the dispatcher and builded the
plugin.
Yes, this morning...
The {../1} is only working if you use the head of locationmap.xml! You
need
<match pattern="dispatcher.structurer.resourceType.**">
<select>
<act type="RecursiveDirectoryTraversalAction">
<parameter value="{../1}" name="request"/>
...
I tested this and it works like a charm for me.
indeed :-( .
I tested successfully:
- <act type="sourcetype" src="{project:content.xdocs}{1}.xml"> (e.g.
document-v20.fv)
- <act type="resourceTypeAction"> (e.g. xhtml.fv)
- <act type="RecursiveDirectoryTraversalAction">
<parameter value="{project:resources}structurer/url/"
name="projectDir"/>
- <act type="RecursiveDirectoryTraversalAction">
<parameter value="{project:content.xdocs}" name="projectDir"/>
I have
structurer/
|-- resource-types
| |-- document-v20.fv.bck
| `-- xhtml.fv.bck
`-- url
`-- common.fv.bck
Where I renamed all views to *.bck as soon as they worked successfully.
The last one is in my project dir (the old default place).
Ok, here is a good summary of the different cases that can be met in my
site :
xdocs/
|-- pelt.vf (taken into account)
|-- livres/
| |-- pelt.fv (not taken into account by the files in the livres
directory, the xdocs/pelt.fv is used instead...)
`-- jeux/
|-- ultima.xml (this one is generated with xdocs/pelt.fv which is good)
|-- ultima3.xml
|-- ultima3.fv (this one is taken into account - it corresponds to
<act type="sourcetype" src="{project:content.xdocs}{1}.xml"> if I
understand)
`--ultima2/
|-- mondes/
|-- map10.xml
`-- pelt.fv (this one is not taken into account by the
map10.xml, the xdocs/pelt.fv is used instead...)
Please, can I have more logs with the dispatcher java classes, I may
find my problem alone if it works with you...
Salutations,
Cyriaque,
If I replace the {../1} by the previous {1} :
<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>
<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>
It works again.
I reopen the FOR...
Hmm, it is hard to assist on this since it is working fine for me.
Did you change the locationmap.xml or have implemented own matches in
your project lm?
Can somebody else test the current changes?
salu2
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
Issue 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