[Zope-dev] ToDoManager ZPatterns example not working
Hi, I installed the ToDoManager/ToDoProduct example (http://www.zope.org/Members/sspickle/DumbZPatternsExample ) but it won't work. System is RedHat 6.1, Zope 2.2.2, ZPatterns-0-4-2a3. I get the following traceback when I try to view /ToDoManager/index_html. Is it a bug somewhere or a problem with my installation? Error Type: AttributeError Error Value: _setRack Traceback (innermost last): File /opt/Zope-2.2.2-linux2-x86/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /opt/Zope-2.2.2-linux2-x86/lib/python/ZPublisher/Publish.py, line 187, in publish File /opt/Zope-2.2.2-linux2-x86/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: ProviderContainer) File /opt/Zope-2.2.2-linux2-x86/lib/python/ZPublisher/Publish.py, line 171, in publish File /opt/Zope-2.2.2-linux2-x86/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: index_html) File /opt/Zope-2.2.2-linux2-x86/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: index_html) File /opt/Zope-2.2.2-linux2-x86/lib/python/OFS/DTMLDocument.py, line 177, in __call__ (Object: index_html) File /opt/Zope-2.2.2-linux2-x86/lib/python/DocumentTemplate/DT_String.py, line 528, in __call__ (Object: index_html) File /opt/Zope-2.2.2-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 691, in renderwob (Object: defaultRack.getPersistentItemIDs()) File /opt/Zope-2.2.2-linux2-x86/lib/python/DocumentTemplate/DT_Let.py, line 147, in render (Object: currID="_['sequence-item']") File /opt/Zope-2.2.2-linux2-x86/lib/python/DocumentTemplate/DT_With.py, line 133, in render (Object: getItem(currID)) File /opt/Zope-2.2.2-linux2-x86/lib/python/DocumentTemplate/DT_Util.py, line 337, in eval (Object: getItem(currID)) (Info: currID) File , line 0, in ? File /opt/Zope/lib/python/Products/ZPatterns/Specialists.py, line 34, in getItem (Object: ProviderContainer) File /opt/Zope/lib/python/Products/ZPatterns/Rack.py, line 60, in getItem (Object: ProviderContainer) File /opt/Zope/lib/python/Products/ZPatterns/Rack.py, line 114, in retrieveItem (Object: ProviderContainer) File /opt/Zope-2.2.2-linux2-x86/lib/python/OFS/Uninstalled.py, line 110, in __getattr__ (Object: broken) AttributeError: (see above) -- Itai Tavor"Je sautille, donc je suis." C3Works[EMAIL PROTECTED] - Kermit the Frog "If you haven't got your health, you haven't got anything" ___ 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 questions
Steve Spicklemire wrote: > > Again.. this is an embarrassingly trivial example.. but here it goes: > [snip details] > That's it. I can't imagine anything simpler. ;-) Really! Thanks, I'll be trying this out at work tomorrow. Michael Bernstein. ___ 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 questions
Again.. this is an embarrassingly trivial example.. but here it goes: First of all there is a ZClass 'ToDoClass'. It needs to have a base class of ZPatterns:DataSkin. You don't need constructor methods, but I don't think they hurt anything if you leave them in. The ToDo needs methods: index_html to render itself like any ZClass: -- Name&dtml-id; Description&dtml-description; Doer&dtml-doer; Done?Done!&dtml-done; Last Modified&dtml-bobobase_modification_time; Edit this instance Back to list -- editInstanceForm so folks can edit its contents... (just like any ZClass) -- Edit ToDo Item Name&dtml-id; Description&dtml-description; DoerNobody selected>&dtml-sequence-item; Done?checked> -- a method that actually does the changing of the properties... (just like...) editInstance -- ToDo Changed. -- That's it for the methods of the ZClass...we can view/edit instances TTW. Now.. we need propertysheets: Basic: (Now it's a "Data Skin Attribute Property Sheet"). properties: description (text) doer (string) done (boolean) Shared: (This is a propertysheet that's meant to be shared by all the instances. If you update this... update it in the ZClass, not an instance.) doers (lines) Finally... we need methods for the ToDoManager (Specialist): We'll set the defaultRack of the ToDoManager up to store its objects persistently, using the ToDoClass we just created as the storage type. We can just leave the default data plugins installed since they work fine with persistent storage. If later you want to experiment with other storage methods, you can do it making almost no changes to any other code (with the possible exception of defaultRack.getPersistentItemIds() which might not be appropriate if you're not using persistent ZODB storage) Here is the default method of the ToDoManager... basically, pull out the objects and view a brief list of ids, descriptions doers, and doneness... : -- NameDescriptionDoerDone? Done! Sorry.. no "to do"s! -- We also need to be able to add and delete items from the rack: newToDoForm: -- Add New ToDo ToDo Name ToDo Description -- addNewToDo: -- Thanks for the new ToDo! deleteInstances: -- Deleting Instances -- That's it. I can't imagine anything simpler. ;-) Really! -steve > "Michael" == Michael Bernstein <[EMAIL PROTECTED]> writes: Michael> Steve Spicklemire wrote: >> Ack.. of course I forgot to test creating new >> instances there was a snippet of code for editing and >> creating that didn't work with the new propertysheet stuff. I >> fixed it just now... so it really works. ;-) Michael> I didn't get a chance to play with this today, but I'll Michael> make time to do so tomorow. How easy would it be for you Michael> to write a step-by-step HowTo/WalkThrough of creating the Michael> example? I can edit it and flesh it out if you can write Michael> a bare-bones version. Michael> Thanks, Michael> Michael Bernstein. ___ 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] intersection of ZCatalog queries on the same index
Michel Pelletier <[EMAIL PROTECTED]> wrote:
> Catalog.searchResults({'food', ['foo', 'bar']})
^
I think you meant a : there?
> would find all of the objects whose food property contained both 'foo'
> _and_ 'bar'.
This is not returning the intersection but the union. At least for me.
On the other hand, full-text searches appear to handle a phrase
like 'foo and bar'.
--
Neil Kandalgaonkar <[EMAIL PROTECTED]>
Web Application Developer, ActiveState
___
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: [Zope] Re: [Zope-dev] cookies & ie5.5 win
I had a problem like this once, and worked out that it was because the system time was incorrect in IE somehow. The time that windows was displaying was correct, but that had been manually changed to take in to account day light savings which started early in Australia this year due to the olympics. But for some reason internallyIE was using the wrong time, so my cookies were expiring as soon as they were set! Netscape on windows didn't have the same problem...and obviously netscape on linux didn't have the problem. terry Chris Withers wrote: > Sebastian Luehnsdorf wrote: > > i'm having a strange problem with cookie based user authentication with > > ms internet explorer 5.5 on windows. it seems that the browser (but only > > this version and only under windows!) seems to "forget" its cookies, which > > results in an immediate logout. does anybody have similar experiences or a > > even solution? > > I've had this problem occasionally with other versions of IE. > I wonder whether you're setting the path on cookies correctly? > > That's all I can think of... > > Anyone else noticed this? > > cheers, > > Chris > > ___ > Zope maillist - [EMAIL PROTECTED] > http://lists.zope.org/mailman/listinfo/zope > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope-dev ) -- - Terry Kerr ([EMAIL PROTECTED]) Adroit Internet Solutions http://www.adroit.net/ 03 9563 4461 0414 708 124 ___ 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 questions
Steve Spicklemire wrote: > > Ack.. of course I forgot to test creating new instances there > was a snippet of code for editing and creating that didn't work with > the new propertysheet stuff. I fixed it just now... so it really > works. ;-) I didn't get a chance to play with this today, but I'll make time to do so tomorow. How easy would it be for you to write a step-by-step HowTo/WalkThrough of creating the example? I can edit it and flesh it out if you can write a bare-bones version. Thanks, Michael Bernstein. ___ 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] Thank you very much SteveS for your efforts and the working zpatterns example.
I'd love to bask in the glory of having done something really significant. but just remember... it *is* the Worlds Simplest (some might say Dumbest) example! ;-> -steve > "James" == James Johnson <[EMAIL PROTECTED]> writes: James> At last some meat AND potatoes for us feely touchy zpattern James> people. It opens up a whole new can of worms that I will James> take _fishing with me this weekend. Long live Steve James> Spicklemire! James> Get your Free E-mail at http://tacoma.zzn.com James> James> Get your own Web-Based E-mail Service at http://www.zzn.com James> ___ Zope-Dev James> maillist - [EMAIL PROTECTED] James> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross James> posts or HTML encoding! ** (Related lists - James> http://lists.zope.org/mailman/listinfo/zope-announce James> 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 )
[Zope-dev] Thank you very much SteveS for your efforts and the working zpatterns example.
At last some meat AND potatoes for us feely touchy zpattern people. It opens up a whole new can of worms that I will take _fishing with me this weekend. Long live Steve Spicklemire! Get your Free E-mail at http://tacoma.zzn.com Get your own Web-Based E-mail Service at http://www.zzn.com ___ 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] intersection of ZCatalog queries on the same index
Neil K wrote:
>
> If there a way to get ZCatalog to give me intersections of results on a
> single index? All the examples and tutorials I've seen are union (OR)
> queries.
>
> Basically I just want ZCatalog to give me items where keywords contained
> both 'foo' and 'bar'.
You should use a Keyword Index for this. If your KW index was named
'food' and all your objects had a 'food' sequence attribute, then:
Catalog.searchResults({'food', ['foo', 'bar']})
would find all of the objects whose food property contained both 'foo'
_and_ 'bar'.
> I have browsed through Catalog.py and it seems like it might be possible.
> Disclaimer, I'm pretty new to Zope & python.
In the general case, it's not possible without redesigning Zope's
catalog query language (which implicitly ORs all index queries
together). For the special case of keywords, use a keyword index.
-Michel
___
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] intersection of ZCatalog queries on the same index
If there a way to get ZCatalog to give me intersections of results on a single index? All the examples and tutorials I've seen are union (OR) queries. Basically I just want ZCatalog to give me items where keywords contained both 'foo' and 'bar'. I have browsed through Catalog.py and it seems like it might be possible. Disclaimer, I'm pretty new to Zope & python. -- Neil Kandalgaonkar <[EMAIL PROTECTED]> Web Application Developer, ActiveState ___ 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 questions
Ack.. of course I forgot to test creating new instances there was a snippet of code for editing and creating that didn't work with the new propertysheet stuff. I fixed it just now... so it really works. ;-) -steve > "Steve" == Steve Spicklemire <[EMAIL PROTECTED]> writes: Steve> OK.. here's the dumbest example I could cook up. It was my Steve> first experiment with ZPatterns in July of last summer. It Steve> was based on a really early release, I don't remember Steve> which, but it seems to work with the latest.. (I just Steve> barely testted it... ) Load the Product ToDoProducts.zexp Steve> into the products folder first, then the ToDoManager into a Steve> folder in Zope. Steve> http://www.zope.org/Members/sspickle/DumbZPatternsExample Steve> -steve Steve> ___ Zope-Dev Steve> maillist - [EMAIL PROTECTED] Steve> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross Steve> posts or HTML encoding! ** (Related lists - Steve> http://lists.zope.org/mailman/listinfo/zope-announce Steve> 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] Acquisition/cDocumentTemplate bug
Sorry ignore me, I thought I was being bitten by this bug, but Im not. It was the old difference between and in someone else's dtml. - Original Message - From: "Andy McKay" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 05, 2000 1:07 PM Subject: Re: [Zope-dev] Acquisition/cDocumentTemplate bug > Does anyone know of any progress on this bug its marked as "pending" in the > Collector, so I guess not. > > http://classic.zope.org:8080/Collector/1441/view > > - Original Message - > From: "Shane Hathaway" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, July 20, 2000 6:29 AM > Subject: Re: [Zope-dev] Acquisition/cDocumentTemplate bug > > > > Oleg Broytmann wrote: > > >Anyone is working on it? Should I put this into Collector or Tracker? > > > > Already there. The Zope project manager is gone for the week. > > > > Shane > > > > > > > > On Mon, 17 Jul 2000, Shane Hathaway wrote: > > > > This is an excellent bug analysis. I suggest that we create a new > > > > PyCallable_Check function that works in the presence of wrappers, > > > > perhaps called PyCallable_CheckW(). If it is placed in Acquisition.c > > > > then cDocumentTemplate.c will have to #include "Acquisition.h". Then > > > > we need to replace PyCallable_Check in probably more than just > > > > cDocumentTemplate. > > > > ___ > > 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 ) > ___ 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] Acquisition/cDocumentTemplate bug
Does anyone know of any progress on this bug its marked as "pending" in the Collector, so I guess not. http://classic.zope.org:8080/Collector/1441/view - Original Message - From: "Shane Hathaway" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, July 20, 2000 6:29 AM Subject: Re: [Zope-dev] Acquisition/cDocumentTemplate bug > Oleg Broytmann wrote: > >Anyone is working on it? Should I put this into Collector or Tracker? > > Already there. The Zope project manager is gone for the week. > > Shane > > > > > On Mon, 17 Jul 2000, Shane Hathaway wrote: > > > This is an excellent bug analysis. I suggest that we create a new > > > PyCallable_Check function that works in the presence of wrappers, > > > perhaps called PyCallable_CheckW(). If it is placed in Acquisition.c > > > then cDocumentTemplate.c will have to #include "Acquisition.h". Then > > > we need to replace PyCallable_Check in probably more than just > > > cDocumentTemplate. > > ___ > 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] RFClarification: Security on Product Attributes
"Phillip J. Eby" wrote: > > At 12:27 PM 10/4/00 -0400, Brian Lloyd wrote: > > > >I've verified (any of my previous comments to the contrary) that > >simple attributes (python types) do not really play in the > >permissions machinery. The canonical way to expose such things > >for now is to expose them through method calls (which can play > >in the permissions scheme). > > > > IIRC, this stuff got broken by the switch to the new security machinery. > ZopeSecurityPolicy doesn't check 'foo__roles__' on the parent object the > way ZPublisher does/did. It never did. Before the switch to the new policy machinery, most attributes that don't have roles were unprotected. Now, we at least have a way to make some assertions. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. ___ 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] RFClarification: Security on Product Attributes
Chris Withers wrote: > > Hi, > > If I have the following lines in a Python Product: > > def __init__(self, id): > """initialise a new instance of product""" > self.id = id > self.title = 'Title!' > self.anInt = 0 > self.aString = 'testing' > > Are these attributes protected by the security machinery? > If so, how so? Yes. There are two ways of protecting objects, depending on whether they (can) have a __roles__ attribute. None of the values above can have a __roles__ attribute, so they are covered by assertions made in their containers. See http://www.zope.org/Members/michel/Projects/Interfaces/ZopeSecurityPolicy Note that if you can't adequately control something that can't have __roles__, you can provide an access function (e.g. getAnInt), which you can control > Can I read them? I think the answer is yes for anInt and no for aString. Probably, if you can get at one, you can get at the other. > Don't know the mechanics of title and id, I'm guessing they're going to > be special cases whatever... Nope, except that we may provide separate accessors (e.g. getId). > Are they protectable by permissions? I do hope so although my experience > is that, at best, it's not necessary, which is contrary towhat I thought > the new security policy was. The goal of the new security policy was to: - Centralize authorization policies - Begin the tightening of access to attributes/sub-objects that can't have roles. > Should they have to be protected by permissions? Probably... If you need the sort of control that permissions provide, you should consider providing accessors that can play with permissions. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats. ___ 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 questions
OK.. here's the dumbest example I could cook up. It was my first experiment with ZPatterns in July of last summer. It was based on a really early release, I don't remember which, but it seems to work with the latest.. (I just barely testted it... ) Load the Product ToDoProducts.zexp into the products folder first, then the ToDoManager into a folder in Zope. http://www.zope.org/Members/sspickle/DumbZPatternsExample -steve ___ 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] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!
Hi Phillip
First of all... please forgive the long message. When I started
it was going to be a quick note... now it's turned into a bit
of a novel... but you don't have to read it all. ;-> I'm spewing all
this out in part to illustrate some of the things I've done 'wrong'
so that others might not go down that road... and also... your
reaction (if any) to some of the random thoughts popping up here
and there would be most welcome... anyway.. here goes
OK.. I think this makes sense.. (hmm.. how's *that* for a statement of
supreme confidence!)
> "pje" == Phillip J Eby <[EMAIL PROTECTED]> writes:
pje> As for set/get methods, we usually just define DataSkin
pje> property sheets in the ZClass, and use permission mappings to
pje> define the read/write permissions for each sheet. We group
pje> properties in sheets according to the domain model
pje> permissions for access. Then the domain logic methods in the
pje> ZClass call propertysheets.sheetname.manage_changeProperties() with
pje> keyword parameters to set things. Usually, we have domain
pje> specific methods that alter the values of multiple attributes
pje> at the same time, using the property sheets. We rarely have
pje> code outside of the ZClass directly manipulate attributes.
pje> In instances where we've needed to set attributes which are
pje> of types not supported by Zope propertysheets, we've had to
pje> use ExternalMethods or something similar. In the long run we
pje> expect to be able to use PropertyHandlers to do this without
pje> dropping down to Python.
OK.. let me just make sure I'm understanding you correctly.
You're not using propertysheet providers, but DataSkin propertysheets
'installed' in a ZClass that directly inherits from DataSkin. Your use
of the "Data Skin Attribute Property Sheets" is primarily to associate
permissions with groupings of attributes, and to simplify
establishment and management of those properties through the ZClass
administrative interface. As a bonus, you get 'free' methods needed to
adjust these attributes from DTML (i.e., manage_changeProperties) without
requiring custom PropertyHandlers.
I did notice that when I create a ZClass (in a completely different
project) that inherits from a Python Product (registered with
registerBaseClass) that inherits from DataSkin, I don't get the option
of a DataSkin propertysheet, in the 'common' container of the ZClass,
so there's probably some manual fiddling I need to do when I register
my ZClass base class that I'm not doing...
I'm guessing that the code that defines the SkinZISS, SZHolder, and
_ZClass_for_DataSkin culminating in registerZClass perform the
necessary magic to make that happen
Aha! I just found part of the magic in "ProductContext.py"
lib/python/App/ProductContext.py
This is deep magic! But I think I see that you are up to:
>From DataSkins.py:
class SZHolder:
""" """
def __init__(self):
ZClassSheets.__init__.im_func(self)
self.common=SkinZISS('common')
class _ZClass_for_DataSkin:
propertysheets = SZHolder()
_zclass_ = DataSkin
manage_options = ()
def initialize(context):
context.registerZClass(_ZClass_for_DataSkin)
So you set up SZHolder to pose as a 'propertysheets' attribute of the
ZClass (I'm guessing that im_func(self) is to get around the 'unbound
method' ExtensionClass problem.). Then your 'hand creating' the
_ZClass_for_DataSkin rather than using 'registerBaseClass' You're also
overriding the ZClass 'common' collection of propertysheets with one
that will allow both 'regular' ZClass propertysheets, and also
Dataskin propertysheets.
Sooo... if I want my DataSkin subclass to have the same ability
I'll need to do something similar? (just replace _zclass_ = DataSkin
with _zclass_ = MyDataSkinSubclass?)
This of course begs the question... why do I want to subclass
from anything other than DataSkin in the first place?
Well.. my *new* strategy (I'm using this on EMarket) is to put all the
core logic in a Specialist subclass... and let my DataSkins be
ZClasses that are directly subclassed from __ZClass_for_DataSkin. This
has its own problems (I still have a hard time working in a
'specialist' on a method that is supposed to be acquired by a
DataSkin, and keeping track of who 'self' is and what properties I can
really get to etc...). But in my last project I hadn't figured all that out,
so I originally made a layered system something like this:
Thing.py
--
try:
#
# if we're running in Zope.. this will work and we can inherit
# from OFS.Folder
#
from OFS.Folder import Folder
from Products.ZPatterns.DataSkins import DataSkin
class FlexBase( DataSkin, Folder ):
pass
except:
#
# if we're testing stand-alone... we can just subclass from an empty class
#
class FlexBase:
def
[Zope-dev] Is it possible for a simple dtml/ttw only zpatterns example?
Is it too complicated? Seems to me it would help out alot of people and help to further the cause. I'm starting to get the feeling that some people are not willing to share in their success. By keeping it complicated and jargon filled prevents me from be able to use it. Is this suppose to be in the spirit of open source? Get your Free E-mail at http://tacoma.zzn.com Get your own Web-Based E-mail Service at http://www.zzn.com ___ 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 design questions
I don't think its possible at this point for a working dtml/ttw example. Several people have asked for a simple dtml/ttw only zpatterns based working example, but none of the people who are "getting" Zpatterns finds the time to write a simple example. I'm not sure I know what I'm talking about either. So much for Zen. I think that the flatdatabase product might be a good example for a python based zpatterns framework. http://www.zope.org/Members/itamar/FlatDatabase. I heard that it's possible to have a dtml only zpatterns based example. I would like something like Product specialist addObj Zclass index_html readObj Factory Permission Would this be a correct way to proceed? Get your Free E-mail at http://tacoma.zzn.com Get your own Web-Based E-mail Service at http://www.zzn.com ___ 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 ownership bug!
Jonas Juselius wrote: > > Another thing which I have tried to do, is to add support for local roles to > the LoginManager. At first it looked rather simple, but then I realized that > it wasn't really _that_ simple, and dropped it because I don't have time... It > would however be nice to have local roles support in the LoginManager, as it > would make it more complete. > > I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and > LoginManager-0_8_7a1. I used Membership 0.7.6 on top of what you've got, and added support for local roles as detailed in this posting: http://lists.zope.org/pipermail/zope-dev/2000-September/007030.html This ought to give you the clues you need to add the neccessary getUserNames method to a SQL User Source, and make the LoginManager user_names modification as well. If you have any ideas on how to generalize the user_names method, I'd like to hear them. Let me know how it goes, Michael Bernstein. ___ 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 questions
"Phillip J. Eby" wrote: > > At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote: > > > >While I wouldn't say that there has been an actual 'paradigm > >shift' between the original RIPP presentation and ZPatterns, > > What's happened is that there's been a lot of "implementation shift". The > goals of RIPP have never changed, but they are far from being all available > in convenient form in the ZPatterns implementation of that model. [snip] - we've > implemented less than half of RIPP at this point. Ok, That's what's been confusing me. I was thinking that at least some of the missing functionality was due to a change of goals. > >I'm sufficiently confused at this point to ask for an > >explanation (with definitions and a *simple* example) of > >your current thoughts on separating 'domain code' from > >'implementation code', both of which still need to be > >separated from 'presentation code' (DTML interfaces), unless > >I'm mistaken. Please assume I'm asking a lot of 'why' > >questions along the way. > > Domain logic: methods which implement the basic behavior of an object, by > manipulating its attributes and by calling methods on itself or other > objects. (Including delegation to a Specialist, its own or another.) > > Presentation logic: "view" methods which implement user interface by > displaying object attributes and/or the results of either presentation or > domain methods, and "controller/view" methods which call domain logic > methods and display results. > > Implementation logic: All of the code and objects contained in a Specialist > which map between the domain model of an object and its physical storage > implementation(s). This category can be further subdivided into data > management implementation, and UI implementation. > > DM implementation deals with storing and retrieving objects and associated > data, and firing off of implementation rules (e.g. ensure that all objects > which meet such-and-such criteria are cataloged in catalog Foo). > > UI implementation deals with providing snippets suitable for use by > collaborating classes and/or specialists. For example, [snip] How (and why) do you distinguish between UI implementation and presentation logic? > Our current practice is to place both domain and presentation logic in > ZClasses, [snip] Do domain and presentation logic methods go into the *same* ZClass, or separate ones (I realize that this may be a stupid question)? > dropping down to ExternalMethods or Python bases for the ZClasses > when domain logic requires things you can't do in DTML or PythonMethods. > Domain and presentation logic are kept to seperate methods, so that domain > logic methods can be re-used for XML-RPC or other programmatic interfaces. > Presentation is usually done in a flexible way, relying upon UI > implementation hooks where sensible. (Since objects under a specialist > acquire from the specialist, it's easy to hook to a specialist-level > utility method.) I understood what you were saying until the parentheses. Could you repeat that part in a different way? > We have not yet released any actual frameworks based on ZPatterns, [snip] Isn't LoginManager a framework? > >I'm familiar with the convention of separating 'data' from > >'business logic' from 'presentation logic', but this new > >four-way separation (storage, domain, implementation, UI) is > >confusing the heck out of me. > > There's really only three: Presentation, Domain, and Implementation. These > largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing > UI snippets into the DM/SI part, simply because that's the locale for > customization/integration. (In general, we do not assume that placing more > than one kind of thing together as neighbors in the same place is a > problem. It's what things *reference* that makes their implementation > clean or dirty, not necessarily who their neighbors are in the Zope object > tree.) Ok. That makes some more sense. (still working on the Zen, though) > >I know that both of you (Phillip and Ty) are very busy > >right now, but could you perhaps give us a few short > >installments? Starting at the beginning (wherever that is), > >of course. > > How's the above for a beginning? Great! Now I need a really stupid-simple example. Something that could have been implemented trivially by using Zope's built in objects, maybe a ZClass, and a bit of DTML, like a list of press releases, or a FAQ, or a company directory. Something *really* simple, so I can see how it's done with ZPatterns. Thanks, Michael Bernstein. ___ 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] Trying to catch up - what are the best Zope tools today?
Itai asked: > "I started reading about ZPatterns but I still can't get my head > around it... I'm wondering if I should try to learn it fast enough > for this project, or stick to what I already know. What in people's > experience is the typical learning curve for ZPatterns? How much am I > going to have to figure out to be able to build support for SQL > storage? FYI ZPatterns has been a rapidly moving target, but it's looking pretty solid now, and a few folks have managed to wade in and make sense of it already. There's even some documentation at : http://www.zope.org/Members/pje/Wikis/ZPatterns/HomePage Most of the discussions you'll see on this list between Steve Spicklemire and Phil Eby / Ty Sarna are directly related to the next rev. of EMarket, which will be based on ZPatterns. If you think the flexibility that comes from a cleanly implemented Object Pattern will be worth the learning curve, ZPatterns is just about there now. The "how" of storing data in an RDBMS, accessed with ZSQLMethods is no different with ZPatterns. The real difference is "who" does the storage and retrieval. This is the concept of the "Specialist" object, which "knows" all about the specifics of the data and storage implementation. In any case, get to know ZClasses and PythonMethods, which may not have been ready for prime time, or even released, last time you looked. Those will be useful no matter which direction you choose. Later, Jerry 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 )
[Zope-dev] Accessors for DataSkin attributes (was Re: [Zope-dev] Success!Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTWSpecialists? Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists?
At 06:57 AM 10/5/00 -0500, Steve Spicklemire wrote: > >This brings up another point If I choose 'DataSkin' as a storage >class, then my code hits the security system every time a refer >to any data (simple types) stored directly in the DataSkin. I can either >set __allow_access_to_unprotected_subobjects=1 on each instance, >or I can write accessor methods for each attribute, (yuk!, but >maybe good in some ways...) or I can ask the integrator to create >'dummy' ZClass(es) even for those racks that they don't want/need >to customize (which seems to 'get around' the security system.) >I'm curious to know what you folks do here.. do you write accessor >methods for every type stored in your DataSkins? We never use raw DataSkins, first off. We always create a domain-specific ZClass subclassed from DataSkin. In your case, I would suggest simply including such ZClasses with your product to provide the default implementation of your domain and presentation logic. As for set/get methods, we usually just define DataSkin property sheets in the ZClass, and use permission mappings to define the read/write permissions for each sheet. We group properties in sheets according to the domain model permissions for access. Then the domain logic methods in the ZClass call propertysheets.sheetname.manage_changeProperties() with keyword parameters to set things. Usually, we have domain specific methods that alter the values of multiple attributes at the same time, using the property sheets. We rarely have code outside of the ZClass directly manipulate attributes. In instances where we've needed to set attributes which are of types not supported by Zope propertysheets, we've had to use ExternalMethods or something similar. In the long run we expect to be able to use PropertyHandlers to do this without dropping down to Python. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Success! Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists? Specialists?
Yes.. I see what you mean... this is a 'whitebox customization' that I used as part of the integration of my framework into the 'online catalog' system. This is not 'blackbox' code that is integral to my system In fact, I mis-spoke earlier, it's not in my specialist at all... it only appears in a method of a ZClass that I use as the 'storage class' for objects controlled by one of my specialists this is clearly whitebox territory, since this wrapper is chosen by the integrator... The first thing my docs (will) say to do.. is go through all my specialists and choose 'storage' classes for each specialist. This brings up another point If I choose 'DataSkin' as a storage class, then my code hits the security system every time a refer to any data (simple types) stored directly in the DataSkin. I can either set __allow_access_to_unprotected_subobjects=1 on each instance, or I can write accessor methods for each attribute, (yuk!, but maybe good in some ways...) or I can ask the integrator to create 'dummy' ZClass(es) even for those racks that they don't want/need to customize (which seems to 'get around' the security system.) I'm curious to know what you folks do here.. do you write accessor methods for every type stored in your DataSkins? Anyway.. thanks for the great tools! I'm having fun now. ;-) -steve > "Phillip" == Phillip J Eby <[EMAIL PROTECTED]> writes: Phillip> At 09:15 PM 10/4/00 -0500, Steve Spicklemire wrote: >> This was also nice since in my Specialist I could do things >> like: >> >> > "RESPONSE.redirect(this().theRealThing.absolute_url())"> >> >> After the user is finished working in my 'app area' they could >> get redirected back to the actual object that my Specialist was >> 'posing' for... Phillip> I don't really recommend the above, unless it's being Phillip> done by SkinScript. Otherwise, you're unnecessarily Phillip> exposing an implementation attribute (theRealThing). Phillip> Instead, require that your object implement a redirect() Phillip> method, and define it in the class as Phillip> "class_default_for_redirect". Then you can override the Phillip> method in SkinScript or with a class extender (a new Phillip> 0.4.3 feature). Doing it this way means your framework Phillip> code will not incorporate an assumption that your Phillip> whitebox specialist is always going to be wrapping Phillip> someone else's objects. ___ 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 questions
At 09:49 PM 10/4/00 -0700, Michael Bernstein wrote: > >While I wouldn't say that there has been an actual 'paradigm >shift' between the original RIPP presentation and ZPatterns, What's happened is that there's been a lot of "implementation shift". The goals of RIPP have never changed, but they are far from being all available in convenient form in the ZPatterns implementation of that model. That's why ZPatterns' version number is so low - we've implemented less than half of RIPP at this point. Meanwhile, along the way we came up with better ways to do things than we had in our first round of ideas. For example, before we thought of Attribute Providers, we assumed that PropertyHandlers were necessary to implement RIPP designs successfully. And before we thought of SkinScript, we assumed that AttributeProviders would be custom written for different types of databases. And so on. This has caused a lot of shifts in the details of our recommended implementation practices, even though the design philosophy for RIPP applications has not actually changed in the slightest. All that's happened is that implementing such applications is now far easier than Ty or I would have dreamed possible a year ago when we began to formulate the RIPP concepts. (Even though we still haven't got all of RIPP available and occasionally suffer for the lack of some bits like PropertyHandlers.) >I'm sufficiently confused at this point to ask for an >explanation (with definitions and a *simple* example) of >your current thoughts on separating 'domain code' from >'implementation code', both of which still need to be >separated from 'presentation code' (DTML interfaces), unless >I'm mistaken. Please assume I'm asking a lot of 'why' >questions along the way. Domain logic: methods which implement the basic behavior of an object, by manipulating its attributes and by calling methods on itself or other objects. (Including delegation to a Specialist, its own or another.) Presentation logic: "view" methods which implement user interface by displaying object attributes and/or the results of either presentation or domain methods, and "controller/view" methods which call domain logic methods and display results. Implementation logic: All of the code and objects contained in a Specialist which map between the domain model of an object and its physical storage implementation(s). This category can be further subdivided into data management implementation, and UI implementation. DM implementation deals with storing and retrieving objects and associated data, and firing off of implementation rules (e.g. ensure that all objects which meet such-and-such criteria are cataloged in catalog Foo). UI implementation deals with providing snippets suitable for use by collaborating classes and/or specialists. For example, in the DropZone example, the billing sub-application would probably delegate the user interface for presenting a "find customer" form to the Customers specialist, which would contain an appropriate HTML snippet. "Out of the box", that specialist would contain a default find-customer form provided by the creator of the billing framework, and it would be the job of the application integrator to override it to fit the overall application. Our current practice is to place both domain and presentation logic in ZClasses, dropping down to ExternalMethods or Python bases for the ZClasses when domain logic requires things you can't do in DTML or PythonMethods. Domain and presentation logic are kept to seperate methods, so that domain logic methods can be re-used for XML-RPC or other programmatic interfaces. Presentation is usually done in a flexible way, relying upon UI implementation hooks where sensible. (Since objects under a specialist acquire from the specialist, it's easy to hook to a specialist-level utility method.) We have not yet released any actual frameworks based on ZPatterns, but if we were to do so, we would probably also define many UI methods as "class_default_for_X" so that end users could override them with a Class Extender in their Rack or Specialist, without having to subclass our classes. We do not have any "best practice" recommendations in this area as yet, since we haven't had to tackle a project of this nature so far. >I'm familiar with the convention of separating 'data' from >'business logic' from 'presentation logic', but this new >four-way separation (storage, domain, implementation, UI) is >confusing the heck out of me. There's really only three: Presentation, Domain, and Implementation. These largely correspond to Coad's UI, PD, and DM/SI, although we're also mixing UI snippets into the DM/SI part, simply because that's the locale for customization/integration. (In general, we do not assume that placing more than one kind of thing together as neighbors in the same place is a problem. It's what things *reference* that makes their implementation clean or dirty, not necessarily who their neighbors
Re: [Zope-dev] Success! Was: Re: [Zope-dev] How is 'retrieveItem intended to work with TTW Specialists? Specialists?
At 09:15 PM 10/4/00 -0500, Steve Spicklemire wrote: > >This was also nice since in my Specialist I could do things >like: > > > >After the user is finished working in my 'app area' they could >get redirected back to the actual object that my Specialist >was 'posing' for... I don't really recommend the above, unless it's being done by SkinScript. Otherwise, you're unnecessarily exposing an implementation attribute (theRealThing). Instead, require that your object implement a redirect() method, and define it in the class as "class_default_for_redirect". Then you can override the method in SkinScript or with a class extender (a new 0.4.3 feature). Doing it this way means your framework code will not incorporate an assumption that your whitebox specialist is always going to be wrapping someone else's objects. ___ 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] RFClarification: Security on Product Attributes
"Phillip J. Eby" wrote: > > IIRC, this stuff got broken by the switch to the new security machinery. > ZopeSecurityPolicy doesn't check 'foo__roles__' on the parent object the > way ZPublisher does/did. Can anyone say why? cheers, Chris PS: Will the new new security stuff (still in proposal stage, IIRC) start checking this stuff again? ___ 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] AttributeError: __call__
Chris, Ofcourse, the phenomina disappeared abruptly. However, I intend on using 2.2.2 again within minutes, so I will post a detailed message if the phenomina occurs again. Regards, Knight [EMAIL PROTECTED] On Thu, 5 Oct 2000, Chris Withers wrote: > > > knight wrote: > > > > I just installed a fresh copy of 2.2.1 also, and I'm getting the same > > issue. Any items starting with a subfolder has a __call__ AttributeError. > > What do you mean by 'starting with a subfolder'? > > Can you give some exampels and a full traceback? > > 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] Strange Error - in collector yet?
Lalo Martins wrote: > > This is on Zope 2.2.1. I'd really appreciate some clues on how > to bust these ghosts. Have you put a full description in the bug collector yet? 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 )
Re: [Zope-dev] AttributeError: __call__
knight wrote: > > I just installed a fresh copy of 2.2.1 also, and I'm getting the same > issue. Any items starting with a subfolder has a __call__ AttributeError. What do you mean by 'starting with a subfolder'? Can you give some exampels and a full traceback? 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] LoginManager ownership bug!
Hola, There seems to be a problem with the ownership model in Zope (or ZPatterns). The problem is the following: I have implemented a nice login system based on the LoginManager and SQL methods. I would like to make this acl_users the top level user folder, but... then hell brakes lose... The problem has to do with the ownership of the acl_users. When the LoginManager (acl_users) is created it sets the _owner attribute to UnownableOwner. This is fine, for if the acl_users folder is owned it results in various errors: Excessive recursion or ValueError: unpack list of wrong size (when logging in), IndexError: list index out of range (when trying to view ownership info of acl_users). This has to do with the top-level folder being unowned, it seems. There is no problem with the LoginManager being owned in a folder which is owned itself. The problem is that the acl_users folder becomes _owned_ (by whom I don't know) every time Zope is restarted, or when any method is edited or added in the acl_users folder. It seems that the _owned attribute is not persistent, or that something, somewhere changes it. I have a dirty fix for the moment, consisting of an external method which sets the ownership of acl_users to UnownableOwner. This is however a far from satisfying solution... Another thing which I have tried to do, is to add support for local roles to the LoginManager. At first it looked rather simple, but then I realized that it wasn't really _that_ simple, and dropped it because I don't have time... It would however be nice to have local roles support in the LoginManager, as it would make it more complete. I am currently using Zope-2.2.1 (and Zope-2.2.2), ZPatterns-0-4-2a1 and LoginManager-0_8_7a1. Best regards, .jonas. -- *** Jonas Juselius e-mail...: [EMAIL PROTECTED] voice: +358 9 191 40188 P.O. Box 55/ Department of Chemistry GSM..: 040 506 6599 FIN-00014 University of Helsinki fax..: +358 9 191 40169 FINLAND http://www.iki.fi/jonas Home address: Helsinginkatu 16 B 42 tel..: +358 9 753 3369 00500 Helsinki FINLAND *** [ GPG public key: http://www.iki.fi/jonas/pubkey.asc ] ___ 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 )
