Thorsten Scherler wrote: > 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.
It sounds like you have not re-read the previous discussion. We arrived at a solution and documented it at http://forrest.apache.org/docs/dev/status-themes.html "... This would enable any theme engine to be used, whether that be Skins or Dispatcher or some other." > Like Brain states "community support of skins is questionable", see the > mail from Cyriaque. You missed the important "If" at the beginning of Brian's words. It seems to be too early to determine the situation. > 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. I for one am not yet convinced that Dispatcher should be the only solution. I find it to be very complex. As you said in the previous discussion that i linked to above. > > > > > 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! Oh sure. However you were indicating that they should be "provided by the plugin itself" which is not true. > 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. Which shows that there is quite a lot of work to move the skins stuff out of the core. Yes the locationmap will help immensely. -David
