forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: Dumping some ideas for Views
Date Wed, 13 Jul 2005 18:48:39 GMT
On Wed, 2005-07-13 at 10:33 +0100, Ross Gardler wrote: 
> 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.

We have to start using the view specific naming for e.g. templates
otherwise we will not understand each other very well. 

> 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.

This template are our contracts (*.ft). A forrest:contract contains
forrest:templates. This are design for different output format (fo,
xhtml, inx,...) and different input formats (xsl,...).

The templates in the contract we have now are xsl:templates for xhtml

>  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.

about which templates do you talk about? About forrest:contract (*.ft)
or (*.vt)? Or forrest:views (*.fv)?

forrest:call-template is in the view (*.fv) is requesting a *.vt
template or like I call it 'view-tiles' (*.vt).

Do you mean adding all contracts that we extracted (like
content-feeder.ft) again into one single template? 

I would be against that because I did that for maintainment reason and I
consider that a strength of views.

>  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. 

Yes. view-tiles and contracts. 

...but further it can offer different skin implementations for the view

Like I will implement soon in our viewHelper.xhmtl. We will have
default.fv and pelt.fv (as soon as we created it) ;-) which are two
different skins sharing the same contracts.

Then the user choose the view plugin and which default view he would
like to use as default.

...I *only* recommend to create a new viewHelper.xhtml implementation if
the new one is *not* using any contracts from default, or the
implemented contracts are very different. 

Otherwise the future maintainment is to high to sync it with the
forrest.viewHelper.xhtml plugin.

> Forrest will download these templates as and when needed 
> (as with plugins).

Hmm, there are part of the view plugin because the contracts are very
specific to it.

I do share the vision of a contract and view repository where contracts
and views are registered.

Then the user can use a bright range of format/features/skins/themes
around views. 

...we just need to get more people to help with views core integration,
and then we can implement this feature quite quick. ;-)

> This would mean we have:
> org.apache.forrest.output.Pelt
> org.apache.forrest.output.Leather
> etc.

You are using skin names here. 

No, the idea should be to have skins *in* the view plugin.

Let me explain:
In skins we have the "common" skin resources. Ideally we would have used
all the templates from there in pelt, krysalis,... The problem is that
sometimes that was not possible.

Now the contracts on the other hand are pretty flexible and can be used
for different skins without touching a single contract (skins are
normally the job of a webdesigner). 

Some skins may need to override some contracts. That would not be a
problem with our fallback mechanism. In forrest we will develop our
skins in our default viewHelper.xhtml implementation. 

IMO we have to make format specific view plugins and not skin specific.


> 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:

It is like this right now (in theory - never test to formats in the same
time). ;-)

> org.apache.forrest.template.xhtml.Branding
> org.apache.forrest.template.xhtml.FontSizing

Do you recommend to create 1. plugin for 1. contract? Or is it just the
call for the contract?

The correct call (naming conventions) would be:

> org.apache.forrest.template.text.Branding
> org.apache.forrest.template.text.FontSizing
> etc.
> Things to Consider
> ------------------
> Does it make sense to lump all the output formats together into a single 
> view or should it be:
> org.apache.forrest.output.xhtml.Pelt
> org.apache.forrest.output.pdf.Pelt
> org.apache.forrest.output.text.Pelt
> org.apache.forrest.output.voiceXML.Pelt
> etc.

see above

> ---
> 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 
> generated.
> Do we need a new view plugin or should we reuse the existing output 
> plugin namespace?


The main different I see is that output plugins 'normally' just do a
document2{format} transformation. A view plugin is using this as one

> ------------------------------------------------------------------------
> 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.

I think the locationmap and view should be coordinated and happen to the
*same* time. 

What we are doing to do will be refactoring a lot of code from the core
and we need *many* eyes and hands. Everyone can see it as chance to
"really better know Forrest" ;-)

All we need is good coordination and communication. ;-)

> ------------------------------------------------------------------------
> 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?

We will find out ;-)

> ------------------------------------------------------------------------
> Portals
> =======
> 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 
> templates.

I need to have a look on that but I would support basing views on a
standard if possible. I hope that I then can use views in all java/xml
based systems. ;-) ...that would be awesome. :)

> 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?

We can talk about that, I have no experience with JSR-168 yet. ...but
IMO my "businessHelper" are the missing part for views to become one.

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

I tried it once (way back time) but gave up on it quite quick, I have to
admit. ;-) Anyway, somebody told me that their change something that was
not good for this somebody. ...but I just do not remember what.

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

What do you mean?

I will not add anything right now...seriously I cannot get started here,
you have to wait for the workshop to see my visions of
forrest:views. ;-)

open secrets: ;-)
...using views in lenya and other cocoon based frameworks. 
...enabling java processing as business helpers.
...finishing views as implementation of the J2EE dispatcher view



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

View raw message