May 2000 - Zope-Dev - Zope lists

Adding your own (complex) data types to property pages: example a nd problems... nd problems...
by Mike Fletcher 05 May '00

05 May '00

It is often necessary to have slightly more complex data types on your Z-Class-like products. For instance, in my current project, I need to be able to set VRML-style vectors (particularly colors and three-element float vectors). Zope allows for creating converters fairly easily, so that you can register code for interpreting data types. However, Zope handles the creation of input fields for property pages through a hard-coded if/elif/else mechanism in OFS/properties.dtml . The result is that your non-standard datatype shows up as "Unrecognized field type" and will not be part of the form when submitted (which will often cause logic errors if (as is likely) it is a required property). Of course, it is possible to create custom manage documents for each property page which has more advanced data types, but this almost completely obviates the value of using property pages (i.e. automatic management of property sets such that the programmer need not even consider the management interface). 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)? Here is the example of creating the converters: A product wishing to use these converters merely imports this module, and is then able to use property types such as VRML97_SFVec3f (a single-field vector composed of three-floats). Currently, they will have to also create custom property management pages as well :( . Enjoy yourselves, Mike 8<____ vrmltypeconverters.py _________ from ZPublisher import Converters import re, string whiteSpaceRegex = re.compile( '[ \011-\015,]+' ) killBrackets = string.maketrans( '[]()',' ') class field2Vec: def __init__ (self, multiple= 0, number= 3, range= ( None, None), name= "SFVec3f", converter=string.atof): self.multiple = multiple self.number = number self.range = range self.name = name self.converter = converter def __call__(self,value): ''' Convert an HTML field value into a three-element list ''' if hasattr (value, "read"): value = value.read() else: value = str( value) if not value and not self.multiple: raise ValueError ("%s value cannot be null"%self.name) elif not value: return [] # in case someone has used brackets, eliminate them from the string as white space value = string.translate( value, killBrackets) value = whiteSpaceRegex.split (value) if self.multiple and len(value) % self.number: raise ValueError ("%s value must have even multiple of %s entries, has %s: %s"%( self.name, self.number, len(value), value ) ) elif (not self.multiple) and len(value) != self.number: raise ValueError ("%s value must have %s entries, has %s: %s"%( self.name, self.number, len(value), value ) ) # we have a correct number of elements result = [] for item in value: try: # first see if the value is valid for this type item = self.converter (item) except ValueError: raise ValueError ("%s value (%s) is not recognizable as a %s value"%(self.name, item, self.name)) # now check ranges if (self.range [0] is not None) and item < self.range[0]: raise ValueError ("%s value (%s) is below range for %s elements, minimum is %s"%(self.name, item, self.name, self.range [0])) elif (self.range [1] is not None) and item > self.range[1]: raise ValueError ("%s value (%s) is above range for %s elements, maximum is %s"%(self.name, item, self.name, self.range [1])) else: # okay, we can append result.append( item ) return result def toInteger (value): return string.atoi( value, 0) Converters.type_converters.update( { 'VRML97_SFVec3f': field2Vec(), 'VRML97_SFVec2f': field2Vec( number = 2), "VRML97_SFColor": field2Vec( range = (0.0, 1.0) ), "VRML97_SFRotation": field2Vec( number = 4), "VRML97_SFImage": field2Vec( number = 1, converter =toInteger, multiple = 1), "VRML97_MFVec3f":field2Vec( multiple = 1), 'VRML97_MFVec2f': field2Vec( number = 2, multiple = 1), "VRML97_MFColor": field2Vec( range = (0.0, 1.0), multiple = 1 ), "VRML97_MFRotation": field2Vec( number = 4, multiple = 1), "VRML97_MFInt32": field2Vec( number = 1, converter =toInteger, multiple = 1 ), "VRML97_MFFloat": field2Vec( number = 1, multiple = 1), }) __________________________________ Mike C. Fletcher Designer, VR Plumber http://members.home.com/mcfletch

4 3

Re: [Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))
by Jimmie Houchin 05 May '00

05 May '00

At 9:24 AM -0500 5/4/00, Phillip J. Eby wrote: >At 10:29 PM 5/3/00 -0500, Jimmie Houchin wrote: [snip] > >>What would complement Rack storage well and is basically the topic is >>multifile ZODB. If the ZODB had multifile capability and each Rack could >>name it's file and path that the ZODB uses. Then we would have an excellent >>balance between transparency of storage and capabilities. > >Yes. But not so much multifile ZODB, as multi-*storage* ZODB or >multi-ZODB. I'd like to see a way for getting at (and managing) >connections to other ZODB's from within the "primary" ZODB. Rack already >has the dropdown and some stub routines for using this; all I need is what >to put in 'em. :) When I stop to think about what your saying I agree. My initial goals did not so much as require multiple files per se, but multi-storage. Just like a RDBMS can have multiple tables in a single file. As with RDBMS the app developer here should not have to be concerned with the physical layout of the data. That is purely the concern of the db. In this case ZODB. The only primary gain multi-file would bring is allowing for great db size on some oses. If my thinking isn't straight on this, feel free to fix it. :) Thanks, Jimmie Houchin

1 0

XML Document: why not create with FTP, WebDAV or PUT?
by Peter Ring 04 May '00

04 May '00

The release doc for XML Document 1.0a6 states that "You cannot create new XML Document objects with FTP, WebDAV or PUT." Before I delve into this, I'd like to ask: Are there a reason this should be intrinsically impossible or difficult, or is it just on the TODO list? kind regards, Peter Ring

1 0

RE: [Zope-dev] Adding your own (complex) data types to property p ages: example and problems...
by Mike Fletcher 04 May '00

04 May '00

Incidentally, I just finished the simplistic method I described. (Attached 2 files, import the .py file and it updates PropertyPages to use its mechanisms). I've only tested it lightly (1 or 2 properties per input), but it is pretty much a direct rip of the stuff in properties.py . If general consensus is that this is too ugly, I'll stop working on it (I was thinking of putting this and the extant converters module into one registry class/object that would have registration/deregistration support, but what's here now does what I need it to do (incidentally, it also adds all of the types with input handlers to the list of datatypes in the "create property" part of the properties form). "While we're waiting for the real solutions, this might fix the problem." Enjoy, Mike

1 0

RE: [Zope-dev] Adding your own (complex) data types to property p ages: example a nd problems...nd problems...
by Mike Fletcher 04 May '00

04 May '00

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

3 2

Warning! TransparentFolders and ZClasses
by Shane Hathaway 04 May '00

04 May '00

Zopistas, The current version of the TransparentFolderPatch does mix well with ZClasses. I found this out the hard way: if you have TransparentFolders installed, you cannot create ZClasses that use ObjectManager or Folder as a base class. I'll be working on a fix. Shane shane(a)digicool.com

2 2

Access to member functions of a product
by Fabio Augusto Mazzarino 04 May '00

04 May '00

Hi folks: I have a problem here. I need to access an internal method of class inside a product, but I couldn't do it until now. I supposed that this would be pretty easy, even trivial, but it doesn't seems to be so. (maybe it's a lammer question). Well, I have a class definition inside a product, it's like this class DotShop(Folder, RoleManager, Aquisition.Implicit, Persistent): meta_type = 'DotShop' def __init__(self, id, title, dbName): (...) def createClientTable(self): (...) I need to access createClientTable from a dtml method, but i cant do it. I tried to use this url: http://myserver:8080/folder/shop/createClientTable But it returns an error, telling me that this document doesn't exists. What can I do? Thanx for your help. Fabio Augusto Mazzarino - mazza(a)radiumsystems.com.br

2 1

Re: [Zope-dev] Racks and Persistence (was Alternative Storages)
by Jason Spisak 04 May '00

04 May '00

Phillip J. Eby: This clears things up *a lot*. Thank you very much. Sometimes reading the sources doesn't answer all the questions. > At 01:03 AM 5/4/00 +0000, Jason Spisak wrote: > > > >What about storing the class data itself in a Rack? Is there any > >limitation > >to what you can put into a Rack. I am only asking this to clarify what we > >are heading towards. Somewhere to put just the instance data. > > Racks hold a collection of objects derived from the RackMountable base > class. The objects may be ZClass instances, or instances of a Python > ZClass base, as long as in either case they derive from RackMountable. > RackMountable (as of ZPatterns 0.3.0) contains a C mixin class that gives > Persistent objects the ability to coexist with (renamed) > __get/set/delattr__ methods. It also contains hooks that delegate various > operations to the Rack, such as propertysheet management. > > When a RackMountable is retrieved from a Rack, the Rack calls _setRack() on > the RackMountable to tell it where it came from. From then on, the > RackMountable can delegate its data management operations to the Rack. > > Conceptually, a Rack is like a database table. It holds only one kind of > object (although there are ways around that if it's really needed), and has > a key by which items are stored/retrieved. The basic Rack interface > consists of Rack.getItem(key) and Rack.newItem(key). Both return an > instance of the class the Rack stores. You then talk to that object > directly for any operations you need, such as setting its initial > properties, or telling it to delete itself from the Rack. Racks have a > "Methods" tab, however, where you can add your own DTML, Python, or > whatever else to add extended operations such as searching, automatic > generation of sequential ID's, etc. By default, Racks use the "id" > attribute as a key, but this can be overridden in a subclass if you desire. > > > > >So a "standard" ZODB connection from which a class can get it's data which > >can be fulfilled by anything inherited from BaseStorage? > > Um, no, it would need to be something which could provide a ZODB > connection. <Lights going on> >The connection would be back-ended to something inheriting > from BaseStorage, yes. In practice, all that Racks need is someplace to > retrieve a BTree object with all its attached children (PersistentMapping > objects containing instance data and/or propertysheets). > > > >> The thing about these "persistence providers", though, is that they need to > >> provide some kind of root for each thing that wants to use them. > > > >Is that for acquisition sake or class container sake or what exactly? > > It's a ZODB internal issue. A ZODB has to have a root object, which is > normally a PersistentMapping. Items placed in that root are never garbage > collected. That root's namespace would have to be shared among the users > of that ZODB in some fashion, and garbage collection would be important so > that deleting a Rack from the primary ZODB would ensure deletion of its > data from the secondary ZODB. Or, alternatively, the secondary ZODB must > expose access to the root object to manually remove sub-roots. > Again thanks, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Re: [Zope-dev] Alternative Storages: (was RelationalStorage (was LocalFS))
by Jason Spisak 04 May '00

04 May '00

Phillip J. Eby writes: > At 10:29 PM 5/3/00 -0500, Jimmie Houchin wrote: > > > >I think the Rack system can, from my understanding, handle the requirements > >I listed in my post. Basically, the ability to place certain objects with > >their own distinct storage characteristics in an appropriate storage. > > That is precisely what they were designed for. Late last year, Ty Sarna > and I were doing extensive analysis of the performance of the standard > FileStorage under high write loads and large data sets, followed by > consulting with Digital Creations to explore alternatives. What we ended > up with was realizing that there had to be a way to have (effectively) > class-by-class storage management. We took some ideas we had used > previously for SQL applications in Zope/ZPublisher, plus a few design > patterns from Coad and other sources, and came up with Rack and Implementor > (now called Specialist). > > > >What would complement Rack storage well and is basically the topic is > >multifile ZODB. If the ZODB had multifile capability and each Rack could > >name it's file and path that the ZODB uses. Then we would have an excellent > >balance between transparency of storage and capabilities. > > Yes. But not so much multifile ZODB, as multi-*storage* ZODB or > multi-ZODB. I'd like to see a way for getting at (and managing) > connections to other ZODB's from within the "primary" ZODB. Rack already > has the dropdown and some stub routines for using this; all I need is what > to put in 'em. :) > I believe Michel mailed out an idea about having Zope "mount" (don't like this term because it conjures up NFS ghosts. Boo!) specific storages at startup. Kind of a "this is the path/connection where you can find this part of the tree" Then the valid ones are available to fill your list. All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

Object hierarchy in RIPP
by Kevin Dangoor 04 May '00

04 May '00

This is mostly directed at Philip Eby, but I'm sure there are others out there who are trying to work RIPP into their design patterns. Basically, all of my Zope development has been through-the-web. I'm quite comfortable with using ZClasses, DTML, PythonMethods and ExternalMethods to get the job done. Something I'm unclear on with ZPatterns is how to do some of the things that I currently do with ZClasses. Here is a specific example: I have a database of products, built from ZClasses. Products are bundled into groups for convenience of management, and the URL of a product is based on its SKU. So, we can have a product at products/1/5, and that would be the item 1-5. This direct traversal to a product object is very useful. The products are all indexed in a ZCatalog, and I do use acquisition to get at some useful things for displaying these products. Now let's say I want to create new product objects that allow me to do the same kinds of things, but I also want a propertysheet that comes from an RDBMS (to keep track of inventory, let's say). Would I pretty much store things the same way as I have been and just work in a separate SheetProvider to take care of the inventory propertysheet? Or is there some way in which I would store things on a Rack and yet still have the traversal structure that I want? Understanding the RIPP way of tackling a problem like this would really help me out... TIA, Kevin http://www.byproducts.com - Humor and Novelties

2 1