Re: [Zope-dev] a simple example of the ZPatterns frame work
"Phillip J. Eby" wrote: > >The AttributeProvider (that my rack have by default) raise an exception > >in MyItem.__init__ because i and s do not exist (indeed, I want to > >create them in the instance!) > > Could you give the traceback? I think it is more likely your __init__ is > failing because you are setting self.id. You should not set self.id > directly in your __init__ method, you should call RackMountable's __init__ > method like this: > Thanks for the insight. It is a pity that I can't write e-mail from where I work. When I'm back to the office, I will cut and paste the traceback and send it to you tomorrow. I hope it will be useful. You probably noticed that when you are at work, it's time to sleep for me. see you tomorrow :-) we-should-definitely-have-36-hours-a-day-ly yours, Jephte CLAIN [EMAIL PROTECTED] begin:vcard n:CLAIN;Jephte x-mozilla-html:FALSE version:2.1 email;internet:[EMAIL PROTECTED] adr;quoted-printable:;;71 rue Lory les Hauts=0D=0AAppt 16;Ste Clotilde;;97490; x-mozilla-cpt:;0 fn:Jephte CLAIN end:vcard
Re: [Zope-dev] a simple example of the ZPatterns frame work
At 12:53 PM 5/18/00 +0400, Jephte CLAIN wrote: > > >"Phillip J. Eby" a écrit : >> >> When created, Racks create some default Attribute and Sheet providers. >> These objects are used by Rackmountables to access data which is not stored >> directly in the rackmountable. > >Indeed, attribute and sheets are not stored in the rackmountable. Where >are they stored then? in the specialist? in the rack? reading the code >does not help to answer that question. They are stored wherever the SheetProvider or AttributeProvider specifies. That is the point of having AttributeProviders and SheetProviders - to make it possible to put things in different places without application-level code needing to know where/how they are stored. >say I have in MyItem.py: > >class MyItem(RackMountable, Item): > "" > meta_type = 'My Item' > > def __init__(self, id): > self.id = id > self.i = 0 > self.s = '' > >and in __init__.py, MyItem is registered as a z base class > >i and s are properties my objects are going to store. I would like to >use MyItem objects until I am ready to move the data into an SQL >database, where i and s will be columns in a table. > >The AttributeProvider (that my rack have by default) raise an exception >in MyItem.__init__ because i and s do not exist (indeed, I want to >create them in the instance!) Could you give the traceback? I think it is more likely your __init__ is failing because you are setting self.id. You should not set self.id directly in your __init__ method, you should call RackMountable's __init__ method like this: def __init__(self,id): RackMountable.__init__(self,id) self.i = 0 self.s = '' Or, better yet, don't define an __init__ method at all, and set the default values for i and s in your class itself. As a general rule, RackMountables should not redefine the __init__ method. (And yes, I'm going to add that rule to the docstrings right now...) >Also, say I want to add the OFS.ProperyManager.PropertyManager mixin >class to MyItem to manage my properties through the standard interface. >Will it clash with the sheet provider? No. RackMountables can be PropertyManagers. The attributes will be handled by the AttributeProviders. >I'm not interested in the ZPatterns framework to allow my customers to >customize the data sources or the collaborators. I'm interested in it >because I want to develop code that is independant of the data sources. >I want to store some data in the ZODB (because they are python list and >dict, or because it is easier for me to use Zope objects until I move to >a SQL database), and some of them in an SQL database (because they might >be used by externals applications), but still want to have a common >interface to the data. The default AttributeProviders for a Rack are of two kinds: an "acquired" provider and a "persistent internal" provider. The "persistent internal" provider simply stores attributes in the object itself whenever you set them. i.e., it assumes that the object is stored in the ZODB, so setting an attribute will cause it to be stored. In effect, it's as though you just had a normal ZODB object. The "acquired" provider allows you to share AttributeProviders between Racks in a Specialist. If you add AttributeProviders to the Specialist, the "acquired" provider will detect this and make the appropriate attributes available in the Rack. Both of these providers can be removed or reconfigured; by default they are set up to use all available providers from the Specialist, and to allow any attribute to be set in a rack-mounted object. As other providers become available, such as SQLAttributeProvider or LDAPAttributeProvider (which Ty is tinkering with at the moment), I think this will all begin to make a bit more sense. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] a simple example of the ZPatterns frame work
"Phillip J. Eby" a écrit : > > At 08:39 PM 5/17/00 +0400, Jepthte CLAIN wrote: > > > >I wonder if someone can send me a simple example using the ZPatterns > >framework. I read all the source, and I still can't figure out what is > >the relationship between the objects instantiated by the Racks and the > >Rackmountable objects. Also, why do the rack try to instantiate a > >ZClass??? > > When created, Racks create some default Attribute and Sheet providers. > These objects are used by Rackmountables to access data which is not stored > directly in the rackmountable. Indeed, attribute and sheets are not stored in the rackmountable. Where are they stored then? in the specialist? in the rack? reading the code does not help to answer that question. > > When used, Racks create instances of the ZClass you've specified. If you > call newItem(key), you will receive a new instance of that ZClass, which > will be stored in the rack under the specified key. Whenever you call > getItem(key), the instance will be retrieved. Some Racks, like > GenericUserSource, do not store items in themselves, but in external > databases. When you call getItem(key) on a GUS, it calls methods to access > the external database, then creates an instance of the appropriate > LoginUser subclass and returns that. > I don't like ZClasses, because I want to use XEmacs to edit my code. In fact, I have trouble using a python class to store my data. say I have in MyItem.py: class MyItem(RackMountable, Item): "" meta_type = 'My Item' def __init__(self, id): self.id = id self.i = 0 self.s = '' and in __init__.py, MyItem is registered as a z base class i and s are properties my objects are going to store. I would like to use MyItem objects until I am ready to move the data into an SQL database, where i and s will be columns in a table. The AttributeProvider (that my rack have by default) raise an exception in MyItem.__init__ because i and s do not exist (indeed, I want to create them in the instance!) Also, say I want to add the OFS.ProperyManager.PropertyManager mixin class to MyItem to manage my properties through the standard interface. Will it clash with the sheet provider? > Hope that helps; I'm not 100% clear on your question. Anyway, my question was not 100% clear neither :-) I'm not interested in the ZPatterns framework to allow my customers to customize the data sources or the collaborators. I'm interested in it because I want to develop code that is independant of the data sources. I want to store some data in the ZODB (because they are python list and dict, or because it is easier for me to use Zope objects until I move to a SQL database), and some of them in an SQL database (because they might be used by externals applications), but still want to have a common interface to the data. I'm still figuring out how it works, but once I'm done, I will rule the world :-) Thanks for your good work, and thanks for the advices! regards, jephte clain [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] a simple example of the ZPatterns frame work
"Phillip J. Eby" wrote: > > At 08:39 PM 5/17/00 +0400, Jepthte CLAIN wrote: > > > >I wonder if someone can send me a simple example using the ZPatterns > >framework. I read all the source, and I still can't figure out what is > >the relationship between the objects instantiated by the Racks and the > >Rackmountable objects. Also, why do the rack try to instantiate a > >ZClass??? > > When created, Racks create some default Attribute and Sheet providers. > These objects are used by Rackmountables to access data which is not stored > directly in the rackmountable. > > When used, Racks create instances of the ZClass you've specified. If you > call newItem(key), you will receive a new instance of that ZClass, which > will be stored in the rack under the specified key. Whenever you call > getItem(key), the instance will be retrieved. Some Racks, like > GenericUserSource, do not store items in themselves, but in external > databases. When you call getItem(key) on a GUS, it calls methods to access > the external database, then creates an instance of the appropriate > LoginUser subclass and returns that. > > Hope that helps; I'm not 100% clear on your question. It helps me a litle. I think what Jepthe was asking for though, is a simple howto. For example, lets say I wanted to implement a image-like object that stored the actual in a SQL database, for example, with 'meta' information (photographer, date, category, etc) stored in the ZODB for indexing and management. A walkthrough on how to do this would be especially useful at this stage. At least, that's what I interpreted Jepthe as wanting. no-my-desire-for-this-colored-my-perception-in-way-:^)-ly y'rs Bill ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] a simple example of the ZPatterns frame work
At 08:39 PM 5/17/00 +0400, Jepthte CLAIN wrote: > >I wonder if someone can send me a simple example using the ZPatterns >framework. I read all the source, and I still can't figure out what is >the relationship between the objects instantiated by the Racks and the >Rackmountable objects. Also, why do the rack try to instantiate a >ZClass??? When created, Racks create some default Attribute and Sheet providers. These objects are used by Rackmountables to access data which is not stored directly in the rackmountable. When used, Racks create instances of the ZClass you've specified. If you call newItem(key), you will receive a new instance of that ZClass, which will be stored in the rack under the specified key. Whenever you call getItem(key), the instance will be retrieved. Some Racks, like GenericUserSource, do not store items in themselves, but in external databases. When you call getItem(key) on a GUS, it calls methods to access the external database, then creates an instance of the appropriate LoginUser subclass and returns that. Hope that helps; I'm not 100% clear on your question. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] a simple example of the ZPatterns frame work
Hello, I wonder if someone can send me a simple example using the ZPatterns framework. I read all the source, and I still can't figure out what is the relationship between the objects instantiated by the Racks and the Rackmountable objects. Also, why do the rack try to instantiate a ZClass??? I'm lost. The LoginManager code does not answer my question because the generic user source does not instantiate any object. comments ? Regards, Jephte CLAIN [EMAIL PROTECTED] begin:vcard n:CLAIN;Jephte x-mozilla-html:FALSE version:2.1 email;internet:[EMAIL PROTECTED] adr;quoted-printable:;;71 rue Lory les Hauts=0D=0AAppt 16;Ste Clotilde;;97490; x-mozilla-cpt:;0 fn:Jephte CLAIN end:vcard
