forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Dumping some ideas for Views
Date Wed, 13 Jul 2005 21:51:54 GMT
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

Mime
View raw message