Re: RFC: Schema Refactoring, first steps
Rob Miller <[email protected]> Fri, 14 Jul 2006 10:47:52 -0400
| Newsgroups | gmane.comp.web.zope.plone.archetypes.devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 14 Jul 2006 09:17:43 +0100, Martin Aspeli wrote: > Rob Miller wrote: > >>> The better-interoperbility argument you make is really good (though I >>> can't envisage how it'd work right now), >> >> i imagine having the 'main' slot of main_template.pt invoke a viewlet >> container. then we'd write viewlets that can render AT schema widgets, >> and other viewlets that can render Z3 widgets. perhaps we can embed >> some display organizational info that the viewlet manager would use as >> Z3 annotations on the FTI for a type, or even on individual instances. > > Sorry, I still don't understand this. A viewlet manager is basically > something you put in a template (using a special TAL expression: <div > tal:replace="structure provider:plone.top"/> where plone.top is the > registered name of the viewlet manager). Viewlets register themselves (in > ZCML, at Zope startup) as being renderable in a particular viewlet > manager, for a particular view (i.e. page; or just all pages), for a > particular context (e.g. a content type, or just any content type). > > At least in the way that zope.viewlet works now, I don't see how they'd be > used in this way. Perhaps the composition of the fields in base_edit.pt or > similar could be handled by viewlet registrations, although this still > seems a bit of a strange use of viewlets to me. I'd need to think about it > a bit more, though. in Fate there are Z3 views that perform the same function as base_edit, although the addform has the added bonus of not actually instantiating the "real" object (it generates a stub on the fly) until after you've submitted the form. i'm imagining creating a viewlet that basically does the same thing, iterating through the fields (or a passed in set of fields) and rendering the widget for each field in the context of the AT object, just like the templates do now. it would also be possible to register another viewlet for a given content type that would perform an analogous function for a Z3 schema that is associated with that type. so in the simplest case, there would be two viewlets. it wouldn't be very much different from using metal:slots, really. >> trickier would be handling the validation, since the AT validation is >> usually driven by CMFFormController while the Z3 validation is driven by >> formlib. it may be possible to invoke these processes one after the >> other... i'd have to play around to see if that were really possible. > > And not just the validation, the whole saving logic (e.g. what happens > with title-to-id renaming, storage initialisation etc.). of course. > But the one-step-back I'd like to take is not "how do we make it work", > but rather, "how does the AT developer work". i.e., what would your > fictional product that started life in AT and wanted to do some Z3 look > like. Let's invent the syntax we'd like to use first, and then think about > how it may actually be made to work, rather than the other way around. At > least for me, AT is just about making things convenient to use for the > "end developer". :) the AT product would look just like it does now; the AT templates are what would change, and in the default case the behaviour of the new templates would match that of base_view and base_edit. when the developer wanted to extend the type w/ some Z3 schema fields, he would define the schema interface and would register the schema on the type just as illustrated in rocky's formlib tutorial. then he'd register the predefined "Z3 schema rendering" viewlet on his type. the viewlet manager in the default template would render the AT schema viewlet and the Z3 schema viewlet on the same page, one after the other. if it were required that the schema fields actually be interwoven, the developer would have to do more work to define add'l viewlets, i imagine. i'm not even sure this approach will work, but it doesn't seem unreasonable, nor even particularly difficult, to me. as i said, another approach would be to just add additional slots to the base_edit and base_view templates that can be used as a hook for getting the Z3 stuff on the page. -r ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642