forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: Skin plugin
Date Wed, 25 Apr 2007 21:09:41 GMT
On Wed, 2007-04-25 at 13:40 +1000, David Crossley wrote: 
> Thorsten Scherler wrote:
> > Brian M Dube wrote:
... 
> > > If community support of skins is questionable, then a flexible framework 
> > > seems to me the way to go.
> > 
> > I do not see the need nor the work force to have to different
> > skinning/theming frameworks.
> > 
> > I see the dispatcher as successor of skins which should be moved to a
> > plugin, but not 2 different frameworks. 
> 
> Hang on. Last time that we talked about this,
> we were quite clear that skins could remain.

As I understood as legacy code. We will maintain it but not extend it.
Like Brain states "community support of skins is questionable", see the
mail from Cyriaque. 

IMO new development regarding skinning should be conducted in the
dispatcher. Actually upcoming 0.9 will switch to dispatcher as default
theming engine if I recall correctly. 

> > > > Not sure what to do about the different skins.
> > > > There would be a similar discussion in the archives about
> > > > when the Dispatcher work established the f.a.o.themes.core
> > > > plugin.
> > > 
> > > > Let us continue to express our needs for a little
> > > > while on this dev list, before launching into the
> > > > actual development.
> > > 
> > > Fair enough. For one of my projects I tested a modification to the 
> > > Forrest build files that leaves out (unused) skin resources when 
> > > building dispatcher sites. It would be great if this case is handled 
> > > when skins move out of core.
> > 
> > Regarding this files they should be provided by the plugin itself in the
> > jar. 
> 
> Some of these resources are copying the potential
> project-based things like images and css

Images if not skin/dispatcher related that reside in the project are not
copied (better said should not, that is the copyless approach we
follow). Actually, all images and css should not be copied anymore at
all, having the locationmap now!

All targets copying one resource to another location have to be reviewed
and removed if they can be done with the locationmap. Meaning removing
skin related copying forces us to use the locationmap instead in the
skin plugin. 

When we added skin support we did not had the lm and used good old ant
for moving files to a common location to better resolve them. This
always violated the copyless approach.  

See FOR-809, FOR-986, FOR-987, ...

> , so they would
> not be provided by the plugin. 

Some css and image are coming from the plugin as fallback where for skins the fallback order
is as follow:
- project skin 
- project common skin
- plugin skin 
- plugin common skin

This assumes the current structure of
skins/
|-- common
|   |-- css
|   |   `-- forrest.css.xslt
|   |-- images
|   |   `-- ...
...
|-- pelt
|   |-- css
|   |   |-- basic.css
|   |   |-- ...
|   |   `-- screen.css
|   |-- images
|   |   |-- chapter.gif
...

for plugin and project.

> See the messages towards
> the end of 'forrest site' just before Cocoon starts.

Yeah, all not needed if the locationmap is be used to resolve such resources.

> 
> > I can help a wee bit but my time is limited ATM since my 2 girls are 3
> > days old. 
> 
> Good luck to you all.
> 
> Looking forward to the improvements in Forrest's
> Gallery plugin ;-)

jeje.

:)

Yeah, will definitely use the plugin much more now. 

salu2
-- 
Thorsten Scherler                                 thorsten.at.apache.org
Open Source Java                      consulting, training and solutions


Mime
View raw message