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 the data at transaction commit time. Voila. No need to make any
custom attribute
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
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
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
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
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 AddedStatus.
3.3. The DataSkin calls
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 AddedStatus.
3.3. The DataSkin calls
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
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 )
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
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 )
[Zope-dev] ZPatterns AttributeProvider question
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. Also defined in my provider are _objectAdded(), _objectAdding(), _objectChanged() (but not _objectChanging()). Here's what they do: _objectAdded() is storing the data collected via SetAttributeFor() into an sql database as new record _objectAdding() is doing the same as the original method but also committing the transaction as otherwise the new record will not be stored into the database (basically it calls _objectAdded() via the transaction mechanism). I needed to do that as otherwise a getattr on the primary key (==loadAttrib) failed as I try to retrieve the record inside the _AttributeFor() method. _objectChanged() doing the same as objectAdded() but updating the sql database. So what's happening is that _objectAdding() and _objectAdded() get called from the newItem() call but _SetAttributeFor() is not called. When doing the manage_changeProperties() inside a new method which is called manually (and does a getItem()) everything is fine. I've also tried to do obj=newItem() newid=obj.id obj2=getItem(newid) obj2.propertysheets.data.manage_changeProperties(foobar=13) but this also did not call _SetAttributeFor(). So does any ZPatterns wizard has any idea on what I might do wrong? (I can also send someone the source code if this message seems too confusing ;-) regards, Christian Scholz PS: What I am trying to create is an sql attribute provider for ZPatterns which is some replacement for manually creating the zsql method and SkinScript methods. Unfortunately it seems more difficult than I thought at first ;-) -- 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 )
