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