You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Marshall Roch <ma...@exclupen.com> on 2003/12/15 20:04:37 UTC
[PATCH] Customized stylesheets and grammars
As I've already mentioned, current CVS has problems with stylesheets for
custom content types saved in src/documentation/resources/stylesheets/,
and custom grammars in src/documentation/resources/grammars/.
The attached patch to forrest.xmap fixes the problem. IMO, it's a
rather ugly hack, but I hope that's just because of my lack of knowledge
about Forrest.
I don't like "{project:content}/../resources/stylesheets/" and
"{project:content}/../resources/grammars/". Shouldn't there be
something like {project:stylesheets}?
NOTE: I have included several examples in the diff to demonstrate this
path stuff, which, obviously, should not be patched into Forrest...
--
Marshall Roch
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Johan Kok wrote:
>
> Nicola Ken Barozzi wrote:
...
>> In any case, please take a look at the CVS version of the
>> krysalis-site skin. In the CSS you can also find a forrest-site like
>> color profile. The idea is to replace the forrest-site skin with the
>> krysalis-site one.
>
> Also useful .... assuming that would get rid of the rounded corner
> bitmaps. --- colour changing those were a little painfull. ( have my own
> template where they were removed, and borders adapted. not have have to
> change them).
Yup, this is intended too. If we define the color in the skinconf, we
can easily generate the rounded corners of the right colors with the
SVG, or do without them altogether in the CSS (yes, specifying just an
extra CSS for the skin is another thing to do)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Nicola Ken Barozzi wrote:
>
> For the krysalis-site skin, I have started to move all colors in the
> CSS file and to better componentize the xslt. The idea is to be able
> to define the colors of the skin in the skinconf.xml.
Will check those in a day or three.... (and likely switch to that).
Want to do something like a colouriser (whenever I can get to it), for
a site. 40% of the time I use the same skin, but with different colour
schemes and logos.
I like the idea of componentizing the xslt. Next nice step should be
something like seperate component definitions, being able to define any
format shape or size of component for whatever purpose, including having
components within components (e.g. portal window or sideline minders,
references, additional information blocks, being able to add case blocks
within text etc.)
> Yes, now there is a skin download in place. The idea is to add a DTD
> download in place too, along with the relative transformations.
>
> I wanted to finish this stuff well before now, but the Incubator is
> taking up much of my time.
>
> In any case, please take a look at the CVS version of the
> krysalis-site skin. In the CSS you can also find a forrest-site like
> color profile. The idea is to replace the forrest-site skin with the
> krysalis-site one.
Also useful .... assuming that would get rid of the rounded corner
bitmaps. --- colour changing those were a little painfull. ( have my own
template where they were removed, and borders adapted. not have have to
change them).
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Johan Kok wrote:
> Ross Gardler wrote:
>
>> This is a problem I have been running into too (and with skins with
>> custom xmaps). The real problem is that if you use a skin to do
>> anything more than change the layout you end up with parts of your
>> skins all over the place.
>
> My problem with forrest is exactly that it's definition IS all over the
> place, albeit sort of seperated. The current definition is all but
> coherent..... The skin is litterally all over the place. Just to change
> the colour scheme, one has to make changes to the XSLT files AND the
> page.CSS file. In fact the page.css file contains a mix of the page,
> tabs and menu. That is three different units all mixed into that. At the
> same time you find parts of that same units in different XSLT files.
>
> Should colour definition not belong seperately to each functional area,
> e.g. menu, tabs OR should one have a seperate "skin" definition that
> contain all of these together. The same would apply to the positioning,
> shape etc of the skin.....
For the krysalis-site skin, I have started to move all colors in the CSS
file and to better componentize the xslt. The idea is to be able to
define the colors of the skin in the skinconf.xml.
...
>> So the question then becomes how do I (and Marshall) customise Forrest
>> in the way that we have been doing (i.e. grammars, xmaps and
>> stylesheets from custom grammers to xdoc). Should there be another
>> concept similar to skins that package all this stuff together as well?
>
> A grammer is not part of the skin, because that tends to form part of
> the funtional logic flow, like an xmap. Yes, there should be a concept
> similar to current skins to package all that stuff together.
Yes, now there is a skin download in place. The idea is to add a DTD
download in place too, along with the relative transformations.
I wanted to finish this stuff well before now, but the Incubator is
taking up much of my time.
In any case, please take a look at the CVS version of the krysalis-site
skin. In the CSS you can also find a forrest-site like color profile.
The idea is to replace the forrest-site skin with the krysalis-site one.
Comments appreciated.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Johan Kok <jk...@messianic.dyndns.org>.
Ross Gardler wrote:
>
> This is a problem I have been running into too (and with skins with
> custom xmaps). The real problem is that if you use a skin to do
> anything more than change the layout you end up with parts of your
> skins all over the place.
My problem with forrest is exactly that it's definition IS all over the
place, albeit sort of seperated. The current definition is all but
coherent..... The skin is litterally all over the place. Just to change
the colour scheme, one has to make changes to the XSLT files AND the
page.CSS file. In fact the page.css file contains a mix of the page,
tabs and menu. That is three different units all mixed into that. At the
same time you find parts of that same units in different XSLT files.
Should colour definition not belong seperately to each functional area,
e.g. menu, tabs OR should one have a seperate "skin" definition that
contain all of these together. The same would apply to the positioning,
shape etc of the skin.....
I have to agree with Marshall's defintiion in this regard, and have
mentioned this issue in the past.
>
> The question is therefore, what is a skin intended for. If it is just
> look and feel (which is what a skin normally deals with) then I
> believe the current skinning system works fine since xmaps,
> resources/stylesheets and resources/grammers would not be a part of
> the skin.
How do you eassiliy change the colour scheme, let alone, change the look
and feel of the tabs without having to hack in both the specific XSLT
and the common CSS file.
>
> So the question then becomes how do I (and Marshall) customise Forrest
> in the way that we have been doing (i.e. grammars, xmaps and
> stylesheets from custom grammers to xdoc). Should there be another
> concept similar to skins that package all this stuff together as well?
A grammer is not part of the skin, because that tends to form part of
the funtional logic flow, like an xmap. Yes, there should be a concept
similar to current skins to package all that stuff together. But the
current skins concept requires a whole redesign in philosophy and
require a way to easilly package a look and feel with various skin
components (e.g. tabs, menu, header, page, portal views etc.) How about
defining an initial set of such components (or just plainly define them
generically and let the skind designer use them which ever way he/she
sees it fit), and take that as the springboard for a look and feel skin
design, which does not restrict the shape, functionality and number of
components of a skin.
>
> I have customised Forrest to provide online course materials. I have a
> number of custom grammers such as:
Grammers is not part of a skin.... A unit (require a better naming)
consist of the following, in line with the seperation of concerns:
Skin components (requirements) definition: Providing the presentation
look and feel, or should it rather be a definition of
Logic/Process flow: Providing the logic of processing, including
grammers etc
Content: Source, intermediate and presented content.
One should have a seperate skin processor which will do the following:
Take the skin components definition of a unit and add to that the
site's look and feel definition, in the likeness of winamp/windows media
player and several other products, i.e. that does not change the
functionality of the skin in terms of buttons, menus etc, but purely
provide the look and feel of such.
>
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Johan Kok <jk...@messianic.dyndns.org>.
I agree with Marshall.......
Marshall Roch wrote:
> Ross Gardler wrote:
>
>> The question is therefore, what is a skin intended for. If it is just
>> look and feel (which is what a skin normally deals with) then I
>> believe the current skinning system works fine since xmaps,
>> resources/stylesheets and resources/grammers would not be a part of
>> the skin.
>>
>> So the question then becomes how do I (and Marshall) customise
>> Forrest in the way that we have been doing (i.e. grammars, xmaps and
>> stylesheets from custom grammers to xdoc). Should there be another
>> concept similar to skins that package all this stuff together as well?
>
>
> <snip>
>
>> So, should can all this fall under the banner of "skin" or do we need
>> some other packaging device?
>
>
> I don't think it should all part of the skin. When I think of
> "skins," I think of Winamp[1]. The skins in Winamp don't change any
> of the functionality, just your access to it. For example, a Winamp
> skin could add another button, but it doesn't make the button work.
> You need plug-ins for that.
>
> I see skins as you described them: templates for layout. All of the
> other XSL and grammars, etc. are working "behind the scenes" to
> generate the document format that the skins/templates accept.
>
> Now, I don't know if packaged "plug-ins" are the way to go, but I do
> think there should be some (dare I say "easy"?) way to customize and
> extend Forrest's functionality without making copies of everything. A
> big part of my problem was that I had made a copy of forrest.xmap
> before resource editing had been commited, and had to patch that in
> manually once I realized what happened. I know I have to expect/deal
> with this because I'm working in CVS, but imagine the problems during
> a 0.5 to 0.6 upgrade.
>
> --
> Marshall Roch
>
> [1] A Windows MP3 player (http://www.winamp.com)
>
>
Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Marshall Roch <ma...@exclupen.com>.
Ross Gardler wrote:
> The question is therefore, what is a skin intended for. If it is just
> look and feel (which is what a skin normally deals with) then I believe
> the current skinning system works fine since xmaps,
> resources/stylesheets and resources/grammers would not be a part of the
> skin.
>
> So the question then becomes how do I (and Marshall) customise Forrest
> in the way that we have been doing (i.e. grammars, xmaps and stylesheets
> from custom grammers to xdoc). Should there be another concept similar
> to skins that package all this stuff together as well?
<snip>
> So, should can all this fall under the banner of "skin" or do we need
> some other packaging device?
I don't think it should all part of the skin. When I think of "skins,"
I think of Winamp[1]. The skins in Winamp don't change any of the
functionality, just your access to it. For example, a Winamp skin could
add another button, but it doesn't make the button work. You need
plug-ins for that.
I see skins as you described them: templates for layout. All of the
other XSL and grammars, etc. are working "behind the scenes" to generate
the document format that the skins/templates accept.
Now, I don't know if packaged "plug-ins" are the way to go, but I do
think there should be some (dare I say "easy"?) way to customize and
extend Forrest's functionality without making copies of everything. A
big part of my problem was that I had made a copy of forrest.xmap before
resource editing had been commited, and had to patch that in manually
once I realized what happened. I know I have to expect/deal with this
because I'm working in CVS, but imagine the problems during a 0.5 to 0.6
upgrade.
--
Marshall Roch
[1] A Windows MP3 player (http://www.winamp.com)
When is a skin not a skin? (was Re: [PATCH] Customized stylesheets
and grammars)
Posted by Ross Gardler <rg...@wkwyw.net>.
Marshall Roch wrote:
> As I've already mentioned, current CVS has problems with stylesheets for
> custom content types saved in src/documentation/resources/stylesheets/,
> and custom grammars in src/documentation/resources/grammars/.
This is a problem I have been running into too (and with skins with
custom xmaps). The real problem is that if you use a skin to do anything
more than change the layout you end up with parts of your skins all over
the place.
The question is therefore, what is a skin intended for. If it is just
look and feel (which is what a skin normally deals with) then I believe
the current skinning system works fine since xmaps,
resources/stylesheets and resources/grammers would not be a part of the
skin.
So the question then becomes how do I (and Marshall) customise Forrest
in the way that we have been doing (i.e. grammars, xmaps and stylesheets
from custom grammers to xdoc). Should there be another concept similar
to skins that package all this stuff together as well?
Here's a use case:
I have customised Forrest to provide online course materials. I have a
number of custom grammers such as:
- worksheets
- exams
- classlist
- marks
- ...
together with a number of stylesheets to convert from these grammers to
xdocs of various forms, for example:
- worksheet2marksheet_xdoc.xsl
- worksheet2student_xdoc.xsl
- worksheet2modelAnswer_xdoc.xsl
(originally I stored these in src/resources/stylesheets but I recently
moved them to my skin becasue of the above problem).
I also have a number of custom xmaps to allow processing of these files:
- worksheet.xmap
- marks.xmap
- ...
So, should can all this fall under the banner of "skin" or do we need
some other packaging device?
Ross