forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Bolger <pbol...@gmail.com>
Subject Re: common.fv not working - have I missed something?
Date Mon, 16 Jan 2006 04:51:09 GMT
Hi Thorsten, I've been trying to digest your replies before answering.
Not easy when I understand about 20% of it...
>
> The only difference is that you are linking to more/other css files in
> the {customTheme}.fv. ...and like always in the dispatcher we have
> fallbacks implemented.

Yeah, I'm beginning to understand that, It'd be good to have the
fallback sequences detailed in the howtos. I might have a go, but
unlikely to have time till next week.


>
> No, with the locationmap you can override everything what I wrote above
> and in the other mail about fallbacks in the dispatcher. That means if
> you use your custom locationmap you override the core.
>
> > Right at the moment I'm finding the whole theme setting/defining
> > procedure quite confusing.
>
> Hmm, ....

And I think a large part of that is confusion over terms. Maybe I'll
knock up a rough Dispatcher definitions document. It's finally
clicking that the .fv files are 'structurer' files (I thought
fv=Forrest View= view files). I'm thinking that running an evolving
list of definitions may be helpful to rename some Dispatcher terms at
a later date, when their functions have stopped developing. I've had a
look at some of the Cocoon docs and I realise that some of the
terminology came from there.


> > Wouldn't it make sense to set the project
> > theme in forrest.properties,
>
> Yeah that is how it is done.

The 'missing link', however, is that a theme *must* have an .fv file
in the themes directory or the theme fallback mechanism won't work. I
can understand that this makes sense as there may be project files
which aren't in the xdocs file system, but I think it would make more
sense for the master .fv file to be in the theme directory itself.
Then one could copy and move the whole directory into another project
and never have to worry about it unless one specifically needed to
change it.


> 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 certainly seems that way.


> 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.

See above, it'd be less likely to cause problems if it was in the
custom theme directory itself.

>  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.

Ok, when I'm happy that it's doing what I think it's doing I'll do a patch.

Mime
View raw message