[Zope-dev] Adding your own (complex) data types to property pages: example a nd problems...nd problems...

[Phillip J. Eby]

At 01:18 PM 5/4/00 -0400, Mike  Fletcher wrote:
>
>As of yet, I don't see a clean way of fixing this problem other than
>re-writing properties.dtml to call out to an extensible mechanism for
>generating edit fields.  To make this ideal, you would allow, for instance,
>dropping in a more advanced date editor (such as a calendar) to replace the
>default text-field version, or allowing for "object" fields where you can
>paste or create generic objects etc.  If I do this work (at least the basic
>mechanisms, if not the ideal ones), would Digital Creations be willing to
>incorporate the changes? I am currently developing on 2.1.4, but can upgrade
>if there have been any changes in this area. If not, are there any
>suggestions on other means to accomplish the same ends (complex property
>data types)?

Ty and I were planning to solve this problem in ZPatterns at some point,
but taking a somewhat different approach.  Our idea was to address the
issue through the RIPP model PropertyHandlers.  PropertyHandlers are like
methods that have methods - so if an object had a date value called
StartDate, you could do something like object.StartDate.HTMLeditor() to get
an HTML snippet for editing that property, object.StartDate() to get the
actual property value, and object.StartDate.set(data) to change the
property.  This makes the system wildly extensible, while keeping the
ZPublisher type marshalling clean.  (One problem with adding new types to
the registry is that it's not very isolatable for virtual hostingish
applications' security.)  It's up to the PropertyHandler to determine how
the data is marshalled to/from standard ZPublisher-supported types.

The other advantage to this approach is that it scales to properties which
are actually relationships to other objects - for example, mapping a
customer number property to establish a relationship with a customer
object.  Relationship PropertyHandlers actually delegate their
display/editor rendering and input marshalling to the Specialist
responsible for the kind of object the relationship "points to".

None of this exists in code yet; just thought I'd bring it up as an
alternative approach.  (Actually, in some older code I have some things
that work similarly to this idea, but they're based on ASDF, an alternative
to the Zope framework that I wrote a couple years back which runs on
ZPublisher.  It won't port, though, and you really wouldn't want it to,
either. :) )