On Wed, Aug 26, 2009 at 09:32:32AM +0800, Tim Hoffman wrote: > Hi Robert > > I am coming pretty late to your discussion about owrap, from what I have > gleaned it does look interesting and potentially very > useful for a project I am working on. > > From looking at the code and the dummyapp it looks like its almost inverting > the relationship between a views template and the owrap views template > vs the traditional templating model in plone for instance where your view > invokes main template and you fill slots. Does that make sense ?
Yes, by having the owrap configuration external to the view, it should be easier to interchange views with different themes. Having the owrap being an adapter lookup can also buy you some flexibility by taking advantage of the zca. > How do you see it really being used compared with what I am used to from > plone land and what I am doing in bfg-pages. > I specifically I am looking to address sidebar/portlet type functionality > with repoze.bfg on top of app engine as well as a general strategy of > composing > complex pages from many components based not only on content type but other > properties of the content itself, and broader contexts. > > I am using full zpt/metal so I am pretty comfortable approaching this using > macros, but conceptually I see some advantages if my interpretation of > owrap is correct. > > Any thoughts. I will be in position to do some experiments in a couple of > days if that would also help you in exploring where you take owrap > functionality > > regards > > Tim Hoffman There are tradeoffs with each approach. In particular, when you have a dynamic owrap that has many differences on a per view basis, the owrap approach can add complexity. Making several different registrations just to put a view on the screen spreads the logic out over multiple components. In this case, using a macro approach probably makes more sense. But as Chris mentioned earlier in this thread, the approaches aren't mutually exclusive. Using a hybrid can make the most sense in some scenarios too. Robert _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
