forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Kok <j...@messianic.dyndns.org>
Subject Re: When is a skin not a skin? (was Re: [PATCH] Customized stylesheets and grammars)
Date Tue, 16 Dec 2003 04:13:14 GMT


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.

>


Mime
View raw message