Re: [Zope-dev] Re: Fixed reply Re: [Zope-dev] Trouble setting LoginManager default user class default user class
At 04:04 PM 5/18/00 -0400, Dan L. Pierson wrote: The portal now gets created, but I can't login to the initial account. I also can't display the members roster by clicking on Members (AttributeError for getUsers), but can write a DTML method in the UserSource that lists all one user. The code in DemoPortalBase that trys to display the roster follows, I suspect it's this bug again, but don't know where to put the __of__: Actually, the problem is probably that, as a DTML method, it expects to be passed its containing object as the first parameter. You might try using a PythonMethod, DTML Document, or an ExternalMethod instead. ___ 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: Re: [Zope-dev] ZPatterns framework improvements
At 03:51 PM 5/21/00 -0400, Tres Seaver wrote: This is really just the classic Observer pattern, a la GoF Design Patterns. "ObjectAdded" and "ObjectRemoved" are events a "RackObserver" would register for; "AfterCreate", "Changed", and "BeforeDestroy" are events of the "hosted" object itself. Note that "ObjectAdded" and "ObjectRemoved" would be called during move or rename operations, even though the object is not being created. Yes, but the DataManager will filter that such that Zope "Move" and "Rename" operations will show to Indexing and Rule agents as though they were just "Change" events. See the DataManagementEvents entry in the new ZPatterns Wiki for details on how this will work. ___ 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: rackmountables must be of-wrapped
At 05:33 PM 5/24/00 +0400, Jephte CLAIN wrote: Hello, I believe items got from a rack have to be wrapped in context of the rack. I've been bitten by this (and it hurts!). When I try to use items from DTML, only the superuser can use it, even managers can't access the objects. When I wrap the items in the context of the rack, everything is fine. So: retrieveItem, createItem use vanilla objects retrieveItem and createItem are not intended to be public methods; the only reason they don't begin with an "_" is that I wanted to make it possible for them to be implemented as DTMLMethods or PythonMethods. getItem, newItem wrap objects before returning them These are the API's you should be using, as they are the ones that tell the rackmountable what rack it belongs 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] Problems with LoginManager form-based login
At 05:24 PM 5/24/00 +0300, Itamar Shtull-Trauring wrote: "Phillip J. Eby" wrote: Make your root acl_users a LoginManager, with the loginForm there. LoginManager will only allow "Anonymous" to log in if it is the root acl_users. This is how standard user folders behave, and *have to* because of the way manage_workspace works, unfortunately. Until/unless a new login protocol is worked out in Zope, this is the workaround. But this user isn't even supposed to access manage_workspace - I just need it to access a PTK join_form so it can become a member. I tried making loginForm on the top level display a dtml method customLoginForm (which contains the actual form), and then override it in the PTK folder, but it doesn't - it displays the one on the top level. And I can't use the same loginForm in the whole site, because I may have few portals, and I need the login form to say "if you are not a member you can join here". Any ideas? This is a problem that apparently can only be solved by replicating ZPublisher's backward walk, which is the wrong thing to do because the traversal will be O(n^2). Bleah. I guess we'll have to do something like Stuart Bishop's backward walk in the GUF, since any enhancement of the ZPublisher architecture to handle login forms properly won't happen until at least 2.2. Meanwhile, I suppose Ty and I should try to come up with a proposal for revising ZPublisher to be able to walk back on the user lookups but still use the login form closest to the URL being accessed. ___ 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] Observer / Notification Interface Proposal
At 07:19 PM 5/24/00 -0400, Tres Seaver wrote: I have started a page for an implementation of the GangOfFour Observer pattern within Zope: URL http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificat ion Please comment, either here or in the wiki. Is this only for events occurring within a transaction, or across transactions? If across transactions, how do you intend to handle persistent references, acquisition, and cross-database references? (My suggestion would be to use a path to the callable.) Second, I think there should be an opportunity for the observer to specify more detail about what it wants to be called *for*. I.e., either a specific event or an event mask, to avoid unnecessary calls for irrelevant events. I realize this is all very implementation oriented, but that's me. :) (Oh, btw on "ObserverInterface", I'm guessing you mean the contract requires that *observable* not worry about delays, not the other way around.) ___ 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: rackmountables must be of-wrapped
At 01:56 PM 5/25/00 +0400, Jephte CLAIN wrote: When I don't wrap items like this, I get strange unauthorized errors. Only the super user can use the items. All the other users (Managers or not) can't. In normal usage, one only accesses a rack from or in a Specialist. Specialists wrap the objects in the context of the specialist for you. I've just checked the code, however, and notice that Specialist.__bobo_traverse__ does this wrapping, not Specialist.getItem, so I will fix this in the next release. That way, calling getItem on the Specialist will ensure you have proper context. Patch follows... Index: Specialists.py === RCS file: /u/idsuser/REPOSITORY/ZProducts/ZPatterns/Specialists.py,v retrieving revision 1.7 diff -u -r1.7 Specialists.py --- Specialists.py 2000/05/18 05:24:49 1.7 +++ Specialists.py 2000/05/25 12:57:35 @@ -1,7 +1,6 @@ from PlugIns import PlugInGroup from DataManagers import DataManager from Globals import HTMLFile, default__class_init__ - _marker = [] @@ -23,7 +22,7 @@ if ob is _marker: ob = self.getItem(name) if ob is not None: -return getattr(ob,'aq_base',ob).__of__(self) +return ob raise 'NotFound' return ob @@ -32,7 +31,8 @@ return self.retrieveItem(key) # XXX need DTML check? for rack in self.rackList: item = rack.__of__(self).getItem(key) -if item is not None: return item +if item is not None: +return getattr(item,'aq_base',item).__of__(self) def newItem(self, key=None): """Create a new item""" ___ 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] Observer / Notification Interface Proposal
At 12:45 AM 5/25/00 -0400, Tres Seaver wrote: Ah, ok -- I was planning simply to leverage the ZODB's facilities for maintaining persistent references in the DefaultObservable mix-in; more elaborate schemes would be possible (for instance to support rack-mounted observers?) Actually, just using a plain reference might cause you some problems. If you don't strip off the acquisition wrapper, you'll pickle the entire acquisition tree for the subscriber, including the REQUEST and RESPONSE objects. But if you *do* strip off the wrapper, you'll call the observer without its acquisition context, causing security and possibly other problems. I would suggest using object paths, ala ZCatalog, since this fixes these problems as well as cross-database and outside-the-ZODB references. Also, it takes care of being able to pass Python-level methods as observers, since you can't pickle a direct reference to a method. The references don't have to be de-referenced unless an event actually occurs, although the high cost of de-referencing objects (even without using a path) does suggest to me that observers should at least register some kind of channel name or list of names, to prevent needless reactivations. Unless, of course, the idea is for "subjects" to not subclass Observable directly, but rather to have various "event" subobjects which are callable observables. Calling an "event" object could fire it, relaying the event to the subscribers, who would subscribe to the individual event sub-object, rather than to the main "subject" object. An interesting side-effect of this approach is that it allows one to create a subclass of "event" that can be added to any ObjectManager subclass. One could also create another subclass of event as a methoid for use in class/ZClass definitions. This subclass would store its subscription data in its parent object, allowing the event object itself to be shared across instances of the class. Still another interesting possibility is the idea that event objects could define their own calling parameters, and optionally relay those to the observers, which would allow a more interesting dataflow. In the work I've been doing on my SWARM project, workflow Plan objects have a collection of Event objects which were planned to work similarly to this, but a bit more complex. Event objects were going to have Properties, and Plans also had "Roles" (relationships to a workflow instance) which effectively were the subscribers of the events. Role objects receive all event firings, and selectively forward or transform them for their "audience" (the objects in that relationship to the workflow instance). Plans and Phases could also have Forms which were effectively input forms for the properties of an Event. Last, but not least, calling the Event object with property data would create an "event instance" object which would have methods for such things as "don't process this event further", and which would contain all the data for that firing. All that is probably overkill for this interface, but the basic idea of callable "event" sub-objects which are subscribed to by observers is I think a useful pattern to apply here. ___ 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] Resource Discovery (was Observer / Notification Interface Proposal) Proposal)
At 10:03 AM 5/26/00 +1000, Anthony Baxter wrote: "Phillip J. Eby" wrote I would suggest that it ask for an interface, rather than a meta_type. Otherwise, you've hardwired yourself into a single object type with no extensibility. For example, an SQL method wants the nearest SQL connection, but shouldn't have to explicitly ask for each kind of SQL connection (Sybase, Oracle, etc.) In that case, would you have a matching call in the observer objects where they can specify what it is that they offer? Rather than basing it on type, you'd say 'find the nearest resource that wants to know about blah'. I would say that resource discovery is orthogonal to event subscription, and that if you were discovering resources for the purpose of sending them events, you should search for an interface that lets you query whether that object wants to receive events. :) In practice, however, doing resource discovery for event subscriptions is backwards. If you have a Catalog or some other thing that wants to subscribe to events below it, it should subscribe to events from containers to know when things are added, (including sub-containers, which it could also subscribe itself to) then subscribe to the objects themselves whenever it's notified of an add. Having "catalog aware" objects look for a catalog doesn't make sense in the context of an event-driven system. Objects need only generate change events, and containers need only generate add/delete events. The rest can be done by the Catalog or other observer. Notice, by the way, that a Catalog that worked this way would be extremely flexible; you could specify persistent rules for what kinds of objects would be "found into" the Catalog, and you could dynamically add/remove the catalog's hooks from various folders, "pruning" its "search" scope. The catalog itself would hold no references to the objects which send it events, but could wander far and wide over the database. At this point it's really tempting to take a whack at adding an event system to ZPatterns based on the models discussed so far, except for the fact that I'm rather behind on getting its more modest event management system finished, *and* the fact that Zope doesn't really have a robust traversal interface at the moment. If 2.2 ends up with a solid traversal system, I will certainly be willing to take a look at it. One interesting interplay between ZPatterns events and Zope events, is that ZPatterns triggers (aka RuleAgents) could be used to set up rules which fire events on managed objects. This would allow one to wrap custom events and subscriptions around any DataSkin-based object instance, without the skin's class having to have been designed to send those events. An interesting idea, indeed. ___ 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] Problems with LoginManager form-based login
At 03:05 PM 5/26/00 -0400, Evan Simpson wrote: - Original Message - From: Phillip J. Eby [EMAIL PROTECTED] Been there, done that. Yours doesn't work either, btw. Well, actually, it does, it's just that it causes a memory leak because it leaves an unintended circular reference. We've got a version that fixes the circular reference, but in a really really ugly way (it does a run-time patch to BaseRequest.close() to remove the poked-in unauthorized() method). The GUF version, at least, doesn't need this drastic a fix. Adding the following line to the top of guf_unauthorized should suffice: del request.RESPONSE.unauthorized You're making the assumption that unauthorized gets called. If it doesn't get called (because the current user *does* exist in a higher-level folder), then the hook will never get released. ___ 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] Problems with LoginManager form-based login
At 06:14 PM 5/26/00 -0400, Evan Simpson wrote: D'oh! How 'bout if REQUEST.close() were to always do a self.__dict__.clear()? Are you absolutely positively sure that REQUEST.response is never accessed following REQUEST.close()? In my cursory examination of the code paths, I wasn't sure that could be definitively said. ___ 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] CatalogAwareness for RackMountables
At 12:53 PM 5/30/00 +0300, Itamar Shtull-Trauring wrote: I've been playing around with ZPatterns, and I must say it's very cool - finally you can mix ZCatalog and SQL storage. CatalogAwareness is slightly different than regular Zope objects in that you have to find the ZCatalog in the Rack's acquisition path, but that's about it. IMHO, you don't need to keep referring to self._v_rack to do the cataloging as described, so long as you retrieve your objects from a Specialist; then the acquisition path is via the Specialist. I would suggest that you modify your patches somewhat to reflect this, and use only self.* attributes, not self._v_rack.*. It will improve your forward-compatibility with 0.4.0. The absolute_url function I define here should be moved to the RackMountable class since it may be useful in other situations. I have to disagree with this, since the standard Zope absolute_url method will work correctly, so long as you access a RackMountable by traversing (via bobo_traverse) from a Specialist. If you would like to make your work easier with version 0.3.0, it would be best for you to move the __of__ wrapping from Specialist.__bobo_traverse__() to Specialist.getItem(), as I have done in the working copy of 0.4.0. This will ensure that whenever you retrieve a rackmountable from a Specialist, it will be wrapped in context of the Specialist. Then, by deriving your classes from RackMountable and CatalogAware, you need only adjust for the absence of add and delete hooks. And you'll only need to adjust for that until 0.4.0 makes add/change/delete hooks available for indexing agents. I don't know if there will be a Catalog IndexAgent released with 0.4.0 yet, but there should be one eventually (or perhaps someone will contribute one). ___ 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: ZPatterns complexity?
At 01:40 PM 6/2/00 +0800, Mike wrote: As I'm reading ZPatterns source code more and more I'm finding there are good things just hidden in unclean or bad defined interfaces. Just a suggestion: define interfaces as abstract classes first, then implement them (as AbstractRack, DefaultRack and GenericRack for example). I might back interfaces out later. But while the whole thing is still a prototype it doesn't make a lot of sense to keep two going. Originally, Rack itself was a base class, but the way things are shaping up it will only need subclassing if you want a custom way of mapping from a mountable's "id" to the persistent data stored by the Rack. told 'mess' I meant I spent a lot of time to realize the Rack do not store RackMountables but just manages them. That was the whole point of Rack; this has been mostly addressed on the mailing list, in my talk/slides at the Python conference, and in the ZPatterns wiki. The second thing confusing me is property sheets. They come from problem domain isn't it? I guess attribute providers are sufficient to do all the work. What that sheets needed for? Two things. 1) WebDAV support requires the ability to add arbitrary property sheets containing arbitrary data. 2) Propertysheets (especially when used with XML namespace URL's) give a way of standardizing an interface to common properties, without polluting an object's "main" namespace. This way, one can take an object that wasn't designed for a certain purpose, and attach a propertysheet that serves as an adapter to give it a different interface to its data. Consider the scenario of a scheduling application that creates calendars, or manages resource contention. But you would like to use it with say, a "room" object that was not written as part of the scheduling application. If the scheduling application can just add a scheduling propertysheet to the room object, or you can configure the room objects' datamanager or rack to add a propertysheet that makes it usable with the scheduling application, then you get to benefit from two unrelated frameworks (room management and scheduling). This is a core intent of ZPatterns: making it easy to blend frameworks that cover different behavioral aspects and problem domains. Because real world objects have a funny way of being part of more than one "problem domain" from a software development point of view. :) And one more thing I would to say. I agree the RackMountable should not be acquisition-aware because Attribute providers have full responsibility on its (acquired) attributes. But I do not like default Specialist.__bobo_traverse__ behavior. It is trying to make __of__ on thing which is not an Acquisition.Implicit by definition! Good point. __of__, however, is not limited only to acquisition. In any case, I have moved the __of__ call to the Specialist.getItem() method in 0.4.0. In 0.4.0 DataSkins (the replacement for RackMountables) include an __of__ method in their base class, as this is where they figure out their controlling DataManager (when retrieved from something other than a Rack). Thus, with 0.4.0 it is not necessary to include Acquisition.Implicit in a RackMountable's base classes. ___ 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] LM 0.8.6 w/CurrentCVS failure
At 01:51 AM 6/2/00 -0600, Bill Anderson wrote: "Phillip J. Eby" wrote: [...] LM 0.8.6 also works with Zope 2.2 as far as being able to be added, although I'm not sure it interoperates properly with the new security API. It will still be backward compatible with Zope 2.1.6 either way, though. Hmmm ... just tried it on a fresh (Thursday) CVS dump, and get a no-go: Error Type: KeyError Error Value: _owner Thanks for the heads-up, but it worked with the current CVS as of the release of 0.8.6. It's going to be a little while before we can take a whack at it again. 2.1.6 is our primary development platform for both ZPatterns and LoginManager. When we do releases, we check them against the latest CVS of Zope for compatibility, but it's something of a pain as we have to do a certain amount of conditional coding to deal with the presence or absence of 2.2 API's. This is more a problem with LoginManager, although ZPatterns is about to have some conditional code added to work with Jim's new __get/set/delattr__ support (which, if it works, would mean the DynPersist module would not be required for 2.2). ___ 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] Externalize or Adapt? (ZPatterns)
At 06:31 PM 6/10/00 +0800, Mike wrote: Maybe the best way is to put a 'thumb' data source into Customers instead of native one. This thumb should translate all messages to SkyDivers' data source. Yes, a "Delegation Rack" is certainly possible. It would make it really easy to merge data from different specialists; just drop in more than one. I suppose you could even make the DelegationRack have an expression to use to translate from the ID asked for in the horizontal specialist, to the kind of ID used by the vertical specialist, perhaps by using a search function of the vertical specialist. I'm just considering on specialized racks which implement non-standard api, such as 'findItem( criteria)', 'itemValues()' or something similar. By the way, racks should have a kind of 'scanning' api, like Zope's Folders, at least they should have itemIds() method. This is waiting for indexes and predicates; which won't hit until 0.5.0. Meanwhile, I'll add a getPersistentItemIDs() method to Rack in 0.4.0. This will not get you the id of all possible items in the rack, since you might be using SQL or some other kind of storage. It will only get the items which have data or propertysheets in the ZODB. Currently, the correct way to have 'scanning' API's is to implement them on your Methods tab using SQL methods, LDAP methods, or whatever is appropriate for your dataset. In 0.5.0 or later, hopefully there'll be some sort of plug-in API for that. ___ 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 )
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] 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 FORM METHOD="POST" ACTION="manage_setStorage" --- FORM METHOD="POST" ACTION="." 56c56 brINPUT TYPE="SUBMIT" value=" Change Storage Settings" --- brINPUT TYPE="SUBMIT" name="manage_setStorage:method" value=" Change Storage Settings" 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 )
[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 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 )
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 )
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
dtml-if "CHANGED('attr1')"
attr1=dtml-var "object.attr1",
/dtml-if
...
WHERE primary_key='dtml-var "object.id" sql_quote'
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] 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 )
[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] 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:
dtml-unless sequence-end,/dtml-unless
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 -
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] 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: 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". snip! 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] 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] 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 value',
message='Password and confirmation must be specified',
action ='manage_main')
-if self.getUser(name) or (name==self._super.getUserName()):
+
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,
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] 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: dtml-with "getItem(key='whatever key you have in the specialist')" dtml-raise /dtml-raise /dtml-with 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] 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: 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] 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 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 a BasketManager
for each shopper that is
[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] 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 )
[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] But I used __ac_permissions__! :S
This is just a SWAG (Strategic Wild-Ass Guess), but Ty and I have been
having a problem with the search feature in Squishdot 0.7.0 that seems
possibly to be related. Our trace of the problem shows that catalog
searches from the SquishSite return objects which are wrapped with a
*different* acquisition hiearchy than the SquishSite itself or from the
User object it's trying to check roles on. Thus, *even though* the user
has the right roles, user.allowed() disallows the roles as invalid because
they're being granted from a (seemingly) different hiearchy.
What we found is that ZCatalog uses the older REQUEST.resolve_url() method
to access the "true" objects, which has this side effect. If it used the
new 2.2 traverse methods, the acquisition hierarchy would be the same. As
it stands, the objects returned by ZCatalog.getobject (by way of
SquishSite.__call__) even have different REQUEST objects than the original
REQUEST object for the web hit.
Does this sound like it's anything related to the problems you're having?
At 05:00 PM 9/1/00 +0100, Chris Withers wrote:
Brian Lloyd wrote:
Here's a quick thing to try- if 'subject' is an attribute
of your Article class, try adding:
class Article(...):
subject__roles__=None
then restart and see if you still get unauthorized...
yup, I do :-(
And besides, 'subject' is already in __ac_permissions__, as you can see:
(a lot of stuff snipped out though ;-)
__ac_permissions__ = (
('View', ['subject','getThread'], ('Anonymous', 'Manager')),
)
and I do appropriate Globals.default__class_init__'s...
Man, I really have no idea, and not even any clue where to look.
The big factor seems to be that 'subject' is a string. I had a similar
problem with the SquishFile class with the 'icon' attribute.
When it was a string:
# protected by 'View' permission
icon = 'misc_/Squishdot/squishfile_img'
..even though it was a class variable and protected in
__ac_permissions__, I was getting very similar errors to the above...
I was lucky, in that case, because it was a class variable, I could turn
it into a method:
# protected by 'View' permission
def icon(self):
return 'misc_/Squishdot/squishfile_img'
..and, lo and behold, no more security errors from there... :S
Unfortunately, the string attributes in the Article class are instance
attributes, not class attributes, so I can't do the same thing :-(
Any ideas?
cheers,
Chris
___
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 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] PlugIns.py bug.... (was incorrectly ZPatterns: transaction bug)
At 08:46 AM 9/5/00 -0500, Steve Spicklemire wrote: OK I think I found the actual intent of aq_base() in _checkId of PlugIns.py: ... it comes from the ObjectManager _checkId which has basically the same code execpt it ObjectManager.py also has the needed: from Acquisition import aq_base Fixed in my CVS. 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] ZPatterns (sub-)transaction problems
At 01:41 PM 9/14/00 +0100, Steve Alexander wrote: I think there's something not quite right about the way ZPatterns is handling subtransactions, even with this patch, and the other one related to Transactions.py that I posted a while back. Is there any detailed documentation about how Zope transactions and subtransactions are supposed to work? Unfortunately, the problem is not with Zope but with ZPatterns. I was about to announce this today anyway, but I figured I might as well do it by replying to your post. The ZPatterns transaction machinery is seriously broken with respect to subtransactions. It is mostly functional with respect to "plain" transactions. It has been broken since its inception due to a design stupidity on my part. Under pressure to get a working 0.4.0 system, I started coding without a fully thought-out design for the transaction handling system, and changed it midway two or three times before I got something that (basically) works. I did not discover the flaws until yesterday, when Ty tried to use subtransactions in a to-be-production application. An hour or so of debugger-stepping and Zope-source-reading later, we were able to fix the code to allow a single subtransaction commit to succeed, but *only* if no work were done following the subtransaction commit. sigh I will try to have a ZPatterns snapshot release made this week that will include those fixes (plus the fix for a problem with DynPersist that we also discovered yesterday). It should be noted, however, that the resulting release will still not be good for much with respect to subtransactions. I am in the process now of redesigning the entire transaction machinery to correct the problems. On the bright side, I have already seen how the redesign will simplify the code of several classes, while possibly improving both performance and memory usage. ___ 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: ZPatterns (sub-)transaction problems
At 03:56 PM 9/14/00 +0100, Steve Alexander wrote: Can we lose DynPersist altogether for this release? Unfortunately, no. Zope's cPersistent class appears it may have a bug that is roughly similar to the one we're fixing in DynPersist. (i.e., not calling __of__ or other binding operations on an object returned from __getattr__) I've written Jim to ask whether my interpretation of that code is correct, but have not received a reply. It may take a new Zope release before DynPersist is able to go away. :( Or are there still folks out there using ZPatterns with 2.1.6? Support for 2.1.x was officially dropped with ZPatterns 0.4.2a1, but in practice most of the support code is still there today. It's just that I've stopped testing on 2.1.x and no longer write code with 2.1.x compatibility in mind. The re-architecting of the transaction machinery will *require* 2.2.x's transaction ordering semantics. ___ 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.2a2 bug fix release
It's up now. In addition to the transaction fixes and DynPersist fix, this release also fixes the missing import of aq_base in PlugIns.py, and the SkinScript compiler fouling up certain expressions due to its removal of spaces between tokens. Last, but not least, you can now place Specialists inside other Specialists without getting an error. At 03:56 PM 9/14/00 +0100, Steve Alexander wrote: "Phillip J. Eby" wrote: I will try to have a ZPatterns snapshot release made this week that will include those fixes (plus the fix for a problem with DynPersist that we also discovered yesterday). Great. I'm looking forward to that. ___ 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.2a2 bug fix release
At 05:39 PM 9/14/00 +0100, Steve Alexander wrote: Phillip J. Eby wrote: It's up now. In addition to the transaction fixes and DynPersist fix, this release also fixes the missing import of aq_base in PlugIns.py, and the SkinScript compiler fouling up certain expressions due to its removal of spaces between tokens. Last, but not least, you can now place Specialists inside other Specialists without getting an error. According to diff, there is no difference between DynPersist.c in the latest release, and DynPersist.c in 0-4-2a1. The dates on the files are both Apr 26 too. Oops! It's fixed now. Everyone please note that the correct file size for ZPatterns-0-4-2a2.tgz is 47,811 bytes, not 47,756. Sorry about the mix-up; Ty and I missed a few files in the tagging process prior to generating a 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 bug: infinite recursion with External Attribute Provider
At 09:18 PM 9/17/00 +0100, Steve Alexander wrote: ZPatterns-0-4-2a2 When I use an External Attribute Provider, I get an infinite recursion problem, and Zope hangs. Argh. This is what happens when I create a new feature on the spur of the moment and toss it in just before a release. :( This is because DataManager (in DataManagers.py) uses normal getattr() and object.__skinSlot__ methods to get and set the special attribute __skinSlot__ on DataSkins. Yes, that clearly should be fixed. This works, in as far as I can do things like add sub-objects to a ZClass that derives from DataSkin and ObjectManager without infinite regress. However, I still get an attribute error. This is because the External Attribute Provider only offers to set and delete its attributes. I'm confused as to why this should be -- surely the External Attribute Provider should offer to get the same attributes as it is offering to set and delete? Yes, it should, and that's my own stupid implementation error. I forgot to include code for that. :( I'll do another update release this week to fix this and the other problem you reported (w/link to parent providers). You might want to report the list vs. string behavior on that one to the Collector, since that does indeed sound like a Zope bug to me. IMHO, multi-select properties ought to be tuples anyway, but they certainly should never be a string. ___ 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] ZSQL Methods from Python?
At 08:43 AM 9/22/00 -0400, Jim Fulton wrote: Also, does anyone know of any work done to extend ZSQL Methods to allow stored-procedure calls? No, but I'd love to see someone tackle it. The semantics of stored procedures varies so widely accross databases, that I doubt that it would be easiliy generalizable. I think, at least for starters, a form of stored procedure support for Oracle would make alot of sense. Ty and I have put together a Stored Procedure method for Sybase; it requires a minor patch to ZSybaseDA, however, to allow for the status code return. I'm not sure how useful it would be to anyone else, though, since all we ever do with stored procedures is process the return value, and ignore any actual SELECT results. ___ 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] ZSQL Methods from Python?
At 12:49 PM 9/22/00 -0400, Jim Fulton wrote: "Phillip J. Eby" wrote: Ty and I have put together a Stored Procedure method for Sybase; it requires a minor patch to ZSybaseDA, however, to allow for the status code return. I'm not sure how useful it would be to anyone else, though, since all we ever do with stored procedures is process the return value, and ignore any actual SELECT results. I think it would be useful. Can you get multiple return values? By "return value", I mean the "return status" code which is an integer returned by the Sybase "RETURN" statement. Sybase also can generate its own, negative-numbered return statuses, which indicate a Sybase error. These error codes can include ones that mean the current transaction has already been aborted. Apart from the "return value", a Sybase stored procedure can execute SELECT's which result in rows being returned. We have never used this capability, so I'm not sure what would need to be done for it to be practical. We ordinarily use stored procedures only to perform inserts, updates, deletes, and other things that only need a integer result if anything. (Eg: get next counter value to assign an object identifier.) ___ 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] How is 'retrieveItem intended to work with TTW Specialists?
At 08:00 AM 9/25/00 -0500, Steve Spicklemire wrote: So my retrieve item gets called. *unfortunately* it gets called without any namespace parameter... so my retrieveItem DTML method has no way to acquire a namespace so that it can delagate to something else! So... here is what I did... I defined a method in my Python subclass of Specialist.. class MarketItemManager(ZPatterns.Specialists.Specialist): """A Market Item Manager""" # Specify a name for the item type: meta_type='MarketItemManager' def retrieveItem(self, key): """ get an item""" return self.__of__(self).delegateRetrieve(self, None, key=key) Then I made a DTML method called 'delegateRetrieve' like so: dtml-return "myGreatSite.ThingManager.getItem(key)" this way, my integrator can edit 'delegateRetrieve' to point to whatever Specialist he wants to... and I have a Python implementation of retrieveItem. Does this sound OK? Am I working way too hard here? (I feel like I am! ;- ) Remember in the code where I have "# XXX DTML check?" That's because I was anticipating your problem, but since I didn't personally need to do what you're doing yet, I didn't implement it. For one thing, I was waiting to see if Zope core method binding would get fixed. Unfortunately, I'm not sure that Zope method binding is going to be available for anything but PythonMethods in 2.3. As of right now, however, you should be able to use a PythonMethod for retrieveItem, rather than a DTML Method, and it should work. In short, even now, delegateRetrieve should not be necessary. You should be able to implement retrieveItem using a PythonMethod or a DTML Document rather than a DTML Method. (I say *should* because I have not tried it personally.) ___ 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] Skinscript tutorial. How's it going?
At 06:33 PM 9/29/00 GMT, [EMAIL PROTECTED] wrote: Just wondering if there is a new time frame. FWIW, I have begun writing a SkinScript reference document on the ZPatterns Wiki. Lots of sections are just outlines at the moment, but it's already much better than any other available information on SkinScript (like my meanderings on the list and in chats). ___ 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 )
