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)
