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
_______________________________________________
Archetypes-devel mailing list
Archetypes-devel lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/archet
ypes-devel
|