forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@wkwyw.net>
Subject Re: Forrest customization
Date Sun, 28 Dec 2003 02:02:40 GMT
Nicola Ken Barozzi wrote:
> Dave Brondsema wrote:
> 
> In any case, this is part of what I'm going to do in these days.
> Let me try to summarize and see what you think.
> 
> --- Forrest Customization ----
> ==============================
> 
> Forrest is loosly organized as MVC, where
> 
>  - model      -> 1 content
>  - view       -> 2 style (skins)
>  - controller -> 3 control (sitemaps + xslts)
> 
> I'm trying to make it easy to extend these parts indipendently.
> 
> For each point, here are the extensibility options in increasing 
> difficulty.
> 
> 1) a - locationmap
>    b - @class attribute (thanks Ross :-)
>    c - autodownload of DTDs
> 2) a - color schemes in skinconf.xml
>    b - enhancing CSS
>    c - autodownload of skins
> 3) a - autodownload of xslts
>    b - autodownload of extra sitemaps
> 
> Where the autodownloads of 1 and 3 must be done together in a same 
> package, as they are coupled.



> 
> Let me try and explain them separately.
> 
> 1 - Content configuration
> ===========================
> 
> a) A problem we have now is how to specify where the content is. We 
> cannot easily tell Forrest to download feeds from the web or even get 
> files from two directories. The locationmap will make it easy to tell 
> Forrest where the sources are.
> - status: the locationmap code is done and inclusion is tabled in
>           version 0.7

This is cool. I am doing this at the moment with XInclude (another 
reason for having validation turned off). If Locationmap means I can 
remove my XIncludes I will be very pleased.

I'll try and find time to move one of my smaller courses over to this as 
a test.

> b) By making it possible to use a @class attribuite, content writers can 
> easily add semantics to documents without changing the DTD. The style 
> can be changed down the chain to accomadate for it. In any case if the 
> extra CSS is not there the rendering will not break down but just use a 
> subset of what the semantics can convey.
> 
> - status: go ROSS, go!

OK, as soon as I get the necessary access, which I suspect will be 
longer than usual at this time of year.

> c) To accomodate extra DTDS, we now have to edit the sitemaps. Not good 
> as far as compatibility with future Forrest releases goes. If we make it 
> possible to download DTD packages with corresponding xslts, we can make 
> Forrest use them just by using simple naming convensions (ie the xslt 
> filename is somewhere in the private id of the DTD)
> 
> - status: TBD, assigned to nicolaken

This is something I really want to see working. I would like to make my 
skin available using the autodownload, but it has many xmap 
customisations and extra DTD's so the current skin packaging is not 
sufficient. However, I do believe the skin will provide a good example 
of the extensability of the basic Forrest framework. I volunteer to help 
with this.

> 2 - Style configuration
> ===========================
> 
> a) color schemes in skinconf.xml
> 
> This is what I'm going to do now: make it possible to decide what colors 
> to use in the skin directly in skinconf.xml
> 
> This makes it possible to then use these in the skin without editing 
> CSS, that can easily be skin specific. In this way we can change skin 
> but keep color profile.

Each skin is likely to have a different set of colour areas. For 
example, none of the existing skins have a colour for slides, but mine 
does. does this mean that each custom skin will also need a custom 
skinconf.xml?

Would it not be better to have a separate CSS that just deals with 
colours? We can then simply edit them in place.

> c) autodownload of skins
> 
> - status: DONE, needs testing

I volunteer my skin as a first test, but I need the DTD customisations 
as well. Alternatively we could separate out one of the other skins, for 
example Krysalis (I believe you suggested this when commiting the 
original download code).

> 3 - control configuration
> ===========================
> 
> The extra xslts download is part of the DTD extenstions. As for extra 
> sitemaps, I'm not ready to table it yet, but if someone wants to work on 
> it, Cocoon now has configurable insertions of subsitemaps.

OK, perhaps this is the part of the customisation stuff I should look 
into. I can't really get deep into this for quite a while as I am away 
for a couple of weeks at the start of Jan so if someone else gets 
started before me that's cool. Otherwise I'll pick up mid to late January.

Ross


Mime
View raw message