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 13:09:20 GMT
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> 
>> Nicola Ken Barozzi wrote:
>>
> ...
> 
>>> 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.
> 
> 
> Since this has a big impact, I would like to table it for the next 
> version. In any case, if you get ahead of it, it would be awesome :-)

Given my coming workload, and as you say the big impact, I suspect this 
will be next version anyway. More important for 0.6 form my perspective 
is extension packaging.

<snip what="about extension (DTD and xmap) packaging"/>

> What worries me are the xmap customizations, that I have not yet seen 
> how to do. If you could focus on that part it would be excellent. In 
> particular, look in Cocoon, they have recently added the possibility of 
> adding sitemaps without having to edit the main sitemap.

+1

>>> 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?
> 
> 
> No, it simply means that a skin gets a basic set of colors that it can 
> use. If it needs more, then CSS edit is needed.
 >
>> Would it not be better to have a separate CSS that just deals with 
>> colours? We can then simply edit them in place.
> 
> 
> The fact is that it's not so easy to make a single CSS that can make 
> colors be edited for all skins. For example, the tigris-style skin has 
> it's own CSS, and I don't want to edit it to make it conform the the CSS 
> colors in the krysalis-site one.

I wasn't thinking of a single CSS for all skins (this would have the 
same problems as colour definitions in a single skinconf.xml for all 
skins). I was thinking more of a "colour.css" (oh it would be nice if it 
had English, UK, spelling, but I doubt that ;-)) in the skin directory. 
  This could be accompnaied by a layout.css. Each can optionally have a 
_local (i.e. colour_local.css) file for local modifications.

IS there some benefit of using skinconf.xml that I am missing (I only 
refer to colours here).

For me the benifit is that is a skin wants to define a colour item that 
doesn't exist in the skinconf.xml, they simply need to add it to the 
colours.css file, no confusion over where the colour is set.

> 
> So the skinconf colors are a *basic* set of colors, a profile that skins 
> can use (or can even disregad). If more infos are needed, then it's 
> necessary to have a CSS to be extended, but it will be skin specific.

My main concern is that we may be making it too hard for page designers 
to style pages without the aid of a developer. It's OK if they only want 
to change a basic colour, but if they want to create a whole new view on 
the docs they need to know XSL as well as CSS.

As a result many skins may end up using whatever user extension 
mechansim we introduce rather than the skinconf.xml settings. What we 
end up with is colour definitions (and whatever comes next) in 
skinconf.xml that don't get used but cause plenty of confusion for those 
trying to customise the skins for their own sites.

I think we should make every effort to keep *all* style information 
inside the CSS directory of the packaged skins.

Ross

Ross


Mime
View raw message