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
