Re: [Zope-dev] Racks and Specialists Simplified
At 02:33 PM 6/11/00 -0600, Shane Hathaway wrote: > >I believe I have come to understand the basics of ZPatterns and would >like to be sure I understand correctly, as well as help others >understand also. > > [a lot of good stuff snipped] > >The other concepts in ZPatterns expand upon this model. I am still >working on grasping them. Bravo! An exquisite introduction to the purpose of ZPatterns. May I post an edited version of your message to the ZPatterns Wiki, and make it or subsequently edited versions a part of the ZPatterns documentation? (With attribution, of course.) >ZPatterns also provides the "Plugins" architecture. Racks and >specialists are derived from the plugins classes. I see plugins as >being a concept that could be used by product authors who don't have a >use for racks and specialists. I wonder whether plugins ought to be >made a part of standard Zope. It certainly might be reasonable for them to be a package of their own, or to be a part of "standard" Zope, since PlugIns.py and its associated DTML files do not make use of any other part of ZPatterns. It is mostly a question of whether DC has an interest in making it a part of the library. I think it should probably wait, however, until it is a bit better documented and the few API bits that are still fluctuating settle down completely. I would also be interested in figuring out a way to register ZClasses as PlugIns; right now they have to be registered from Python. ___ 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] 0.4.0 prerelease snapshot (was zpatterns-0.4 ?)
At 04:22 PM 6/11/00 -0400, Kevin Dangoor wrote: > >What will be the right way to subclass ObjectManager? CatalogAware won't >really be necessary, because you can use the events stuff to catalog >things... but, I make a lot of things ObjectManagers... All that's required is that manage_afterAdd call self._objectAdding() and manage_beforeDelete call self._objectDeleting(). See DataSkins.py for an example in the DataSkin base class. As for what the right way to get this to happen in ZClasses (apart from creating a Python base), I haven't the foggiest. So, in the code I'm working on now, I've revised DataSkin's implementation of these methods to call ObjectManager's implementation, as long as the skin's aq_base has an objectValues method. This ought to work safely with any kind of object. I'll have to try it out though, to be sure. Perhaps you'll see it in snapshot 2 (if there is one before the final release). In any case, my goal is that all you ever need to do to make a DataSkin ZClass should be to put DataSkin first in the base class list. About the only real limitation would be that you mustn't overwrite the default __init__ method with something that isn't specifically written for DataSkins support. ___ 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] package descriptions
At 12:06 PM 6/13/00 -0600, ethan mindlace fremen wrote: > >Ok, lighter grey & less blue bars. Also simply asking for more products will >hide the DC products, as opposed to having to sort (which still works) > Whitespace between entries, please, and an indent of the description would be nice. It's still really hard to visually parse where one item begins and the previous one ends. Bolding and/or increasing font size of the product titles might be helpful too. ___ 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] Logging for ZScheduler?
At 12:42 PM 6/15/00 -0400, Shane Hathaway wrote: > >Agreed; I see this as by far the best approach. It's a tried and true >pattern. > Not only that, but it gives you extremely fine-grained control over what you do and don't log. And, if the other events like adds and deletes on folders are in place, you can make a monitoring object that notices when new things are added, and subscribes the logger to them... ___ 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] Observable and ZPatterns (was Logging for ZScheduler?)
At 01:40 PM 6/15/00 -0700, Loren Stafford wrote: > >Where is Observer->Observable in the development plan? ZPatterns 0.4? > >-- Loren No. 0.4 is targeted for 2.1.6 compatibility, and Observable will require Zope 2.2's new Traverse features. Also, 0.4 is due out tomorrow and I'm way behind on finishing up some bits. (Like icons...) ___ 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] 0.4.0 alpha 1 Released
ZPatterns 0.4.0 alpha 1 has been uploaded to zope.org. No new docs, but
README, TODO, and CHANGES have been updated since last week's snapshot.
This is now in more or less stable form for this revision cycle; it's
labelled alpha mainly because regression testing has been minimal.
Some highlights of additions since the snapshot:
* DataSkins now work for everything but cut/paste (and that should work
under Zope 2.2, although I haven't verified it yet). They do work for
copy/paste, and you can make a Folder DataSkin just by blending the two
classes in a ZClass w/no additional work.
* Generic Triggers have been added. They let you call an arbitrary Python
expression (using DTML's safe eval) at transaction commit time in response
to an object being added, changed, or deleted. In the expression
namespace, you have a CHANGED_ATTRS() function you can call for a list of
attributes set or deleted during the transaction, and a CHANGED('varname')
function you can use to verify whether a particular attribute was
changed/deleted. Generic triggers will also save the "before" values of
arbitrary expressions on the object from "before" it changed or was
deleted, and provides these before values as attributes of an object called
"OLD".
Generic triggers have only been lightly tested, but if they work correctly,
they should let you do things such as catalog items in a ZCatalog without
subclassing CatalogAware and without blindly using the recatalog function.
You can also specify that certain attributes will be handled by the
trigger, in which case any set/delete operations will be cached, and the
trigger can access the new values from the object at
transaction/subtransaction commit time, and do whatever's necessary to save
those values in SQL, LDAP, or another system of your choosing.
* Runtime extensibility - DataSkins look for a class_default_for_x
attribute when they don't have an attribute "x" available from their
Providers. This allows you to define default implementations of methods,
for example, and override them with a Customizer. This really needs a
ClassExtender AttributeProvider to be really useful, but you could get by
with a Generic Attribute Provider if you had to.
These are probably the main new features of interest in 0.4.0, which is now
feature-complete in its framework. Next on my list are more plugins (such
as ClassExtender), a SkinScript/ASL compiler, and of course, more docs.
Future ZPatterns releases will soon be switched to Zope 2.2 as a
development system, as the new help system, transactions, path traversal,
security API, and other features are very compelling for continued
advancements in ZPatterns. (Not to mention that trying to write code that
works on both 2.2 and 2.1.x is a royal pain.) Last, but not least, I hope
that Jim's new persistent __get/set/delattr__ method support will let me
ditch DynPersist.c and let people using binary installs avoid having to
compile something special to run ZPatterns.
If you're using any previous version of ZPatterns, please check the CHANGES
file in this release for notes on compatibility with future versions. I
had to use a __setstate__ hack in this release to upgrade older data
structures, and certain classes are going to be phased out. I am satisfied
at this point, however, with the overall structure of ZPatterns, and should
be able to avoid any further upheavals. (Crossing fingers.) Please also
see the TODO file for known issues relating to current limitations of the
fancy new features, especially on Zope 2.1.x.
0.4.0 will probably have some minor numbering upgrades as I add plugins,
docs, and SkinScript. The next big upgrade after that will be work for the
0.5.0 series - indexing, searching, joining result sets across disparate
data sources, that sort of thing. I haven't even begun that yet, so no
promises on what capabilities will actually result, or when they will
materialize. As far as I'm concerned, the 0.4.0 series is complete enough
to build useful applications on, and I plan for my team to start doing that
ASAP. In the process, we'll probably find and fix bugs, but it will help
if I can get any bug reports y'all might have from playing with it.
Ty should be releasing a LoginManager 0.8.7 patch release soon to address
compatibility with 0.4.0. There are only a few minor changes needed, one
having to do with the way LoginManager gets some of its tabs from
Specialist, and two changes for RackMountable->DataSkin compatibility.
They've been done, but not yet tested or packaged for release.
___
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 0.4.0a1) Getting Customizers to recognize DataSkin descendants
At 06:50 PM 6/18/00 +0300, Itamar Shtull-Trauring wrote: >I want to customize (with a Customizer) a class I made. It inherits from >DataSkin. However, it's meta_type doesn't show in the Customizer's >manage_typesForm page, so I can't tell the Customizer to use this class >unless I call manage_setTypes manually (which works.) > >So how come my class won't show up - DataSkin and RackMountable both show >up, and my Product isn't broken - I can add instances of my DataSkin >descendant. If it's a Python class, you need to register it as a ZClass base. Now that you mention it, there really isn't much reason for Customizers to restrict themselves to ZClasses, since all they use the meta_type for is as a string to check on instances. Unfortunately, there's not an easy way with non-ZClasses to get at the underlying class and see if it's a DataSkin. I'd prefer that Customizer didn't "falsely advertise" that it could work with something that wasn't a DataSkin, like a regular folder or something. ___ 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] Bug in Changed events in ZPatterns 0.4.0a1?
At 11:33 AM 6/19/00 +0300, Itamar Shtull-Trauring wrote: >As far as I can tell, the first time an object is changed, an Agent's >_objectChanged() will be called, but as long as the object is still in the >memory cache, _objectChanged() will not be called again. _objectChanged is a once per object per transaction event. >Another problem I'm having is giving default values to objects (e.g. default >UNAPPROVED status for approval). I can do this with a trigger (whith >objectAdded being "client.status = UNAPPROVED"), but I also have a trigger >that is equivalent to CatalogAwareness. The problem is that I don't know >what order the triggers get called - will the changes made by one trigger be >consistently cataloged by the other trigger? I would suggest that you set up an attribute provider for client.status that returns UNAPPROVED. Since attribute providers are only active if the attribute does not exist, this should solve your problem. As for trigger ordering, they are guaranteed to be called in their plugin sequence for a given object, but the order of objects they will be called on is not guaranteed. However, if a trigger is shared between two DataManagers (Customizers, Racks, Specialists, etc.), it may be called sooner than expected from the point of view of one of the DataManagers' plugin sequences. ___ 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] Yet another bug. (Re: [Zope-dev] Bug?)
At 08:45 PM 6/19/00 +0800, mike wrote: >It looks like retrieved items have no _v_dm_ set. I fixed it (not sure >this is right) with: > Um, check to make sure you're using _RawItem, not _v_itemConstructor, in your retrieveItem method, if you're using a subclass. If you are using _RawItem, then I've got a bug somewhere deeper that needs fixing. But getItem isn't the place it's broken, as _RawItem is responsible for ensuring the datamanager invariants (skin points to _v_dm_ and has its canonical form registered). ___ 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] One more bug
At 08:44 PM 6/19/00 +0800, mike wrote: >Fix for www/storageForm.dtml > >$ diff storageForm.dtml.orig storageForm.dtml >7c7 >< >--- >> >56c56 >< >--- >> > What was the original doing incorrectly? Thanks. ___ 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] Bug? + another bug (ZPatterns 0.0.4a)
At 08:12 PM 6/19/00 +0800, mike wrote:
>
>Another bug I found (file Rack.py):
>
>def createItem(self,key):
># Create a new object, identified by key
>item = self.getItem(key)
># XXX What if all items potentially exist?
>if item is not None:
>raise KeyError,("'%s' already exists" % key)
>item = self._RawItem(key)
>a = self.loadAttrib
>if not a:
>slot = self._writeableSlot(key)
>slot[SelfKey] = item
>item._setSlot(slot) # Not needed for non-ZODB
>storage
>item._objectAdding()
>self._registerCanonical(k,item) # XXX Should we cache
>non-creation?
>^^ - k was not defined (=key?)
>
It's supposed to be a single-item tuple of the key (key,), so the fixed
line would read:
self._registerCanonical((key,),item) # XXX Should we cache
non-creation?
I'll put out an alpha2 release today with this and other fixes.
___
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 0.4.0a2 bug fixes
0.4.0a2 is out, to fix the bugs reported by Itamar and Mike. I have not yet reproduced all the bugs Mike has reported, but here's what's fixed in alpha 2: * The missing _objectChanged() message - it was very hard to track down, because everything appeared to be working right, except for the fact that it wasn't working. Turns out that _v_status_ (the variable, not the method) was an empty string. Which meant that what looked like self.__dict__['_v_status_'] in code was actually self.__dict__['']. As a side effect, this means that if you've used non-rackmounted DataSkins, they now have an '' (empty name) attribute that is not removable through the Zope management interface. Hopefully this will not affect any production apps since it has only been possible to have this problem since 0.4.0snap1. Anyway, the solution was to simply move the location in the class where the default value of _v_status_ was set. As for your DataSkins... well, you'll need to delete any instances if you want to be rid of the useless empty-named attribute. * Two of the bugs reported by Mike - the manage_setStorage/manage_pack stuff, and the NameError in createItem. I haven't been able to reproduce the "nonexistent _v_dm_" problem Mike has reported. Mike, are you on 2.2 or 2.1.x? Your last post on that subject was unclear, since you said "2.2.6" and there is no such version to my knowledge. :) ___ 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] Yet another bug. (Re: [Zope-dev] Bug?)
At 08:45 PM 6/19/00 +0800, mike wrote: >It looks like retrieved items have no _v_dm_ set. I fixed it (not sure >this is right) with: > >File: Rack.py > >def getItem(self, key): >"""Get an item from the rack by key""" > ># Borrow canonicals map for per-transaction item cache >k = key, >item = self._canonicalForm(k,_marker) > >if item is _marker: >item = self.retrieveItem(key) >self._registerCanonical(k,item) # XXX Should we cache >non-existence? > >if item is not None: item._setRack(self.aq_inner) >^ >return item Okay, I've tracked this one down now. It's retrieveItem() that's broken; the _setRack(self.aq_inner) call should go right before the _setSlot(slot) call. Checking this one in now... Will upload an alpha3 release shortly. ___ 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 alpha 3 released (was re: ZPatterns 0.4.0a2 bug fixes)
At 11:54 AM 6/20/00 +0300, Itamar Shtull-Trauring wrote: >"Phillip J. Eby" wrote: > >> * The missing _objectChanged() message - it was very hard to track down, >> because everything appeared to be working right, except for the fact that >> it wasn't working. Turns out that _v_status_ (the variable, not the >> method) was an empty string. Which meant that what looked like >> self.__dict__['_v_status_'] in code was actually self.__dict__['']. > >Now I'm having problems with changing objects - > > Error Type: KeyError > Error Value: _v_status_ >.. > File /home/Zope2/lib/python/Products/ZPatterns/DataSkins.py, line 192, in >__set_attr__ > File /home/Zope2/lib/python/Products/ZPatterns/DataSkins.py, line 137, in >_objectChanging >KeyError: (see above) > > >As far as I can tell _v_status_ is not initialized at any point, which is >what causes the problem. > Huh? Oh, %&#()@&%... I fixed that in my working copy, but didn't check it into CVS before building a release .tgz yesterday... Argh. Line 137 of DataSkins.py *should* read: if self._v_status_ is not ChangedStatus: Sorry, everyone. I've checked in this fix, along with the one for Mike's "missing _v_dm_" problem, and uploaded an alpha3 release. ___ 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] Test request: ZSession - ZPatterns based session manager
At 08:58 PM 6/19/00 +0800, mike wrote: > >http://www.zope.org/Members/RainDog/ZSession/ZSession-0.0.2.tar.gz/view > >Comments? > Now that I've had a chance to really look at this (while tracking down one of the bugs you found), I do have a few comments. First, nice job... It's a good adaptation use of ZPatterns. I do have some suggestions for fine tuning, though. * Rather than putting property manipulation functions right into the base Session class, I would simply let users derive ZClasses of their own from Session. They could then actually give the Session a UI of its own, for example. Think of someone creating a Session subclass called "Shopping Cart", with methods for viewing, checking out, adding/deleting items, etc. Or, if they have many subsystems which want to share the same Session objects, they could do this by having each subsystem use a different propertysheet of the same Session object. IMHO, the basicSheet stuff you've done, while convenient, encourages developers to take the quick-and-dirty route of just using the Session as a place to store variables - and that throws away a lot of the usefulness of ZPatterns. For one thing, you've guaranteed that Sessions have to be stored as persistent objects in the ZODB, or at least that the basicSheet has to support arbitrary properties. * Make dead session removal something that doesn't happen automatically, or at least have an option to do so. Your default deletion algorithm would be very expensive when executed against a non-ZODB database, and would be more efficiently done a few times a day in large batches by a cron job. * Delegate determining which sessions are dead to the Rack, rather than doing it in the Specialist. This allows an SQL implementation to make use of indexes. Specifically, make removeDead call: self._getSource().findIdleSessions(self.session_ttl) And then provide a default implementation of findIdleSessions() in the Specialist. (Btw, please note that your current implementation absolutely requires that at least *some* session data be stored persistently in the ZODB, which if you're using a FileStorage, is a bad place for it to be.) Now, the whole thing works the same way when first installed, but if someone implements the session ID and lastAccessed attributes in an SQL database, they can substitute a different implementation for findIdleSessions() by putting it in the Rack. ___ 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 alpha 3 released (was re: ZPatterns0.4.0a2 bug fixes)
At 10:25 PM 6/20/00 +0800, mike wrote:
>"Phillip J. Eby" wrote:
>>
>
>> Huh? Oh, %&#()@&%... I fixed that in my working copy, but didn't check it
>> into CVS before building a release .tgz yesterday... Argh. Line 137 of
>> DataSkins.py *should* read:
>>
>> if self._v_status_ is not ChangedStatus:
>>
>> Sorry, everyone. I've checked in this fix, along with the one for Mike's
>> "missing _v_dm_" problem, and uploaded an alpha3 release.
>>
>
>Thank you, Phillip. I've spent all the evening hunting these bugs.
>By the way, how do you debug? Is there better way than inserting things
>like
>
> print "objectChanging %s, has status=%d" % (
> self, self.__dict__.has_key('_v_status_')
> )
>
I haven't found one yet. I'm actually using zLOG.LOG calls, however, to a
logfile, so I can look back at things easily (and because I didn't realize
you could use print until you posted this... :) ).
___
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] Test request: ZSession - ZPatterns basedsession manager
At 10:51 PM 6/20/00 +0800, mike wrote: >"Phillip J. Eby" wrote: >> example. Think of someone creating a Session subclass called "Shopping >> Cart", with methods for viewing, checking out, adding/deleting items, etc. >> Or, if they have many subsystems which want to share the same Session >> objects, they could do this by having each subsystem use a different >> propertysheet of the same Session object. > >Well, well, well. As for me, beter I've set up a Client abstraction >which have access to CartManager and store cart_id in the session >object. Mixing Session and Cart is not a good idea just because Client >can have several carts, for example. The composition is better than >inheritance in this case, Phillip :-) I look at components in terms of "value add". Your SessionManager's value-add is that it lets you transparently create an instance of something which is associated with a cookie and which can be expired whenever it's idle for greater than a certain period of time. But the idea of a "Session" has no real value-add to me; it just makes it possible for a thing to be managed by the SessionManager. You could in fact do without the Session class altogether, and have SessionManager simply set the lastAccessed attribute directly. This would actually make SessionManager more useful, because you could use it with ZClasses that hadn't been explicitly designed to be session-based, as long as there was an AttributeProvider for lastAccessed. And you could drop the SessionSource class altogether as well, since any RackMountable/DataSkin would be acceptable as a "Session". Popular opinion to the contrary, I don't believe that there is such a thing as a "session" object. Session objects are a hack, to give you a place to put session-specific objects' data. In my opinion, if you can have session-specific objects, you don't really need a "session" object. If one can simply call CurrentCart() or CurrentGame() (where CurrentCart and CurrentGame are SessionManager specialists) to retrieve a session-specific shopping cart or gameboard, why have a "session" object? If I want them both to use the same cookie, I can certainly do that by setting the properties on both CurrentGame and CurrentCart. And there's also no chance that two session-specific objects from different vendors (such as perhaps my Games and Carts) will accidentally collide with each others attributes or sheets in the "session" object, since they're being handled by seperate specialists. >> IMHO, the basicSheet stuff you've done, while convenient, encourages >> developers to take the quick-and-dirty route of just using the Session as a >> place to store variables - and that throws away a lot of the usefulness of >> ZPatterns. For one thing, you've guaranteed that Sessions have to be >> stored as persistent objects in the ZODB, or at least that the basicSheet >> has to support arbitrary properties. > >But without this stuff people will have to code ZClasses each time they >want sessions. Hmm... I guess the best way is splitting current session >class into two - simple Session and LazySession. Yeah, but to my way of thinking, they *should* be coding them, because if they're not it means they haven't thought their design through enough to know what *kind* of session-specific object they're making. To me, there is no such thing as a session object, only session-specific objects. In any case, it's not a big deal to make a session-specific object. Add a ZClass, base it on DataSkin, set up a "common instance" property sheet, and boom, you're done. Now set your session manager's rack to use it, and you're in business. ___ 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 alpha 3 released (was re: ZPatterns0.4.0a2 bug fixes)
At 05:49 PM 6/20/00 +0300, Itamar Shtull-Trauring wrote: >> Huh? Oh, %&#()@&%... I fixed that in my working copy, but didn't check it >> into CVS before building a release .tgz yesterday... Argh. Line 137 of >> DataSkins.py *should* read: > >Great, it works! > Tell me, were you able to use GenericTrigger(s) to do the cataloging? It might be more convenient to update/modify than your cataloging-specific Agent class. Also, I noticed that your getMemento routine saves the object's __dict__, but that's of absolutely no value whatsoever, since the __dict__ is a mutable object and will thus have been changed by the time you get the commit-time messages. ___ 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 bug. Very serious.
At 11:11 PM 6/22/00 +0800, mike wrote:
>
>0025 'self'={'_v_attrCache': {'a_': [],
>'filtered_manage_optionsisDocTemp': [],
>'_Change_permissions_Permission': [], 'MANAGE_TABS_NO_BANNER': [],
>'im_func': [], '__allow_groups__': [], '_Manage_properties_Permission':
>[], 'tabs_path_infoisDocTemp': [], '__roles__': [], 'target': [],
>'_View_Permission': [], 'Zope-Version': [],
>'locked_in_versionisDocTemp': [], 'n_': [], 'PATH_INFO': [],
>'AUTHENTICATED_USER': [], 'manage_tabs_message': [],
>'tabs_path_info__roles__': [], 'SCRIPT_NAME': [], 'REQUEST': [],
>'__bobo_traverse__': [], 'URL': [], 'locked_in_version__roles__': [],
>'_isBeingUsedAsAMethod_': []}, 'id': '0025', '_v_dm_': instance at 8649988>, '_v_writeableSlot': 864ae78>, '_v_readableSlot': ,
>'_v_currentSheets': (,),
>'_rackMounted': 1}
>
>---
>
>Wow! _v_attrCache stores a lot of various junk, including REQUEST!!!
>This disables, by the way, all the security mechanisms on traversed
>items!
>
>
>Phillip, would you be so kind and fix this? ;-)
>
This is not a bug, it's a feature. :) If you look closely at the
dictionary, you will see it contains empty lists for all these items.
These empty lists are the DataSkins.NOT_FOUND singleton, which caches the
nonexistence of these attributes. This is not a security problem, nor any
other kind of problem. It is instead a performance optimization which
keeps the DataSkin from querying all the AttributeProviders every time a
known-to-be-nonexistent attribute is looked for.
___
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 bug. Very serious.
At 01:06 PM 6/23/00 +0800, mike wrote: > >There _IS_ a problem. Maybe _v_cachedAttr is not a guilty, but do you >know it exists only in newly created objects and do _not_ exists in >old?. The attribute cache is created only when used in a transaction, so if you retrieve a persistent object from a Rack and immediately dump its dictionary, the cache will not exist. >Anyway, newly created DataSkin instances return wrong REQUEST (and >other things) but _old_ retrieved ones work good. I tell you this >because it is impossible to obtain AUTHENTICATE_USER from fresh >DataSkins, so things like 'manage_tabs' just do not work properly. Try >set up Rack for any real ZClass and you see this. I'm not currently seeing this, but the work Ty and I are doing with Racks at present involves objects which are not actually stored in the ZODB, so perhaps we're missing a bug with things that are stored in the ZODB, like the last one you found. But as far as I know, Rack.getItem() should always return an object whose acquisition context is the Specialist. >If you'd like I send you complete test suite reproducing the situation. Please do. Thanks. ___ 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] Logging for ZScheduler?
At 01:58 PM 6/15/00 +1000, Stuart 'Zen' Bishop wrote: > >Its not a problem with ZScheduler, it a problem that no one has written >a plug-in logging system that is good enough for what you are trying to >do. The existing zLOG API is fine (well - it could be better), but just >needs someone to write the relevant modules. Hmm... I think I'll >add a section to the Interfaces Wiki... Hm... this could work well with Observer->Observable, too. Imagine firing ObservableEvents, and subscribing a "Log" object to them... ___ 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 alpha 4 released (was Re: ZPatterns bug. Very serious.)
ZPatterns 0.4.0 alpha 4 has been released, fixing the bugs described below. I will be away from e-mail most of this coming week. If when I get back there isn't a pile of new bug reports, I'll upgrade ZPatterns to beta status. On Friday, Ty completed a project using LDAP and ZPatterns' "generic attribute providers" and "generic triggers" to perform an actual useful function for our department, and it should be in production use this coming week. So 0.4.0 is starting to look pretty stable. At 09:49 PM 6/23/00 +0800, [EMAIL PROTECTED] wrote: > >1. Install product as usual >2. Import ZSessionTest (ZClass) >3. Create an instance of ZSession >4. Go 'Racks' tab, then deep into SessionSource, then select 'Storage' >tab >5. Make sure ZSessionTest is the 'Class to use for stored items' >6. Go to the Session level >7. Select 'View' tab to allocate the session object >8. Go back and select 'Contents' tab. You should see a table with one >live session. >9. Click on the session's id >10. You should see the only 'View' tab >11. Restart Zope server to drop the caches >12. Refresh frame. Now you see two more tabs! > >The reason why the tabs was not visible first time is the wrong REQUEST >object, acquired by App/Management.py/filter_manage_options method. When >the zope server restarts (and caches get cleared), acquisition works OK. I think I found the problems. First, Rack.newItem() sets slot[SelfKey]=item when it should be item.aq_base. And second, Rack.retrieveItem() fails to wrap the returned object to the specialist. (Instead of returning item on the last line of the function, it should return item.__of__(self.aq_inner.aq_parent)). These problems affected only objects whose primary storage was in the ZODB (a mode of storage Ty and I aren't currently using much, as our projects are focused on LDAP at the moment). Once these changes are made, one can safely remove all the places where you were taking session.__of__(self), since the Rack provides an equivalent effect. I was not able to import your .zexp file, so I did the best I could to simulate your test conditions. I got somewhat different errors, but like yours they occurred only when adding new items and went away once Zope had been reset. With the changes, everything seems to work fine. >P.S. About the Shoping Cart. I've realized that Cart is also bad >concept. There are no shopping carts in real life, When's the last time you went to the grocery store? :) > but relations between >Shoppers and reserved Products, which *can* (but not *should*) be >arranged as shopping carts. So, in most common case there should be a >Clerk which able to set up and maintain those relations. The purpose, IMHO, of a shopping cart, is the same as in a store... to gather the items you intend to purchase at one time in a single place, in a convenient way, allowing you to browse through the store rather than having to make a list and then request all the things at once from the "clerk". If you have only the "clerk", then you lose your ability to browse the store, and commit your purchase as a single transaction. Or if you make it possible to do those things, all you've done is re-invented the cart under a different name. ___ 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-0.4a4
At 01:08 PM 6/26/00 +0400, Jephte CLAIN wrote: > >This code should (IMHO) read: > >def getItem(self, key): >if hasattr(self.aq_base,'retrieveItem'): >return self.retrieveItem(key=key) # XXX need DTML check? > >for rack in self.rackList: >item = rack.__of__(self).getItem(key) > if item is not None: >return item >return None Corrected for next release. ___ 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] Specialists in Specialists (was Re: zpatterns-0.4a4)
At 07:13 PM 6/26/00 +0800, mike wrote: > >By the way, I do not like this Rack list at all. Racks and Specialists >are both DataManagers with compatible interfaces (getItem, newItem). >IMHO, Specialists should have list of DataManagers. This make much sense >in context of combining Specialists - ZSession and ClientManager, for >example. It is not sufficient just to tune ZSession using >ClientManager's rack and ZClass, because in this case we are losing the >ClientManager's aspect in sessions. Of course, one always can create >delegating rack (and even rack-to-specialist bridge), but what do this >for if simple replacing rackList with dataManagerList will solve all >such problems? Let me see if I understand what you're saying... you want a Specialist to be able to be used as a Rack in another Specialist? That seems reasonable enough. But why not just add the Specialist on the Methods tab, and then override retrieveItem and createItem to include the Specialist in the list of sub-objects queried? Or, simply create a SpecialistRack class that's a plain Specialist, except registered with the 'Rack' __plugin_kind__, so that it can go on the tab. I don't have Specialists registered as a 'Rack' plugin by default because PlugInContainers use the presence of a __plugin_kind__ attribute to suppress display of PlugIns on their main Contents tab, and that would mean that if you put a Specialist inside a PlugInContainer, it would disappear from the management interface unless the PlugInContainer had a tab which supported the Rack plugin kind. (Perhaps by 0.5.0 this display quirk could be fixed, however, by making the Contents tab a bit smarter). (Note, by the way, that the DataManager interface doesn't support getItem/newItem, so I can't just make Specialist use DataManagers. Customizers, for example have no idea what objects they're customizing, so they can't support getItem.) ___ 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] bug in zpatterns-0.4 ?
At 11:54 AM 6/27/00 +0400, Jephte CLAIN wrote: >mike wrote: >> There is no way to infinite recursion if Rack.getItem is leaved >> untouched. >Ah ah. But people will touch it. Like me for example :-) >There is no way to prevent overriding getItem from a ZClass for example. >And it *will* recurse infinitely, making Zope dumping core. > >> getItem/newItem are not a high level methods, they are *part >> of DataSource's protocol* which *implemented* in Rack with retrieveItem >> and buddies. >getItem/newItem are not meant to be overrided. retrieveItem/createItem >are to overrided. This is different level for me. > >When Philipp wake up (I guess he's asleep right now :-)), he might give >his opinion about that. > I've been on vacation. I'm basically with Mike on this one, with a slight amplification on my intention here. IMHO, what you should be doing with your SQL is making it an AttributeProvider, and using the "virtual" mode of the Rack which does not store the item in the ZODB, only its propertysheets. Then you will not need to override *anything* in any of the ZPatterns classes. If you need to store persistent attributes, this may be an issue. I'm planning to create a "Persistent External Attribute Provider" to allow one to store attributes persistently even when the object itself isn't stored in the ZODB. In any case, my intention for mixed-database objects in racks is that one should not need to override any of the built-in methods of Rack. In earlier versions of ZPatterns, such overriding seemed like it would be necessary, but as of 0.4 there is really no reason at the framework level to mess with any of Rack's implementation details unless you need to create a special hand-tuned version for some critical bit of efficiency. Almost anything you could do by overriding those methods can now be done through Generic Attribute Providers or other plug-ins. ___ 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] Racks and Specialists Simplified
By all means, feel welcome. I've been on vacation a while. At 02:29 PM 6/28/00 +0100, Steve Alexander wrote: > >I just looked over the ZPatterns Wiki for Shane's explanation, but I >can't find it. > >If it isn't there (hiding somewhere), perhaps I can add it from Shane's >original email? > ___ 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] Re: Comments on ZPatterns
At 03:10 PM 6/28/00 +0100, Chris Withers wrote: > >1. Too much jargon... by far... Lots of complicated words that are >meanlingless to the layman and don't help to convey the concepts. Yep, like "Acquisition" and "object publishing". :) Seriously, that is very much the level we're talking about here. ZPatterns is an evolution to Zope's revolution, in the area of web-based application development models. Zope says the answer is publishing objects in an environment supporting acquisition. The ZPatterns design approach is an attempt to answer to the question, "So what objects should I publish, and what are the appropriate uses of acquisition?" As with Zope itself, it is both a design approach *and* an implementation toolkit for the approach, which certainly doesn't help the confusion. :) Also, as in the early days of Zope, terminology evolves and changes as the developers of the concepts seek better ways to explain them to other people. As an example, "Specialist" was originally called "Interface" by Ty and I back around September or so. It evolved to "Implementation Provider" in the later part of the year, and "Implementor" by the time of our conference presentation. After using that name on the lists a while, and in developing the ZPatterns code, it became clear that the name still really sucked and we needed one that made more sense on initially encountering it. After considerable brainstorming, the term "Specialist" was born, and on the whole we're happy with it. Other terms are still in flux, and many I hope we can do away with by replacing them with simpler, more powerful ideas (such as replacing all of the different Trigger and Provider plugins with a simple declarative scripting syntax that lets you specify the aspect weaving for your objects). >2. Feature runaway. It seems every day something new (and more >confusing) has been added to ZPatterns. I think ZPatterns will only work >if it is kept as simple and functional as possible. My view (bearing in >mind my limited understanding ;-) would be to concentrate on Containers, >Container Groups and Plugins on the one front and Racks, Specialists and >the various providers and agents on the other. Been there, done that, actually. There really hasn't been much change in ZPatterns from 0.3 to 0.4 in that regard. Most of the upheaval has been due to making it possible for the capabilities of "Rackmountables" to be used in non-rack settings. This forced some significant generalization of the model and some extension to the "theory" in the area of the internal event model (which was previously incomplete and too hardwired). Believe it or not, in 0.4 I have actually *removed* some previously existing data management plug-ins. The acquired attribute provider and acquired sheet provider classes were replaced with a generic "link to parent data plug-ins" class, for example. As Ty mentioned in his post on this subject, we will be trying to do away with other such features later, replacing them with general-purpose tools. Unfortunately, all this evolution makes ZPatterns a moving target for comprehension at the moment. In spite of this, my reading of the lists seems to indicate that there are a few people besides Ty and myself who are actually achieving results with the framework. I hope that they can help to provide more accessible how-to materials, because I'm still very focused on *finishing* ZPatterns to the level that my "paying job" requires. And it's likely going to be a few months before my "paying job" requires that I have introductory docs available for the tools (although I'd personally really like to have some available before then). ___ 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] More comments on ZPatterns
At 10:06 AM 7/3/00 -0500, Steve Spicklemire wrote: > >Seriously, I'm trying to get it all figured out, and I thought maybe >if I attempted to do something 'real' with it I would at least learn >what I *don't* understand. Well.. I've learned a *lot*! (about what I >don't understand.. ) ;-) The source code is astonishingly simple >looking, but about one layer deeper that I can easily grok, apparently. That's an unfortunate side-effect of applying Demeter's law... it's easy to grasp (in an abstract way) local implementation aspects, but hard to grasp how the actual *concrete* implementation works from looking at the pieces. It's the "there's no *there* there" effect, as Ty dubbed it. >I also create a "TableInfo" ZClass, subclass of DataSkin, that >quantifies the kind of data the customers have to choose from, and >metadata about the data (headers, query parameters and suchlike). > >I create a ZClass property sheet for the TableInfo ZClass. > >Finally I create an instance of Specialist (tableManager) with a >(default) rack of TableInfo objects. > >Now... some of the Tableinfo properties, and some of the View >properties are *really* in MySQL. I figured out, from the mail list >and the source code, that I can create a Generic attribute provider in >the rack that can get attributes from an SQL database for my DataSkin >descendents using the 'source expression' and 'target expression' >business. Congratulations, you found the top secret documentation. :) >Source expression: > (GetTableInfo(tableInfoID=self.id) or [NOT_FOUND])[0] > >Target expressions: > tableHeaders=RESULT.tableHeaders > footnote=RESULT.footnote > >and when I ask one of my TableInfo instances for their footnote it >comes right out of MySQL! Cool. Now.. I can't seem to figure out how >to *change* the data in the database when the user 'edits' the >DataSkin which brings up the whole issue of changing stuff in >DataSkins. Here's some more top-secret documentation... Use a GenericTrigger to implement attribute changes. Set up your trigger to be activated on object changes, and set the trigger expression to call an SQL method, e.g.: UpdateTableInfo(object=self,CHANGED=CHANGED) In the SQL method, code something like this: UPDATE mytable SET attr1=, ... WHERE primary_key='' with an "if" block for each attribute you might want to update. Last part, and this is the trick that's not yet documented... set the "Set Attrs" field to be a list of the attributes you want the trigger to handle set/delete operations for. (You don't need to put anything in the "Keeping" field unless you need a "before" value of an expression to use in your SQL.) ___ 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: DropZone example
At 05:26 PM 6/28/00 +0100, Steve Alexander wrote: > >The suggested specialists in the Accounting framework are: > > Invoices > Orders > Customers > Products > >What I'm finding is that these are just the White-box specialists. A >clean design would seem to want all the specialists above, plus at least >one Black-box specialist to do the "heavy lifting. Let's call it the >"AccountingProcessor" specialist. Keep in mind that a Specialist doesn't just "store" a bunch of objects, it also provides *methods for dealing with sets of objects*. So an Invoices specialist could usefully contain a wide variety of reporting methods, for example. Similarly, the Customers specialist might have a method to post balances forward on all customer accounts whose statement cycle is in a certain date range. These are all "heavy lifting" from an accounting point of view, but perfectly valid to have in the white-box specialists. White-box doesn't mean that there's no implementation; it just means that the implementation is intended to be extensible or integratable by someone other than the framework's original developer. >Now, if I had a third-party accounts package (something by Sage >perhaps), I could make the AccountingProcessor specialist expose various >functions to the four other White-box specialists. It would implement >these by making equivalent calls on the underlying accounting package. > >I could also swap the heavy-lifting portion of my framework by swapping >the black-box AccountingProcessor specialist for one that talks to some >software by Quicken, or perhaps some software that is written in Python >as a conventional Zope product. That's all quite true, but it would probably be simplest to do such a thing using AttributeProviders and SheetProviders in the white-box specialists. It does seem reasonable to have those providers talk to an AccountingProcessor object if you want to make your framework talk to different back-ends, but I think it is misleading and incorrect to call AccountingProcessor a specialist, as it's not an application-level service object, but a private implementation helper. Interestingly, you've just given me what may be a motivating example for using Shane Hathaway's DatabaseAPI in conjunction with ZPatterns, assuming of course that I've correctly understood his most recent explanation of the DatabaseAPI product. >The same goes for the Resource Scheduling framework. We have some >White-box specialists, ripe for customisation: > > Resources > Reservations > ResourceUsers > >And then for the heavy-lifting we have the black-box ResourceScheduler >specialist. Again, this might be a Zope Python Product, or it might be >an interface to some application written on top of Microsoft Exchange. Again, look to what these specialist would do besides look up objects. For example, utilization or load-balancing reports. Generating bills for usage. Generating calendars for individual resources. Checking for conflicts. Etc. >Are specialists intended to be placed inside other specialists, as >"contents"? You *can* do this, but I've not yet encountered a real-life situation where I *would* do this. (Mike has given some examples that suggest it might be useful under some circumstances, however.) >So in this case, would the white-box specialists live inside >the black-box specialist -- so they become the customisable aspects of >the overall framework? Or would both black-box and white-box specialists >live inside an uber-specialist? If anything, the black box should be inside the white. Otherwise, you are creating confusion between heaven and earth. :) Seriously, the white boxes are the parts you will reference in URL's most often, so why have /AccountingProcessor/Invoices/ when you can just have /Invoices/? If you have to share a black box among white boxes, acquire it. If your "root" gets too messy, then make an "Accounting" folder and put Invoices, AccountingProcessor, and the rest inside of it. ___ 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 Specialist Question
At 11:54 AM 7/3/00 +0100, Chris Withers wrote: >Just a quickie: > >If, as the the ZPatterns Wiki states, 'Specialists are not classes', >then why is there a 'Specialist' python class in the ZPatterns >distribution? > Specialists are instances of the class "Specialist". They are not themselves classes. The reason for emphasizing that point is that it is a common misconception of people beginning to use the ZPatterns design approach - they conflate or confuse specialists with the class of the things which they intend to use the specialist to gain access to. In other words, they assume that a specialist called "Customers" would always manipulate "Customer" instances, when in fact it might manipulate "SkyDiver" instances. Most of the point of having a specialist is to have a binding point which allows you to decouple your intended use of a thing, from the specific implementation of it. If one misses this point, one will be blind to a wide variety of ZPatterns' useful applications, and at the same time likely to ask why both Racks and Specialists are needed. They are both needed because the Specialist deals with a particular problem-domain aspect of a thing, and the Rack deals with implementation aspects. ___ 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] bug in zpatterns-0.4 ?
At 10:33 AM 7/4/00 +0400, Jephte CLAIN wrote: > >Back to my first question: is it intended that Rack.createItem (a IMHO >low level method) calls Rack.getItem (a IMHO higher level method) to >check the existence of the item? Yes. It is perfectly valid OO design (and common framework-building practice) for a private method to call a public one, and that is all that is taking place here. > Shouldn't it be Rack.retrieveItem >instead? That's why I asked the question in the first place. Nope. The two levels of methods (get/retrieve and new/create) are there to seperate Rack-level concerns from implementation concerns. getItem() and newItem() handle maintenance of Rack-level invariants such as the retrieval cache, while retrieveItem() and createItem() deal with object-level invariants. If you called retrieveItem() instead of getItem(), the code would bypass the rack-level invariants managed by getItem(), which would mean in this case that the per-transaction cache would be bypassed. >About my applications now. The primary keys in the SQL database may be >integers, or tuple of integers, or strings (depending on the project, I >have several to deal with right now). I want to merge results from >several databases from a single rack. >For example I have a Site table (with SiteKey as the primary key) and a >Subdivision table (with SubdivisionKey as the primary key) which I want >to merge into the LocationRack (with the key being the tuple (SiteKey, >SubdivisionKey)) >This is why I mess with the implementation of the rack. Hm. Seems to me that you should just use two GAP's, one for each DB table, each using "self.id[0]" and "self.id[1]" respectively to determine their primary keys. >Also, my racks >are specialized to have a searchResults method, and a editItem method >(until I can find the time to write a decent SQL Attribute setter >provider) A reasonable approach. Although, in the case of SQL attribute setting, see my other e-mail from this evening about the use of Generic Triggers to do SQL attribute setting. >btw, the genericattributeprovider has saved me a great deal of time. >thanks very much! No problem. Did you ever try re-casting your CatalogAwareness replacement to use GenericTrigger instead of a specific Agent plug-in? ___ 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: DropZone example
At 02:21 AM 7/5/00 +, Scott Parish wrote: > >Does anybody out there have even the slightest clue about how to go about >using AttributeProviders and SheetProviders? A select few terse hints on >this subject would really help us (me) figure it out enough to start working >on some howto's. You might look at some of the recent posts which included an example of using GenericAttributeProviders to read from a MySQL database, and my reply explaining how to use a GenericTrigger to update that same database. >Am i wrong in thinking that DatabaseAPI is a completely separate solution to >the same problem that ZPatters is suppose to address? Personally i have to >give DatabaseAPI props for being quite easy to understand and use, while >not sacrificing power. Peter Coad's design approach (which ZPatterns is heavily based on/biased towards) emphasizes four major layers of classes in an application: 1) User Interface (GUI, forms, etc.) 2) Problem Domain (the actual application purpose) 3) Data Management (object persistence/lifecycle management) 4) System Interaction (interfaces w/hardware or other software) ZPatterns is focused on providing tools for transparent mappings between layers 2 and 3, while DatabaseAPI, as far as I can see (and I actually did play around with it today to get a feel for it), is focused on tools for building clean mappings between layers 3 and 4. In my mind, this makes them complementary tools, rather than competitors in any real sense. Indeed, looking at DatabaseAPI has shown me that there are some features I'd planned for ZPatterns (or already started) that I can scrap because DatabaseAPI has them and can easily interoperate. (Personally, I'd like to see a version of DatabaseAPI using PlugIns to structure its user interface, which I think could easily make it even cleaner and easier to use than it already is. It might then also be possible to reuse some of its plug-ins for functionality in areas of ZPatterns. But I digress.) So where do DatabaseAPI and ZPatterns overlap? DatabaseConnector has some functional overlap with Specialist. If you ignore the attribute, sheet, and trigger providing aspects of ZPatterns (and also look only at the raw functionality), the primary difference between a Specialist and a DatabaseConnector is that DatabaseConnectors will probably have methods to delete objects or change their data, which is a no-no for a Specialist because it's an encapsulation breach. Beyond this, there's a significant difference in intent between a Specialist and a DatabaseConnector (IMHO). A Specialist serves as a broker to access objects which fill a certain role in a framework, while a DatabaseConnector represents an object which manipulates "records" which are of "record types" and have "fields". Specialists use Racks to explicitly distinguish between problem-domain and data-domain concerns; you can probably do this with nested DatabaseConnectors but you'll have to do some additional work to support it. ZPatterns could definitely benefit from some ideas found in DatabaseAPI, primarily in the aspect of documenting API's and supporting better design contracts. For example, it would be nice for a Specialist to be able to define the API expected from its Racks, and a for an application framework to somehow define the API expected from the Specialists it will interact with. One could of course use the existing DatabaseAPI product to do these things, but the integration would be less than smooth, since you'd have to make the Specialist ask the Racks for their DatabaseConnectors, or else have a Rack class that delegated to a DatabaseConnector, or something like that. Anyway, I'm going to have to give these possibilities some more thought. ___ 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: DropZone example
At 03:12 PM 7/5/00 -0500, Jimmie Houchin wrote: >"Phillip J. Eby" wrote: >[snip] >> Peter Coad's design approach (which ZPatterns is heavily based on/biased >> towards) emphasizes four major layers of classes in an application: >> >> 1) User Interface (GUI, forms, etc.) >> 2) Problem Domain (the actual application purpose) >> 3) Data Management (object persistence/lifecycle management) >> 4) System Interaction (interfaces w/hardware or other software) > >Is this from one of his books? If so, which one? "Object Models: Strategies, Patterns, and Applications" ___ 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] Proposed interface: Restricted creation
At 12:01 PM 7/5/00 -0400, Shane Hathaway wrote: >Itamar Shtull-Trauring wrote: >> I propose a Restricted Creation Interface - when an ObjectManager constructs >> it's Add list in manage_main, it first checks with each addable class if >> it's instances can be added in this specific ObjectManager. > >The place where this is needed most (IMHO) is for ZClass factories. So >there needs to be a way to create meta type filters through the Web. > >On the other hand, the plugins framework by Phillip Eby solves this >problem in a nice way. I'm hoping to eventually modify the plugins >framework so it's more accessible for ZClass development. I am too. :) If you have any ideas on how to make a ZClass constructor object that could work with PlugIns, I'm all ears. Right now, PlugIns have to be Python classes, although I think that it might be possible to make the PlugIn registry walk the entire ZClass registry, looking for things with a __plugin_kind__. That's something I'll want to look into when I get a chance. If you'd like to champion getting PlugIns into Zope as a standard feature, I am willing to contribute the code for ZPL use. Personally, given the small handful of other things I'd like to do to polish off PlugIns (such as documentation), I'm not sure now is the right time for making such a transition. ___ 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] ZClass inheriting from ObjectManager and DataSkin?
At 01:58 PM 7/5/00 +0300, Itamar Shtull-Trauring wrote: >Are there (or better yet, what are) any potential problems here? My gut >feeling was that it wouldn't work, but you can at the very least add objects >in instances of the ZClass - deleting and renaming don't work though. When you say deleting and renaming don't work, I'm not following you. Are you using these ObjectManager dataskins in a Rack, or in a Folder w/customization support? If the latter, have you set up a customizer for that meta-type? And when you say they don't work, do you mean no triggers fire, or that they just plain don't work. (Tracebacks would be nice in the latter case.) ___ 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-0.4: creating an item in "virtual mode"
At 11:14 AM 7/5/00 +0400, Jephte CLAIN wrote: >Hello, > >I use virtual attribute access to provide access to my SQL database. >However, I want to use the Rack.newItem facility to create new records >in the database. >But it fails because in virtual mode, an item always exists. >This patch solves the problem, at least for me > > > # XXX What if all items potentially exist? > >comments? > The XXX comment shown above says it all. :) Actually, all it says is that I knew the problem you're having would happen. However, if I put your patch in, I now have to have one that said: # XXX What if object already exists in virtual mode? That having been said, I will think about adding your patch, or alternatively a storage setting that tells the Rack whether to check for existence before adding new items. This setting would default to being true, so you could change it for your circumstance, which is a fairly special case, I think. ___ 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] More comments on ZPatterns
At 03:10 AM 7/6/00 +, Scott Parish wrote: > >Anyway, Under Zope 2.2, the 'Upon' property of a trigger doesn't have a list >of 'event_kinds'. I think this is related to an earlier post where i >complained about zope 2.2 not being able to get such values (for select >types) from aquisition, or in this case from a seperate property in its >class. Has anybody thought of a way to address this problem, as it didn't >sound like the official zope distribution wants to act the way that would >allow the 'Upon' property to get its proper values right now. (no, i'm >not going to go off about that ) In our working copy of ZPatterns, Ty has patched ZPatterns to make the list a property. Personally, I think this recent behavior of 2.2 is broken, and I hope to submit a patch soon to the Collector to fix it, so that we can back out the ZPatterns patch. It should not be necessary for the value of a select/multiselect property to be another *property*, as this will break other people's code besides ZPatterns. The Zope documentation in OFS/PropertyManager.py explicitly states: For 'selection' and 'multiple selection' properties, there is an addition item in the property dictionay, 'select_variable' which provides the name of a property or method which returns a list of strings from which the selection(s) can be chosen. So this is pretty clearly broken in 2.2. >Also, should i not be trying to use ZPatterns 4aX under Zope 2.2? I thought >i read that to use triggers a person should use Zope 2.2, but it doesn't >appear this has been tested under 2.2. (although it is alpha, i haven't >forgotten that) Yeah, you can use it under 2.2, although as you've pointed out, there is a problem with the property issue. It has been tested rather extensively under 2.2, it's just that this one item hasn't been put out in a fix release, because we were going to report it to the Collector as a bug (I'm not sure if Ty has done so yet; it was right before my vacation that he found the problem). As for the warning about transactional issues with triggers under 2.1.x, they have to do with triggers that update things stored in the ZODB, and they will not always have problems. It's just that transaction ordering semantics are very different between 2.1.x and 2.2; 2.2 is pure FIFO where 2.1.x is a LIFO stack, even during the commit process. >ZPatterns is starting to taste pretty sweet. Keep up the good work! Thanks. ___ 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] LoginManager patch considered harmful (was Re: can't addloginmanager below root) loginmanager below root)
At 09:21 PM 6/28/00 +, Ty Sarna wrote: >In article <[EMAIL PROTECTED]>, >Shane Hathaway <[EMAIL PROTECTED]> wrote: >> Ok folks, >> >> I thought I had made it clear that this problem has been solved. I have >> sent a patch to Ty (about two weeks ago) as well as made the change in > >Sorry for the delay. I'm just now cacthing up on all my zope-related >mail. I've applied this patch, and it will be in the release tonight. >However, I am a bit concerned about what happens if _owner is deleted. >For purposes of setuid code, we'd like to use the owner as the user to >setuid to, but if we can't force it to be the right user, that could be >a problem. This will definately need more thought. > I'm afraid I've confirmed Ty's fears. The LoginManager patch to fix the "can't add below root" problem creates a new issue: ownership of objects within the LoginManager. I will be asking Ty to make a re-release of 0.8.7 to unpatch part of the patch, but for now, here's a short synopsis of the problem and how to fix it. Shane's patch changes manage_addLoginManager to set ob._owner = UnownableOwner, which is good, because this ensures that AccessControl.Owned.Owned._deleteOwnershipAfterAdd() can del self._owner. (I think that Owned shouldn't be doing this this way, but as yet I don't have a good alternative to propose that DC implement.) The problem is that once this is done, the LoginManager is no longer "unowned". To fix this, add the line: _owner = UnownableOwner to the body of the LoginManager class. This will ensure that even after _deleteOwnershipAfterAdd(), the LoginManager will remain "unowned". After you have made this fix and restarted Zope, you may want to "un-own" any objects contained within your LoginManagers which might have been created with ownership. To do this, you should go to each page of each LoginManager's management interface and copy all objects, then paste them. Delete the originals, and rename the copies back to their old names. The copies will then be "unowned". You can verify this by checking each object's management interface: if it is unowned, it will have no "Ownership" tab. Why does LoginManager want its contents unowned? It has to do with the new security model. When an executable object is owned, the security machinery wants to validate that its owner is allowed to do whatever the executable is doing. This is great except for the fact that in many sites, the owner of the LoginManager's objects is actually a user that was retrieved from that LoginManager. This means that if LoginManager executes an object to find out information about a user, and that object is owned by a user from that LoginManager, infinite recursion and a core dump will swiftly follow. For this reason, you should make sure that all executable objects in a LoginManager are either unowned or owned by a user who is *not* supplied by that LoginManager. In practice, making sure they're unowned is usually easier. ___ 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] More comments on ZPatterns
At 12:38 PM 7/9/00 -0500, Steve Spicklemire wrote: > >pje> None of the above. SkyDiver should inherit from a Party base class. For >pje> Customer and ResourceUser behavior, one adds propertysheets whose class is >pje> provided by the respective frameworks. This is extension through >pje> *composition*, rather than inheritance. It is similar to the COM approach, >pje> where you can ask an object to give you a pointer to an interface. In this >pje> approach, you ask for a propertysheet that provides the interface. > >"One adds propertysheets" is much easier said than done... IMHO. The only way >I've seen to add propertysheets to objects is to call manage_addPropertySheet >on individual instances... as described in this earlier email: That's the only way that's implemented "out of the box". But there's no reason you can't implement a SheetProvider that automatically creates the sheet when the object is added, or why you can't use a GenericTrigger to add the sheet using one of the out-of-the-box SheetProviders. When I get SkinScript objects done, this'll be easier because you'll be able to just spec out a propertysheet in SkinScript and have the dirty work done for you. >I just want to make sure I understand... is the intention that property management >needs to be done on each instance separately? So if I add a new property to one >of my property sheets, I need to somehow update the propertysheets of each of the >instances? Also if I need to create propertysheets for each instance... where >should that be done? I suppose it makes sense to put that in the Specialist that >handles the object that gets the properties?...no? The intention is that you use SheetProviders for anything global. Adding propertysheets on an instance-by-instance basis is something that's intended for an interface point between two frameworks. Say for example you have a project scheduling framework that needs to store a due date associated with a document -- the scheduling system can query for a scheduling propertysheet, and if it doesn't exist, add it. However, since you control what SheetProvider implements that propertysheet, you can (for example) use the same SQL database for all scheduling fields across your site. If you don't need special handling, however, you can leave the default "Persistent" SheetProvider in place and the scheduling properties would get stored persistently. ___ 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] More comments on ZPatterns
At 01:37 PM 7/9/00 -0500, Steve Spicklemire wrote: > >Thanks Steve, > >Eegads! OK... all my instances currently live in a defaultRack of one >specialist or another... so exactly how do I "configure this >DataManager to provide the PropertySheets (I) want, with sensible >default values, and suddenly, all (my) instances suport this >propertysheet." I think this is the step I'm missing. I seem to be >able to fiddle with "Data Plug-ins" all day long.. I can create >"Persistant Sheet Providers" and type all sorts of stuff into various >boxes and they never magically seem to behave the way your are >describing... so either I'm missing some basic concept or it >doesn't really work that way! > It doesn't *quite* work that way. As mentioned in my e-mail, if you want the sheets to already exist, you'll need to either create a custom SheetProvider in Python, or you'll need to use a GenericTrigger to add them when objects are added (which won't help you when you want to add a new sheet after the fact). Now, if you're designing a new project, as Steve A. was, then of course you can set things up cleanly from the start. Globally adding sheets at a later point currently requires a custom provider, but should be doable with a later version of ZPatterns just by writing the SkinScript for the new sheet(s). ___ 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] LoginManager patch considered harmful
At 09:22 AM 7/10/00 -0400, Shane Hathaway wrote: > >The new security machinery actually provides a different way to solve >this problem. Since we now have an execution stack, we can limit that >stack, causing an exception to be thrown rather than letting it >overflow the C stack. It would actually be more reliable than the >current mechanism, which depends on DTML namespaces. That would probably be a good idea, independent of LoginManager et al. >If the LoginManager is created by the superuser and is used as the root >authenticator, it stays unowned, so the ownership problem should not >occur. If that is not the current behavior then it needs to be >corrected. That is not the current behavior, unless _owned=UnownableOwner is placed in the class. >If untrusted users are allowed to add LoginManagers, the methods called >to get ownership information should be owned by them. This is to avoid >the server-side trojan horse. Understood. I'll try to keep that use case in mind. Keep in mind, however, that being able to create a LoginManager is a pretty risky business in a portalish environment - you could potentially get access to somebody's password, since after all you will control an actual login screen! (Note however, that someone can create a phony login screen in DTML and bypass the entire Zope security model with a little "social engineering" anyway.) Also note that it is not necessary to give a user access to the full power of LoginManager. One could give them rights only to add a small subset of the available UserSources and LoginMethods. It would probably be a bad idea to give them the ability to add a GenericUserSource, which is where most of the potential for mayhem lies. Better to give them some sort of PersistentUserSource, with no ability to do much. >Now, the problem still remains that ownership information cannot be >retrieved if the method that gets ownership is in ZODB, is owned by a >user defined in that user folder, and has to call another method. Note >that this also applies to Generic User Folder. Yep. The problem is that the superuser *can't* create those methods in the root folder, so there's no place to bottom out the recursion at present. >With the correction in the execution stack, instead of killing Zope, an >attempt to authenticate that way will result in a controlled stack >overflow. Unless you can come up with another option, we can either >break the security model or slightly reduce the capabilities of >LoginManager. > >What would you do if you were in my position? Well, I'm hoping you'll take a look at my Collector suggestion for a new Zope feature. :) Specifically, extending the "access" file to allow other "top-level" users to exist besides the superuser, who have roles defined in the file. There are many ways this would be useful, not the least of which is to break the "you need to do that at the next level up" problem. (Others include a simplified process for getting your Zope site set up, since you then don't have to login as superuser and add a user folder, then log back in as somebody else.) If this were done, we could easily go to letting LoginManager objects be owned, since there'd always be a place "above" the LoginManager for the owner user to reside. ___ 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] More comments on ZPatterns
At 04:40 PM 7/9/00 -0500, Steve Spicklemire wrote:
>
>Wow.. alright. I think I need "ZPatterns for Dummies" or maybe there
>needs to be a disclaimer "ZPatterns are NOT for Dummies." ;-)
>
>I've pretty much given up on Sheets for now. Nothing I've tried
>has actually worked. I thought maybe I needed to switch to 2.2,
>but then all the code that *was working* stopped working...
It's possible that something *is* broken. Ty and I are not yet using
ZPatterns-based propertysheets for production work, and anything we don't
use yet for production work isn't as thoroughly tested.
>(e.g., I would get permission errors when I tried things
>like "ni=newItem('foo')"... "ni.propertysheets.get('Basic')"
>'get' is disallowed... in 2.2 somehow.. "Basic" is a propertysheet
>defined in the ZClass for my instances.)
This appears to be a Zope bug; OFS.PropertySheets.PropertySheets does not
define roles/permissions for the "get" method. This should probably be put
in the Collector.
>Maybe someone could just say, in a plain, step-by-stepish sort of way,
>how to add/delete/etc sheet providers for a pure ZClass based object
>at any time at all. (I would be happy to start over, if I felt I knew
>what I was doing!)
I'm not sure what you're asking for here; I thought you previously quoted
from an explanation of how to do that.
>Anyway... I went back to 2.1.6 and finally got triggers working. I
>thought I would share a minor success and ask the ZPatterns gurus if
>this is 'right' so that I might not go too far down the 'wrong' road!
>
>I defined a Generic Trigger in my defaultRack's Data Plugins
>that managed the same attributes that I have defined in
>my "Generic Attribute Provider" in the same Rack, for the
>same instances. The only persistan attribute is the id of
>the object, which turns out to be the primary key of a single table
>in MySQL that I use for my SQL based attributes. My Generic Trigger
>has
You don't need "id" to be persistent, if all it's for is to map to the SQL
database. Just make sure your GAP returns NOT_FOUND (if the record doesn't
exist) for some attribute you can then use as your "load attribute" on the
Storage Settings tab of the Rack. (If you were keeping "id" persistent so
that you could use the getPersistentItemIds() method, note that you can use
an SQL method for that purpose instead.)
>(I had to make the last attribute unconditionally set
>since otherwise the extra comma created an SQL syntax
>error if it was excluded... could sqlgroup fix this?)
No, but you could use the CHANGED_ATTRS() function instead and use an "in"
loop. CHANGED_ATTRS() returns the list of attribute names which were set
or deleted during the transaction. You could then use:
,
to add the comma between SET clauses. You would still, of course have to
do conditional code for the types of your variables.
>My only problem was that I couldn't trigger the trigger!
>In the past I've always called manage_changeProperties to
>adjust an ZClass's properties. But since only the ID is
>stored persistently... that doesn't make any sense. Instead
>I ended up creating an external method:
manage_changeProperties is an ideal way to change the attributes, actually.
The only problem is that a "common instance property sheet" won't work, as
Ty and I found out last week when we tried to build a production app using
GAP's and GenericTriggers.
The problem is that when a default attribute is set on the ZClass,
__getattr__ doesn't get called on the instances for that attribute, so you
can never get the value from your database. You can change the properties
all you want, and your database will be updated, but you'll still never see
the data in Zope.
So I've added a new kind of property sheet, a "DataSkin Property Sheet",
which sets default attributes as "class_default_for_X" names in the ZClass.
DataSkins already support defaulting to class_default_for_X if an
attribute provider doesn't come up with something, so it works out quite
well. Trick is, I haven't released this new feature yet; I only added it
Thursday evening and there are some other unfinished bits as yet.
The approach you took, with external methods, is the approach Ty took as a
workaround until I got DataSkin Property Sheets together, and is a
reasonable way to deal with it for now.
>That called the external method to actually trigger the "Generic Trigger".
>It did work... I can't help but wonder if I missed some obvious
>and much simpler way to accomplish this!
You didn't miss it; this is a defect in ZPatterns which I discovered when
Ty began building a production app similar to yours in what it uses in
ZPatterns. As with many things in ZPatterns, it's not so much that it's
inherently complicated as it is unfinished, undocumented, and untested.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.
Re: [Zope-dev] More comments on ZPatterns
At 10:02 AM 7/10/00 -0400, Shane Hathaway wrote: >Phillip, > >What if the management interface for specialists provided a way to >manipulate, or at least view, the table of virtual objects (or, in >ZPatterns-speak, DataSkins)? Wouldn't that make ZPatterns more >accessible? Probably. The sticking points are twofold, however. 1) I'm not sure what a default for such an interface would look like, and so am holding off until Ty and I have built a couple of ones for "real life" use. 2) I need a good way to make the methods overrideable without any subclassing (whether in Python or ZClasses), since Specialists "want to be singletons". I have an idea about how to make Specialist and similar ObjectManagers able to permit adding of attributes that they already have, so long as it's a *class* attribute and not a manage_* method, but I haven't had time to implement it yet. If ObjectManagers did this themselves (wink wink, nudge nudge) it would lift a lot of restrictions I'm currently holding to with regard to default interfaces on Specialists, Racks, UserSources, etc., because then users could override them at a whim. I think this may relate to an existing interest of yours regarding specification of interfaces and overriding them in instances; I'd be interested in hearing your comments regardless. ___ 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] Expanded "access" file (was Re: LoginManager patch consideredharmful) harmful)
At 03:07 PM 7/10/00 -0400, Shane Hathaway wrote: >"Phillip J. Eby" wrote: >> >> Understood. I'll try to keep that use case in mind. Keep in mind, >> however, that being able to create a LoginManager is a pretty risky >> business in a portalish environment - you could potentially get access to >> somebody's password, since after all you will control an actual login >> screen! (Note however, that someone can create a phony login screen in >> DTML and bypass the entire Zope security model with a little "social >> engineering" anyway.) > >I've thought of that as well. Perhaps we'll have to accept that the >new model just doesn't lend itself to the area of configurable user >databases. I'm not sure which model you mean, here, but in any case I think the new security model is fine, *except* for the absence of a "root" user folder that is outside of Zope and is always present when you install Zope. >> Well, I'm hoping you'll take a look at my Collector suggestion for a new >> Zope feature. :) Specifically, extending the "access" file to allow other >> "top-level" users to exist besides the superuser, who have roles defined in >> the file. There are many ways this would be useful, not the least of which >> is to break the "you need to do that at the next level up" problem. >> (Others include a simplified process for getting your Zope site set up, >> since you then don't have to login as superuser and add a user folder, then >> log back in as somebody else.) >> >> If this were done, we could easily go to letting LoginManager objects be >> owned, since there'd always be a place "above" the LoginManager for the >> owner user to reside. > >Hmm... this sounds like a good idea, but now that the ownership problem >has been resolved in a way I didn't expect, the issue that motivated >your idea is gone. Maybe, maybe not. I think perhaps the most compelling argument from Digital Creations' viewpoint for having an expanded "access" file might be the simplification of the setup process for customers. And it would also make it easier to: 1) Phase out unownedness (user databases wouldn't need it) 2) Narrow the role of superuser (super-can-create hack can go away) 3) Do Zope virtual hosting and give somebody a Zope root and even superuser, while still being able to log in 4) Stop all the whining from people who want to know why superuser can't create or own objects any more. :) ___ 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] More comments on ZPatterns
At 02:29 PM 7/10/00 -0400, Shane Hathaway wrote:
>
>I decided to try out this idea. It turned out to be a cinch! It
>doesn't restrict the manage_* methods yet; I'll get to that after I get
>some feedback. Thoroughly untested except on my box; use at your own
>risk, etc. :-)
>
>http://www.zope.org/Members/hathawsh/ConfigurableInstances/
>
Looks pretty good. A suggestion, however. There isn't any need to do it
as a patch to ObjectManager.py; you can implement this in a Product just
fine. Just organize it like this:
class ConfigurablesSheet:
...
class Configurable(OFS.ObjectManager.ObjectManager):
def _checkId(self, id, allow_dup=0):
...
class ConfigurablesSheets:
configurables = ConfigurablesSheet('configurables')
class _ZClass_for_Configurable:
propertysheets = ConfigurablesSheets()
_zclass_ = Configurable
manage_options=({'label': 'Configurable objects', 'action' :
'propertysheets/configurables/manage'},)
Then all you have to do is
context.registerZClass(_ZClass_for_Configurable), and anyone mixing in
Configurable to their bases will now have the configurable stuff on your
screen. (Btw, please don't take offense if you already knew how to do all
this; doing mixins to alter the ZClass machinery itself is pretty deep Zen
to most people, including me until just last week. I knew the theory
before that, but only actually did some mixins like this late last week,
working on some experimental stuff for PlugIns.)
>> I think this may relate to an existing interest of yours regarding
>> specification of interfaces and overriding them in instances; I'd be
>> interested in hearing your comments regardless.
>
>The thing that's really missing is the interface that DatabaseConnector
>provides. It shows you all the methods you need to implement, and when
>you're done, the interface is ready to try out. This leads to a sense
>of completion, which in turn makes the user pleased to be using
>Zope/ZClasses/ZPatterns/etc. This can only be good.
Yep, it would be nice to have such a thing. It's rather like PlugIns,
except it's designed for single methods, rather than lists of collaborator
objects. The other comment I have, now that I've seen your approach, is
that it might be more flexible from a subclassing perspective, to use a
__replaceable__ attribute. Here's how it could work:
1) Configurable._checkId() checks to see if the existing attribute to be
replaced has a __replaceable__ = true attribute, or if it lacks a
__replaceable__ attribute, it checks the objectmanager itself for a
subobjectname__replaceable__ attribute.
2) The Configurables ZClass mixin UI would set/reset
subobject.__replaceable__ on the list of names given (and in the case of
attribute errors would set/reset class.subobjectname__replaceable__
The advantage to this approach is that if you create mixin classes that are
designed to be added to Configurables, you don't have to go and re-check
your configurability list; the replacability lives with the methods, not
the class.
___
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] Re: Expanded "access" file (was Re: LoginManager patchconsideredharmful) consideredharmful)
FYI, I entered a Collector feature request for this over the weekend; I classified it as "somewhat important/future", IIRC. It mentions the "set up two accounts" concept you describe below, and I think there might be some other notes as well. At 05:07 PM 7/10/00 -0400, Shane Hathaway wrote: >Jim, > >Phillip has an idea that could make life simpler for Zope newbies. >This would be intended for the next major Zope release. > >As I understand it, the reason we needed to revoke capabilities from >the superuser was to ensure there was someone who could be assigned >ownership for every object. Do you think an expanded access file, >which would include multiple users and role lists, would enable us to >reduce the magnitude of the SuperCannotOwn dilemma? Perhaps during >installation the user would set up two user accounts, a superuser and a >normal user. > ___ 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] Re: error adding specialist
I found this one on Saturday. The problem is that Zope recently changed
the way constructors bind to their factory objects, and the "self" that
ZPatterns is providing to the constructors is no longer needed. I've
changed ZPatterns to fix this (still maintaining 2.1.x compatibility in the
process) and a few other reported and unreported bugs, but haven't had time
to issue a new release just yet. I'm up to my neck in "regular job" work
for the next few days. Hopefully I'll have a release out before the
ZPatterns chat Friday, though.
At 01:36 PM 7/11/00 +0100, Steve Alexander wrote:
>I've come across an error on trying to add a Specialist.
>
>Zope 2.2b4, ZPatterns latest release (ZPatterns-0-4-0a1).
>
>Go to the zope management pages, as a Manager.
>Choose to add a Specialist.
>Leave the "Create Default Rack of type" drop-down set to "Rack".
>Put in an appropiate id, such as "test".
>Press "Add".
>
>We get a Zope error:
>
> Error Type: TypeError
> Error Value: keyword parameter redefined
>
>
>Traceback (innermost last):
> File /usr/local/zope/SiteBox/lib/python/ZPublisher/Publish.py, line
>222, in publish_module
> File /usr/local/zope/SiteBox/lib/python/ZPublisher/Publish.py, line
>187, in publish
> File /usr/local/zope/SiteBox/lib/python/Zope/__init__.py, line 221, in
>zpublisher_exception_hook
> File /usr/local/zope/SiteBox/lib/python/ZPublisher/Publish.py, line
>171, in publish
> File /usr/local/zope/SiteBox/lib/python/ZPublisher/mapply.py, line
>160, in mapply
>(Object: manage_addSpecialist)
> File /usr/local/zope/SiteBox/lib/python/ZPublisher/Publish.py, line
>112, in call_object
>(Object: manage_addSpecialist)
> File
>/usr/local/zope/SiteBox/lib/python/Products/ZPatterns/Specialists.py,
>line 71, in manage_addSpecialist
> File /usr/local/zope/SiteBox/lib/python/Products/ZPatterns/PlugIns.py,
>line 436, in _constructPlugIn
>TypeError: (see above)
>
>
>
>The error occurs because the _constructPlugIn() method of PlugIns.py
>attempts to give "id" to manage_addRack as a keyword argument, whereas
>it has already been given the id as a positional argument. Actually, I
>think what it is being given as an id is wrong too :-)
>
>The offending line is 436:
>
> return apply(getattr(product, method), (product,)+args, kwargs)
>
>
>
>The rest of this is mainly for my benefit, and will be obvious to anyone
>familiar with the code :-)
>
>
>"getattr(product, method)" evaluates to the python method
>manage_addRack, and it appears to be a bound method.
>
>"product" is a __FactoryDispatcher__ instance.
>
>"args" is None, or ().
>
>"kwargs" is {'id': 'defaultRack'}.
>
>The signature of manage_addRack() is:
>
> def manage_addRack(self, id, title='', REQUEST=None):
>
>and is effectively getting called as:
>
> instance.manage_addRack(some __FactoryDispatcher__, id='defaultRack')
>
>I'm not sure whether the method intended to get an unbound method rather
>than a bound one, or whether "id" needs special handling here.
>
>--
>Steve Alexander
>Software Engineer
>Cat-Box limited
>http://www.cat-box.net
>
___
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] Designing with ZPatterns
At 03:39 PM 7/11/00 +0100, Steve Alexander wrote: >Quick question on designing with ZPatterns: > >Is a developer meant to specialise Specialist by defining a subclass, as >is the case in LoginManager? > >Or, given how many plugpoints Specialist has, is it best to instantiate >Specialists as-is, and fill them with DTML methods, External methods and >triggers and so forth. Then, when you want a new one, it gets >constructed by some sort of wizard. > >Or, is the answer "whichever seems most appropriate" ? Yes, with a slight inclination towards instantiation rather than subclassing. As soon as one finds oneself repeating the same pattern of setup, however, it's probably time to start looking at subclassing. At this point, so few ZPatterns-based apps have been developed, that I personally think it's premature to begin subclassing. The work that Shane is doing in the area of making ObjectManagers' built-in methods overrideable by adding new methods in-place, however, should allow for the optimum blend of these approaches. I can foresee a time when people have created several Specialist variants for common usage patterns, such as a "simple database" specialist that includes an add form, search form, etc., based on properties meta-data in the specialist itself. There are many exciting possibilities once ZPatterns itself is stabilized and the missing pieces are finished. I think Shane's work in the area of defining interfaces for customization will be an important part of making ZPatterns a powerful tool for developers of all skill levels. ___ 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 -- trigger add events not working
At 09:29 PM 7/11/00 +0100, Steve Alexander wrote: > >I've inserted print statements into the _objectChanging() and >_objectAdding() methods of DataManagers.DataManager. It seems that when >I add a DataSkin-derived-ZClass, it gets added and also changed set in a >single transaction, and only one of them gets reported to the trigger. Hm. That's a bug, since if an object is changed and added, it should only get the *add* event, not the change event. >Strangely, the call to _objectChanging() comes before the call to >_objectAdding(). This would explain why you only get a change event, since if add happens after change, it is ignored. I'm curious how the change event is getting called first, since... Oh. I'll bet I know what it is. It's probably that manage_afterAdd is being called later in the ObjectManager code than it used to be, and/or Zope is trying to set an _owner attribute on the newly added object. Crap. This is going to take some rethinking to find another way to trap the Zope "add" event. :( ___ 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 -- trigger add events not working
It could cause a problem if the object is added after any other sort of change from the point of view of the Agent. The Agent would view it as having been added, when in fact it is actually merely changed. I have not, however, been able to think of any scenario where this condition could occur unless the DataManager containing the Agent was itself being reconfigured during the same transaction as the other events, which is an "all bets are off, hold onto your butts" type proposition anyhow. My guess is that your patch will probably work fine. I've checked it in locally and will incorporate it into a release soon. At 04:09 PM 7/12/00 +0100, Steve Alexander wrote: >Steve Alexander wrote: >> >> "Phillip J. Eby" wrote: >> > >> > This would explain why you only get a change event, since if add happens >> > after change, it is ignored. I'm curious how the change event is getting >> > called first, since... Oh. I'll bet I know what it is. It's probably >> > that manage_afterAdd is being called later in the ObjectManager code than >> > it used to be, and/or Zope is trying to set an _owner attribute on the >> > newly added object. Crap. This is going to take some rethinking to find >> > another way to trap the Zope "add" event. :( >> >> >> Looks like you're right -- manage_setLocalRoles. > >I have patched the _objectAdding method of class Agent in Agents.py: > > ... > >I'm not sure whether this will have any nasty side-effects though. > ___ 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: missing docstring in getItem()
At 11:05 PM 7/12/00 +0100, Steve Alexander wrote: >ZPatterns 0.4.0a4 > >The file "version" reports it to be "ZPatterns-0-4-0a1". That gave me a >shock! I thought for a moment that I'd been working on an obsolete >edition :-) > >Specialists.py, line 28, method getItem() needs a docstring. > Changes checked in. I should be releasing an alpha5 tomorrow. I had hoped to finish my work on proxy roles, ZClass plugins, and maybe even my local-roles stuff first and make it a "beta" release, but real life has been very much in the way of that sort of thing this week. :( ___ 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: how to specify default values?
At 12:24 PM 7/13/00 +0400, Jephte CLAIN wrote: >hello, > >a common practice is to put default values for attributes for a classe >as class variables. >if the instance hasn't got the value, it gets the value from the class. > >but I can't do this with dataskins, because direct dataskins attributes >take precedence on attributes providers. > >the way I do it now is to make a default_attributes attribute provider >which provides defaults. is this correct? >or is there a better way to do this? Yes. Name the attributes "class_default_for_X" where X is the attribute name. This works with the currently release ZPatterns, but alpha5 will go one better and let you create ZClass property sheets that transparently implement this. That is, if you add a "DataSkin Property Sheet" to your ZClass instead of the standard "Common Instance Property Sheet", that sheet's attributes will be translated to/from the "class_default_for_X" names on the ZClass. ___ 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: BTree folder w/ customizer support
At 02:30 PM 7/13/00 +0100, Steve Alexander wrote: >Steve Alexander wrote: >> >> I want to combine Shane Hathaway's BTreeFolder product with ZPatterns to >> create a "BTree folder w/ Customizer support". > > > >> Instead, why not make PlugInContainer a mix-in class, and have concrete >> classes for PlugInFolder and PlugInBTreeFolder ? >> >> Then, it is easy to have a CustomizerFolder and a CustomizerBTreeFolder. >> >> Then again, I wouldn't mind if things stay as they are, except that >> PlugInContainer is made to derive from BTreeFolder rather than Folder. >> Of course, that creates a dependency that you need the BTreeFolder >> product in order to use ZPatterns. > >Or... I could alter Shane's BTree Folder product to split it into a >mix-in class and a usable folder class. Would that work, I wonder? > Probably. I think the main problem you'll run into will be the UI, since the BTreeFolder is going to probably display all its contents without filtering out PlugIns. You may have to do some work on that. Other than that, though, my guess is that a BTreeFolder mixin would layer nicely over PlugInContainer. ___ 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: missing docstring in getItem()
At 08:50 AM 7/13/00 +0100, Steve Alexander wrote: >"Phillip J. Eby" wrote: >> >> Changes checked in. I should be releasing an alpha5 tomorrow. > >That's great. Did you get my message about errors in triggered methods? Yes, I did, but the solution requires some more thought. I had thought I had the "Transactional" machinery set up so that stuff was only called during transaction phases where it was safe to throw errors. So I'm going to have to go back and review that. However, I also think that errors in triggers should result in a rollback-and-abort, rather than silently failing, which could cause many other problems. >I realised that I only sent it to the zope-dev list, and not cc-ed to >you. Not necessary; my reading rate simply varies. :) >> I had hoped to finish my work on proxy roles, ZClass plugins, > >Does that increase the number of "Waaa!" comments in the code? No, I hadn't even got that far yet. :) >> and maybe even my local-roles stuff first and make it a "beta" release, > >*If* you get time, can you put a note on the ZPatterns Wiki, or to the >zope-dev mailing list briefly describing what proxy roles, and local >roles mean in the context of ZPatterns? Thanks. The proxy roles stuff is for Generic providers and triggers, so that when they execute your expressions they can have roles other than those of the current user, which is important for constructing secure applications. The local roles stuff is the ability to have a DataSkin get local role information from "local role providers", thus allowing rules-based local roles to exist/co-exist with the standard Zope persistently-managed local roles. One aspect that will be considered in the local roles work is adjusting the LoginUser class so that it can use more efficient ways of checking access to an object if it's a DataSkin. The built-in Zope approach has to look for *all* local roles that a user has, even when it only wants to know about one of them. In general I'd like to see Zope's local role API's tightened up in this fashion. Another tightening would be to use the user object rather than the user's ID or name when calling local-roles API's, since a rule-based approach may need to consult data on the user object. ___ 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-0.4: defaults attributes, more...
At 07:11 PM 7/13/00 +0400, Ava wrote: > >first generic attribute provider: >fromexpr = '(self.id[0] and sql_get_first(key=id[0]) or [NOT_FOUND])[0]' >attrsexprs = ['first_data=RESULT.data'] > >second generic attribute provider: >fromexpr = 'self.id[1] and sql_get_first(key=id[1]) or [NOT_FOUND])[1]' >attrsexprs = ['second_data=RESULT.data'] > >third generic attribute provider: >fromexpr = '' >attrsexprs = [ >'which_one=self.id[1] and 1 or 0', >'data=[self.first_data, self.second_data][self.which_one]' >] > >however, this does not work, because if which_one is 0, self.first_data is >ok but self.second_data is taken from NOT_FOUND. An error is raised and all >the attribute served by the third generic attribute provider are ignored. > >any ideas to solve that problem??? thanks for any input. Try: data=(self.which_one and [self.second_data] or [first_data])[0] Then only the correct one will be referenced. Offhand, I'd guess that there is probably a lot easier way to do what you're doing, and that you probably don't even need/want "id" to be a sequence, let alone some of the other things you're doing here. But without knowing what your app is actually trying to do, I can't suggest anything further. ___ 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 alpha 5 released
Here's the details from the CHANGES file: New Features/Bug Fixes in 0.4.0alpha5 - Property Sheets for DataSkin-based ZClasses. Now you can put define property sheets on a ZClass and still use AttributeProviders for the properties. Just add a "DataSkin Property Sheet" to your ZClass instead of a "Common Instance Property Sheet". (Note: you can only do this with *new* DataSkin-derived ZClasses. If you have an already existing ZClass, you must either re-create it by hand or do the "setbasesholdontoyourbutts" hack to re-create the ZClass.) - GenericTriggers now also pass a variable "ORIGINAL" which is a dictionary of the original values of changed attributes (or NOT_FOUND if the attribute did not exist before changing). Note that if the values are complex or mutable, they cannot be guaranteed to be truly the same as their starting state, so this should really only be used for simple atomic values like strings and numbers. - Numerous bug fixes, including: - Specialists were always returning the result from the first Rack - setuid support for LoginManager was broken, and also didn't deal with executable-owner masking - _DelAttributeFor() was broken for persistently-stored attributes - Deleting a non-existent attribute no longer flags the attribute as changed - _constructPlugIn() was broken with latest 2.2 version that binds constructors to their products/factories - In the latest Zope, setting ownership after adding was causing a Changed event to fire instead of an Added event. ___ 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: how to specify default values?
At 10:37 PM 7/13/00 +0400, Jephte CLAIN wrote: > >What I don't understand is where the properties are stored. This is not >clear when I read the PropertyManager source. I guess property sheets >are for grouping some related attributes, but the actual work of >storing/retrieving the attribute is done by the attribute providers, >right? PropertyManager stores properties as attributes. ZClass property sheets generally do the same. So the work gets done by attribute providers if you're using DataSkins. >- is the python programmer have to mix PropertyManager in with DataSkin >to use property sheets? I guess so, but what, I seem to be the only one >who use zpatterns directly from python. All the ZClass junkies out there >do have all the mixin classes ready even before they start :-) If you're doing it from Python and you just want one property sheet, then the answer is yes. If you want multiple propertysheets, you need propertysheet objects and/or a sheet provider. >- I sometimes have a dataskin that is willing to get something from its >context. What is the preferred way to do this: try to acquire the >attribute from self._v_rack, wich is guaranteed to be wrapped in the >specialist's context, or just mix Acquisition.Implicit in with DataSkin? DataSkins *are* Acquisition.Implicit already; there should be nothing you need to do. (Yes, I know they don't inherit from it, but that is because they have an alternative implmentation of the __of__ method which is functionally equivalent to that in Implicit, with some extra handling needed by DataSkins.) ___ 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] Intializing the objects formerly-known-as-RackMountables
At 12:42 PM 7/19/00 +0300, Itamar Shtull-Trauring wrote: >I need to do initialize some properties of new instances of a DataSkin >subclass - ASPAccount. However, I can't put this in __init__ since the >object hasn't been stored at that point. > >Doing self.__dict__['name'] = 'Rincewind' seems kinda ugly. Maybe newItem >should by default call a function on newly created objects, say __init? I >don't want to have to subclass Specialist (or in my case, LoginManager) each >time I want to this, since it's a *very* common action. For example, Could you give a more specific example? My assumption is that if you need to have things happen upon adding, that one uses a trigger to do it. Or, if the data is specific to that instance, then the appropriate thing would be to manipulate properties or attributes in the code that calls newItem(). Also, it isn't necessary to subclass the specialist -- you don't have to call your routine newItem(), after all. newUser() would be a better choice of name for the method, it sounds like. ___ 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] Intializing the objectsformerly-known-as-RackMountables
At 05:41 PM 7/19/00 +0300, Itamar Shtull-Trauring wrote: > >class ASPAccount(LoginUser, MemberMixin): > >def __init__(self, id, title=''): >LoginUser.__init__(self, id) >self.__dict__['_currentPayment'] = None >self.__dict__['debt'] = Payment.Debt(0.0) >self.__dict__['debtInPayment'] = Payment.Debt(0.0) >self.__dict__['services'] = ServicesManager.ServicesManager() >self.__dict__['lastMonthlyPayDay'] = None ># day in month on which we pay >self.__dict__['payday'] = 15 >self.__dict__['log'] = "" > > >> Also, it isn't necessary to subclass the specialist -- you don't have to >> call your routine newItem(), after all. newUser() would be a better choice >> of name for the method, it sounds like. > >Again, why should I fagment my class into multiple parts? I want it all to >be in once place - it's more readable, easier to debug, easier to >understand, and more portable. > If what you want is default values, then just put them in a DataSkin property sheet in the ZClass. Or, if using a Python class, implement them as class attributes named "class_default_for_X". E.g.: class ASPAccount(LoginUser, MemberMixin): class_default_for__currentPayment = None class_default_for_payday = 15 class_default_for_log = "" Of course, this is only useful for immutables. ___ 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] Expanded "access" file (was Re: LoginManager patch consideredharmful)harmful)
At 10:15 AM 7/19/00 -0400, Shane Hathaway wrote: >Chris Withers wrote: >> >> "Phillip J. Eby" wrote: >> > Maybe, maybe not. I think perhaps the most compelling argument from >> > Digital Creations' viewpoint for having an expanded "access" file might be >> > the simplification of the setup process for customers. And it would also >> > make it easier to: >> > >> > 1) Phase out unownedness (user databases wouldn't need it) >> > 2) Narrow the role of superuser (super-can-create hack can go away) >> > 3) Do Zope virtual hosting and give somebody a Zope root and even >> > superuser, while still being able to log in >> > 4) Stop all the whining from people who want to know why superuser can't >> > create or own objects any more. :) >> >> This sounds great, what happened about it? > >You speak in the past tense. This is only a suggestion and a >possibility. It's not as important as some other feature requests. > Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, I've been tempted to do it as a LoginManager function, since Zope doesn't pay attention to anything past the first line of the "access" file... ___ 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] Intializing theobjectsformerly-known-as-RackMountables
At 05:54 PM 7/19/00 +0300, Itamar Shtull-Trauring wrote: >"Phillip J. Eby" wrote: > >> If what you want is default values, then just put them in a DataSkin >> property sheet in the ZClass. Or, if using a Python class, implement them >> as class attributes named "class_default_for_X". E.g.: > >I don't like ZClasses all that much, I'd rather not use them. > Okay, then override _objectAdding(). Just be sure to call the original implementation in your overridden version. _objectAdding() is always called with the invariants set up. Note, however, that if you use DataSkins outside of Racks, _objectAdding() is called when an object is moved or copied, as well as when added. ___ 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] Expanded "access" file (was Re: LoginManagerpatch consideredharmful)harmful)
At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote: >> >> Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, >> I've been tempted to do it as a LoginManager function, since Zope doesn't >> pay attention to anything past the first line of the "access" file... > >We would be most grateful! :-) > So are y'all at DC in agreement that this would be a useful feature with no pitfalls? Should we go through the new fishbowl process thing to do this? ___ 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] Expanded "access" file
At 12:50 PM 7/19/00 -0400, Shane Hathaway wrote: >"Phillip J. Eby" wrote: >> >> At 11:09 AM 7/19/00 -0400, Shane Hathaway wrote: >> >> >> >> Patch opportunity, perhaps? :) Ty and I would do it, no problem. Heck, >> >> I've been tempted to do it as a LoginManager function, since Zope doesn't >> >> pay attention to anything past the first line of the "access" file... >> > >> >We would be most grateful! :-) >> > >> >> So are y'all at DC in agreement that this would be a useful feature with no >> pitfalls? Should we go through the new fishbowl process thing to do this? > >Some of the crew are at oscon this week so they'll have to answer when >they get back. But I am of the opinion that the fishbowl process is >only needed for relatively major changes. Small modifications can just >be posted, reviewed, and merged. > Hm. I don't think this could be classed as a "minor" change, however, since it has impact on ownership, for example. What's the path of the user folder which is above "/", for example? The whole thing is useless if these extra users can't be owners, and the ownership machinery right now wants an access path. I think perhaps we should go the fishbowl route on this, if only to make sure that Jim doesn't have a heart attack when he gets back. :) ___ 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] PATCH: Expanded "access" file
At 01:27 PM 7/19/00 -0500, Phillip J. Eby wrote:
>
>Hm. I don't think this could be classed as a "minor" change, however,
>since it has impact on ownership, for example. What's the path of the user
>folder which is above "/", for example? The whole thing is useless if
>these extra users can't be owners, and the ownership machinery right now
>wants an access path. I think perhaps we should go the fishbowl route on
>this, if only to make sure that Jim doesn't have a heart attack when he
>gets back. :)
Looks like I was wrong. This was in fact quite a minor patch. I've only
tested this lightly so far, but if anyone else wants to try it out, here it
is. Note that the new "access" file format looks like this:
# Lines beginning with '#' are comments
#
# First user in file is "super" user, unless roles
# are specified, in which case there is NO superuser
#
superusername:{SHA}fsjdflfs:domain1.com
#
# Format for all other users is name:pw:domains:roles
#
somemanager:{SHA}rr70flksf::Manager Editor SomeotherRole
somedeveloper:{CRYPT}flsdajfd:domain2.com:Manager
You can access a dictionary of all the "access" file users by importing
rootUsers from AccessControl.SpecialUsers. It is a dictionary mapping user
names to user objects. Be sure to use __of__ to wrap them to your
UserFolder if you are adding support for this to a UserFolder variant. I
have not yet added support for this to LoginManager, but as you'll see from
the changes to the basic UserFolder, it is probably not going to be at all
difficult to do so.
Patch follows; watch out for line wrapping...
Index: User.py
===
RCS file: /cvs-repository/Zope2/lib/python/AccessControl/User.py,v
retrieving revision 1.112
diff -u -r1.112 User.py
--- User.py 2000/07/11 18:42:48 1.112
+++ User.py 2000/07/23 01:38:51
@@ -314,13 +314,30 @@
'No access file found at %s - see INSTALL.txt' % INSTANCE_HOME
)
try:
-data=split(strip(f.readline()),':')
-f.close()
-_remote_user_mode=not data[1]
-try:ds=split(data[2], ' ')
-except: ds=[]
-super=Super(data[0],data[1],('manage',), ds)
-del data
+d=f.readlines(); f.close(); del f
+rootUsers = SpecialUsers.rootUsers = {}
+
+for data in map(strip,d):
+ if not data or data[0]=='#': continue
+data=split(data+':::',':') # allow for missing fields
+
+n = data[0]
+ds = split(strip(data[2])) # space-delimited domains
+pw = data[1]
+r = split(strip(data[3])) # space-delimited roles
+
+if rootUsers or r:
+ # If not first user in file, or if roles are specified,
+# user is a "normal" user object
+rootUsers[n] =
SimpleUser(n,data[1],tuple(split(data[3])),data[2])
+else:
+super = rootUsers[n] = Super(n,pw,('manage',), ds)
+_remote_user_mode=not pw
+
+del data,n,ds,pw,r
+
+del d
+
except:
raise 'InstallError', 'Invalid format for access file - see INSTALL.txt'
@@ -383,6 +400,11 @@
"""
try: return self.getUser(id)
except:
+
+ # Don't return the superuser, so that super can't own things
+ if rootUsers.has_key(id) and id!=super.getUserName():
+ return rootUsers[id].__of__(self)
+
if default is _marker: raise
return default
@@ -405,7 +427,6 @@
_remote_user_mode=_remote_user_mode
-_super=super
_nobody=nobody
def validate(self,request,auth='',roles=None):
@@ -440,11 +461,11 @@
return None
name,password=tuple(split(decodestring(split(auth)[-1]), ':', 1))
-# Check for superuser
-super=self._super
-if self._isTop() and (name==super.getUserName()) and \
-super.authenticate(password, request):
-return super
+# Check for superuser/root users
+if self._isTop() and rootUsers.has_key(name):
+user = rootUsers[name].__of__(self)
+if user.authenticate(password, request):
+return user
# Try to get user
user=self.getUser(name)
@@ -508,10 +529,9 @@
return ob
return None
-# Check for superuser
-super=self._super
-if self._isTop() and (name==super.getUserName()):
-return super
+# Check for superuser/root users
+if self._isTop() and rootUsers.has_key(name):
+return rootUsers[name].__of__(self)
# Try to get user
user=self.getUser(name)
@@ -560,7 +580,7 @@
title ='Illegal va
Re: [Zope-dev] ENHANCED PATCH: Expanded "access" file
I've further enhanced yesterday's patch with the following additions:
* "Short-circuit evaluation" of local roles in User.getRolesInContext().
This speeds up security evaluation for complex DTML by stopping the local
role search as soon as one of the desired roles is found. The change is
fully backward compatible with any other usage of getRolesInContext()
(although there *arent'* any other usages in the Zope core). (Note: this
change also prevents infinite recursion of local roles lookup when the
local roles are provided by a ZPatterns attribute provider which is owned
by a user who has the necessary roles to compute local roles.)
* Encapsulation fix. The current version of Zope directly accesses
__ac_local_roles__ when checking access rights, which negates any ability
for Zope objects to provide rule-based local roles without computing all
possible roles for all possible users.
* Added "get_local_roles_for_user()" method to
AccessControl.Role.RoleManager that works with a user object, rather than a
user name. This is to allow objects to supply computed local roles using
attributes of the user as part of their decision process. An object need
only implement get_local_roles_for_user(user,roles) to carry this out.
These additions, in conjunction with the ability to add more users to the
"access" file, will allow ZPatterns and LoginManager to do without
'unownedness' and other convoluted alterations of the Zope security model.
They will also make it possible to add local role plugins to ZPatterns.
This is somewhat more tested than yesterday's variant of the patch,
although I have not found any bugs in what I posted yesterday. The post
itself was flawed, however; this time I'm attaching it as a file in the
hopes of preventing that happening again.
If there are no comments/questions/feedback on it, I'd like to go ahead and
submit it to the Collector for inclusion in Zope CVS; as it will make
continued development of ZPatterns and LoginManager much cleaner and in
full compliance with the 2.2 security model.
As I move further into the development of local role plugin support for
ZPatterns, I may have additional patches to suggest, as there are some
other encapsulation/interface issues with the "get_local_roles()" method as
currently used/implemented in Zope. Most likely, there needs to be a
"get_users_with_local_role()" method for those uses, leaving
"get_local_roles()" to mean "get *editable* local roles". Also,
ObjectManager still inspects __ac_local_roles__ rather than going through
an interface to set the initial owner role of an object. Personally, I
think this should be done by one of the many other after-add type calls
such as manage_afterAdd or manage_fixupOwnershipAfterAdd, etc., but
backward compatibility for that would be tricky.
Patch follows.
Index: AccessControl/Role.py
===
RCS file: /cvs-repository/Zope2/lib/python/AccessControl/Role.py,v
retrieving revision 1.39
diff -u -r1.39 Role.py
--- Role.py 2000/06/20 01:59:40 1.39
+++ Role.py 2000/07/23 18:46:03
@@ -365,9 +365,12 @@
keys.sort()
return keys
-def get_local_roles_for_userid(self, userid):
+def get_local_roles_for_userid(self, userid, roles=()):
dict=self.__ac_local_roles__ or {}
return dict.get(userid, [])
+
+def get_local_roles_for_user(self, user, roles=()):
+return self.get_local_roles_for_userid(user.getUserName(),roles)
def manage_addLocalRoles(self, userid, roles, REQUEST=None):
"""Set local roles for a user."""
Index: AccessControl/User.py
===
RCS file: /cvs-repository/Zope2/lib/python/AccessControl/User.py,v
retrieving revision 1.112
diff -u -r1.112 User.py
--- User.py 2000/07/11 18:42:48 1.112
+++ User.py 2000/07/23 18:46:04
@@ -137,22 +137,27 @@
"""Return the list of roles assigned to a user."""
raise NotImplemented
-def getRolesInContext(self, object):
+def getRolesInContext(self, object, findRoles=()):
"""Return the list of roles assigned to the user,
including local roles assigned in context of
- the passed in object."""
-name=self.getUserName()
+ the passed in object. If asked to find specific
+ roles, return true if any of the specified roles
+ is found, false otherwise.
+"""
+
roles=self.getRoles()
+for r in findRoles:
+if r in roles: return roles
+
local={}
object=getattr(object, 'aq_inner', object)
+
while 1:
-if hasattr(object, '__ac_local_roles__'):
-local_roles=object.__ac_local_roles__
-if callable(local_roles):
-local_roles=local_roles()
-dict=local_roles or {}
-for r in dict.get(name, []):
+if hasattr(object, 'ge
RE: [Zope-dev] PATCH: Expanded "access" file
At 10:54 AM 7/25/00 -0400, Brian Lloyd wrote: > >I think that this is _definitely_ the kind of thing that >should be done in the fishbowl on dev.zope.org. Why? Because >while it may be a "minor patch" in terms of lines of code, just >applying the patch causes a number of problems that have nothing >to do with software per se. Sorry about that. As you may have seen from the list, I did enquire as to whether this should go in the fishbowl, and was told that such a minor patch probably didn't need it. I thought the issue was more complex than it was also; I was under the impression that Zope had a user folder *above* the official "root", not realizing that it was merely that the "physical root" had a default user folder in existence. >What is the problem being solved? How exactly does this solve >it? Is it the right solution? Why did we make the decisions we >made? Of course some discussion of these has occurred on the dev >list, but the only way I (or anyone else) can discover these is >to piece things together by searching list archives. Problem being solved: the new ownership model requires a place for ownership to "bottom out" so that user databases themselves can have owners. The previous solution was the creatable-by-super hack, which only created further holes in the ownership model, since user databases which involved components which followed the security model (e.g. GenericUserFolder and LoginManager) then had to suppress ownership characteristics or else be unusable as a root-level user database. Second problem: the initial existence of only a single Zope user who could not actually do anything except create a UserFolder, was troubling to new users of Zope and at best inconvenient for experienced ones. > o There is no visibility of the impacts of the change. > >How does this affect ownership? Does this work with all existing >user folder objects, or do they all need to change to support it? * The "rootUsers" can own things * They appear to be normal members of the root UserFolder, except that they do not appear in its contents as they are not stored there. * It is not necessary for a user database to support the rootUsers; however if the top-level user database of a Zope installation does not support them, they will not be usable in that installation. * User databases using the existing name==super.getUserName() protocol are unaffected; they simply will not provide access to the new rootUser objects. * User folder objects must be changed to support the rootUsers dictionary. The patch provides this support for the Zope UserFolder object. In practice, I believe that there is a relatively small (i.e. near-zero) number of publically-available user databases currently in existence which correctly support the Zope 2.2 security model, apart from those developed by DC themselves. Private developers of user databases need only implement the support if they would like the additional feature, and for the rest, I believe this patch should actually make it easier to implement 2.2 support for most such user databases, since they won't need to implement the creatable-by-super protocol or work through ownership issues. > o This would become Yet Another Undocumented Feature. > >One of the big things that the dev area is going to do is to force >us to assess the documentation impact of changes and ensure that >the required documentation is produced and integrated with the >appropriate offical or unofficial docs. I can see the expanded >access file change potentially having an effect on at least two >kinds of documentation (user/admin guides and developer materials >regarding how to implement new kinds of user folders). My assumption was that this feature would actually be easier for DC to document than explaining to someone why they have to log in as superuser, create a user folder, put a user in it, then log out by closing their browser, and then log back in again as that other user in order to start using their Zope installation. My intent was to make both your and my life easier, not more complex. I apologize for any such side effect. :( ___ 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] PATCH: Expanded "access" file
At 10:54 AM 7/25/00 -0400, Brian Lloyd wrote: > >I think that this is _definitely_ the kind of thing that >should be done in the fishbowl on dev.zope.org. It's there now. See: http://dev.zope.org/Wikis/DevSite/Proposals/UserProgrammableSecurityObjects It covers in full, I think, the issues that Ty and I have been struggling with to make LoginManager and ZPatterns give users the power to script user databases and local roles in a secure way, while not having things blow up due to infinite recursion as the security model checks that it has the right to check that it has the right to check that it has the right to ___ 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] Re: zpatterns-0.4.0a5: problem with unregistering transactionals
Question... Are you on 2.1.x or 2.2? Also, in your example, tpc_entered is not set because tpc_entered is only true if the transaction commit process (tpc = two-phase commit) has been started. At 11:53 AM 7/27/00 +0400, Jephte CLAIN wrote: > >Ok, so ZPatterns.Transactional._unregistered method is called twice for >a ZPatterns.Transactional object when an exception is raised and the >ZPatterns.Transactional object has not be freed: once from the >ZODB.Transaction.abort method, once from the ZODB.Transaction.__del__ >method which call abort if objects to be aborted remain in the zodb >transaction aware object >The call is made twice for DataSkins and for TransientMapping (as far as >I know, they are at the moment the only Transactional objects in >zpatterns) > >for example, try this DTML code in a specialist: > > > > > > >without my patch, Zope should display 'uncatched exceptions in >Transation object' > >so what now? I'm lost. Is this normal or not? Is my patch sufficient >(ignore attempts to abort the object twice by trapping exceptions in >_unregister). What about Transactional.abort which check for >tpc_entered? Why is tpc_entered never set to 0? > ___ 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] Quickie on ZPatterns ... I promise :)
At 09:15 AM 7/27/00 +0100, Steve Alexander wrote: >Bill Anderson wrote: >> >> Let's say I have an object I will store in a rack. Let us say I want this object to be >> cataloged in a ZCatalog. Any caveats I need to know about >> ..such as "Don't do that!" ? >> ?;^)= > >Make one of the object's base-classes DataSkin. > >Don't make it CatalogAware. > >Use triggers to index and unindex the object from a catalog. You'll >probably want to store the catalog in Specialist. > >By the way, Phillip Eby has released a new development snapshot: > > >http://www.zope.org/Members/pje/ZPatterns/ZPatterns-0-4-1snap1.tgz/view > >I'll be trying it later today. > FYI, the snapshot really only adds proxy roles support for generic providers/triggers, and adds a first-cut version of SkinScript. If you're adventurous, you can look at SkinScript/Compiler.py and have a look at the grammar in order to figure out what the language does. So far I've successfully tested a SkinScript method that does the work of four GenericAttributeProviders and two GenericTriggers, just by using the appropriate statements. Here's a SkinScript snippet you might use for CatalogAwareness: WHEN OBJECT ADDED CALL somecatalog.catalog_object(self) WHEN OBJECT CHANGED CALL somecatalog.recatalog_object(self) WHEN OBJECT DELETED CALL somecatalog.uncatalog_object(self) (Replace the incorrect catalog API calls with ones that are correct... I'm sure I'm missing some parameters and probably getting the names wrong...) Note that "somecatalog" must be in the acquisition context of the SkinScript method itself. If you want to use a catalog in the context of the DataSkin, you need to say "self.somecatalog...". Some other SkinScript snippets: # Store attribs persistently - replaces # Persistent Internal Attribute Provider STORE attrib1,attrib2 IN SELF # Computed attributes WITH SELF COMPUTE attrib1=attrib2+attrib3, attrib4=attrib6*10 # Generic attrib provider WITH (SomeSQLMethod(key=self.id) or [NOT_FOUND])[0] COMPUTE field1, field2, somefield=field3+field4, fancy_id = '*(%s%s)%' % (otherfield,self.id) # Generic trigger WHEN OBJECT ADDED,CHANGED,DELETED CALL someexpr(self.id) SAVING foo,bar, baz=spam, widget=diddly+id # Attribute provider STORE attr1,attr2 USING somefunc(self) SAVING attr1,attr2 # Conditional attrib provider WHEN OBJECT ADDED STORE attr2 USING otherfunc(self) That about covers it for what's implemented so far. The goal is to ultimately replace the majority of providers and triggers with SkinScript. But it will still be possible to write and use custom plug-ins that provide attributes or handle events in other ways. But SkinScript will be quite handy for most things. ___ 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] Re: zpatterns-0.4.0a5: problem withunregistering transactionals
At 07:12 PM 7/27/00 +0400, Jephte CLAIN wrote: >"Phillip J. Eby" a écrit : >> >> Question... Are you on 2.1.x or 2.2? >I'm still on 2.1.6. I cannot afford a migration of my product now since >it is still in developpement and my customer wants it to work as soon as >possible. Okay, that makes sense. 2.1.6 has a weirdness in the ZPublisher exception hook that begins a new transaction instead of aborting the old one cleanly, and that ultimately causes the objects to get aborted twice. I reported this a month or two ago and it got fixed in 2.2. You're going to have to go with your patch, though, because there's not a simple patch you can apply to 2.1.6 to fix the problem in Zope itself. Unfortunately, it is hard for me to tell whether your patch has any other repercussions. :( I will try to review the structure of my Transactional class and see if there are any side effects (besides the one you've found) of an object being aborted twice. >> Also, in your example, tpc_entered >> is not set because tpc_entered is only true if the transaction commit >> process (tpc = two-phase commit) has been started. >I thought that tpc_entered would go back to 0 when the transaction is >over. It is clear that I don't know how the transaction machinery really >works. It's probably because of the double-abort weirdness. :( ___ 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] Re: zpatterns-0.4.0a5: problemwithunregistering transactionals
At 08:06 PM 7/27/00 +0400, Jephte CLAIN wrote: >By the way, besides new features like skinscript and proxy settings, did >you fix any bugs from 0.4.0a5 in 0.4.1a5 that would make me have to >upgrade my current ZPatterns? > IIRC, nothing that would affect you on 2.1.6. I vaguely recall some fixes for 2.2 stuff, but I think they were all out in 0.4.0a5 anyway. ___ 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 Documentation
Despite the implications of the bait-and-switch subject line, I have not yet written any substantial amounts of documentation. I have, however, written this: http://www.zope.org/Members/pje/Wikis/ZPatterns/DataSkinsOverview DataSkins (formerly known as RackMountables) are central to the operation of ZPatterns, and I decided to take a whack at explaining them at an introductory (I hope) level, complete with a diagram. Could anyone who gets a chance please give me some feedback? I'd like to know if this is the kind of stuff that people would like to see more of, or whether it's too much detail, not enough, right questions, wrong questions... Just comment, please, preferably in e-mail via Zope-dev. Thanks. _ _/__) ___/ ___ 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] Re: [Zope-PTK] ZPatterns Documentation
At 10:58 PM 7/27/00 +0100, Steve Alexander wrote: >"Phillip J. Eby" wrote: >> >> Just comment, please, preferably in e-mail via Zope-dev. >> Thanks. > >Generally very clear and helpful. Tomorrow, I'll try it out on someone >who hasn't been looking at ZPatterns a great deal, and see what she gets >from it. Thanks. >A few suggestions. I feel sad that these seem to come across as >criticisms. Really, I'm very glad that you've found some time to work on >more accessible documentation. > Hm. Well, your comments have convinced me that 1) I'm not really qualified to write good beginner docs, and 2) I shouldn't try to combine a design document with beginner documentation in any event. :) Probably the doc needs to be split into seperately focused documents for "What are DataSkins (for)?" and "How do they work?". I was trying to capture all the things that happen in the interactions between DataSkins and their primary collaborators in order to have that documentation later. Unfortunately, a lot of that "how" detail is extraneous to the "how do I" and "why" questions. Probably as written, the doc is more useful as an introduction to ZPatterns innards than it is as an intro to ZPatterns 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] PROPOSAL: Splitting ZPatterns into two products
Many people have suggested splitting out the PlugIns part of ZPatterns as a seperate product for general Zope use. In addition to this, it is becoming clearer to me as I work on docs, etc., that there really is only one thing left in ZPatterns after you take out PlugIns, and that is DataSkins. (Pretty much everything else in ZPatterns only has meaning in relation to DataSkins.) So, I am thinking perhaps I should split ZPatterns into two products: PlugIns and DataSkins. The DataSkins product would require the PlugIns product. LoginManager would require both. For backward compatibility, there would need to be a "final release" of ZPatterns which contained stubs to load in classes from their new locations, so that existing objects stored in ZODB's would not be "broken". Newly created objects, of course, would refer to the new products automatically. The term "ZPatterns" would then go away, which is just as well because it doesn't really mean anything, anyway. :) Please let me know if you have any comments or questions on this. _ _/__) ___/ ___ 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] Re: [Zope-PTK] PROPOSAL: Splitting ZPatterns into two products
At 09:51 AM 7/28/00 +0100, Chris Withers wrote: >Steve Alexander wrote: >> "Phillip J. Eby" wrote: >> > So, I am thinking perhaps I should split ZPatterns into two products: >> > PlugIns and DataSkins. > >If 'PlugIns' includes plugins, plugin groups and plugin containers, then >that's a pretty good name :-) Yes. >'DataSkins' doesn't mean a lot to me as a name :S >What components would go into this product? DataSkins themselves, and all the things that support them. Data Managers (Racks and Customizers), Data Manager containers (Specialists and Folders w/Customization Support), and Data Plug-Ins (Attribute Providers, Sheet Providers, Triggers, etc.) >Yup, sounds like a great idea. Hopefulyl Pluggins could get into the >Zope core ASAP. I reckon they might be quite useful to ZMI mark II :-) That might be, but the PlugIns part isn't really where it should be before it could even be proposed to go into the Zope core. The biggest hurdle remaining is full ZClass support. I would like to have it so that if you base a ZClass on PlugInContainer, you get a tab in the ZClass management screen where you can add and configure plug-in groups... and the groups themselves would be plug-ins, so that you could have specialized forms of plug-in groups. >Has anyone done anything with the 'glossary wiki' idea I punted out a >while back? I don't believe so. But I think that splitting the package will make documentation easier. Partly because it will allow starting from a fresh viewpoint that is DataSkins-centric and more use-oriented. I figure on leaving the ZPatterns Wiki alone for the most part until the DataSkins docs start to mature, and then yanking out documentation-type stuff from the ZPatterns Wiki and re-purposing it to focus on application design, object modelling, and the like, in the context of the DataSkins and PlugIns packages. ___ 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] PROPOSAL: Splitting ZPatterns into two products
At 10:22 PM 7/28/00 +0100, Chris Withers wrote: >Steve Alexander wrote: >> There are various types of DataManager in ZPatterns, and the important >> ones take plug-ins so that you can greatly modify their behaviour. > >I thought there were only two right now? Technically, there are three - Specialist, Rack, and Customizer. But Specialist is never directly used by a DataSkin as its data manager, because of the Rack. Specialist derives from DataManager, though, so it can have data plug-ins for use by its Racks. So there are only two "true" DataManagers - Rack and Customizer. I don't expect there will be any more in future, because I don't know of any other ways to organize Zope objects besides: 1) a flat namespace (Rack), or 2) a sub-object tree (supported by Customizers). >> Specialists may have Racks inside them to actually do the work of >> storing the data, > >Now what's a rack in Plugin terminology? A plug-in that's also a plug-in container. >> so you can think about your application's architecture >> at many different levels of abstraction. You can say "The AddressBook >> specialist manages Address DataSkins" but you can also say "The >> Addresses rack in the AddessBook specialist stores the Address >> DataSkins". > >By DataSkins here, particularly in the secodn phrasing, wouldn't it be >better to say the AddressBook specialist stores the flesh and bones of >the Address DataSkins? Here's how I prefer to say it... An "AddressBook" specialist is where you get, create, or manipulate en-masse, things which you'd like to have in an address book. It may contain one or more racks which store some particular concrete class of things which have addresses, and which you want to have available through your addressbook specialist. The rack does not necessarily store the "flesh and bones", because that might reside in LDAP, SQL, the filesystem, or something else altogether. The rack is a "storage manager" which manages the process of realizing DataSkins of a particular class with common storage characteristics. >>> When Objects get created or deleted or changed, a DataManager will tell >> any Agents it knows about that this has happened, in case they are >> interested. > >Are 'Objects' here DataSkins, non-DataSkins or either? DataSkins only. >> An Agent is anything that monitors the events produced when >> things happen to DataSkins. > >But they're actually called by the Data Managers? Yes. DataSkins tell their DataManager they've changed; the DM forwards the appropriate messages to the Agents. >> A Trigger is a kind of Agent that does something concrete, like calling >> a method, in response to a change in a DataSkin. You can use a Trigger >> to update a ZCatalog when a DataSkin gets added or deleted or changes. > >Sounds cool, where does SkinScript fit in here? SkinScript can be used to specify DTML expressions to be called as triggers, or to be used to calculate attributes, etc. In place of an AttributeProvider or Trigger, you plug-in a SkinScript Method to a DataManager, then write the SkinScript code to describe all the attributes and triggers, etc. you want. >> You can even use two Triggers to update two different Catalogs when a >> DataSkin changes -- for example, the AddressBook catalog, and also a >> SiteIndex catalog for searching all the data in your system. > >Now how would these triggers actually get added to the datamanager in >the above example? You go to its Data Plug-ins tab, and select from the "Add" dropdown the kind of trigger or provider you want. Then you fill in its settings to do what you want it to do. >Ah, okay, I see now. So, for example, a SheetProvider would prove a >property sheet for each DataSkin served by the DataManager in which it >was located? Yep. ___ 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: bug in DataSkins.py
At 08:07 PM 7/30/00 +0100, Steve Alexander wrote: >Steve Alexander wrote: >> >> I'm using ZPatterns 0.4.1snap1. >> >> DataSkins.py line 377 >> method _v_currentSheets(self,_v_dm_=_v_dm_) >> >> l.extend(list(sp._PropertySheetsFor(client))) >> >> However, the variable "client" isn't declared elsewhere. > >..and when I replace it with "self", I get this error when I try to >iterate through a dataskin's propertysheets: > Would you try something for me? Stick a routine in that class, call it getCurrentSheets(), with exactly the same code as the _v_currentSheets method, then call it from your code in place of iterating through propertysheets? I have a feeling it'll provide a clearer error message. (That's the only problem with ComputedAttributes - errors that break them manifest as AttributeErrors, hiding the true error.) Thanks. ___ 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 design question
At 11:09 PM 7/30/00 +0100, Steve Alexander wrote: >Let's say I have an AddressBook specialist. Why? :) Seriously, what is the function of "address book" in your application? Is it to find people in general? Or...? >Let's say I want to combine my AddressBook with a Suppliers specialist. >The Suppliers specialist knows about DataSkin-ZClasses called Supplier. >A Supplier has its own propertysheet "supplies" that has information >about the kind of goods and services supplied. A Supplier also has an >address. > >Suppliers appear in the AddressBook. When I get a Supplier from the >Suppliers specialist, I want it to have two propertysheets: supplies and >address. I'm having a lot of trouble understanding your application. Can you tell me what you're trying to do in the problem domain? ZPatterns design is strongly rooted in the problem domain, not the programming side. The answer on the programming side is usually, "do whatever supports the problem domain." :) > >Bunch of questions: > >Is this the ZPatterns ideomatic way to do this? Dunno. Explain the problem you're trying to solve, and I'll tell you the simplest way I know to do it. >Can I use SkinScript to get propertysheets from another specialist? No. I don't have SkinScript sheet providers yet. I'm not sure exactly how to make them just yet, because I haven't run into a spot where I've needed them. I hate trying to write something when I don't have a good feel for what's needed yet... :( >Is the SheetProvider that gets the address for the Supplier objects also >responsible for adding and deleting Address objects? Eh? A sheet provider is responsible for sheets. If you want to have the "same" sheetprovider being used for both objects' address sheet, that should work just fine. And it would be reasonable to have that sheet provider also act as a catalog trigger, if you want it to be an invariant that all address sheets are stored in the catalog. >Do I need an Address object for each Supplier object? No, just a propertysheet. >What kind of propertysheet should I be using? Depends on what your application needs. I can see circumstances where the best place for that sheet could be LDAP, SQL, or the ZODB. Your app's needs decide. (That's the nice bit about ZPatterns, too... you can always change your mind later, as long as you don't build in your assumptions.) >Should the method in the AddressBook specialist be returning an Address >object, or just an address propertysheet? Depends on what you want to do with it. Generally speaking, though, I have a hard time seeing what your addressbook specialist is FOR, unless it's just to provide a combination of general search location for anything that has an address plus a PIM-style addressbook. In which case, I think your confusion comes from terminology. I would expect to store "Contacts" or "Entries" in an addressbook, and these would have address sheets, as would "Suppliers" or whatever else. So the thing in an addressbook isn't a sheet by itself, but it's kind of confusing to be mixing address objects and address sheets. Anyway, to answer your question - I think that your getItem() for an address specialist wants to return some object with an address sheet. But not an address object. Contact, Entry, Supplier, TennisBuddy... whatever the heck kind of object it is. >Or, more generally: Adding sheets to a "party" seems to be one of the >important ZPatterns ideas. What is the best way of implementing it, >using the simple case of two specialists as an example? Let's assume that the specialists are at different abstraction levels, e.g. "Addresses" and "Suppliers", where other things exist that have addresses, like "Customers". Customers and suppliers both have an "address" property sheet, which you want to be searchable, printable, etc. from your "Addresses" specialist. There are at least a few ways to do this: 1) Store all addresses in the same database, and implement a sheet provider which you place in all the specialists. Then create a Rack which returns generic "addressbook entry" objects from this database. (Downside: unless you store URL's in the database, there's no easy way to jump back to the "real" object from which the address entry derives.) 2) Store them in different places, but have all the sheet providers update a catalog in the addresses specialist (which takes care of the URL problem) 3) Combine 1 and 2 - use the same database for storage but use a catalog also anyway Which you select depends on your application and the things you're integrating. ___ 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] Re: MySQL Transaction Support
At 05:05 PM 8/1/00 +0200, Monty Taylor wrote: >Good point. It still irks me to have two DA's though. It gets confusing >enough >with the three different DA's running around now, much less if one of >them >actually had two valid versions. What if we had two classes like you >said, but >then in the manage_addForm had a checkbox for Transactions enabled, >which would >determine which Class got instantiated? Any good reasons why that >shouldn't work? > Nope. Since Zope constructors are generally implemented as functions, they can actually create any class at all. Of course, you won't be able to change it later without deleting and re-adding... Btw, do you happen to know whether locking is handled automatically on "BDB/transaction-safe" tables, or do you still have to specify it explicitly? ___ 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] DataSkin propoerty Sheets/Providers.
At 07:09 PM 8/2/00 -0600, Bill Anderson wrote:
>I think I have a decent handle on this concept, but something seems
lacking, I hope
>someone can clear it up :)
>
>So, let us say I have an object, call it a Member. :)
>And let us say I want to be able to add a property sheet to it in a
customizer/specialist.
>AIUI, I should be able to add a persistent sheet provider, give it the
name I want for the
>sheet, and define the sheet?
>
>Geex, the more I write what I want to do, the less I feel I grasp it. :(
>
>Basically, let me put it this way:
>I have DataSkins (ZClasses). I have one or two property sheets that I want
most/all of the
>DS objects to have. I don't want to have to define the property sheet in
each and every
>ZClass. AIUI, PersistentSheet providers can do this. I want to do it with
the default
>ZPatterns/LoginManager includes.
>
>So, am I totally clueless, or am I just looking to hard, and missing
something blatantly
>obvious?
>
PersistentSheetProviders can do what you want - *but* there is one
drawback. PSP's have no concept of a sheet schema, so you have to add the
sheet and set up its schema in code for *each instance*. The good news is,
you can do that from an "add" trigger, by calling
self.propertysheets.manage_addPropertySheet(id='name', xmlns=''), followed
by self.propertysheets.get('name').manage_editProperties(...). (You can
even do it as a tuple expression, i.e. just seperate the two expressions
with a comma. Rendered in SkinScript it would look like:
WHEN OBJECT ADDED CALL
self.propertysheets.manage_addPropertySheet(id='name',xmlns=''),
self.propertysheets.get('name').manage_editProperties(...)
(The "..." should be replaced with appropriate parameters for
manage_editProperties, of course.) Unfortunately, this will not allow you
to initialize the property sheet contents except with constant data, data
from the instance, or from self.REQUEST.
___
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] DataSkin propoerty Sheets/Providers.
At 05:38 PM 8/3/00 -0600, Bill Anderson wrote: >"Phillip J. Eby" wrote: >> >> PersistentSheetProviders can do what you want - *but* there is one >> drawback. PSP's have no concept of a sheet schema, so you have to add the >> sheet and set up its schema in code for *each instance*. > >Rats. :/ > I forgot to mention, but you can also create your own sheet provider (possibly derived from PSP) that creates sheets of the kind you want, and since all providers are able to receive the _objectAdding() event, you can have it happen as soon as the object knows it's being added, without even waiting for transaction commit. You would have to write such a provider in Python directly, however. ___ 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] RE: [Zope] ZPatterns Question
At 01:57 PM 8/8/00 +0200, RC Compaan wrote: >I've added a propertysheet called "properties" to my ZClass and i notice >there is Persistent Sheetprovider under the default rack already. The >Sheetprovider has properties Sheet_Names and Sheet_Namespaces. I guess >Sheet_Names should refer to the sheetname i created for my ZClass??? but how >do Sheet_Namespaces come into play. Actually, neither relates. Property sheets created on ZClasses always have their data stored in attributes of the object itself, so if you want to control those property sheets you would not use a sheet provider at all. Sheet providers are only used to provide property sheets whose data is stored external to the object. The "name" refers to sheet names, yes, although again these are not ones created on the ZClass, which will be handled by the ZClass. The "namespaces" refers to the XML namespaces of the property sheets, which is a WebDAV thing. In the WebDAV protocol, "property sets" are added/changed using URLs as XML namespaces. So you could have a property sheet whose XML namespace is "http://www.zope.org/PTK/MemberProperties" and whose name is just "MemberProperties" or "MemberInfo" or something else altogether. ZPatterns supports WebDAV, and WebDAV requires the ability to add arbitrary property sets with arbitrary properties to an object. Also, the XML namespaces concept can be useful as a way of avoiding name collisions between frameworks. >>From the IRC_Chatlog: >"Call "getItem(key)" to retrieve an item from the Specialist, and >"newItem(key)" to create a new item in the specialist." > >Does this imply that I can simply call "newItem(key)" from a dtml-method >inside the specialist to create a new instance of my object? Yes. >I think I understand ZPattern architecture somewhat but get lost on the >implementation side, particularly at that place where attributes are >retrieved from storage or more clearly how a specialist(datamanager) links >up/communicates with a sheetprovider (data-plugin) and how the sheetprovider >in turn communicates with the rack and how the rack retrieves from storage >(dataskin). > >A very simple outline like this would help me a lot, eg: >Specialist to Sheetprovider (handled in IDE - add a SheetProvider under >Plugins) >Sheetprovider to rack (handled in IDE - select Storage Class under rack) >Rack to Dataskin () >Dataskin to physical storage () > >Roché > >PS: I would be more than willing to document my enlightenment in a howto The Specialist does not talk to the sheet provider. The Specialist asks its racks for an object. The Rack which "retrieves" the object tells the object that it belongs to the rack and should ask the rack for anything it needs. When the object needs a property sheet or attribute or whatever, it asks the rack to give it a list of relevant providers for that attribute/sheet/whatever. It then walks the list asking those providers if they can perform the function it desires. If none of the providers are successful, it performs a default behavior (such as raising an AttributeError to indicate the attribute does not exist). This general pattern is followed for almost anything that can be delegated from a skin to a provider. When DataSkins are used outside a rack, the process is similar, except that the DataSkin itself notices it is being retrieved from somewhere and has not been told it belongs to a rack, so it searches its acquisition path asking for a Customizer. Once found, it then uses the Customizer in the same way as it would have used the Rack (i.e. to ask for lists of providers that might be useful for performing tasks it needs done). ___ 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 Question
At 06:07 PM 8/8/00 +0100, Steve Alexander wrote: >"Phillip J. Eby" wrote: >> >> Actually, neither relates. Property sheets created on ZClasses always have >> their data stored in attributes of the object itself, so if you want to >> control those property sheets you would not use a sheet provider at all. > >> Sheet providers are only used to provide property sheets whose data is >> stored external to the object. > >I'm confused here. Please excuse me if these questions seem silly. > > >What does "Property sheets created on ZClasses" mean, exactly? I mean, if you go into the management screens for a ZClass, and add a property sheet to the *class*, the sheet's definition is stored in the class, and its contents are stored as attributes on the instances. Sheet providers have no effect on such property sheets, as they are defined in the class. However, if you use a "DataSkin Property Sheet", the attributes of the sheet are stored in the instance in a way that is compatible with attribute providers. Thus, you can use attribute providers to provide the content of the sheet. But you cannot provide the sheet object itself. This may seem a subtle distinction, but it is an important one for some applications. Sheet providers are primarily intended to add sheets outside the scope of the class of object being used. >If I use some DataSkin-derived ZClass instances inside a Customizer >folder, and if I want to store the data in the ZODB, do the >propertysheets for one of these ZClass instances come from >PersistentAttributeProviders or PersistentSheetProviders? If you create the sheets *in* the ZClass itself, then the *data* for the sheets comes from an AttributeProvider (actually, it's just stored in the instance, but the storage is controlled by an AttributeProvider). The sheet *itself* would come from the class. If you create the sheet with object.propertysheets.manage_addPropertySheet(), then the sheet will be created and managed by a SheetProvider. >What is the difference between a Common Instance Propertysheet and a >Dataskin Attribute Propertysheet when added to a Dataskin-derived >ZClass? The difference is that a Common Instance property sheet stores default values in the class under the original attribute name, which makes __getattr__ unusable on the instances. A DataSkin property sheet stores default values in the class under the name "class_default_for_X" where "X" is the attribute name. This lets the DataSkin instances give an AttributeProvider a chance to supply the value of an attribute before falling back to a class-level default. >Is the following true, part true, false, or irrelevant? > >If I want to add a propertysheet that contains information from an SQL >database query to a ZClass-dataskin instance, I have to : > >* Declare in my Product that the ZClass has that propertysheet (unless I >do clever stuff with triggers to add the sheet if it isn't there >already) > >* Use a custom SQL SheetProvider? Or an AttributeProvider? Or some >skinscript that calls various methods in my specialist? You can do any of the above. Currently, the easiest way to do it would probably be to add the sheet to the class, and then use attribute providers to supply the data. If you needed to add this atop a class which needed to be "final" (in the Java sense, i.e. no modifications allowed), then the best route would be a custom SQL sheet provider. ___ 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: how to invalidate the attribute cache?
At 05:23 PM 8/10/00 +0400, Jephte CLAIN wrote:
>Hello,
>
>I feel a need to invalidate a dataskin attribute cache after it has been
>edited, because other objects might want to use the just modified
>dataskin, but with the new values.
>Of course, these values come from some attribute providers that should
>be re-queried.
This should not be necessary. Note that both __set_attr__ and __del_attr__
call self._objectChanging('name') which invalidates the cache entry for
'name'. If you are changing the object in some other way via Python such
that neither __set_attr__ nor __del_attr__ are being called, you should
call _objectChanging('attrname') in order to ensure that change events get
fired properly and the cache for the attribute is invalidated.
I don't see a need for a mass invalidation operation, just more
documentation on these inner workings. :)
___
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] RE: [Zope] ZPatterns Question
At 10:28 AM 8/10/00 +0200, RC Compaan wrote: > >Oh ok, this divide clears it up a bit. I somehow imagined that an object's >properties are always stored inside the object and that Providers are the >managers of those properties. I am finding that most people outside of Digital Creations aren't aware that there's any other kind of property sheet besides the kind that stores its data in attributes. :( >The Specialist (filing clerk) asks its racks (filing cabinet) for an object >(dental records). The rack (filing cabinet) tells the object (the dental >records) that it belongs to the rack AND that the object should ask the rack >for anything it needs. > >Why would the object "need" anything. Is it not the specialist with the >"need"? > >If object data is stored external to the dataskin object does the dataskin >only implement behaviour? I find it difficult to understand because I >associate Dataskin with Storage. DataSkins do not implement storage; the whole point of a DataSkin is that it is storage-neutral. It is a behavioral "skin" which can be wrapped over other objects which actually implement behavior. It's a rather sophisticated variant of the GOF "Strategy" pattern, where an object delegates the choice of algorithm to another object. > If object data is stored externally is it >stored in Persistent Property Sheets? Well, that's one way to do it, and the only way implemented for you in ZPatterns currently. If you want to do it another way (e.g. SQL), you'll have to write your own sheet provider. >How does one define properties for >Persistent Property Sheets? By calling the standard propertysheet methods to manipulate their properties from code, e.g. manage_editProperties and the like. ___ 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 Question
At 11:58 PM 8/9/00 +0100, Steve Alexander wrote: > >1: ZClass instances can have PropertySheets added to them, independently >of any sheets declared in the ZClass class definition. > >I've been working with Zope for a while, but this had never occurred to >me. I guess this is just another one of those hangovers from writing in >Java for so long. It's not a very well-known feature of Zope. AFAIK, it was implemented to support WebDAV, which requires the capability to add arbitrary propertysets to an object, which must NOT interfere with one another or the object's base properties. >2: If, in a dataskin-derived ZClass class definition, I define a "common >instance" propertysheet, values in that propertysheet for instances get >stored in the ZODB just like any other ZClass instances' propertysheets. Not exactly. What happens is that __getattr__ never gets called for those attributes, so you can't have a provider give a value for them. __setattr__ and __delattr__ *do* get called, so if you modify those values on an instance, the providers will get called. However, since they never get called for attribute retrieval, you will never see the effects of the change. In short, "common instance" property sheets are *broken* with respect to DataSkins and should be avoided in favor of DataSkin propertysheets which are built so as not to have this problem. >However, if I define a "dataskin" propertysheet for my ZClass, I can >provide the content of these sheets to my ZClass instances using >AttributeProviders. Yes. >However, because of the way Attributes work, I cannot supply data for a >dataskin-propertysheet as a separate independent sheet object. The sheet >comes from the ZClass, the data comes from an Attribute Provider. Yep. To supply an independent sheet object, you need a sheet provider. And ZPatterns "out of the box" only includes a Persistent Sheet Provider, primarily to support WebDAV's requirement for adding arbitrary property sets. >3: If I want to use a SheetProvider, and thus use some of the important >features of ZPatterns, I need to use >object.propertysheets.manage_addPropertySheet() on each ZClass instance >that should have a sheet from a SheetProvider. One way of doing this is >with a Trigger. Yes. Another way is that if you write your own SheetProvider, you can define its _objectAdding() and _objectDeleting() methods to automatically create the sheet. Or, if existence of the sheet is predicated upon something else, you can simply answer the getSheet/getSheets() method calls by checking to see if that sheet exists, and if so, returning it. This is useful when, for example, you need to provide an object with a propertysheet that presents and/or updates data from a legacy database or other external system. >4: >> If you needed to add this atop a class which needed to >> be "final" (in the Java sense, i.e. no modifications allowed), then the >> best route would be a custom SQL sheet provider. > >..because the SQL sheet provider can provide sheets to ZClass-dataskin >instances, even though the original ZClass was not defined to have this >propertysheet. But I'd also have to add sheets to each applicablt >instance, as in learning point 3 above. Right, unless you write your sheet provider to just provide the sheet anyway. Sheet providers get asked what sheets are available for an object, and can simply provide some whether they've been "added" or not. The "manage_addPropertySheet" step is optional if you're creating custom sheet providers which can either add the sheet automatically, or have the sheet just always exist. ___ 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, Transactions, _register/_unregister
At 11:13 AM 8/14/00 +0200, Bob Pepin wrote: >Hi, >I've encountered some weird behaviour in the ZPatterns Transactional class when >I was trying to write a User Source for the Login Manager Product. > >I'm using Zope 2.2.0 with LoginManager 0.8.7a1 and ZPatterns 0.4.1snap1 > >The problem is that _unregister seems to be trying to delete the _v_registered >attribute of an object that doesn't have it set whenever I return None from >authenticateUser(). The weird thing is that the object seems to be >_register()ed and _v_registered appears to be set to 1 in _register(), but when >_unregister() is called it has the value 'None' again. > Hmmm. Just a thought, but, does your user source object change itself in any way during the transaction? It is possible that it is getting reloaded from the ZODB during transaction abort, and that would delete the _v_registered attribute and mess the whole thing up. Looking at your source code, I see that you are incrementing self.i in your dbg() method, which is called from other methods that would be active during the transaction, so this would produce the behavior you're seeing. Specifically, failing to authorize a user results in an Zope exception being thrown, causing the transaction to roll back. As part of the rollback, the ZODB will invalidate the in-memory state of your UserSource object (since it was changed during the transaction) and the _v_ attribute values are lost. Ironically, you could fix this by changing your debug code to use a _v_ attribute as well. Arguably this behavior is an architectural flaw in either Transactional or the way it is used in DataManager derivatives such as Rack and UserSource. I'll have to give it some thought, but the cure may be worse than the disease as I suspect it may require circular references. :( ___ 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 bug: Specialist does not implement _PropertySheetsFor(client)
At 09:23 PM 8/24/00 +0100, Steve Alexander wrote: >I'm using ZPatterns 0.4.1snap1. > >The LinkToParentProviders datamanager doesn't work properly because it >assumes that the Specialist it lives in has a _PropertySheetsFor(client) >method. > >However, Specialists (and DataManagers) don't provide this method. > >This stops /specialist/object/propertysheets/manage from working. It >also stops _v_currentSheets from returning all the sheets a Dataskin >might have. > >Phillip, is this fixed in your internal version? > >If not, I'll add the method over the weekend. > Ouch. That's not the problem. This is fallout from making DataSkins more "personally responsible"; the bug is in the propertysheet providers that expect to acquire from a parent. They need to be rewritten to work the way dataskins do now, or else configured to find the parent providers, and provide those instead. :( I'll have to take a closer look at this later. By the way, I've been away from the list a while due to day-to-day business concerns and travel. I'm hoping to start the process of catching up soon, but I saw this and since it's a bug I'm going to tackle it first before trying to answer any other unanswered questions that might be floating around out there. Sorry. ___ 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] LoginManager.
At 11:53 PM 8/20/00 +0200, Terje Malmedal wrote:
>
>I've written this, but it just does not work, all that happens is that
>it writes opened to /tmp/source.log
>
>class USER:
>"Just a little test"
>name= None
>roles = [ 'Anonymous' , 'member' ]
>domains = []
>
>def __init__(self, name):
>self.name = name
The above will not work, because UserSources *must* provide a user object
which subclasses from LoginUser.
>class SolidUserSource(BasicUserSource):
>
>""" Solid User Source """
>
>__plugin_kind__ = "User Source"
>meta_type = "Solid User Source"
>f = open("/tmp/source.log",'a',0)
>f.write("opened\n")
>
>#def __init__(id,title):
>#self.f.write("init %s %s\n" % (id,title))
>#self.id = id
>#self.title = title
>
>def existsUser(self, name):
>self.f.write('Users exists %s\n' % name)
>return 1
>
>def retreiveItem(self, name):
>
>self.f.write('Creating object for %s\n' % name)
>return USER(name)
Your retrieveItem isn't checking to see if the user exists. Also, you
spelled it "retreive" when the correct spelling is "retrieve".
>def rolesForUser(self, user):
>self.f.write('Returning roles for %s\n' % user.name)
>return user.roles
>
>def domainsForUser(self, user):
>self.f.write('Returning domains for %s\n' % user.name)
>return user.domains
>
>def authenticateUser(self, user, password, request):
>self.f.write('Authenticates user %s\n' % user.name)
>if user.name == 'aaa' and password == 'aaa':
>return 1 == 1
>return 1 == 0
These methods never get called because the code that calls them is in the
LoginUser class, which you have not subclassed your user from.
You may want to consider simply configuring a GenericUserSource; you can
always use ExternalMethods to do so. It is not so much that making a
custom user source is hard, as that it effectively requires an
understanding of how to subclass the ZPatterns "Rack" concept, and you may
not wish to expend that much effort simply to create a custom user source.
Once you've created a GUS that works as you wish, you can always subclass
GUS and hardwire your working methods into it, if your needs call for a
pure-python, quickly installable solution.
___
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: how to invalidate the attributecache?
At 04:32 PM 8/21/00 +0400, Jephte CLAIN wrote: >"Phillip J. Eby" wrote: >> I don't see a need for a mass invalidation operation, just more >> documentation on these inner workings. :) > >or the lack of an attribute depencies mechanism :-) >if attribute x depends on attribute y from another generic attribute >provider, invalidation of y doesn't make y to be recomputed. > You can do that with a custom attribute provider also. At this point, however, I have not run into a situation where I or my developers have needed that. In general, we have taken the approach that "dependencies (such as triggers, indexing, etc.) are only validated/executed at (sub)transaction boundaries." In other words, an approach in keeping with Zope's optimistic transaction approach. If there is enough demand, I might implement a SkinScript construct to specify code to be executed immediately after an attribute changes, or to (semi-)automatically invalidate dependent attributes. IMHO, however, I think this sort of situation is one to be avoided if at all possible, because dependencies have a way of becoming spaghetti (think complex makefiles). ___ 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] Porting EMarket to ZPatterns....
At 10:04 AM 8/22/00 -0500, Steve Spicklemire wrote:
>
>Moving this to ZPatterns brings up all sorts of questions. First of all I
no longer
>know that the actual class stored my shopper specialist is a 'Shopper'. It
could
>be any class kept in the shopper manager's rack(s). Soo... my addShopper
should
>probably become:
>
>def addShopper(self, id, REQUEST):
>""" add a new shopper... self is now the shopperManager (Specialist) """
>
>newShopper = self.newItem( id )
>
>
newShopper.propertysheets.methodToUpdatePropertySheetsFromMappingObject(
REQUEST )
Depending on how your framework specifies its requirements for a Shopper,
you probably want something like:
newShopper.propertysheets.get('shopperData').manage_changeProperties(...)
or
newShopper.manage_changeProperties(...)
or
if newShopper.propertysheets.manage_addPropertySheet(id='shopperData',ns=''):
newShopper.propertysheets.get('shopperData').manage_changeProperties(...)
else:
raise 'Unable to add propertysheet'
Notice that you must specifically ask for a particular sheet from the
propertysheets object before trying to change it. Also note that unless
you require users of your framework to make that sheet already available
when a newItem() is created, you must add the sheet yourself.
>Looking through VirtualSheets and PropertySheets code I see __propsets__
>so I was thinking something like:
>
>for prop in newShopper.propertysheets.__propsets__():
> setattr(newShopper, prop, REQUEST.get(prop,None))
Don't do this. __propsets__ is a private method and should not be touched.
If you must iterate through an object's propertysheets, use:
for sheet in newShopper.propertysheets:
...
Which will go through all of the object's property sheets, including
default sheets such as the object's main WebDAV property set.
>but this doesn't seem to work (I get 'nameError 'client'') in the
>debugger I have no clue where 'client' comes from, reminds me
This looks to me like a problem that someone else reported, and which I
fixed, but it's not fixed in a released version. :( See below:
Index: DataSkins.py
===
RCS file: /u/idsuser/REPOSITORY/ZProducts/ZPatterns/DataSkins.py,v
retrieving revision 1.49
retrieving revision 1.50
diff -r1.49 -r1.50
377c377
< l.extend(list(sp._PropertySheetsFor(client)))
---
> l.extend(list(sp._PropertySheetsFor(self)))
>of the 'DTML Method' argument called 'client'... but I don't see
>a traceback in the debugger.. anyway.. I've come to something like
>this, though it doesn't do what I need :
>
>newShopper = self.newItem(id)
>newShopper.passwd = passwd
>
newShopper.propertysheets.manage_addPropertySheet(id='EMarketProps', ns='')
>emp = newShopper.propertysheets.get('EMarketProps')
>emp.manage_addProperty('email', '', 'string')
>emp.manage_addProperty('name','','string')
>#
># ... blah blah blah...
>#
>emp.manage_changeProperties(REQUEST)
>self._setObject(id, newShopper)
Actually, this is the correct way to do it, if you are not requiring
shopper objects to have this sheet predefined and available for you. My
suggestion, though, is that you do just that (require the shopper objects
to support what you need).
>I am hopeful that this will expose a glaring misconception of mine
>about propertysheets. ;-) Someone please tell me how stupid I am
>and what I'm missing here... This does me no good... since I have to
>create the propertysheets and I want to allow for properties that
>I *don't know about* (i.e., customizations that individual
>applications need to make these 'shoppers' work as 'clients' or
>'memebrs' or whatever else...) Clearly I'm flailing here..
I don't see that you are. I don't see any problems at all here.
>Any ideas
>from the wizards of Z? How would you modify addShopper to make it
>work with other applications and allow for multiple propertysheets
>that need to be set up from the addShopperForm
I wouldn't do that. Actually, I think I now see what your actual problem
is. You're trying to implement a whitebox specialist as if it were a
blackbox specialist. A whitebox shouldn't have an add function unless you
want to make it possible for someone to use the whitebox without
customization. If someone wants to have clients (for example), they should
override your addShopperForm to redirect to an addClientForm in their
Clients specialist, and similarly override the other functions of your
Shoppers specialist to delegate to the Clients specialist.
>Also.. I'm hoping for some advice about the old 'Basket' object. Basically
>the old basked object was a simple container, one for each shopper, that
>held 'Basket Items' which were essentially references to MarketItems,
>that were on sale in the store, along with quantity, options, etc..
>How should I work these in with ZPatterns? Should there be
[Zope-dev] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
Hi folks. I'm working on a ZPatterns 0.4.2b1 release for the early part of the coming week, and intend to bug Ty into perhaps releasing an 0.9.0 beta later in the week. However, these versions are likely to have some (hopefully minor) compatibility issues with previous releases. Specifically: * We would like to drop support for Zope 2.1.x from here on out. I know at least one user has a production 2.1.x system, and I hate to strand them, but at least they can continue to use existing ZPatterns releases until their client can upgrade. Dropping 2.1.x support means that we may be able to get rid of DynPersist, which should be a big plus for ease of installation. It also means that we'll be able to start adding newer capabilities that take advantage of 2.2.x-isms such as getPhysicalPath()/restrictedTraverse(), etc. * We would like to drop support for Specialists directly containing data plug-ins. This feature was intended to allow for acquiring shared data plug-ins from within Racks, so that common attribute or sheet providers could be shared among Racks without copying. In practice, Ty and I have never once used this capability, and it could be easily replaced with the ability to "include" a SkinScript within another SkinScript, if we take advantage of 2.2.x-isms. * Related to the above, the "Link to Acquired Provider" and "Acquired ... Provider" objects would no longer be needed, since they exist only to make use of shared plug-ins contained in Specialists. We would remove these classes from ZPatterns, causing any existing instances to become "broken". Deleting these "broken" objects, however, would restore normal operations of the system. As you can see, all of these issues are somewhat interrelated. I wanted to post some advance warning of all this, so that if anyone has any objections, they would have a last chance to protest. :) The overall release plan at this point is that the only other major features planned in the 0.4.x series are content providers (mirroring virtual sub-objects from SQL, LDAP, or whatever) and local role providers (computation by an object of local roles applicable to a user). I do expect to add a few minor features in the way of easier SkinScript editing, and some hooks to allow help to be added to the management tabs which are auto-generated for PlugInGroups. The next big project will be documentation, now that the feature set and terminology is beginning to stabilize. ___ 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 bug with patch
At 10:22 AM 8/27/00 +0100, Steve Alexander wrote: > >I've fixed this by adding a test to the start of __set_attr__ of >DataSkins.py: > >def __set_attr__(self,name,val,_v_dm_=_v_dm_): >+ if name=='id' and val==self.__dict__['id']: >+ return >dm = self.__dict__[_v_dm_] This looks reasonable, and backward-compatible, since __init__ guarantees the dict will have an id. I'm not thrilled with adding more overhead to attribute setting, however, so I'll probably do it like this: try: dm = self.__dict__[_v_dm_] except KeyError: if name=='id' and val==self.__dict__['id']: return raise Hopefully this should only perform the extra computations when the first part fails... ___ 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] Compatibility issues: ZPatterns 0.4.2,LoginManager 0.9.0
At 11:04 AM 8/27/00 +0100, Steve Alexander wrote: > >I have been putting CatalogTriggers as DataManagers directly in >Specialists. > And this *works*??? None of the "Acquired ... Provider" classes supported forwarding to an acquired trigger, as far as I can recall. The fact that it's so bloody awkward to forward to acquired providers is part of why I think they should be dropped. Hmm... looking at source code... aha! Okay, so "Link to Parent Data Plug-ins" provides linking to triggers. I'd forgotten about that, obviously. Dang. >This seems to me the obvious place to do some triggering action that >applies over all the Specialist's racks, but which has nothing to do >with storage. Yes, it is. But it also adds to new user confusion, and leads to a bunch of otherwise-unnecessary code complication. In particular, Specialist wouldn't need to be a DataManager when it's really only a PlugInContainer. >I don't yet use SkinScript. However, I imagine there are a number of >uses for Triggers that apply at the level of abstraction of a >Specialist. Would it be an undue hardship to copy these into all the relevant racks or customizers, until there is a feature to allow inclusion from another rack or customizer? >Please think about keeping the feature, if it doesn't make things too >complicated. Basically, the problem is that I am trying to decouple delegation interfaces from the ZPatterns core. That is, I'm trying to make it such that DataManagers don't have to know about all the possible things that can be delegated to Data Plug-ins. That way, as additional plug-in capabilities are added, such as content providers and local role providers, the DataManager class doesn't change, since it's just an intermediary for *finding* those providers, and giving dataskins certain persistence-related services. Unfortunately, using items that link to acquired providers with any kind of filtering means that the link itself must provide some form of the interface which is being delegated, which means that the link must know about all possible interfaces. :( Now, I can provide *unfiltered* linkage by direct delegation, but this would mean dropping the ability to selectively take only certain attributes or sheets from the parent. But I suppose that, compared to dropping the capability to acquire altogether, this might be preferable. Hmmm. Let me think about this. ___ 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] BTreeFolder w/ Customizer support
At 09:24 AM 8/29/00 +0100, Steve Alexander wrote:
>Shane Hathaway wrote:
>
>> Bill Anderson wrote:
>> > Any chance at a BTree Folder w/customizer support in the near future? :)
>>
>> It should be quite easy to do. I vaguely recall Steve A or Steve S
>> might have done it.
>
>I want to include a BTreeFolder w/ Customizer support in the next
>release of DataSkinAddons.
>
>If anyone's done one, and you're happy for it to be included in
>DataSkinAddons, please let me know.
>
>Otherwise, I'll work on this later today.
>
>I've just produced a BTreeDataSkin:
>
>BTreeDataSkin is a DataSkin that is an ObjectManager.
>The ObjectManager stores subobjects in a BTree that is directly in the
>object (not stored in an attribute provider).
>On __getattr__, subobject ids are searched before the datamanager is
>asked to provide attributes.
>
If I may offer a suggestion... it would probably be a lot cleaner to
implement this as an AttributeProvider, and use the dataskin's "persistent
data slot" to store the b-tree. Otherwise, your b-tree contents can only
be used with DataSkins which are not stored "virtually" in a Rack. If you
use the slot API, it will work with any DataSkin. In other words, a
BTreeAttributeProvider which simply stores attributes in a persistent
BTree. Such a thing would be useful independent of the BTreeFolder user
interface and could work with any DataSkin.
Here's some code that implements a similar notion (using a dictionary in
the DataSkin's storage slot, rather than a BTree). It's from the version
of ZPatterns I'm currently working on.
eaKey = 'ZPatterns.AttributeProviders', 'ExternalAttributes'
class ExternalAttributeProvider(AttributeProvider):
"""
This attribute provider stores persistent attributes outside the object
itself, in its persistent 'slot'. This allows persistent attributes to
be used even with non-persistent DataSkins (e.g. those which are only
virtually stored in a Rack.
"""
def _AttributeFor(self,client,name,default=None):
return client._v_readableSlot.get(eaKey,{}).get(name,default)
def _SetAttributeFor(self,client,name,value):
"""Set the attribute and return true if successful"""
attrs = client._v_readableSlot.get(eaKey,{}); attrs[name]=value
client._v_writeableSlot[eaKey] = attrs
return 1
def _DelAttributeFor(self,client,name):
"""Delete the attribute and return true if successful"""
if client._v_changedAttrs_[name] is NOT_FOUND: del
client._v_changedAttrs_[name]
attrs = client._v_readableSlot.get(eaKey,{})
if attrs.has_key(name):
del attrs[name]
client._v_writeableSlot[eaKey] = attrs
return 1
# Class Metadata
meta_type='Persistent External Attribute Provider'
The code works by handling a persistent "slot". Currently, slots are used
only by Persistent PropertySheet Providers to store propertysheets. The
"_v_readableSlot"/"_v_writeableSlot" objects refer to a PersistentMapping
which is associated with the DataSkin. By convention, the entries in the
persistent mapping are keyed with a tuple that is the module name and
purpose of the entry. This is why things are written to
client._v_writableSlot[eaKey] -- eaKey is a constant that ensures that
other providers needing to use the slot for persistent storage will not
collide with it. You could probably take the code above, and, with some
adaptation, produce a BTreeExternalAttributeProvider which used a BTree in
place of a dictionary to store the attributes. You would need, of course,
to use a different constant tuple to key the slot.
_v_readableSlot always returns either a PersistentMapping, or an empty
dictionary if the DataSkin's slot has never been written to.
_v_writeableSlot always returns a PersistentMapping, ready to be written
to. Once _v_writeableSlot has been accessed even once, the slot exists and
_v_readableSlot will return the same PersistentMapping object as
_v_writeableSlot. This rather odd-seeming setup is to prevent accidental
changes to persistent storage when no changes have actually been made.
___
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 bug: Customizers don't rename well
At 07:32 PM 8/29/00 +0100, Steve Alexander wrote: > >To reproduce the error, do this: > > Create a Folder with Customizer support > Give it a Customizer > Rename that Customizer > Press the "Customizers" tab in the folder > >Zope Error > >Error Type: AttributeError >Error Value: __customizerRegistry__ What's happening is that the new manage_renameObjects (plural) function doesn't have a masking method in PlugInGroup. These masking methods serve to alter the URL base used for the management tabs, so that a PlugInGroup's management tabs will point to the parent PlugInContainer's methods, and not to nonexistent methods of itself. The resulting error is a harmless side effect of this URL confusion; you can simply click your way back into the right place and everything will work fine. Meanwhile, I'm adding the following method to the PlugInGroup class for the next release of ZPatterns: def manage_renameObjects(self, ids, new_ids, REQUEST=None): """Rename several sub-objects""" self.aq_inner.aq_parent.manage_renameObjects(id,new_ids) if REQUEST is not None: return self.manage_main(self, REQUEST, update_menu=1, URL=REQUEST.URL1+'/manage_workspace') This should fix the problem, although I have not yet tested that it in fact does so. ___ 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 bug: Compute instance has not _objectAdding method
At 04:13 PM 8/28/00 +0100, Steve Alexander wrote: >Zope 2.2.1, ZPatterns 0-4-1snap1, with some small patches. > >I'm adding a dataskin-derived ZClass instance underneath a Customizer >folder. > >The Customizer has a SkinScript plug-in. > >When I try to add a new ZClass instance, I get an exception that I can >trace to the fact that DataManager's _objectAdding method is trying to >call _objectAdding on a Compute object. > I actually fixed this problem about three weeks ago, but neglected to publish the code. :( In the latest version, all of the objects which the SkinScript compiler creates are derived from a class "NullProvider" which has empty methods for all the _objectXing events, including _objectChanging. Luckily, there is not much more to do for the new release (0.4.2b1) besides updating the release-related files, and perhaps a bit more work on improving the management screens for SkinScript methods. ___ 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] (CORRECTION) ZPatterns bug: Customizers don't rename well
At 06:15 PM 8/30/00 -0500, Phillip J. Eby wrote: > >Meanwhile, I'm adding the following method to the PlugInGroup class for the >next release of ZPatterns: > >def manage_renameObjects(self, ids, new_ids, REQUEST=None): >"""Rename several sub-objects""" >self.aq_inner.aq_parent.manage_renameObjects(id,new_ids) >if REQUEST is not None: >return self.manage_main(self, REQUEST, update_menu=1, >URL=REQUEST.URL1+'/manage_workspace') > That should actually say: self.aq_inner.aq_parent.manage_renameObjects(ids,new_ids) And I've now confirmed that it does indeed fix the URL messups. ___ 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 0.4.2a1 released
Mostly bugfixes and internal reorganizations, some very minor feature additions. This thing is finally beginning to stabilize a bit. Wish me luck on getting some time to document SkinScript... :) Meanwhile, my department is about to embark on a significant production product using ZPatterns, and I hope to funnel some of its design and/or code out as a ZPatterns example. Wish me luck on that, too. Anyway, 0.4.2a1 can be found in its usual place at: http://www.zope.org/Members/pje/ZPatterns/ ___ 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] Compatibility issues: ZPatterns 0.4.2
At 10:37 AM 9/1/00 +0100, Steve Alexander wrote: >Steve Alexander wrote: > >> Phillip J. Eby wrote: >> >> > Now, I can provide *unfiltered* linkage by direct delegation, but this >> > would mean dropping the ability to selectively take only certain >> > attributes >> > or sheets from the parent. But I suppose that, compared to dropping the >> > capability to acquire altogether, this might be preferable. >> >> >> This sounds fine for my use of Triggers that apply across everything >> that a Specialist manages. > >I've got ZPatterns 0.4.2a1 now. > >I see that Folders w/ customizer support now have their own >Data-plug-ins tab (they didn't before), and that it does direct >delegation, rather than filtered forwarding. Direct delegation? I've lost you here. If it's doing that, then something's broken. Check and see if you have any "Link to Parent Data Plug-ins" in your customizers (they're added by default now on new customizers). You can filter the parent providers by selecting the ones you want to leave out on the "exclude" property. >Does this mean that your suggestion above has become a design decision >for ZPatterns? Data plug-ins directly in Customizers and Specialists >aren't due to be deprecated? I'm guessing that this is the case. Argh. I knew there was something (else) I was forgetting to document in the CHANGES file. I had better go fix that now. >Also, it is a bit of a pain to refresh each of the DataManager instances >on each upgrade. How about an external method in ZPatterns to walk the >object tree and update instances as required? Perhaps it could use >ZopeFind. Or, seeing as Specialists and Customizer folders contain other >DataManagers, could you add a button to a tab in Specialists and >Customizer folders that refreshes them, and recursively all the >DataManagers they contain? Then I'd just have to go to each top-level >datamanager and refresh them when I upgrade. It isn't actually be necessary to refresh on every upgrade. IIRC, that note about refreshing is in reference to pre-0.4.x versions. I guess I need to fix that too... >Oh also, FYI, we're using ZPatterns for a couple of medium sized >projects, one of which is functionally complete. SkinScript has proved >extremely useful. I've been able to evolve an application in a very >clean way using propertysheets and SkinScript, whereas before I'd have >had to retrofit a custom base class. > >Phillip and Ty, thanks for your sharing your work and sharing your ideas. You're welcome. Since you've obviously managed to figure out how to code SkinScript just from my cryptic notes on the mailing list, and perhaps by looking at the grammar embedded in the compiler, do you think you could perhaps be persuaded to write a short reference and/or tutorial for us to include (perhaps as a help screen from the SkinScript method object's management screens)? Thanks. ___ 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 )
