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

[Mike Fletcher]

Interestingly, I had seen the lack of localization as a feature :) .  For
instance, updating the date property control is something that could allow
every date property in the system to be edited with the more advanced
control.  Another example: the "list" type is not supported in the current
properties.dtml . Adding to the global pool, (which can only be done by
products as far as I can see) allows you to enable that type throughout the
system. Keeping the static properties.dtml means that this edition must
overwrite a "system" file to do that update.

ZPatterns looks interesting, by the way, will give it a try.

Enjoy,
Mike

-----Original Message-----
From: Phillip J. Eby [mailto:pje@telecommunity.com]
Sent: Thursday, May 04, 2000 1:55 PM
To: Mike Fletcher; Zope Development (E-mail)
Subject: Re: [Zope-dev] Adding your own (complex) data types to property
pages: example a nd problems...nd problems...


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. :) )