forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: common.fv not working - have I missed something?
Date Fri, 13 Jan 2006 11:36:30 GMT
El vie, 13-01-2006 a las 18:34 +1300, Paul Bolger escribió:
> I've done a bit more experimentation and it seems that pult.fv works
> as expected in the xdocs directory - affects all documents below it -

That is done by

forrest-trunk/whiteboard/plugins/org.apache.forrest.plugin.internal.structurer$ cat locationmap.xml
...
  <act type="RecursiveDirectoryTraversalAction" src="">
    <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"/>
    <!--  project-based theme-based = directory-based / parent-directory
based (recursively) -->
    <location src="{uri}" />
  </act>
...


> if a pult.fv file exists in the project local themes directory. 

Hmm, you mean you have to have a default structurer for the theme in the
theme dir?

> It
> doesn't matter if that file has any content. It also seems this also
> sets the project css default directory to the pult theme directory
> (I'm really starting to regret not giving this theme a sensible name!)

Yes, see the other mail, but you can still use and place them in your
local common directory since it gets matched by the lm. Generally we
assume that a theme will only override parts of the common stuff, but
keeping the resources in the {customTheme} resource dir makes them
unique usable for this theme (if {customTheme} != common).

> Does this mean I've found a real, live, bug?

That part about only if it exist in the theme dir sounds like one, but
as more I think about it, it seems to be a feature. ;-) I mean a theme
*has to* provide a default structurer {themeName}.fv in the theme dir
otherwise it cannot be used out of the box. It would forces the user to
add a default structurer for the customTheme which is not good.

>  It'd be good to adjust
> the documentation to reflect what's going on, but I'm loathe to spend
> much time on it if it's about to be swept away by v3.

v3 has changed the internal processing for delivering e.g. html and some
grammar but the concepts are the same.

salu2
-- 
thorsten

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


Mime
View raw message