You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@wkwyw.net> on 2003/12/28 03:02:40 UTC
Re: Forrest customization
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
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)
---------------------------------------------------------------------