You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Nicola Ken Barozzi <ni...@apache.org> on 2003/12/27 21:39:59 UTC
Forrest customization (was: partial skin overriding)
Dave Brondsema wrote:
...
> I still agree that in most cases partially overriding a skin is bad. But here
> is a good use-case:
>
> Since many skins now use CSS (a *good* thing), it would be ideal for users to
> modify just the css file(s) to tweak the appearance of a standard skin.
You are bringing up a very important part of the current changes I've
done and still doing, so I'm very happy about it.
I agree with what you say, and add that it's not only about tweaking a
skin but also *enhancing* it.
In fact, if we add a @class attribute to elements, users can easily
customize Forrest the *right* way, by adding semantics with the class
and visualization with the CSS, without using more complex things like xslt.
> Could this be solved with a matcher that looked in the project's skin directory
> for the requested file and if not found, then looked in the standard skin
> directory? This would still prevent a custom skin from overriding stylesheets
> because the xsl:import would only look for files relative to itself.
IIRC I had already inserted a matcher to look in the common skin first...
What about adding the possibility to add a skins/user.css that every
skin adds at the end of the CSSes?
In this way the user can change skin but keep the customizations.
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
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!
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
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.
Problem: the colors are in CSS. Thus I need to generate CSS by giving it
values from skinconf.
Possibilities:
- use velocity and put skinconf in the context
- use JXTemplate Generator and put skinconf in the context
- generate it from the skinconf.xml and insert the CSS in an xslt
Since CSS is textual, the first option is the correct one, but we are
addin another (albeit small) dependency...
- status: TBD, assigned to nicolaken
b) enhancing CSS
Where should we add the user CSS? What about skins/user.css?
In this way the user can change skin but keep the customizations.
- status: TBD, assigned to nicolaken
c) autodownload of skins
- status: DONE, needs testing
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.
Comments?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest customization
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
...
>> What I'm trying to say is that it's not easy to do this.
>
> I'm having difficulty understanding how colour can be separated out in a
> single sninconf.xml file but not in a single css, but...
Here is the color-customization csses of krysalis-site and tigris-style.
Wanna join them? I don't. Especially when I don't want to change the
names of the tigris styles as they keep updating it. Futhermore, when we
will have another skin taken from another site, will we have to change
the names to conform to our color schemes? Too restrictive IMHO.
In any case, I'm doing it now, we'll see if it's ok or not soon :-)
Krysalis-site
=============
/* ==================== main block colors ============================ */
body { background-color: #FFFFFF; color:#000000;}
.header { background-color: #FFFFFF;}
.border { background-color: #a5b6c6;}
.subborder { background-color: #CFDCED;}
.dialog { background-color: #F7F7F7;}
.footer { background-color: #a5b6c6;}
.tab.selected { background-color: #a5b6c6;}
.tab.unselected { background-color: #F7F7F7;}
/* ==================== main text colors ============================ */
a:link { color: #0F3660; }
a:visited { color: #000044; }
a:active { color: #800000; }
a:hover { border: 0px solid #a5b6c6; background: #CFDCED; }
.menu .menupagetitle { background-color:#CFDCED; border-color: #a5b6c6;}
.menu .menupageitemgroup { background-color:#FFFFFF; border-color: #a5b6c6;}
.menu { border-color: #a5b6c6;}
.menu a { color: #000000; }
.menu a:visited { color: #000000; }
.menu a:active { color: #000000; }
.menu a:hover { color: #000000; }
/* ==================== other colors ============================ */
.highlight { background-color: yellow; }
.datenote { color: #F7F7F7;}
table .title { background-color: #FFFFFF; }
.content .ForrestTable { color: #ffffff; background-color: #7099C5;}
.content .ForrestTable caption { color: black; }
.content .ForrestTable td { color: black; background-color:
#f0f0ff; }
.fixme { border-color: #c60;}
.note { border-color: #069;}
.code { border-color: #CFDCED;}
.dtdTag { color: #990000; }
Tigris-style
==============
* colors, backgrounds, borders, link indication */
#cn {
background-image: url(../images/corporate_logo.gif);
display: block;
height: 17px;
width: 138px;
}
#poweredby {
background-image: url(../images/poweredby_036.gif);
display: block;
height: 38px;
width: 102px;
}
#sc {
background-image: url(../images/product_logo.gif);
display: block;
height: 25px;
width: 138px;
}
#toptabs td, #toptabs th {
background-image: url(../images/nw_min_036.gif);
}
.app h3, #banner, #banner td, #toptabs {
background-color: #036;
color: #fff;
}
body #banner td a, .app h3 a, .app h4 a {
color: #fff !important;
}
#banner {
border-top: 1px solid #369;
}
#mytools .label, #projecttools .label, #admintools .label,
#communitytools .label {
background-color: #ddd;
border: none;
}
#mytools .body, #projecttools .body, #admintools .body, #communitytools
.body {
background-color: #fff;
border-right: none;
border-bottom: none;
border-top: 1px solid #999;
}
#mytools, #projecttools, #admintools, #communitytools {
background-color: #ddd;
border-right: 1px solid #666;
border-bottom: 1px solid #666;
}
#helptext {
background-color: #ffc;
}
#helptext .label {
border-bottom: 1px solid #996;
border-right: 1px solid #996;
background-color: #cc9;
}
#helptext .body {
border-bottom: 1px solid #cc9;
border-right: 1px solid #cc9;
}
#topmodule {
background-color: #ddd;
border-top: 1px solid #fff;
border-bottom: 1px solid #aaa;
}
#topmodule #issueid {
border-right: 1px solid #aaa;
}
#login a:link, #login a:visited {
color: white;
text-decoration: underline;
}
#banner a:active, #banner a:hover {
color: #f90 !important;
}
#toptabs td {
border-bottom: 1px solid #666;
border-right: 1px solid #333;
border-left: 1px solid #036;
}
#toptabs th {
border-left: 1px solid #036;
}
/* font and text properties, exclusive of link indication, alignment,
text-indent */
#bodycol h2 {
font-family: Tahoma, Verdana, Helvetica, Arial, sans-serif;
font-size: 1.5em;
font-weight: normal;
}
/* box properties (exclusive of borders), positioning, alignments, list
types, text-indent */
#toptabs {
margin: 0;
padding-top: .67em;
padding-left: 8px;
}
#topmodule {
margin: -4px -4px 0 -4px;
}
#topmodule td {
vertical-align: middle;
padding: 2px 8px;
}
#navcolumn {
margin-right: -4px;
}
#mytools .body, #projecttools .body, #admintools .body, #communitytools
.body {
padding-top: .33em;
}
#mytools, #projecttools, #admintools, #communitytools {
padding: 0 6px 6px 6px;
margin: -4px 0 6px -4px;
}
#mytools .label, #projecttools .label, #admintools .label,
#communitytools .label {
padding-left: 2px;
}
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest customization
Posted by Ross Gardler <rg...@wkwyw.net>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
>
>> 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.
>
>
> What I'm trying to say is that it's not easy to do this.
>
I'm having difficulty understanding how colour can be separated out in a
single sninconf.xml file but not in a single css, but...
<snip/>
>
> Look, let me do it, and then we'll see if it's ok or if it's inappropriate.
... seems very reasonable :-)
Ross
Re: Forrest customization
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
> 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.
What I'm trying to say is that it's not easy to do this.
Look inside krysalis-site and tigris-style. Then try making a colors.css
file that goes well for both *without* changing the standard tigris CSS
files. You can *only* if you make these colors.css files have different
names for the colors, and you cannot port the colors between the skins.
>> 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.
Not really, I use XSLT only as a templating thing.
Look, let me do it, and then we'll see if it's ok or if it's inappropriate.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest customization
Posted by Ross Gardler <rg...@wkwyw.net>.
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
Re: Forrest customization
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 :-)
...
>> 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.
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.
>> 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.
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.
>> 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).
Let me see what I can do in these days about the DTD extensions, if you
look into the xmap stuff we can work parallely.
>> 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.
I will surely not work on it till then, and we need to release 0.6
before it, so it should be just fine.
Thanks, man :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Forrest customization
Posted by Ross Gardler <rg...@wkwyw.net>.
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