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 22:54:07 GMT
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.




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

> 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

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

View raw message