[Fwd: Re: views dependency]

[Thorsten Scherler <th...@apache.org>]

I do not know what is up with mail this days, but in the hope that
reaches the ml faster here again.
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: [Fwd: Re: views dependency]

[Ross Gardler <rg...@apache.org>]

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 <th...@apache.org>
> Date:
> Fri, 17 Jun 2005 11:33:28 +0200
> To:
> dev@forrest.apache.org
> 
> To:
> dev@forrest.apache.org
> 
> In-Reply-To:
> <d8...@sea.gmane.org>
> References:
> <20...@minotaur.apache.org> 
> <11...@localhost.localdomain> 
> <42...@apache.org> 
> <11...@localhost.localdomain> 
> <d8...@sea.gmane.org>
> Content-Type:
> text/plain
> Message-ID:
> <11...@localhost.localdomain>
> 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