Re: views dependency

[Nicola Ken Barozzi <ni...@apache.org>]

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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------

Re: views dependency

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

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.

I agree that the controlling portion of the view is in fact part of core 
(i.e. the stuff in o.a.f.p.internal.view). However, the parts that 
define the contracts (i.e. o.a.f.p.output.viewHelper.xhtml) are not, 
there may be different versions of these, like we have different skins 
at present.

However, they should not be called "plugins", that will serve to 
confuse. A plugin adds functionality, it does not change the look of the 
final document. I think they need to be called "views" (a name that will 
be freed up if we move the view "plugin" into core).

Ultimately, what I think would be great to see is the provision of each 
contract as an independently downloadable unit. Views (aka skins) would
then define a collection of related contracts via the default.fv file.

Allowing contracts to be downloaded and used independently provides a 
set of building blocks for view designers. For example, someone could 
choose to have the AJAX enabled search contract from the (fictitious) 
fully dynamic view, but the static navigation menu contract from another 
view.

With careful CSS design the look and feel of the resulting page will be 
consistent.

I suspect that this is what Thorsten has had in mind all along, I'm only 
seeing it now I have had chance to have a little play.

Ross

Re: views dependency

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

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.

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.

WDYT? 

salu2
-- 
thorsten

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