- Zope-Dev - Zope lists

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

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

04 May '00

When I wrote my notes I didn't know of RIPP. When I wrote the message my thoughts/thinking had not been revised to include RIPP. However now that you mention it. :) I have read your PP version. I like what I read. At my earliest opportunity I plan on looking a ZPatterns and working on wrapping my mind around the RIPP. I reasonably well understood what I read, but it still requires a pardigm shift to change the way you think or address the problem. 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. 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. Thanks for the input. Jimmie Houchin At 7:01 PM -0500 5/3/00, Phillip J. Eby wrote: >At 05:27 PM 5/3/00 -0500, Jimmie Houchin wrote: >> >>As far as usage is concerned I generally like the ZODB best because it >>is reasonably transparent to the building of a web app with Zope. >>However there are areas in which it does not currently excel that which >>if your site requires these skills then alternatives must be used. A >>couple of areas are data size and heavy writes. > >Agreed. > > >>Some people use an RDBMS to solve these issues. While this will work it >>does expect more from the developer. Some do not have the skills or the >>tools. Even if one does it still requires leaving the transparency of >>developing with the ZODB. > >Ty and I are working on fixing that. As of today, the Specialist+Rack >subsystems of the ZPatterns library are now capable of managing objects >with mixed-source attributes and property sheets. That is, objects stored >in a Rack can have attributes and property sheets whose data comes from >non-ZODB sources. Currently, no non-ZODB sources are implemented, alas, >and the mechanism is only applicable to rack-mounted objects. In future >releases, we'll be adding SQL and LDAP data sources, and the ability for >any Zope object to take advantage of these abilities (as long as it >subclasses RackMountable, and knows how to find the "designated Rack" which >will provide support for the desired features). > > >>Class/Object based db files. >> >>Each class gets it's own db file. This could be similar to the current >>ZODB file except specific to a class. As objects are created they are >>appended to the db file for their class. This could be somewhat > >>analogous to tables in an RDBMS. >> >>Advantages would be spreading out the data space over multiple files >>which would help with some oses. Also I think that each class has >>different characteristics which would be able to be managed better if >>separate. >> > >Basically, what you've described could be considered an instance of the >Specialist and Rack patterns of the RIPP model, but with a less flexible >implementation. That is, you can do what you just described using the >Specialist/Rack patterns, but what you described won't do everything >Specialist/Rack can (such as mixed-source data for the same object or a >sensible place to put class extent methods (e.g. find, listAll, that sort >of thing)). > >The only thing missing from Rack today that would be needed to implement a >"ZODB per class" approach, is the ability to use an alternative >"persistence provider" for storage. I'd like to see some discussion on a >mechanism for providing such things. My thought is that they would sort of >look like SQL Connection objects: something you can add, that can be >acquired, and which Racks can select from a dropdown. (The dropdown even >already exists in the about-to-be-released ZPatterns 0.3.0, it just is >empty except for an option to use the primary ZODB.) > >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. I'm >assuming each provider may be shared by more than one Rack or rack-like >object, that security constraints need to exist on who can create root >branches in these DB's, and that the branches need to be able to be removed >when their owners go away. If there were a design (or implementation, >better yet) for gizmos like these, hooking up Racks to use them would be a >snap, since all Racks need to do is store a single BTree. > >(By the way, Racks can be written to store the "base" object data in an >RDBMS, db file, LDAP, or anything else that you can implment createItem(), >retrieveItem(), and deleteItem() methods for.)

3 2