Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41852762.5090300@apache.org>
Date: Sun, 31 Oct 2004 17:56:50 +0000
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: [RT] How to move the skins into a plugin? Plans for
 leather-dev/corium
References: <cm0th1$16k$1@sea.gmane.org> <418411E6.1010300@brondsema.net>
 <cm190i$f3k$1@sea.gmane.org>
In-Reply-To: <cm190i$f3k$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

(having just posted a mail saying I'm withholding comment, I discovered=20
this mail from much earlier today was still sitting at the spell check=20
stage, since I already wrote it I'm posting it anyway)

Thorsten Scherler wrote:
> Dave Brondsema escribi=F3:
>=20
>> Thorsten Scherler wrote:
>>

<snip/>

>> It is also possible to have different skins for PDF output.  Why not? =

>> Or different skins for SVG output.  Or TXT output.  Just because most =

>> of our skinning is for HTML currently doesn't mean that is all we need=
=20
>> to think about.
>>
>=20
> Maybe we should have the pdf-plugin as subplugin of the skin-plugin.

This is what made med think that plugin is probably not the right name=20
for what you are proposing. It will get confusing. I would suggest we=20
stick with skin for your main "controlling" "plugin" and go with=20
skin-plugin for things like PDF (and all other output stage plugins).

> Like I stated before I like to have atomic parts in forrest. Plugings=20
> are for me an aggregation of functionality. These functionality can hav=
e=20
> dependences on other atomic parts.

This kind of inter-plugin dependency is almost certainly going to become =

a necessity. However, I don't want to start thinking about that until we =

have solidified exactly how the plugins will work. The current=20
architecture is not flexible enough to do everything we need, but it is=20
getting there.

With the plugins I do not want to allow a plugin to access anything=20
available in another plugin. If it is not available in core then a=20
plugin cannot use it (again, I expect this to change in the future but=20
want to keep it simple at this early stage). In your original post you=20
said a skin plugin would be a container of sub-plugins. If we stop=20
thinking about the container as being a plugin but start with it as a=20
part of core then that means values that are needed by your skin-plugins =

can share values through core.

> The idea is that you can have this different pdf skins but there=20
> independent from the xhtml skin. I would like to choose from a wide=20
> range of pdf-skins, xhtml-skins.

Let me make sure I understand where this is going and if my slight=20
alteration of your proposal fits your ideas:

Plugins deal with the input stage and are managed by core. Examples of=20
these plugins are:
  - IMSManifest
  - OpenOffice.org
  - Wiki
Examples of the kind of shared values provided by core are:
  - project:xdocs
  - forrest:stylesheets

Skins (part of core) manages a series of skin-plugins. Examples of these =

plugins are:
  - XHTML
  - PDF
  - SpeechML
Examples of the kind of shared values provided by core are:
  - project.name
  - project.copyright
  - project.url

> I would suggest to split apart the skinconf.xml in subconfigs. The=20
> remaining skinconf.xml would include links to installed subplugins.=20
> Where the subplugins are responsible for keeping their own specific dat=
a.

With the above model do we get the kind of separation that you think we=20
need? As I said I am concerned about having plugins maintain their own=20
set of properties since that will encourage plugin dependencies.

If the above doesn't work let me throw in a totally random idea that I=20
have not even started to think through:

How about we have another kind of plugin called a "configuration=20
plugin". This will provide project specific configuration details.=20
Plugins are allowed to depend on these, but not on each other?

Ross