Dumping some ideas for Views

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

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:

org.apache.forrest.output.Pelt
org.apache.forrest.output.Leather
etc.

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:

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

org.apache.forrest.template.fo.Branding
org.apache.forrest.template.fo.FontSizing

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.

---

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?

------------------------------------------------------------------------

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?

------------------------------------------------------------------------

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

Re: Dumping some ideas for Views

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

On Wed, 2005-07-13 at 22:51 +0100, Ross Gardler wrote:
<snip "leading to:">
> (if there is a nedd for different terminology convince us (me?) in 
> Stuttgart after we have a solid grounding, it will be much easier for 
> you I am sure)
> 

:) I am all for suggestion and face to face we will certainly better
understand each other. 

I hope and think we will find a good new design for views.

> ...
> 
...
> > Do you mean adding all contracts that we extracted (like
> > content-feeder.ft) again into one single template? 
> 
> No. I mean making all contracts (i.e. *.ft = forrest-templates) 
> availablew as separate units of functionlaity rather than bundling them 
> up within a view plugin that prevents their easy reuse across different 
> views (*.fv)
> 

I understand now and I am looking forward to talk about it.

> However...
> 
> 
> > 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.
> 
> OK, this is very similar to what I am proposing, but it is a different 
> approach. I think there is merit in both approaches so we need to 
> discuss these in Stuttgart. I won;t try and do it now as I am starting 
> my travels tomorrow so I won;t be able to follow up.
> 
> Just as a teaser for my thinking avout my alternative approach. It has 
> the advantage of allowing the reuse of contracts across different 
> formatsm, which you approach does not (unless you create dependencies 
> between views plugins). For example, Hanax needs to reuse most of the 
> XHTML view in his voiceML view.
> 

You have a point here. 

> >>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.
> 
> Only in your implementation. Like I say, I see merit in both approaches. 
> We can discuss in Stuttgart and come up with a proposal fot the list 
> from that. Chances are we will take the best of both approaches.
> 


:)

+1

;-)

> >>-
> >>------------------------------------------------------------------------
> >>
> >>Portals
> >>=======
> 
> <snip what="agreement on 'we need to understand more about portals"/>
> 
> 

Yes and they are not priority, you are absolutely right. 

> >>At the very least I would like to consider the ability for individual 
> >>users to customise their views.
> > 
> > 
> > What do you mean?
> 
> I mean the user eing able to turn on/off contracts in their view. Kind 
> of like a user choosing to view a web page with their own CSS rather 
> than that provided by the webiste designer. Or, to stick with the portal 
> theme, the user being able to turn on/off some of the portlets.
> 
> Clearly this is only approproate in a dynamic envirnment.
> 
> 

http://issues.apache.org/jira/browse/FOR-169 :)

> We are not going to have time for everything. This "portals" stuff is 
> future wish list stuff. I'll be attending the portals presentations at 
> Apachecon, but they are after the workshop. I think the immediate work 
> needs to be on getting views complete for 0.8. Portals (if they ever 
> emerge) will come after that.
> 

+1

> Ross
-- 
thorsten

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

Re: Dumping some ideas for Views

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

Thorsten Scherler wrote:
> 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. 

Yes, and this should be another outcome form our views workshop. I am 
thoroughly confused by the many names in use within views. I feel sure 
many are not needed. For example, in this mail you introduce, for the 
first time, the definition of *.vt as "view tiles". These files are 
templates. They have the same syntax as other templates why give them a 
diffferent name?

<xsl:cal-template ...>, for example, does not call a complete different 
type of template. why should <forrest:call-temlate>

Then we have contracts, which are acrtually defined in *.ft 
(forrest-templates), but the syntax of their language is 
<forrest:tempalte>. It is thoroughly confusing, and I believe totally 
unnecessa/ Lets pick a few simple terms to refer to simple concepts and 
stick with them.

(if there is a nedd for different terminology convince us (me?) in 
Stuttgart after we have a solid grounding, it will be much easier for 
you I am sure)

...

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

Here is a perfect example of why we need clear, unambiguos names. I was 
referring to *.ft (forret-template) *.fv is a view so I don't understand 
why it is even a possability here.

As for *.vt this is something that was introduced a couple of days ago. 
I am not sure why *.vt even needs to exist as a separate extension 
(think <xsl:template match=""> and <xsl:template name=""/>) and so did 
not think about it when writing the above sentence.

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

No. I mean making all contracts (i.e. *.ft = forrest-templates) 
availablew as separate units of functionlaity rather than bundling them 
up within a view plugin that prevents their easy reuse across different 
views (*.fv)

However...


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

OK, this is very similar to what I am proposing, but it is a different 
approach. I think there is merit in both approaches so we need to 
discuss these in Stuttgart. I won;t try and do it now as I am starting 
my travels tomorrow so I won;t be able to follow up.

Just as a teaser for my thinking avout my alternative approach. It has 
the advantage of allowing the reuse of contracts across different 
formatsm, which you approach does not (unless you create dependencies 
between views plugins). For example, Hanax needs to reuse most of the 
XHTML view in his voiceML view.

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

Only in your implementation. Like I say, I see merit in both approaches. 
We can discuss in Stuttgart and come up with a proposal fot the list 
from that. Chances are we will take the best of both approaches.

>>---
>>
>>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?
>>
> 
> 
> org.apache.forrest.plugin.output.viewHelper.{format}
> 
> The main different I see is that output plugins 'normally' just do a
> document2{format} transformation. A view plugin is using this as one
> part.

It is the use of 'normally' that makes me think there may be a need for 
a different type of plugin. This is a point for discussion. I am totally 
undecided at present.

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

Again lets discuss. I am not at all sure this is possible. There are 
simply to many overlapping changes. However, without a roadmap for views 
(and I suppose this portion of the locationmap work too), it is 
impossible to decide.

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

Starting with a plan from Stuttgart followed by a review onlist from 
other devs - this looks like excellent timing.

>>------------------------------------------------------------------------
>>
>>Portals
>>=======

<snip what="agreement on 'we need to understand more about portals"/>


>>At the very least I would like to consider the ability for individual 
>>users to customise their views.
> 
> 
> What do you mean?

I mean the user eing able to turn on/off contracts in their view. Kind 
of like a user choosing to view a web page with their own CSS rather 
than that provided by the webiste designer. Or, to stick with the portal 
theme, the user being able to turn on/off some of the portlets.

Clearly this is only approproate in a dynamic envirnment.


We are not going to have time for everything. This "portals" stuff is 
future wish list stuff. I'll be attending the portals presentations at 
Apachecon, but they are after the workshop. I think the immediate work 
needs to be on getting views complete for 0.8. Portals (if they ever 
emerge) will come after that.

Ross

Re: Dumping some ideas for Views

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

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

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

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.
like:
project.viewHelper.xhtml=org.apache.forrest.plugin.output.viewHelper.xhtml
project.viewHelper.xhtml.skin=pelt


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

 
org.apache.forrest.plugin.output.viewHelper.xhtml
org.apache.forrest.plugin.output.viewHelper.fo


> 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.plugin.output.viewHelper.xhtml.get.contract.branding-tagline

> org.apache.forrest.template.fo.Branding
> org.apache.forrest.template.fo.FontSizing
> 
> 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?
> 

org.apache.forrest.plugin.output.viewHelper.{format}

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


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

salu2

-- 
thorsten

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