Thorsten Scherler wrote:
I do not know what is up with mail this days, but in the hope that
reaches the ml faster here again.
------------------------------------------------------------------------
Subject:
Re: views dependency
From:
Thorsten Scherler <[EMAIL PROTECTED]>
Date:
Fri, 17 Jun 2005 11:33:28 +0200
To:
dev@forrest.apache.org
To:
dev@forrest.apache.org
In-Reply-To:
<[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Content-Type:
text/plain
Message-ID:
<[EMAIL PROTECTED]>
MIME-Version:
1.0
X-Mailer:
Evolution 2.0.2
Content-Transfer-Encoding:
7bit
On Fri, 2005-06-17 at 10:51 +0200, Nicola Ken Barozzi wrote:
Thorsten Scherler wrote:
...
The problem
(like you mentioned above) is that they are depend on each other and it
is quite a pain to read the docu of all the plugins involved right now.
I reckon I should add it to the how-to then we have a central place to
document views.
IMO the views are part of core Forrest, they are not plugins.
This would solve both dependency and documentation problems.
Yes I can remember that you always said that. ;-) Thx to throw that back
into the discussion. :)
That is fine with me, but the viewHelper.{format} can be in any possible
output format and they should like Ross stated become a new typ of
plugin (view plugin). The default xhtml implementation that we have now
(viewHelper.xhtml) goes into the core. ...but it has to be easy to
provide own implementation.
I'd still keep it separate. For two reasons:
a) stops people getting confused
b) allows us to ship different versions of Forrest with different
default outputs (I have a use case where I want the default output to be
an IMS COntent Object, rather than a website for example).
I think we should follow the model of Eclipse (or at least eclipse 3.1)
in which the core of Eclipse is nothing more than a plugin management
facility. Everything else is a plugin (or collection of pugins, called a
feature in Eclipse, or a package in some of Thorstens recent mails).
When you download Eclipse these days you download one of a number of
packages optimised for different purposes, i.e. with different plugins
included by default.
The plugin infrastructure can almost do that. We just eed to be able to
use plugin source code "inplace" when it is available. I think I've done
most of the work necessary with the recent versioned download mechanism.
SHould be a beeze for me to implement once 0.7 is released.
Now in regards to any other new view skin that can provide their own
implementation of the contracts (*.ft), views (*.fv) and style (*.css)
as a view plugin. Then we solved the "new skin" problematic in a nice
clear way. Actually that brings back "good" similarities with the
situation we have now with skins.
+1 - this ties in nicely with my overlapping mail in this thread.
Ross
