Re: [Zope-dev] ZPatterns AttributeProvider question
Hi! So here's more :) > >def _objectAdding(self,client, > >_tmap={ None:AddedStatus, > >DeletedStatus:ChangedStatus, > >ChangedStatus:AddedStatus > >} > >): > >t = client._getTokenFor(self) > >s = t.status > >t.status = _tmap.get(s,s) > > > ># we need to do a commit here in order to store the record into > the database! > > # and we need to have it stored as an AttributeFor() of the primary key will > > # return None otherwise (as this also just makes a query). > >client.commitSubtransaction() > > This is broken. Don't do this! commitSubtransaction() is an > application-level operation. Only. If you have to use it inside of > provider-level code or code called from SkinScript, chances are that you > are doing something horribly wrong. You run the risk of causing a > recursive commit operation in the Zope transaction machinery. Don't do this! well, it always looked no-good to me, I just didn't know how to solve my problem. So my problem I was trying to fix was actually the following: - When creating a new object via newItem(), the Rack checks if self.loadAttrib is defined before creating a new one. if loadAttrib is returned by the attribute provider then the Rack assumes it already exists and raises an exception. - My Attribute Provider now does not know if an object exists or not before looking into the database (I tried different ways to check it but somehow they haven't worked). So it does that. If it finds a record with the given id it returns it, if not it returns the default value (which means "does not exist" to the rack). - When adding a new object in my provider it does an insert via an ZSQL method to store it inside the database. This is done in _objectAdded(). Unfortunately this is too late as before this is called, we already need to have it in the database as the request to my primary key will return the default still. So I moved this insert to _objectAdding(). Unfortunately this new record seems not to appear in the database before commit() (dunno why, maybe some new transaction code in ZMySQLDA? haven't checked this). That's why I did a commit() there which then called _objectAdded(). So my problem is basically that I need to know in _AttributeFor() whether this object is already created or not.. I will check now again with asking the status of the client but I think I also tried this before. The best would be to collect all data before _objectAdded() and store it at once and not as it's done now by first creating an empty record and doing the rest via _objectChanged(). But I am open for any other idea :) > >def _SetAttributeFor(self,client,name,value): > >"""Set the attribute and return true if successful""" > > # attribs stores the attributes we care about > >if name in self._attribs.keys(): > >client._getCache()[name]=value > >client.__dict__[name]=value; > > client._p_changed = 1 > >return 1 > >return None > > This also looks broken to me. Why are you changing both the cache and the > persistent state? There's no reason to do both. ok, this is old code where I wanted to test some other solution to fix my problem. I will remove the additional line.. (__dict__ might be all I need, it's already a cache if I remember right?!?) > I think you're seriously over-engineering this. I don't see anything that > you're doing here that couldn't be done more easily with SkinScript > statements. If all you want to do is store the data in an SQL database, a > few SkinScript triggers would suffice. Well, as mailed yesterday I know this. I've also done this a lot but was then tired of always typing those paramater lists (for each ZSQL method, for each SkinScript call twice, ...). This is of course always the tradeoff between easy to use plugins which are somehow restricted and the more flexible ones which do need lots of configuration. I would like to have the first one for the day-to-day-stuff and the latter for more advanced operations, like linking specialists together etc. > Now, if you're trying to get a row to be inserted in an SQL database at the > actual time of the newItem() call, there is a trick you can use to do that > from SkinScript also. Do this: > > INITIALIZE OBJECT WITH someAttr1=default1, > someAttr2=default2,...,dummyAttributeName=myInsertQuery(primaryKey=self.id) > > Where myInsertQuery() is an SQL insert query that takes primaryKey as a > parameter, and dummyAttributeName is some attribute name you don't care > about. You should also set any default values for fields that will be > inserted. Your insert query will be called, initializing the row in the > database, and then use something like this: > > WHEN OBJECT ADDED,CHANGED STORE foo,bar,baz USING > UpdateMethod(widget_id=self.id, foo_field=self.foo, wbar=self.bar) > > > To update t
Re: [Zope-dev] ZPatterns AttributeProvider question
Hi! Just a quick note as it's quite late already (more tomorrow): > In the early days of ZPatterns, I assumed that I would create SQL > providers, LDAP providers, and suchlike gizmos. Later, it became clear > that it was more useful to have a simple "glue" language to allow > harnessing the full power of Zope in the context of events happening to > objects. I still toy with the idea of making an "SQL attribute provider", > however, that would be based on the ZSQLMethod object and add some > ZPatterns hooks to it, but it's not a big priority. Its main value would > be to cut down on some repetitive typing between one's SQL statements and > SkinScript statements. Well, exactly this was the intention of programming this as I was a bit bored by all this typing, exactly when the attribute lists are getting longer. So right now I define it once in the ZClass, press the "Read ZCLass propsheet" button and the my attribute provider sets everything up itself.. (it also saves me from typing errors..) Actually I did it with SkinScript before but thought some simple plugin would be nicer.. But thanks for explaining the inner workings in some more detail (maybe I should put this into some howto or so? or it might be put into the ZPatterns wiki..), as this really should help (not only me I guess :) I will comment more on this tomorrow.. (at least I got some idea how I might solve my problem... though I thought this some times before already.. ;-) And the other possible option would be (as Steve suggested once on IRC) to create some wizard which sets up all the SkinScript methods and ZSQL methods in one go.. Anyway, more about it tomorrow. good nite.. Christian -- COM.lounge http://comlounge.net/ communication & design [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] ZPatterns AttributeProvider question
At 08:29 PM 4/22/01 +0200, Christian Scholz wrote: >Hi! > >A little update.. > >Actually I was mistaken and SetAttributeFor() is called. Just _objectChanged() >is not called in that case.. and thus my attributes are not stored to the database. When an object is newly added, only _objectAdded() is called. _objectAdded(), _objectChanged(), and _objectDeleted() are mutually exclusive within a given transaction. That is, only one of them occurs in a given transaction. See more below. >Maybe some more code will help (just the important pieces): > >def _objectAdded(self,client): >""" store cached data in database """ > > ... here we do an sql query to insert things in database ... > >def _objectChanged(self,client): >""" store cached data in database """ > > ... here we do an sql query to update things in database ... > >def _objectAdding(self,client, >_tmap={ None:AddedStatus, >DeletedStatus:ChangedStatus, >ChangedStatus:AddedStatus >} >): >t = client._getTokenFor(self) >s = t.status >t.status = _tmap.get(s,s) > ># we need to do a commit here in order to store the record into the database! > # and we need to have it stored as an AttributeFor() of the primary key will > # return None otherwise (as this also just makes a query). >client.commitSubtransaction() This is broken. Don't do this! commitSubtransaction() is an application-level operation. Only. If you have to use it inside of provider-level code or code called from SkinScript, chances are that you are doing something horribly wrong. You run the risk of causing a recursive commit operation in the Zope transaction machinery. Don't do this! >def _SetAttributeFor(self,client,name,value): >"""Set the attribute and return true if successful""" > # attribs stores the attributes we care about >if name in self._attribs.keys(): >client._getCache()[name]=value >client.__dict__[name]=value; > client._p_changed = 1 >return 1 >return None This also looks broken to me. Why are you changing both the cache and the persistent state? There's no reason to do both. >So _objectChanging() is not overridden, the rest I have ommitted.. > >So as you also can see I already do a subtransaction commit but it does >not seem to help for this problem.. > I think you're seriously over-engineering this. I don't see anything that you're doing here that couldn't be done more easily with SkinScript statements. If all you want to do is store the data in an SQL database, a few SkinScript triggers would suffice. Now, if you're trying to get a row to be inserted in an SQL database at the actual time of the newItem() call, there is a trick you can use to do that from SkinScript also. Do this: INITIALIZE OBJECT WITH someAttr1=default1, someAttr2=default2,...,dummyAttributeName=myInsertQuery(primaryKey=self.id) Where myInsertQuery() is an SQL insert query that takes primaryKey as a parameter, and dummyAttributeName is some attribute name you don't care about. You should also set any default values for fields that will be inserted. Your insert query will be called, initializing the row in the database, and then use something like this: WHEN OBJECT ADDED,CHANGED STORE foo,bar,baz USING UpdateMethod(widget_id=self.id, foo_field=self.foo, wbar=self.bar) To update the data at transaction commit time. Voila. No need to make any custom attribute providers just to do this. Just to clarify the event sequence that should take place: 1. newItem() is called, which fires an _objectCreating() event 1.1. The SkinScript INITIALIZE OBJECT statement is triggered by the _objectCreating() event, and calls myInsertQuery() to insert a row in the database, with default values for everything but the primary key. 1.2. newItem() fires an _objectAdding() event, which does nothing except flag the object as "AddedStatus" and pass the event back to the DataManager (Rack). 1.3. The Rack passes the _objectAdding() event to all appropriately registered providers. The WHEN OBJECT ADDED,CHANGED statement is such a provider, so it receives the message and notes that the DataSkin was added, but does not act on it yet. Instead, it registers a proxy for itself with the Zope transaction object so that it will be notified of transaction commit. 2. newItem() returns a new DataSkin to your application, bearing the contents set up by the INITIALIZE OBJECT WITH statement. 3. Your application calls manage_changeProperties, to change an attribute. 3.1. The DataSkin fires an _objectChanging() event, which flags the object as "ChangedStatus", and the event is propagated to all registered providers in the Rack. (Such as the WHEN OBJECT statement) 3.2. The WHEN OBJECT statement ignores the _objectChanging() event, because from its point of view the object is in AddedS
Re: [Zope-dev] ZPatterns AttributeProvider question
At 08:29 PM 4/22/01 +0200, Christian Scholz wrote: >Hi! > >A little update.. > >Actually I was mistaken and SetAttributeFor() is called. Just _objectChanged() >is not called in that case.. and thus my attributes are not stored to the database. When an object is newly added, only _objectAdded() is called. _objectAdded(), _objectChanged(), and _objectDeleted() are mutually exclusive within a given transaction. That is, only one of them occurs in a given transaction. See more below. >Maybe some more code will help (just the important pieces): > >def _objectAdded(self,client): >""" store cached data in database """ > > ... here we do an sql query to insert things in database ... > >def _objectChanged(self,client): >""" store cached data in database """ > > ... here we do an sql query to update things in database ... > >def _objectAdding(self,client, >_tmap={ None:AddedStatus, >DeletedStatus:ChangedStatus, >ChangedStatus:AddedStatus >} >): >t = client._getTokenFor(self) >s = t.status >t.status = _tmap.get(s,s) > ># we need to do a commit here in order to store the record into the database! > # and we need to have it stored as an AttributeFor() of the primary key will > # return None otherwise (as this also just makes a query). >client.commitSubtransaction() This is broken. Don't do this! commitSubtransaction() is an application-level operation. Only. If you have to use it inside of provider-level code or code called from SkinScript, chances are that you are doing something horribly wrong. You run the risk of causing a recursive commit operation in the Zope transaction machinery. Don't do this! >def _SetAttributeFor(self,client,name,value): >"""Set the attribute and return true if successful""" > # attribs stores the attributes we care about >if name in self._attribs.keys(): >client._getCache()[name]=value >client.__dict__[name]=value; > client._p_changed = 1 >return 1 >return None This also looks broken to me. Why are you changing both the cache and the persistent state? There's no reason to do both. >So _objectChanging() is not overridden, the rest I have ommitted.. > >So as you also can see I already do a subtransaction commit but it does >not seem to help for this problem.. > I think you're seriously over-engineering this. I don't see anything that you're doing here that couldn't be done more easily with SkinScript statements. If all you want to do is store the data in an SQL database, a few SkinScript triggers would suffice. Now, if you're trying to get a row to be inserted in an SQL database at the actual time of the newItem() call, there is a trick you can use to do that from SkinScript also. Do this: INITIALIZE OBJECT WITH someAttr1=default1, someAttr2=default2,...,dummyAttributeName=myInsertQuery(primaryKey=self.id) Where myInsertQuery() is an SQL insert query that takes primaryKey as a parameter, and dummyAttributeName is some attribute name you don't care about. You should also set any default values for fields that will be inserted. Your insert query will be called, initializing the row in the database, and then use something like this: WHEN OBJECT ADDED,CHANGED STORE foo,bar,baz USING UpdateMethod(widget_id=self.id, foo_field=self.foo, wbar=self.bar) To update the data at transaction commit time. Voila. No need to make any custom attribute providers just to do this. Just to clarify the event sequence that should take place: 1. newItem() is called, which fires an _objectCreating() event 1.1. The SkinScript INITIALIZE OBJECT statement is triggered by the _objectCreating() event, and calls myInsertQuery() to insert a row in the database, with default values for everything but the primary key. 1.2. newItem() fires an _objectAdding() event, which does nothing except flag the object as "AddedStatus" and pass the event back to the DataManager (Rack). 1.3. The Rack passes the _objectAdding() event to all appropriately registered providers. The WHEN OBJECT ADDED,CHANGED statement is such a provider, so it receives the message and notes that the DataSkin was added, but does not act on it yet. Instead, it registers a proxy for itself with the Zope transaction object so that it will be notified of transaction commit. 2. newItem() returns a new DataSkin to your application, bearing the contents set up by the INITIALIZE OBJECT WITH statement. 3. Your application calls manage_changeProperties, to change an attribute. 3.1. The DataSkin fires an _objectChanging() event, which flags the object as "ChangedStatus", and the event is propagated to all registered providers in the Rack. (Such as the WHEN OBJECT statement) 3.2. The WHEN OBJECT statement ignores the _objectChanging() event, because from its point of view the object is in AddedS
Re: [Zope-dev] ZPatterns AttributeProvider question
Hi! A little update.. Actually I was mistaken and SetAttributeFor() is called. Just _objectChanged() is not called in that case.. and thus my attributes are not stored to the database. Also commit() is not called at all in this case. It get's called once when the subtranscation is committed but not after some data has changed (which happens after that). Printing _v_status_ in SetAttributeFor() also gives me "Changed", thus this seems right. Maybe some more code will help (just the important pieces): def _objectAdded(self,client): """ store cached data in database """ ... here we do an sql query to insert things in database ... def _objectChanged(self,client): """ store cached data in database """ ... here we do an sql query to update things in database ... def _objectAdding(self,client, _tmap={ None:AddedStatus, DeletedStatus:ChangedStatus, ChangedStatus:AddedStatus } ): t = client._getTokenFor(self) s = t.status t.status = _tmap.get(s,s) # we need to do a commit here in order to store the record into the database! # and we need to have it stored as an AttributeFor() of the primary key will # return None otherwise (as this also just makes a query). client.commitSubtransaction() def _SetAttributeFor(self,client,name,value): """Set the attribute and return true if successful""" # attribs stores the attributes we care about if name in self._attribs.keys(): client._getCache()[name]=value client.__dict__[name]=value; client._p_changed = 1 return 1 return None So _objectChanging() is not overridden, the rest I have ommitted.. So as you also can see I already do a subtransaction commit but it does not seem to help for this problem.. regards, Christian PS: It might also be that I am simply blind ;-) But somehow ZPatterns always confuses me, especially the inner workings ;-) -- COM.lounge http://comlounge.net/ communication & design [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] ZPatterns AttributeProvider question
Phillip J. Eby wrote: > Steve Alexander wrote: > >> As a simpler workaround, you can use >>your_object.commitSubtransaction() instead of redirecting to a new page. >> > Um, this shouldn't be the issue here. _SetAttributeFor() should be called > when the attribute is set; it's not transaction-driven. Something weird is > happening with Christian's situation that I haven't investigated yet. I agree. However, if Christian's problem can be worked-around by redirecting before setting attributes, then it should also be workaroundable by calling commitSubtransaction. > Actually, the status should be AddedStatus, and it should stay that way > throughout the transaction, unless the object gets deleted in the same > transaction. That's what I'd originally thought. Then I (mis-?)read the code again... The __set_attr__ method of DataSkins.py says: self._objectChanging(name) The _objectChanging method says: if self._v_status_ is not ChangedStatus: d[_v_dm_]._objectChanging(self) d[_v_status_] = ChangedStatus I don't see an exception for if _v_status is already AddedStatus. -- Steve Alexander Software Engineer Cat-Box limited ___ 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] ZPatterns AttributeProvider question
At 03:07 PM 4/22/01 +0100, Steve Alexander wrote: > > As a simpler workaround, you can use >your_object.commitSubtransaction() instead of redirecting to a new page. Um, this shouldn't be the issue here. _SetAttributeFor() should be called when the attribute is set; it's not transaction-driven. Something weird is happening with Christian's situation that I haven't investigated yet. > You really should be able to create a new object and set its >attributes in the same transaction. The status of the object (_v_status >in DataSkin.py) will be ChangedStatus, if you're adding and changing in >the same transaction. That's a good place to look for where the problem is. Actually, the status should be AddedStatus, and it should stay that way throughout the transaction, unless the object gets deleted in the same transaction. ___ 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] ZPatterns AttributeProvider question
Christian Scholz wrote: > > So what I do now as workaround is > > dtml method 1: > > - creates new object via newItem() > - redirects to dtml method 2 > > dtml method 2: > - retrieves the newly created object with getItem() > - calls manage_changeProperties on that object > > This is working. Putting the manage_changeProperties directly after the > newItem() is not working. I've also tried retrieving the new object > directly after newItem() and calling manage_changeProperties on that > but this also did not work. > (so it is named correctly as otherwise it wouldn't be called either in dtml method >2). > > So the main problem is: SetAttributeFor() is not called (and also _objectChanging() > is not called) in the same request cycle after creating a new object. > They're called however in the "next" request after retrieving it with getItem(). As a simpler workaround, you can use your_object.commitSubtransaction() instead of redirecting to a new page. A few Zope versions ago, that could conceivably cause problems with certain database adapters. With some of the recent fixes to Zope, you should be ok using subtransactions even with DAs that don't support them. Check this out before you use it for important stuff though :-) You really should be able to create a new object and set its attributes in the same transaction. The status of the object (_v_status in DataSkin.py) will be ChangedStatus, if you're adding and changing in the same transaction. That's a good place to look for where the problem is. -- Steve Alexander Software Engineer Cat-Box limited ___ 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] ZPatterns AttributeProvider question
Hi! > >Yes, as said above it registers for handlers and attributes. Also > >_objectChanged and _SetAttributeFor() etc. are called. They're just not > called > >directly after creating the object (when being in the same request that is). > > _objectChanged() is a transaction-commit message. You'll only get it when > the (sub)transaction commits. You'll receive _objectChanging() just > *before* the object changes. Yep, that's how I understood it. That's also working. > As for _SetAttributeFor(), it should be called at the time > manage_changeProperties executes, not at object creation. Are you sure > that you have it properly named and that it isn't still being defined by > one of your ancestor classes instead? The "AttributeProvider" and > "GTMixin" base classes in ZPatterns implement _SetAttributeFor() by simply > noting the change for later. If you don't override this behavior, your > class won't see _SetAttributFor() itself. Well, it actually is working, just not directly after creating the new object. So what I do now as workaround is dtml method 1: - creates new object via newItem() - redirects to dtml method 2 dtml method 2: - retrieves the newly created object with getItem() - calls manage_changeProperties on that object This is working. Putting the manage_changeProperties directly after the newItem() is not working. I've also tried retrieving the new object directly after newItem() and calling manage_changeProperties on that but this also did not work. (so it is named correctly as otherwise it wouldn't be called either in dtml method 2). So the main problem is: SetAttributeFor() is not called (and also _objectChanging() is not called) in the same request cycle after creating a new object. They're called however in the "next" request after retrieving it with getItem(). Maybe it helps if I publish the source somewhere? It's gonna be some public product anyway. regards, Christian -- COM.lounge http://comlounge.net/ communication & design [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] ZPatterns AttributeProvider question
At 08:18 PM 4/21/01 +0200, Christian Scholz wrote: >Hi! > >> > Good evening everybody! >> > >> > I have some question regarding attribute and agent programming for ZPatterns. >> > >> > I have some provider which is registered for the "handlers" and "attributes" >> > methods and some attributes. >> > >> > My problem is when trying to create a new object and directly editing it, e.g. >> > >> > obj=newItem() >> > obj.propertysheets.data.manage_changeProperties(foobar=13) >> > >> > the propertysheet is defined and my provider is also registered for >> > handling the property "foobar". Unfortunately my SetAttributeFor() method >> > is never called. >> >> >> Have you defined a namesForRegistration method in your provider? > >Yes, as said above it registers for handlers and attributes. Also >_objectChanged and _SetAttributeFor() etc. are called. They're just not called >directly after creating the object (when being in the same request that is). _objectChanged() is a transaction-commit message. You'll only get it when the (sub)transaction commits. You'll receive _objectChanging() just *before* the object changes. As for _SetAttributeFor(), it should be called at the time manage_changeProperties executes, not at object creation. Are you sure that you have it properly named and that it isn't still being defined by one of your ancestor classes instead? The "AttributeProvider" and "GTMixin" base classes in ZPatterns implement _SetAttributeFor() by simply noting the change for later. If you don't override this behavior, your class won't see _SetAttributFor() itself. ___ 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] ZPatterns AttributeProvider question
Hi! > > Good evening everybody! > > > > I have some question regarding attribute and agent programming for ZPatterns. > > > > I have some provider which is registered for the "handlers" and "attributes" > > methods and some attributes. > > > > My problem is when trying to create a new object and directly editing it, e.g. > > > > obj=newItem() > > obj.propertysheets.data.manage_changeProperties(foobar=13) > > > > the propertysheet is defined and my provider is also registered for > > handling the property "foobar". Unfortunately my SetAttributeFor() method > > is never called. > > > Have you defined a namesForRegistration method in your provider? Yes, as said above it registers for handlers and attributes. Also _objectChanged and _SetAttributeFor() etc. are called. They're just not called directly after creating the object (when being in the same request that is). cheers, Christian -- COM.lounge http://comlounge.net/ communication & design [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] ZPatterns AttributeProvider question
Christian Scholz wrote: > Good evening everybody! > > I have some question regarding attribute and agent programming for ZPatterns. > > I have some provider which is registered for the "handlers" and "attributes" > methods and some attributes. > > My problem is when trying to create a new object and directly editing it, e.g. > > obj=newItem() > obj.propertysheets.data.manage_changeProperties(foobar=13) > > the propertysheet is defined and my provider is also registered for > handling the property "foobar". Unfortunately my SetAttributeFor() method > is never called. Have you defined a namesForRegistration method in your provider? See Components.py for an example: lib/python/Products/ZPatterns/SkinScript/Components.py -- Steve Alexander Software Engineer Cat-Box limited ___ 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 )