Re: [Zope-dev] PythonLibraries Product

2003-09-11 Thread Dan L. Pierson

--On Thursday, September 11, 2003 10:08:23 -0400 Fred L. Drake, Jr. 

Tres Seaver writes:
  Actually, the restricted case is the one which has the real win;  the
  free-floating library is pretty, but not semanticaally needed.  An
  added argument:  a ZPT with its own private library becomes, in effect,
  a Zope3 view component;  adopting such beasts will ease migration to
And it keeps all the pieces easy to locate!  +1

There are a few ways to approach serialization of a view that contains
both a template and Python code:
- Serialize it as a directory containing two files.
IMHO, this is the obvious and probably best choice.  It's well in line with 
a sentiment
in the the Linux file system world that the way to handle multi-piece files 
is to treat them
as directories rather than introduce another layer of special mechanisms. 
The file sytem
itself can them optimize their storage as part of a general small file 
optimization strategy.
I don't think the objection to having to pack a ZPT and it's script(s) in a 
separate ZODB
folder applies anywhere near as well to file system storage.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation

2003-06-19 Thread Dan L. Pierson

--On Thursday, June 19, 2003 10:07:52 +1000 Adrian van den Dries 

I'd advise against installing Zope library files into site-packages
unless you put them in a site-packages subdirectory (like
site-packages/zope270 or site-packages/zope271).  Otherwise there will
be no way to run multiple Zope versions on the same machine sanely
because different Zope versions have different libraries.
May I respectfully ask why there is so much concern with such
complicated setups?  Surely a production environment (which is what
any Zope distribution should aim for) will standardise on a software
One word: migration

As I've found out the hard way, there are times when it is much easier to 
conduct server upgrades if you can have different versions of Zope 
installed on a server at the same time.  This is especially true in budget 
constrained colocation environments where adding
additional machine for the upgrade would cost money.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope] Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Dan L. Pierson
--On Tuesday, March 11, 2003 03:43:33 PM -0500 Guido van Rossum 

On Tue, 2003-03-11 at 15:22, Guido van Rossum wrote:

 That's why we're including the correct versions of ZODB and ZEO in
 Zope itself.  That's already the case in Zope 2.6.
Zope 2.6 doesn't yet include ZEO, at least I don't think it does. ;-)
Oops, I stand corrected.  But Zope 2.7 does include ZEO!
Very good!  But in that case, shouldn't the new Zope 2.7 install and 
startup stuff support it?

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Dan L. Pierson
--On Tuesday, March 11, 2003 02:39:55 PM -0500 Guido van Rossum 
Does this mean that Zope 2.7 will require ZODB 3.2 for ZEO users?
Zope 2.7 will *come with* ZODB 3.2 (or later, depending on the timing
of the Zope 2.7 release), so I suppose so.
As an aside, am I the only one who's confused by this new bundling
of ZEO as part of the stand alone ZODB product?
I don't know.  What's confusing for you?  The new approach is that:

  Zope includes ZODB includes ZODB

What's confusing about that?
Zope doesn't (currently) include ZEO so to get an up to date ZEO we now 
have to obtain
the correct version of the stand-alone ZODB and extract the contained ZEO. 
The version
numbers of the ZEO and stand-alone ZODB are unrelated so figuring out which 
need to get ZEO is a bit of a pain.   Also, ZEO is packaged differently in 
the stand alone
ZODB than it used to be in on it's own.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Proposed installation changes for review

2003-03-11 Thread Dan L. Pierson
We currently rely on two scripts for running our Zopes:

1. A modified version of  I originally got it from a moribund wiki 
on the Zope site.
The main changes we've made have been to better separate parameters for 
Zope clients from
parameters for the ZEO server and to run an additional server of our own 
along side the ZEO
server (a simple distributed RAM Cache invalidation server).

2. A very simple sysv-init script that implements everything by calling the 

It looks like the new install and startup world will be a huge improvement 
over the current
setup on the whole.  I like moving the log files to their own directory.

The things that seemed to be missing from your writeup were:

Almost no mention of ZEO (only one mention of a zeo client name 
parameter).  How does
ZEO fit into this?

I don't see an equivalent to ./ debug anywhere.  This starts up an 
interactive Python as
a ZEO client with ZServer and Zope imported and app =  I use it 
constantly.  Please?

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] [Vote] PEP308 voting began

2003-03-05 Thread Dan L. Pierson

--On Tuesday, March 04, 2003 03:23:54 PM -0500 Guido van Rossum 

IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python.  If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
If it was just TALES I'd agree.  However I suspect that many other systems 
built on Python
have the same problem of allowing only Python expressions in various 
contexts.  It seems
very likely that most of the other web templating systems have this 

If this is true then, IMO, it's better to have one way to do it across all 
the applications built
on Python than have every app. do it differently.  If I didn't believe this 
I would have voted
for no change to the language.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] ZSQL/ZODB corruption after upgrade

2003-02-09 Thread Dan L. Pierson
Thanks for giving me a push in the right direction.  I already knew from 
the message that it
was the CComMember zclass.  The problem was that I had deleted all 
instances of that zclass
when I deleted the LoginManager based acl_users.  I then deleted the zclass 
from the Products
folder of the Control Panel.

Turns out that it was *still* in the product registry!  I had to use a 
debug session, manually
build a new registry tuple and use app._setProductRegistryData() to get rid 
of it.  Everything
seems fine now.

--On Saturday, February 08, 2003 01:18:50 PM +0100 Dieter Maurer 

Dan L. Pierson wrote at 2003-2-7 13:03 -0500:
  If I open a ZSQL method (any ZSQL method, new or old, inside the
  area that used to be controlled by LoginManager or not) it seems
  OK.  Using the method works.  But if I click on the Advanced tab
  in the ZMI, I get the following:
  (Object: manage_advancedForm)
/var/local/control/V4/site/zope/lib/python/Shared/DC/ZRDB/, line
548, in manage_product_zclass_info

One of your ZClasses is broken...

Catch the exception in line 548 of Shared/DC/ZRDB/
and find out which one. Do something about it...


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Zope components and revision control with cvs

2002-08-02 Thread Dan L. Pierson

--On Thursday, August 01, 2002 10:13:29 PM -0400 Shane Hathaway 

 It's really only a theoretical problem.  To store the extra data about
 folderish objects, you can save the data in a hidden file called, for
 example, .properties.  The theoretical problem is that someone might
 give an object that name, since it's perfectly legal.  In practice, you
 can just prevent people from creating Zope objects with a name that starts
 with a dot.  99% of the users won't mind at all, and those that do can
 use two dots instead. :-)

Doesn't Subversion support versioned emi-arbitrary properties for objects?
If so, much common metadata could be expressed as properties, saving
special maybe hidden files for the complex and uncommon cases.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

RE: [Zope-dev] Speaking of 2.6...

2002-04-17 Thread Dan L. Pierson

--On Wednesday, April 17, 2002 11:48:12 AM -0400 Brian Lloyd 

 We've already learned the hard way that the existing SiteRoots
 and VirtualHostMonsters etc. confuse people. This is partly due
 to under-documentation, but it is also partly because of the
 here, we'll give you several ways to do it! approach.

True, but...

 If there are strong reasons for it to be in the core, then I
 suspect it would need to be sufficient to be the official
 VH solution and we'd want to deprecate the existing things.
 That means that it will need to be well documented, and we'll
 need to produce the needed deprecation docs, transition guides,

Replacing VirtualHostMonster with VirtualHostFolder (via deprecation,
etc.) might be a good decision but please remember those of us
who need to use the SiteRoot/access rule combo to do more than
can be done with the higher level tools.  SiteRoots and access rules
are primitives that can not be replaced by higher level simple

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )


2002-01-24 Thread Dan L. Pierson

--On Thursday, January 24, 2002 01:35:56 AM -0500 vio 

 exUserFolder installed ok, so I'll give it a test drive also.
 But some hints on debugging LoginMgr would be also appreciated.

Personally, I'd stay away from LoginManager.  It depends on ZPatterns,
a very impressive, very complex layer whose author has moved on to
other things.  There are a group of users supporting it to some extent
with occasional help from the original authors, but I just see its
future on new versions of Zope as shakier and shakier.  For example,
Zope 2.4 support requires using the latest CVS patches (last I looked,
about a month ago).

We are currently using LoginManager, but will probably convert to
exUserFolder in the next month or two as part of moving our member
data from ZODB to PostgreSQL.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: Re: [Zope-dev] WebDav Bug? -- And some comments on how greatWebDAV is ;-)

2001-09-20 Thread Dan L. Pierson

I agree that Brian's proposal is a good idea.

--On Friday, September 21, 2001 08:46:42 AM +0200 Robert Rottermann 

 Hi Brian,
 that proposal sounds very good to me.
 Could it be enhanced in a way that we can add an add automatic extension
 when served by webdav.
 What I mean by that is that an object without extension is seen as
 having say .html appended to it when it is access by webdav.
 So we can use all these extension based web authoring  tools without
 changing the python way of doing things.

This wouldn't work very well for two reasons:

1. Sites like ours use a mix of DTML, Python Scripts and other things.  It
   would make some sense to map the DTML method register_user to
   register_user.html but the Python Script would want to be

2. The object on a Zope site already contain type information that can
   and should be leveraged for outgoing access.

My first cut suggestion would be to implement a separate outgoing mapping
table driven by the object's meta-type attribute (with provision for
CMF to override this to use it's different notion of type).

 - Original Message -
 From: Brian Lloyd [EMAIL PROTECTED]
 Sent: Wednesday, September 19, 2001 10:47 PM
 Subject: RE: Re: [Zope-dev] WebDav Bug? -- And some comments on how great
 WebDAV is ;-)

  Some additional issues when using the CMF:
  - There is this really great idea that you can create a news item by
  posting a file to your Member folder. The first
  problem is that
  Word does not let you save an HTML file as .news, so we changed
  the rules
  in CMF and upload news_MyNews.htm files

 FYI - I have a proposal that could also be used to address this.
 It would be great to get some feedback on it:

 Zope Corporation

 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Bulletproof ZCatalog proposal

2001-06-07 Thread Dan L. Pierson

--On Thursday, June 07, 2001 09:34:54 AM -0400 Shane Hathaway 

 But I think I have a solution for all of the issues in conflict
 resolution.  If you, or anyone else, is also interested in this, please
 show support (if only by saying please do this!) :-)  I can't work on
 it unless I have a reason to.

Please do this!  It is the sort of thing that can save us and others a lot
of time by keeping use of Zope simple and stable.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] [Announce] API Documentation Fishbowl Project

2001-06-07 Thread Dan L. Pierson

--On Wednesday, June 06, 2001 11:50:43 AM -0700 jimbo 

 I hope this helps. I wanted to add my feelings on the whole documentation
 issue.  It seems to me that the whole process caters around developers
 too much.

I have to disagree with you **in the context of this thread** for two 

1. DC has done a lot to improve the documentation for non-developers in the 
last year.  The Zope Book(s) should have a major impact when they start to 
appear on shelves in the next month or so.  Developer documentation has 
lagged behind.  This thread is about a proposal to improve developer 
documentation.  It says nothing at all about the other *existing* efforts 
by DC and others to improve other types of Zope documentation.

2. One of the main points DC made at this years Python conference was that 
they have tried to focus the Zope core on too many audiences at once.  They 
had to have a clearer focus and chose developers as that focus.  Of course 
I like this choice because I am a developer, but the more important point 
is that this tighter focus has the potential to make life easier for all of 

For example, the CMF is focused on content managers.  It is implemented as 
a *separate*, *layered* product on top of Zope.  This means that it is free 
to make tradeoffs in favor of content managers that the Zope core isn't. 
It also means that CMF release schedules are not tied to Zope release 

Incremental restructuring of the Zope core and improved Zope developer 
documentation makes it much easier and more practical for DC and others to 
create layered Zope products that address other communities.  Continuing 
the current rather inscrutable nature of the Zope core makes all of this 
harder for everyone involved.

Dan Pierson,, Inc.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] [Announce] API Documentation Fishbowl Project

2001-06-06 Thread Dan L. Pierson

--On Wednesday, June 06, 2001 11:57:06 AM -0400 Paul Everitt 

 Hmm, I'm surprised that 2 days has passed with no comment from zope-dev
 and no comments in the Wiki.  I hear constant complaints about lack of a
 polished API.  I expected this post to generate lots of interest.

I read it over, the final design seems acceptable if docs are actually 
written to it.

My main concern is the one that Chris McDonough expressed in great detail 
in the wiki, namely that definining the (existing) interfaces is THE 
critical step.  Simply documenting all of the methods of objects is not 
sufficient because it says nothing about which are important, which are 
internal only, which are obsolete, how they interact, etc.

The final design does base the API on hand-written interfaces, which is 
good.  There is also some seemingly fuzzy plans to have an interface 
verification tool, which will be of some value in catching some cases of 
non-compliance.  However, the vital hard bit of creating the hand-written 
interfaces and ensuring that they're right is sort of glossed over in my 

I thought of adding some of this to the wiki, but it all seemed to amount 
to a redundant me too and I wasn't sure where to put it :-(

Following the spec for newly written products should be easier.  The CMF 
seems to me to be a good example of a product that has done so (though the 
interfaces seem to be getting out of date at the moment).  I have found 
online CMF API docs useful in practice.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] FTP interface being worked on?

2001-03-18 Thread Dan L. Pierson

--On Saturday, March 17, 2001 08:46:26 PM -0500 Fred Wilson Horch 

 I think lossless serialization should be an explicit goal.  If a
 developer doesn't provide specific object serialization methods, then a
 default method (perhaps XML) should be invoked that is lossless even if
 hard to work with.

I'm not sure what the caveats were that lead to the non-lossless guarantee. 
of the filesystem representation of a ZCatalog.  What is lossless vs. 
If the filesystem representation dumps evrything required to recreate a 
working copy
of the catalog after a (perhaps lengthy) computation but doesn't actually 
dump the
full current contents is that a lossless representation?

 The whole point for us is to get full control of our objects through

And grep and emacs, etc.  At least for us.  This is really the big issue.
If all you need is CVS, a "morally binary" XML representation can do.  Zope
already provides one, though it is not ideal for CVS.  If you want to be 
to use other file system based tools (a.k.a. normal development tools) then
you need a representation much closer normal text. It's almost obvious what 
should be for folders, DTML, ZSQL, PythonScripts, etc.  It's much less 
what this should be for ZCatalogs, Racks (yeah DC probably doesn't care but 
I do),
ZClasses, etc.  It may be hard to come up with something better than XML 
which I agree should probably be the default if nothing better is specified.

Then there is metadata.  That leads into your next question:

 Can anyone tell me where my effort would best be spent?  Would it be
 best for me to start with FSDump or ZCVSMixin and corrupt them to serve
 my evil plans, or should I start from scratch based on the object
 serialization discussion we've been having (but with the explicit goal
 of lossless serialization, unlike Chris' proposal)?

The difference is that ZCVSMixin reads and writes XML pickles because 
all metadata was a major goal.  We can't live with the extreme 
unfriendlyness of
XML pickles to other tools.  FSDump tries to capture all metadata 
explicitly in
".props" files.  I suspect that it is much closer to the eventual file 
representation of Chris' proposal.  FSDump has no read capability.  At 
IPC9, someone
from DC told me that Tres was worried that read capability would be a giant 
hole.  I can't remember if that someone was Tres or not.  IMHO, the 
solution to this
probably involves forcing read to be invoked only from outside of Zope (or 
maybe only from a local machine login?).  I'm not sure how this would be 

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Using LoginManager with SQL and SkinScript

2000-11-30 Thread Dan L. Pierson

I've put up a writeup of a different way to use LoginManager with SQL
that I think is a bit more in keeping with the current ZPatterns at:

Any comments?  (I would have set this up as a formal HowTo, but
couldn't find a way to upload the contents.)

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Membership and latest LoginManager

2000-11-13 Thread Dan L. Pierson

"Phillip J. Eby" [EMAIL PROTECTED] writes:

 At 01:37 PM 11/13/00 -0500, Dan L. Pierson wrote:
 I've been trying to get Membership 0.7.6 working with
 LoginManager-0-8-8b1 (and it's associated ZPatterns) under Zope 2.2.2
 on RedHat 6.2.  After probing around it seems that there is a problem
 storing member passwords.  The  following trace from print statements
 inserted in PersistentUserSource illustrates the problem:
 Dan, can you check what class you're using for users, what kind of
 propertysheet SystemProperties is on that class (DataSkin or CIPS), and
 whether it actually has a "password" property?  Thanks.

PortalMember is a ZClass in the PortalMembership product with bases: 
ZObject, _ZClass_for_DataSkin, _ZClass_for_LoginUser

It has what appears to be a standard ZClass property sheet
SystemProperties with a string property "password" (it also has other
ZClass property sheets CommonProperties, RestrictedProperties, and

PortalMembership is a .zexp file created by installing the Membership product.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Unit testing, ZUnit

2000-10-24 Thread Dan L. Pierson

Lalo Martins [EMAIL PROTECTED] writes:

 Then I figured in the long run a Product isn't the best
 sollution; instead, fiddling with App/Product* sounds more like
 it, to allow developers to register tests just like they
 register classes, ZClass superclasses, _misc and help. Of
 course, just like the current registerHelp and others, it
 wouldn't be mandatory and not using it wouldn't break anything.
 Then, in the Product's page in the Control Panel, there would
 be a tab "Test", where you'd be allowed to run the unit tests.

I like the idea a lot, but would like to suggest that unit tests ala
PyUnit really have three parts that call for separate treatment.

1. Test environment setup: construct the data structure(s) a test
needs to run against.  This wants to be separate because different
tests can frequently share the same data structures and data structure
setup can be non-trivial in systems like Zope.  Since Zope is a
persistent object space, there would also need to be code to tear down
a test environment.  Let's just lump that in here since it will be
automagically invoked by the unit test facility.

2. Test definition and execution: pretty obvious :-)

3. Test results reporting: a small number (1?) of standard reporters
plus the ability to define and register new reporters.

Given the above, the task of writing most tests would consist of:

1. Select test environment.

2. Select default reporter.  Optionally list which other reporters can
be selected at test execution time?

3. Write and test the test.

4. Register the test so that it appears on the Test page.

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Product Data Storage

2000-06-30 Thread Dan L. Pierson

Andy Dawkins writes:
  I have decided AGAINST searching the ZODB for instances of ZMailIn because
  that is just too scary, hideously inefficient and I don't want to go there.
  Instead I thought of keeping an up-to-date list of where all the current
  instances where held.  My original idea was to get the ZMailIn product to
  write a file in to the /lib/python/Products/ZMailIn directory, which
  shouldn't cause any problems that I can see.

... snip ...

  So my question is this:
  What are peoples opinions on storing shared product data?  Where should it
  be placed?  Should this ability be added to Zope as a standard?

Shared data should go in zope/var, or a subdirectory of that.
Zope/lib should be considered read-only by running products unless
explicitly changed by the user.  As you have correctly pointed out,
lots of machines share Zope installations for multiple servers.

A standard interface for Python code to get a private subdirectory of
var might well be useful.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] LM and user objects

2000-06-07 Thread Dan L. Pierson

Bill Anderson writes:
  "Phillip J. Eby" wrote:
   At 04:03 PM 6/6/00 -0600, Bill Anderson wrote:
   I am using the deafult UserSource that comes with LM for the moment (one
   step at a time ;)
   LM or PTK?
  (Waiting for Dan's changes before trying _any_ LM with PTK ;)

I posted the patch about two weeks ago, have you tried it?  I just got 
back from vacation yesterday afternoon.  It looks like Steve Alexander 
tried it and it worked OK (once he tracked down a bug in his manual
patch application that took me about a day to find when I created the
patch -- missing imports whose only references are wrapped in a
try/except can be hard to find :-().

I plan to check this in later today, either directly or on a branch.
Any preferences?

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

RE: [Zope-dev] LM and user objects

2000-06-07 Thread Dan L. Pierson

Chip Vanek writes:
  I also tried to get the patch working with 2.2CVS PTK CVS and had little luck.
  I also needed to manually apply the patch and worked through the errors until
  I got a security violation with the PTK.  I was no longer in any way able to
  access any of my test portals using the management interface.  I needed to
  back the patch out and get to plain 2.21a and PTK cvs to even get a ZODB
  portal working.

Interesting.  I've been avoiding 2.2 until the new security model gets 
some more bugs worked out.  Unfortunately, this means I'm not
surprised that you had problems...

  With all the problems with the standard PTK way of handling users access, I
  think that the best long term solution is to fully make the leap into the use
  of LoginManager and Racks as the standard mechenism for the PTK.  

We seem to have consensus on this.  Looks like Kevin's taken over the
lead on getting to the next step which is a coherent interface for PTK 
Membership to use to specify how to set up its LoginManager (e.g. how
do I create a Membership instance using a Postgressql based UserSource 
here, and another Membership instance using NT domain logins there).

  I also think
  that the standard authentication algorithm should support user login screens
  before basic auth for those folders that have a login_form in the aquisition

That would certainly help.

  So my vote is to check your patch into the main stream and harden

That's three in favor and none opposed so far.  I'll do it after
fighting a higher priority fire this afternoon.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Subclassing LoginManager

2000-05-22 Thread Dan L. Pierson

Phillip J. Eby writes:
  LoginManager will behave just like your outline, if you give it a
  BasicCookie LoginMethod, and a BasicAuth LoginMethod, in that order.
  LoginManager does not climb up the acquisition hierarchy, as that is
  properly the province of ZPublisher to do.  It will provide the anonymous
  user, if it is a top-level user folder.

You're right if course.  I just didn't realize that the PTK was set up 
to require cookie logins, so I was trying to avoid them and solve the
simpler piece of the problem first :-(

Oh well, that's working fine now.  I can log in, but it looks like
permissions aren't getting set/propagated correctly:

The initial management user is created with roles: 

   ['Member', 'Manager', 'Reviewer']

My PersistentUserSource returns this list correctly as the roles list.
All of the following are in Zope 2.1.6:

1. If I create the Portal as superuser with the Portal manager having the
same username as me, then log in to the portal in a new browser I can
see my folder but don't even have the permission to create new objects
in it.

2. If I create the Portal as me, a site Manager, with the Portal manager
having my user name, then log in as above, I can create objects but
clearly don't have Reviewer rights.

3. If I create the Portal as me with the Portal manager having another
username, then log in as above, it's just like the first case.  I can
see my folder but can't create anything in it.

Any idea what I'm doing wrong now?

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Subclassing LoginManager

2000-05-19 Thread Dan L. Pierson

OK, time for another Zen fix :-)

It looks like I've almost got PTK working with the latest
LoginManager.  The remaining problem is that the login form doesn't
work.  I've finally figured out why.
PTKBase.MemberFolder.MemberFolderBase.validate is much hairier than
LoginManager.LoginManager.validate.  A rough sketch is like this:

if req_has('__ac'):
... handle cookie login ...

if req_has('__ac_name') and req_has('__ac_password'):
... handle explicit login ...

if auth and lower(auth[:6]) != 'basic': 
... do basic authentication ...

... climb up the acquisition hierarchy ...

... try anonymous ...

I know that the official way to do most of this sort of thing with
LoginManager is by defining new LoginMethods, but I just don't see how 
to make LoginManager even try the LoginMethods at the correct time
without overriding validate.

Am I on the right track here?

Dan Pierson

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )