[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] 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
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] 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 )
