forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Dumping some ideas for Views
Date Wed, 13 Jul 2005 09:33:41 GMT
As suggested by Ferdinand I am just dumping some ideas I have in my mind 
about the future of views.

I've not really considered these in detail, so they could be full of 
holes, I'm just hoping to seed a few ideas to explore them at the views 
workshop/hackathon if time permits.

Perhaps others can drop ideas into this thread too in order to give us a 
starting point for the discussion in the workshop.


Templates as Individual View Plugin

Right now we have an XHTML plugin that provides a set of templates for 
use in generating an XHTML page. The idea, as I understand it, is that 
we can create different view plugins with different sets of templates. 
However, I feel this is too granular.

I would like to see a new type of plugin that is a single template. A 
view plugin will then consist of a default *.fv file and a set of 
support files (such as CSS). The *.fv file describes which templates 
should be used. Forrest will download these templates as and when needed 
(as with plugins).

This would mean we have:


These views will be able to take a configuration saying what format we 
want the output in (XHTML, FO, PDF, Text, POD, VoiceXML etc.) and will 
select the correct type of templates accordingly:




Things to Consider

Does it make sense to lump all the output formats together into a single 
view or should it be:



Currently we have output plugins that do things like create the various 
output documents. Are vew going to replace these plugins? Thinking about 
the list of output plugins we currently have I see none that cannot be 
replaced by a view. However, Imagine a use case in which we have an 
output plugin that is designed to upload the page to a server when it is 

Do we need a new view plugin or should we reuse the existing output 
plugin namespace?


Moving into Core

We need to think carefully about when to do this. The Locationmap work 
is going to rewrite most of the *.xmap files in core and the Views work 
will touch many of these files too.

We should consider the implications of these changes and decide which to 
do first.


Deprecating XDoc

It looks to me like views are an ideal opportunity for us to switch to a 
subest of XHTML2 as our internal format. We are going to mess with the 
internals of Forrest in order to get the views stuff in there.

But what, exactly, is involved?



Views are taking Forrest very close to a Portal like environment. Yet we 
have not, at any time considered using JSR-168 stuff in the design of 

I'm not suggesting that Forrest becomes yet another Portal 
implementation, but then again, maybe I am. How easy/difficult/.sensible 
would it be to resuse Portal stuff i views?

(Cocoon has a pretty solid Portal implementation already if we can 
leverage that...)

At the very least I would like to consider the ability for individual 
users to customise their views.

View raw message