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. ...
>
> The reasoning sounds fine. I won't comment further until
> we hear Thorsten's view.
>
> The problem with the plugin approach is that there
> is too much extra weight of configuration files, e.g.
> skinconf.xml forrest.properties and other templates
> and default config, just to show one doc.
>
> That is probably an orthoganal issue. We need to
> solve it for plugins too.
>
> It is also creating a maintenance problem for the
> Forrest project. Synchronising and updating those is hell.
>
Yeah that is the main point. We actually would keep a lot of stuff that
is not needed for the theme. IMO extra samples and related resources
should be integrated differently.
Like I wrote as answer on the initial theme commit the theme could be
kept like a skin. Actually theming is working nearly the same as skins
in this regards. The idea is to use the skin download mechanism to
request the theme (if not installed on the system) from a theme
repository. One can specify more then one repository (including file
system) to search for the requested skin.
This description is based on what we have, but it has the problem of the
heavy use of ant and forrest.properties. I did not adopt the new
configuration system till now that is the reason why you can ATM specify
*one* project specific themer in the forrest.properties:
+##########################################
+# *advanced configuration* - you can specify which plugins you want
+# use internal.
+#project.themer=
${forrest.home}/build/plugins/org.apache.forrest.plugin.output.themer
With this property it is possible to override the default themer and use
a custom themer and its themes. That needs to be more specific and
rewritten under the thought of a repository.
I thought about to move this property to the forrest.properties.xml and
rename it to themer-rep. I would prefer to have a clean separation
between plugins and themes.
Another problem is with the proposal and the current above mentioned
project.themer that each theme would have to be a themer itself where it
would be sufficient to only provide theme specific contracts and
modifications (.../resources/themes/*). I expect that a theme will
generally use 90% of the common theme and only provide 10% extra
contracts/css/... The idea is that common theme is the core and all
other themes extend/modify the behavior of this theme.
Anyway, back to the sample thought of Ross
"A second advantage is that the theme can then provide local docs that
demonstrate the unique features of the theme."
in /resources/themes/coat/ we can add a dir called samples or
documentation where we store this stuff if somebody needs it, but it
should be optional.
.../resources/themes/coat/documentation/*
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.
I agree as well on the naming convention, so how can we use the old
fashion skin download mechanism for themes?
Basically it is the same:
- contact theme-server
- search theme
- if found download theme.zip and extracted it to the build theme rep
(e.g.
$FORREST_HOME/build/plugins/org.apache.forrest.plugin.output.themer/resources/themes)
- if not contact next theme-server if exists
WDYT?
> At one stage, Reinhard did some nice experiments at Cocoon
> with centralised config for various projects. Probably still
> in cocoon-trunk.
>
> -David
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
