El mié, 04-01-2006 a las 10:33 +0000, Ross Gardler escribió: > Thorsten Scherler wrote: > > El mar, 03-01-2006 a las 14:14 +0000, Ross Gardler escribió: > > > >>Thorsten Scherler wrote: > >> > >>>El mar, 03-01-2006 a las 13:25 +1100, David Crossley escribió: > >>> > >>> > >>>>Ross Gardler wrote: > >>>> > >>>> > >>>>>I propose that themes be distributed as plugins rather than having them > >>>>>all in the themer plugin. ... > >>>> > >>... > >> > >> > >>>Resuming all above, I am with you that we need a system to package > >>>themes and make them downloadable but disagree about the overhead to do > >>>it with a plugin. > >> > >>What overhead? Specifics please. > >> > > > > > > You would just need > > forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat/* > > > > forrest/trunk/whiteboard/plugins/org.apache.forrest.theme.Coat/src/documentation/resources/themes/coat.fv > > > > everything else is overhead. > > Sure, everything else is optional in the plugin installation process, or > can easily be made optional, it's just a modification of the ant script. > > However, don't forget the docs stuff. I want to see decent docs for > themes too. > > Your suggestion of adding docs to the themer directory plugin does not > work since this means all themes have to be hosted here at Forrest.
Why? The documentation/samples is/could be in the *themes* package. Like: org.apache.forrest.themes.X/x/samples/... ...and of course in the contracts - the main documentation location for a theme! > We > need a mechanism that allows local sites to use their own themes, and > hopefully publish them as well. Yeah, IMO we should extend the http://localhost:8888/ls.contracts.html to include all available contracts. The documentation about a theme should be mainly in the contracts - self explaining and standalone!!! Besides this documentation every theme could provide additional information, but all this could be done with the above root or directly in contracts. > > >>Note that I already addressed the point about docs, which should be > >>removed from the download and packaged separately. This is easily done > >>by adding an <exclude...> pattern to the ant script. > >> > >>Note that things like input.xmap, locationmap.xml etc. are only used if > >>they are present. > >> > > > > > > Yeah, this sentence made me think whether we want to allow themes to > > provide a sitemap.xmap? > > I don't think so, as you say a theme is *.fv and *.css files. and contracts. > If a theme > needs to do processing of the data then it is really an output plugin > isn't it? However, keeping the download mechanism the same gives us > flexibility should a use case for arise. > agree > >>>I agree as well on the naming convention, so how can we use the old > >>>fashion skin download mechanism for themes? > >> > >>The plugin download mechanism *is* the original skin download mechanism > >>(with versioning added). > >> > > > > > > Yeah, but the problem with using it directly as plugin is that the list > > of required plugins is growing to the unreadable. > > We don't have to list it as a plugin. Different naming convention, > different descriptor file, different index page, same download mechanism. > ok, that sounds good, because the easiest thing would be that all themes get extracted to *one* dir like build/themes/... This way it would be very easy to have the documentation of all installed plugins in the project, including the contract documentation. > > Anyway I am fine with using plugins directly but with another template > > like you suggested in your other reply to David. > > > > My suggestion for a theme template would be: > > > > org.apache.forrest.theme.X/sitemap.xmap (optional -> I am not even sure > > whether we should allow that) > > org.apache.forrest.theme.X/themes/x.fv > > org.apache.forrest.theme.X/themes/x/* > > > > or > > > > org.apache.forrest.themes.X/x.fv > > org.apache.forrest.themes.X/x/* > > > > That is optimized with nearly no overhead. > > > > BTW actually I changed the convention because a theme does not only have > > to provide just *one* theme, but it can provide as many themes as it > > wishes. It is a package of themes. > > +1 > :) Ok we have an overall agreement besides the documentation part. Nice. How can I set up the basic infrastructure for this new type of plugin? > Ross > salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
