Tom Lazar wrote: > On Jun 10, 2007, at 1:51 PM, Tim Hicks wrote: > >> This compares to what I envisage the view approach looking like:: >> >> <div tal:repeat="brain weblog/getLazyEntries"> >> <a tal:define="weblogentryview brain/@@weblogentryview" >> tal:attributes="href weblogentryview/getArchiveURL" >> tal:content="brain/Title">title</a> >> </div> > > except that i wouldn't do the 'brains dance' inside the template but in > the view class.
Ah yes, good point. I'm still half thinking in Archetypes-land as my templates are still in portal_skins. I'll shift them over to proper view classes now. That should make things simpler. > i've adopted the practice of only passing out dictionaries or adapted > objects into my templates. > > the `getLazyEntries` method is an implementation detail that should be > abstracted from the template. > > without looking at the current interfaces i would postulate having a > `getEntries` method for `IWeblogView` that simply returns instances that > provide `IWeblogEntry` -- that's all the template needs to know. It probably makes even more sense for IWeblog just to have a getEntries method that returns IWeblogEntry objects, rather than the current getLazyEntries method - and rather than the view having it. To keep the benefits of using catalog brains, the brains class (or adapter to it) can then provide the IWeblogEntry methods in such a way that brain metadata is used where possible, with a fallback to brain.getObject() where necessary. (Hmm, perhaps a call to an explicit method to do the getObject step might make sense so the template-writer knows that they are increasing memory consumption.) Tim _______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
