Re: [Zope-CMF] Zope 2.7.5 and proxy role for workflow scripts

[Dieter Maurer]

Sune B. Woeller wrote at 2005-3-30 22:22 +0200:
> ...
>The script is set to be called after a transition.
>
>Without proxy roles the
>script runs fine.
>If this script gets the proxy role manager (or all roles except anonymous),
>it fails, it has not got access to 'object'.
> ...
>Unauthorized: The owner of the executing script is defined outside the context 
>of the object being accessed. 

A very expressive (and therefore good) error message!

The (execution) owner of the script is not defined in a user folder
in one of the ancestors of the script.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Access rule for setting skin

[Dieter Maurer]

[EMAIL PROTECTED] wrote at 2005-4-1 17:43 -0500:
> ...
>So for instance I have a CMF root at /site/atlas ... This works fine.  The
>view is "root_view" (A FS based PT in the skins).
>
>If I do /site/atlas/en or /site/atlas/fr, I get something entirely
>unexpected.

It might help to explain what you get...

>If I do /site/atlas/en/root_view or /site/atlas/fr/root_view, then I'm back
>in business.
>
>I'm guessing this has something to do with when the access rule actually
>gets called and so on (too early? Too late?).

Indeed. Both the "AccessRule" as well as the "default view" resolution
use the so called "__before_publishing_traverse__" hook.
You probably see a conflict for this ressource.

A workaround might be to move your "AccessRule" up in the hierarchy
(such that it does not change the "__before_publishing_traverse__"
of a content object).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

RE: [Zope-CMF] Access rule for setting skin

[Dieter Maurer]

[EMAIL PROTECTED] wrote at 2005-4-4 11:37 -0400:
> ...
>As I think I'd mentionned, I get the Zope default home home page (Welcome to
>Zope, etc ...), but with a big warning at the top telling me that I don't
>have an administrative user setup and so on ... Which is obviously not true
>:)

Fine. But, I am unable to keep track of everything written in a thread...

>Further reading has suggested that the problem might be because the hook
>occurs before any authentication occurs, so the changeSkin() method will not
>work properly, or something like that?  Saw some archived list discussions
>on this topic ... Post-authentication hook?

This should only be a problem when your "changeSkin" decision
were based on specific user identities or authorization.
Such information is not available in an "AccessRule" as
authentication is performed after traversal (while "AccessRules"
are executed during traversal).

>In fact I believe you have a patch for it on your site?

Yes -- for a post-authentication hook.

But, as explained, it will not help for your current problem.

>Putting the access rule higher I'm guessing wouldn't work.  It's already in
>the root of the CMF site.  Putting it in the root of the entire zope
>instance would move it outside the CMF, and changeSkin() would no longer be
>easily available, or work properly? (Admitedly, haven't tried it yet).

Of course, you would need to "traverse" to the object which defines
"changeSkin"...

>If that's not it, I also discovered a co-worker developped a custom class
>that does what I need by using registerBeforeTraverse.  I think I may do
>that anyways as it allows my code to be on the FS and version controlled and
>so on.

Fine!

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [Performance] "listFilteredActionsFor" unnecessarily expensive

[Dieter Maurer]

In our regular profiles, "listFilteredActionsFor" belongs to
the top consumers of CPU time.

Recently, I found the main culprit (in CMF 1.4):

   It is the completely unnecessary:

  if not action in catlist:

In our case, "listFilteredActionsFor" spends about 70 percent
of its complete time in the checking of "action in catlist".

How in hell should the same action be defined more than once
such that we need to prevent such a case by an explicit check --
especially by such an expensive one?

A comment before the line indicates that the author intended
to check by identity. But, of course, "action in catlist"
does *NOT* check by identity but by equality.


I propose to remove the check altogether...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Modeling with UML of Zope ?

[Dieter Maurer]

Truong Trung Trang wrote at 2005-4-5 10:57 +0700:
> ...
>I'm doing a project of CMS with Zope and Plone. I'd like to understand
>clearly the architecture of Zope but I think that's a hard work for me. It
>will much easier if I have the documentation about how did Zope corporation
>design it, the modeling with UML of Zope, Structural Diagrams, Bihavior
>Diagrams, Modeling Management Diagrams ... but I can not find it anywhere.
>Please tell me where and how to get them. 
>Thanhks alot.

There are (or at least were) UML diagrams for parts of
Zope (ZODB and CMF) on "http://dev.zope.org"; and "http://cmf.zope.org";.

I cannot give you precise URLs (I never search for others).
And they may have removed...

>

Please send plain text only message to the mailing list.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] failing tests and other unit test issues

[Dieter Maurer]

yuppie wrote at 2005-4-4 20:59 +0200:
> ...
>2.) I prefer to see the correct import in each file and to use utils 
>just for the fallback.

But, then you get a nasty "try: ... except:" in hundred of
files rather than just a single one.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

[Dieter Maurer]

Florent Guillaume wrote at 2005-4-22 17:17 +0200:
>Chris Withers  <[EMAIL PROTECTED]> wrote:
> ...
>> Yes we do! I really really really want to know if:
>> - I have a catalog entry that points to an object that no longer exists. 
>> This can ONLY happen due to a bug somewhere and needs to be fixed
>> - I have index corruption or other weirdness
>> - any of the above are happening, and be able to descriminate between them.
>> 
>> I honestly can thing of no sane justification for putting that None 
>> there. It's tantamount to a bare try except, and without even any logging.

I rarely agree with Chris -- but this time I do :-)

>Yes, logging should be there. I'll add a LOG at level WARNING somewhere,
>I'm not sure where (after all it's unrestrictedTraverse that does the
>catching).

When something in the catalog tells you, there were an object
and the object is not locatable, then this is an ERROR
and not a WARNING -- because, you met a data inconsistency.
Data inconsistencies are serious enough to be classified as "ERROR".

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Use unicode or string (char encoding?) for CMF content?

[Dieter Maurer]

Petri Savolainen wrote at 2005-4-20 12:19 -0700:
> ...
>The question becomes, does CMF 1.4.x / do its content types fully 
>support using unicode?

There is only very limited unicode support.

ZPublisher supports a set of "unicode" type conversions (causing
UTF-8 encoded data to be converted to unicode) and
converts unicode on output to the encoding specified
by the "Content-Type" charset of the response.

CMF does not do anything beyond this to support unicode.

> ...
>If strings are to be used in some places rather than unicode, does CMF 
>1.4.x support using UTF-8 encoding everywhere?

You will have no problems when you use UFT-8 encoding everywhere.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Zope 2.7.5 and proxy role for workflow scripts

[Dieter Maurer]

Duncan Booth wrote at 2005-4-12 13:38 +:
> ...
>>>Unauthorized: The owner of the executing script is defined outside the
>>>context of the object being accessed. 
> ...
>A very expressive but not terribly useful error message!
>
>I just had exactly the same error message (except obviously for the script 
>name, user name and required roles). In my case the owner of the executing 
>script was 'admin' defined in the root acl_users folder for the entire Zope 
>instance. There does not appear to be any way to define a user which won't 
>give that error.

This would mean a bug. Since Zope 2.7.3, bugs in authorization handling
seem to be persistent.

Please file a bug report.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] DCWorkflow using workflow variables in guards expressions

[Dieter Maurer]

Konstantin E. Steuck wrote at 2005-4-21 16:20 +0700:
> ...
>While browsing thru DCWorkflow docs I thought I found perfect way to do 
>this by creating state variable called 'user' and setting it to whatever 
>I need. Then guard expression checks if current user is the one who has 
>been assigned to accomplish the task.
>So I set guard expression for worklist to
>
>python:state.get('user') == 'someone' #  maybe user.getId()

"WorkflowTool.getInfoFor" is the method designed to access
workflow variables.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] listFilteredActionsFor performance

[Dieter Maurer]

Tres Seaver wrote at 2005-4-25 15:11 -0400:
> ...
>> So it's hard to measure performance. But in general most time is spent
>> in expressions and in the WorkflowTool. Within the WorkflowTool,
>> worklists are by far the most expensive Actions.
>
>... because they involve catalog queries.  We could perhaps optimize
>that query via a dedicated TopicIndex for the 'review_state' portion.

Hm, the queries used for worklists are quite trivial.
In principle, they should be fast (at least if they would
not include the horribly inefficient "effective/expires" subquery
automatically added by the CatalogTool). Maybe, you try to remove
this subquery.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] DCWorkflow using workflow variables in guards expressions

[Dieter Maurer]

Konstantin E. Steuck wrote at 2005-5-6 18:12 +0700:
>Dieter Maurer wrote:
>> "WorkflowTool.getInfoFor" is the method designed to access
>> workflow variables.
>Thanks for your reply.
>Well, it doesn't work either. Whenever I put
>'python:state_change.workflow.getInfoFor(here, 'state')' into guard 
>expression it says

I spoke about the workflow *tool* and not the workflow definition.

Try again with "here.portal_workflow.getInfoFor"...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] When I call foo/index.html how/who call skins/plone_templates/index.pt ?

[Dieter Maurer]

KLEIN Stéphane wrote at 2005-5-6 09:50 +0200:
>I'm intriged to how working the skin. When I call foo/index.html how/who 
>call skins/plone_templates/index.pt ?

The "SkinsTool" manages a set of skins. Each skin
is a name lookup device consisting of various layes which
are themselves lookup devices.

When a skin is asked to lookup a name, it
asks each of its layes in turn until the one of them
resolves the name. The result is then this object.

A "Portal" inherits "Skinnable.SkinnableObjectManager".
This provides a "__getattr__" which looks attributes
up via the "SkinsTool". The currently selected skin
is determined from the request (or the default skin is used)
and this skin is asked to resolve the attribute name.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] How to use "typesTool.manage_addTypeInformation" ?

[Dieter Maurer]

KLEIN Stéphane wrote at 2005-5-5 19:40 +0200:
> ...
>   typesTool.manage_addTypeInformation(
>   add_meta_type = 
> factory_type_information['meta_type'],
>   id = factory_type_information['id']
>   )
> ...
>   File 
>"/home/harobed/newzope/Products/ZHelloWorld/Extensions/Install.py", line 
>22, in install
> )
>
>   File "/home/harobed/newzope/Products/CMFCore/TypesTool.py", line 598, 
>in manage_addTypeInformation
> raise ValueError, (
>
>ValueError: Meta type ZHelloWorld is not a type class.

The "add_meta_type" must refer to a class described by
"Products.CMFCore.TypesTool.typeClasses".
By default, "typeClasses" describes just "FactoryTypeInformation"
and "ScriptableTypeInformation".

Obviously, your "add_meta_type" does not fulfill this
requirement.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Multiple User Folders

[Dieter Maurer]

Chris Crownhart wrote at 2005-5-16 10:28 -0600:
> ...
>I am building a CMF site that will have many organizations (could be up 
>to 200 or 300).  Each organization will have it's own set of users, and 
>probably it's own set of roles, although most of the roles will be the 
>same across all organizations.
>
>I have a couple questions, and really am just kicking some thoughts 
>around, and would be curious as to anyone's ideas.
>
>1. Should I consider having separate User Folders (I'm using GRUF) for 
>each organization?  This makes sense for a lot of reasons.  Users of one 
>organization will probably never be in another, so why clutter up one 
>huge User Folder?
>
>2. Should I consider just having separate CMF sites for each 
>organization?  This would offer the ultimate in flexibility, but would 
>probably be a maintenance nightmare.  I don't have any idea how many CMF 
>sites I could have on one server, but I'll bet the number is pretty high. 

I would probably go for this solution.

These sites can share a large amount of templates and logic (if they
wish).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF-checkins] CVS: Products/CMFCore - DirectoryView.py:1.47.2.7

[Dieter Maurer]

Chris Withers wrote at 2005-5-26 08:12 +0100:
> ...
>My personal hate of it comes from seeing a thoroughly useless warning 
>coming from the old SearchIndex stuff for years and never being able to 
>figure out exactly what was causing the problem.

You asked for this a long time ago and I responded (a long time ago!):

You turn the warning (all of them, if you like) into exceptions
and you get a nice traceback.

You find details in the description of the Python (command) options
or the module "warnings".

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

[Dieter Maurer]

Florent Guillaume wrote at 2005-5-27 13:30 +0200:
> ...
>Let's not go into too much semantics here. Note that WARNING is an alias
>of PROBLEM. zLOG defines these levels as:
>
>  PROBLEM=100  -- This isn't causing any immediate problems, but deserves
>  attention.
>
>  ERROR=200-- This is going to have adverse effects.
>
>And indeed the missing object isn't causing immediate problems.

But just because you catched the resulting exception...

An inconsistency between the catalog and its object world
is an "adverse effect".

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [Plone-users] DCWorkflow question...

[Dieter Maurer]

Dmitry S. Makovey wrote at 2005-6-2 10:27 -0600:
>I've got workflow which runs script upon transition. At some point In 
>that script I'm trying to get info on what state I'm in via:
>st=getattr(state_change,'new_state')
>and it appears to be working only with 'Manager' role which mean that 
>I have to give that script "proxy role" of manager which I was trying 
>to avoid.

A different solution would be to use a small set of specialized
scripts with "Manager" role that extract the relevant information.

>Is there any other way, and why new_state, old_state and 
>transition attributes are so strictly guarded?

The reason is the

security.declareObjectProtected(ManagePortal)

for "StateDefinition"s and "TransitionDefinition"s.

I doubt the protection is necessary. But, it is there...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Bad interaction between CMF 1.4 and Zope 2.8 (catalog-getObject-raises)

[Dieter Maurer]

Raphael Ritz wrote at 2005-6-3 09:40 +0200:
>Chris Withers wrote:
>[..]
>> That said, I'm also aware that there are currently 4 of us talking about
>> this, 2 on each side. What does the rest of the community think?
>> 
>
>Since you ask so explicitly ;-)
>
>I agree with Florent: Your site's _USERES_ should never get
>an error thrown at. There are other ways to inform the site's
>admin.

But "admin"s are lazy people (I am one, part time; therefore, I know...)
*unless* their users report problems.

I know that lots of admins saw lots of inconsistency reports
in Zope's logfile -- and did nothing!
Only newbies asked from time to time what these log entries
mean -- and got the advice to ignore them...
I speak about the "could not remove XXX from index III"
that plagued Zope's "KeywordIndex" for years.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Zope 2.7.6 acl_user issues - no transaction history

[Dieter Maurer]

Carl Rendell wrote at 2005-6-3 10:53 -0700:
> ...
>In a multi CMF / Plone zope instance local acl_users are not getting  
>any transaction history from which to undo (undo_form returns no  
>results).
>
>So long as the user is in the acl_user folder at the parent level  
>(main zope instance) they do have transaction history that shows in  
>undo.
>
>I'm not sure if this is related to the changes in ZopeUndo/Prefix.py  
>or others changes in zope 2.7.6, but I'm hoping someone may have run  
>across this issue.
>
>head to head comparisons of 2.7.5 to 2.7.6 indicate the change is  
>localized to the difference between the to.

Check that is is not a filtering issue:
analyse the undo records as "Manager" in the top level "Undo" tab.


It would be very surprising when the user location would really
determine whether there is a transaction log or not.
In fact, this is impossible because there would be not transactions
in the first place.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Problem

[Dieter Maurer]

Maya Angelova wrote at 2005-6-17 10:26 +0200:
>I have a the following problem by restarting a plone site under zope.
>Could anybody give me a hint.
>would be very grateful
>
>
>sh plone2 restart
>plone2: line 156: plone2 : command not found
>plone2: line 158: plone2 : command not found

These are problems reported from the shell script "plone2".

  In its line 156 and 158, it references unknown
  commands.

  Check which commands these are and why they are unknown.

In case, you have "bash" installed, try to use "bash" in place
of "sh".


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[Dieter Maurer]

Jens Vagelpohl wrote at 2005-6-20 11:48 +0100:
> ...
>I support that statement. In my opinion it is unacceptable to make  
>this change on the CMF 1.5 branch at this point. If there is a  
>problem, please change the software that relies on the old behavior  
>instead.

The new behaviour was ill conceived (it missed the need
for portal folders without order support as exemplified
by "CMFBTreeFolder").

We now notice this bug. It should be fixed.

I think, it would be acceptable as fix to introduce
a new "PortalFolderBase" (or similarly named) class
as *the* base class for all portal folders.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[Dieter Maurer]

yuppie wrote at 2005-6-20 11:56 +0200:
> ...
>PortalFolder is not just a base class, it's *the* folder class used in 
>CMFDefault. Subclasses can mix in OrderSupport, but that has no effect 
>on PortalFolder instances.

Maybe, we should change this:

  "PortalFolder" is not part of "CMFDefault" but of "CMFCore".
  
  Its name suggests it as the base class for all portal folders.

  "CMFBTreeFolder" provides a convincing use case that
  some portal folders should *not* have order support.


> ...
>I'm open for any proposal that adds a *new* base class for CMF folders.

If we do not want to use "PortalFolder" as the base class
for all portal folders (which I would prefer),
we might introduce a new "PortalFolderBase" for precisely this
purpose.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[Dieter Maurer]

Julien Anguenot wrote at 2005-6-20 11:19 +0200:
>Christian Heimes wrote:
> ...
>> I'm proposing to change PortalFolder in the following way:
>> 
>>  * Revert PortalFolder to be subclassed from Folder
>> 
>>  * Create an OrederedPortalFolder as subclass from OrderedFolder
>> 
>>  * Subclass all classes in CMF from OrderedPortalFolder instead of
>> PortalFolder
>> 
>> All third party software that was working with CMF 1.4 and older would
>> work as expected and all CMF core software would still use the ordered
>> folder. The downside is that software written for CMF 1.5 has to be
>> altered. But it is much easier to alter a few lines in some products
>> than trying to get rid of the ordered stuff in PortalFolder.
>
>- -1. You can change the code of your product to cope with it. (i.e : we
>did this on CPS a long time ago)

I, on the contrary, am in favour of such a change.

"CMFBTreeFolder" demonstrates that there is a useful use
case for a "PortalFolder" *without* order support.

*AT LEAST*, there should be a "PortalFolder" base class
without order support (which might have a different name).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[Dieter Maurer]

Christian Heimes wrote at 2005-6-20 20:19 +0200:
>Dieter Maurer wrote:
>> The new behaviour was ill conceived (it missed the need
>> for portal folders without order support as exemplified
>> by "CMFBTreeFolder").
>> 
>> We now notice this bug. It should be fixed.
>> 
>> I think, it would be acceptable as fix to introduce
>> a new "PortalFolderBase" (or similarly named) class
>> as *the* base class for all portal folders.
>
>You are a little late, Dieter. *g* I have already added PortalFolderBase 
>and fixed BTreeFolder2.

I am reading the digest which I usually receive once a day
(and read in the evening)...


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [DCWorkflow] condition on transition action

[Dieter Maurer]

yuppie wrote at 2005-6-26 19:32 +0200:
> ...
>BTW: I'm not at all happy with the worklist Actions.

They are very useful.

>They are very 
>expensive and specialized.

They can be made *MUCH* faster by using "ZCatalog.searchResults(catalog, ...)"
rather than "catalog.searchResults(...)" when "catalog" is "portal_catalog".

The expensive part is the "effective <= now <= expires" subquery
added by the catalog tool.

>And they are in the wrong place because they 
>are often not workflow specific if you have more than one workflow. 

With this, I agree...

However, you will loose the workflow integration with respect
to the "catalog variable"s.

>Maybe they should be marked as deprecated instead of improved?

They should be improved and maybe moved out of DCWorkflow.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CMFSetup: non-ascii text

[Dieter Maurer]

Florent Guillaume wrote at 2005-7-1 17:19 +0200:
>In many places, CMFSetup exports and imports things like titles and  
>descriptions. For instance, for the workflow states and transitions.
>These fields can often, outside the USA, contain non-ascii strings.  
>How do we export and reimport them ?
>
>1. We can export by converting them to unicode, and the ZPT will  
>render that as UTF-8. Which charset do we assume ? Anything better  
>than "locale.getlocale()[1] or 'latin1'" ?
>
>2. When importing, do we set the values (attributes) as unicode, or  
>do we try to re-convert to the above charset...

I think, we should keep all text as Unicode -- even in
english speaking environments


If this is not an option, the external format should use Unicode
and some configuration parameter (Plones uses "site_encoding")
converts from/to the external Unicode.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] upgrade problem - cannot delete portal_url tool

[Dieter Maurer]

chris wrote at 2005-7-1 13:54 -0700:
>I'm trying to upgrade CMF, and when I try upgrading from CMF 1.2 to 1.3
>or later I start getting KeyError: portal_url. From what I gather, the
>CMF URL Tool was moved from CMF Default to CMF Core, and I need to
>delete the portal_url object and recreate it under the proper tool,
>however ZMI will not let me delete it.

A workaround would be to add the following module
in "CMFDefault":

   URLTool.py
from Products.CMFCore.URLTool import *

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CMFSetup: non-ascii text

[Dieter Maurer]

Florent Guillaume wrote at 2005-7-1 20:43 +0200:
> ...
>The problem is on import, you don't really know if a non-ascii string  
>should be stored as unicode or as an encoded str. And the software  
>may break if it gets something it doesn't expect...

That's why the whole Python world including Zope (it does with Zope 3)
and CMF should follow Java and require "for text always use Unicode".
And for non-text, CMFSetup should use a specialize "binary" type.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CMFSetup: non-ascii text

[Dieter Maurer]

Florent Guillaume wrote at 2005-7-4 15:01 +0200:
>Dieter Maurer  <[EMAIL PROTECTED]> wrote:
>> Florent Guillaume wrote at 2005-7-1 20:43 +0200:
>> > ...
>> >The problem is on import, you don't really know if a non-ascii string  
>> >should be stored as unicode or as an encoded str. And the software  
>> >may break if it gets something it doesn't expect...
>> 
>> That's why the whole Python world including Zope (it does with Zope 3)
>> and CMF should follow Java and require "for text always use Unicode".
>> And for non-text, CMFSetup should use a specialize "binary" type.
>
>Again, I couldn't agree more. My problem here is backward compatibility.


As soon as you fiddle around with encodings, you must know
what is text and what binary data.

Following the "explicit is better than implicit" principle,
the introduction of a new type (or maybe even better two) seems appropriate
-- with a reasonable default for backward compatibility.
E.g. we assume all Python strings to refer to "text" (i.e. unicode
in some encoding).


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] undo_form -> no content

[Dieter Maurer]

David Chandek-Stark wrote at 2005-7-27 09:51 -0400:
>I got no reply from plone-user on this issue -- I believe it's really a 
>CMF issue anyway. Add CMF 1.4.7 to the version info below.

Probably, because your question is not too clear...

> ...
>In my site the undo form is always blank. In the ZMI, however, undoable
>transactions are listed.

Thus, you speak of what "undo form"?

Apparently, the "undo" tab of the ZMI lists what you expect,
but something else does not. What is this something else?

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: undo_form -> no content

[Dieter Maurer]

David Chandek-Stark wrote at 2005-7-27 16:10 -0400:
>Sorry, this is a Plone site. There is a Plone skin template undo_form 
>which calls container.portal_undo.listUndoableTransactionsFor(here) to 
>get the undoable transactions.

Not sure, whether Plone uses its own "UndoTool".

The CMFCore "UndoTool" should show a user with the "ManagePortal"
permission the same undoable transactions as the "Undo" tab
of the portal's ZMI page.
Other users will only see their own transactions.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: undo_form -> no content

[Dieter Maurer]

Sam Brauer wrote at 2005-7-29 08:19 -0700:
>I've recently encountered a similar problem, and I'm
>not using Plone.  I'm in the process of migrating some
>CMF sites to  Zope 2.7.7 and CMF 1.5.2, from Zope
>2.7.2 and CMF-1.4.8.
>With the newer software, I find that users who are
>defined in the site's acl_users (even with the Manager
>role) never see any transactions listed on the
>undo_form, while users defined in the main acl_users
>at the root of the zope instance do see transactions
>listed.

I remember (faintly) to have read in this list that
there have been recent changes with respect to "undo"
that break the CMF.

Please search the archive...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Plone participation in the CMF list

[Dieter Maurer]

Geoff Davis wrote at 2005-8-1 12:53 -0400:
> ...
>* Are there any particular things in Plone that you think should be pushed
>down into CMF?

"PloneBatch" seems quite useful.

I do not use Plone (due to its GPL) but I found the "FactoryTool"
useful. Because it is GPL, I studied its functionality and
then made my own implementation (independant of the Plone one).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: undo_form -> no content

[Dieter Maurer]

Florent Guillaume wrote at 2005-8-4 17:03 +0200:
>I'm willing to fix it if someone explains *why* the patch is needed.
>What code actually adds a username and space in the path. Is that part of
>what's written in the transaction description? Is it something CMF adds?

It is "Zope.App.startup.TransactionManager.recordMetaData".

In Zope 2.7.2 (thus, a bit old but maybe still valid), the
code looks like:

auth_user=request_get('AUTHENTICATED_USER',None)
if auth_user is not None:
try:
auth_folder = auth_user.aq_parent
except AttributeError:
# Most likely some product forgot to call __of__()
# on the user object.
LOG('AccessControl', WARNING,
'A user object of type %s has no aq_parent.'
% str(type(auth_user)))
auth_path = request_get('AUTHENTICATION_PATH')
else:
auth_path = '/'.join(auth_folder.getPhysicalPath()[1:-1])

T.setUser(auth_user.getId(), auth_path)

with "ZODB.Transaction.setUser(user_name, path='/')" defined by
self.user="%s %s" % (path, user_name)

Thus, if "path" is empty, you get " ".

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [dev] i18n improvements - a proposal

[Dieter Maurer]

yuppie wrote at 2005-8-9 19:11 +0200:
> ...
>2.) Using different domains for different products:
>
>While 'cmf_default' should be used by the core products (CMFCore, 
>CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for 
>CMFCalendar.

Can we give "CMFCore" its own domain?

We would like to use "CMFCore" without any reference to
"CMFDefault".

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[Dieter Maurer]

yuppie wrote at 2005-8-11 09:36 +0200:
> ...
>> Can we give "CMFCore" its own domain?
>> 
>> We would like to use "CMFCore" without any reference to
>> "CMFDefault".
>> 
>
>Are you concerned about imports from CMFDefault or do you see a need to 
>ship CMFCore with its own translations?

We build applications on top of CMFCore (we see as a very
efficient framework -- thank you) but without CMFDefault.
(we see as a rather pure portal implementation).

Of course, messages emanating from CMFCore should be
internationalized.

If would be nice if the message catalog translating
CMFCore term were independent from the (probably much larger)
CMFDefault catalog. Especially, we would like to continue to deploy
our application without a need to include the CMFDefault product.

If this does not interfere with giving CMFCore the domain
"cmf_default", then I do not have objections to use this
domain for "CMFCore" as well.


>My plan was to define this in CMFCore.utils::
>
>   CMFCoreMessageID = MessageIDFactory('cmf_default')
>
>That way there is no need to import something from CMFDefault but 
>CMFCore translations will have the 'cmf_default' domain.

Can you nevertheless have a small message catalog for CMFCore
terms and another one for CMFDefault?

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] small proposal, catalog tool

[Dieter Maurer]

computing project wrote at 2005-8-19 23:03 +:
>I'd like to change the way that the catalog is implemented slightly, to 
>allow tools other than the workflow tool to provide variables to the 
>catalog.  I'm happy to submit the code + tests if everyone's 
>happy/interested.

I like your proposal.

-- 
Dieter
___
Zope-CMF maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Nested skins

[Dieter Maurer]

Laurence Rowe wrote at 2005-8-22 17:04 +0100:
> ...
>I often define several skins, and after a while they get a little 
>complicated (I'm using Plone ;-) So in order to make my life easier I 
>thought it would be nice to be able to define a skin 'Foo' like:
>
>foo_skin
>
>
>This would then get expanded to include all the layers of 'My Standard 
>Skin' after the layer foo_skin.
>
>Attached is my patch implementing this, would it be useful for anyone else?

Yes, even very useful.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: CachingPolicyManager improvements

[Dieter Maurer]

yuppie wrote at 2005-9-5 14:06 +0200:
> ...
>PortalTestCase is in the wrong layer. It makes assumptions about the way 
>CMF works. Changes to the CMF might break PortalTestCase and create a 
>dependency on a new Zope release. (We saw that problem already with the 
>_refreshSkinData changes in CMF 1.5)

It is not better to fix such problems at a single place ("PortalTestCase")
rather than in lots of individual tests (that happen to make similar
assumptions)?


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: CachingPolicyManager improvements

[Dieter Maurer]

Florent Guillaume wrote at 2005-9-6 15:30 +0200:
> ...
>Of course if you directly serve content objects from the cache, which  
>is explicitely unsupported and not recommended...

Where did you find this information ("*explicitely* unsupported").

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Sane checkin mail delivery (was: Re: [Zope-CMF] Re: CachingPolicyManager improvements checked in to svn)

[Dieter Maurer]

Jens Vagelpohl wrote at 2005-9-8 11:41 +0100:
>
>On 8 Sep 2005, at 11:08, yuppie wrote:
> ...
>Geoff, can you double- 
>check that the email address you have in your zope.org membership is  
>correct and then subscribe to the cmf-checkins list? That should make  
>any further check-in messages appear for us.

I have seen such a wish several times.

  Would it not be more sane to fix the checkin mail delivery
  such that it does not require the checking in person
  to have a subscription?

  Someone making occational changes may not be interested
  to be informed about all the modifications going on.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [dev] Topic changes: problems with revision 38002

[Dieter Maurer]

yuppie wrote at 2005-9-21 18:10 +0200:
> ...
>   File "Products/CMFDefault/Portal.py", line 26, in ?
> from Products.CMFTopic import Topic
>ImportError: cannot import name Topic

In a similar situation (with Archetypes) something like

   import Products.CMFTopic.Topic; Topic = Products.CMFTopic.Topic

worked around the problem.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: IE Cache Bug and CachingPolicyManager

[Dieter Maurer]

Geoff Davis wrote at 2005-9-28 13:31 -0400:
>On Wed, 28 Sep 2005 12:47:06 -0400, Tres Seaver wrote:
>
>> Thanks for the analysis, and the fix (sorry for the earlier, premature
>> reply).
>
>No problem.  P-J Grizel suggested offline that the problem might be due to
>IE not parsing the time zone string at the end of the Last-Modified date
>stamp correctly.

HTTP 1.1 specifies:

   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
   (GMT), without exception. For the purposes of HTTP, GMT is exactly
   equal to UTC (Coordinated Universal Time). This is indicated in the
   first two formats by the inclusion of "GMT" as the three-letter
   abbreviation for time zone, and MUST be assumed when reading the
   asctime format.


Thus, there *MUST* not be any time zone different from GMT.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] DCWorkflow + Acqusition

[Dieter Maurer]

Victor Safronovich wrote at 2005-10-11 14:04 +0600:
>  I have a question about DCWorkflow, WorkflowTool and Acqusition.
>
>  My  object,  during  change  state,  move  to  another folder and should 
> change
>  acqusition wrapper.
>
>  workflow_tool = getToolByName( my_object, 'portal_workflow')
>  workflow_tool.doActionFor( my_object, 'some_action' )
>  # during doActionFor raised ObjectMoved but i don`t know about that in here
>  # because WorkflowTool._invokeWithNotification shallow it.

But it returns what "objectMoved.getResult()" returns.

   You can use this to communicate with the "doActionFor" caller.


The much more reliable way however is to perform
the necessary unindexing and recataloging inside the action
itself (and not let this as task of the caller).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: RestrictedPython, TALES Expressions and CMF

[Dieter Maurer]

Tres Seaver wrote at 2005-10-11 08:58 -0400:
> ...
>'call_with_ns' should be invoked only for objects with either a
>'__render_with_namespace__' attribute (PythonScripts fit here) or those
>with 'isDocTemp' true.  Its only real purpose is to set up the namespace
>before calling a DTMLMethod;  I don't even understand why PythonScripts
>have such a method.

Probably, because they can bind the DTML namespace...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: Re[2]: [Zope-CMF] DCWorkflow + Acqusition

[Dieter Maurer]

Victor Safronovich wrote at 2005-10-17 13:10 +0600:
> ...
>By the way i think code:
>for w in wfs:
>w.notifySuccess(ob, action, res)
>if reindex:
>self._reindexWorkflowVariables(ob)
>in  _invokeWithNotification should be turn upside-down to:
>if reindex:
>self._reindexWorkflowVariables(ob)
>for w in wfs:
>w.notifySuccess(ob, action, res)
>am i right?

Why do you think so?

  I find the original order more natural (in case "notifySuccess"
  would change some workflow variables).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: CMF and Five views: hooking up "POST"

[Dieter Maurer]

yuppie wrote at 2005-10-17 15:24 +0200:
> ...
>I don't think so:
>
>1.) If you start rendering the default view before the controller has 
>finished you need extra code to abort the rendering if necessary. E.g. a 
>tal:condition that wraps the whole template.
>
>2.) A cleaner separation of controller calls and view rendering makes 
>the code simpler and therefore easier to write and maintain.
>
>3.) Rendering useless views wastes resources.

"CMFFormController" does a nice job in this respect.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: RestrictedPython, TALES Expressions and CMF

[Dieter Maurer]

Tres Seaver wrote at 2005-10-16 14:22 -0400:
> ...
>> Probably, because they can bind the DTML namespace...
>
>I knew that they *could* bind it;  it just don't understand why anyone
>would *want* that feature, given the availability of the other,
>non-ambiguous bindings.

I know that I used it intensively in the past (for a former
employer). Now, I almost dropped DTML and with it the DTML namespace
bindung of Python Scripts, although it works as well with
the ZPT namespace...

>I would argue that it is a misfeature, especially given the bug which it
>surfaces in 'render' / 'call_with_ns'.

I have seen this several times:

  When a bug comes to the surface, a feature is reclassified
  as a misfeature...

I do not need this feature (unlike other reclassified things)
but maybe, fixing the bug is also a solution?



>=nIvs
>-END PGP SIGNATURE-

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Full portal import/export

[Dieter Maurer]

Rui Gamito wrote at 2005-11-3 14:46 +:
> ...
>  * Module Products.PluginIndexes.common.UnIndex, line 247, in
>_index_object
>  * Module Products.PluginIndexes.common.UnIndex, line 205, in
>insertForwardIndexEntry
>AttributeError: _length

A migration bug introduced in Zope 2.8.

Rumours say that it might be fixed in the latest 2.8 release (2.8.4).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CMF 1.5 manage_afterAdd & co

[Dieter Maurer]

Florent Guillaume wrote at 2005-11-9 16:17 +0100:
> ...
>To make sure that CMF 1.5.5 will play well with Five 1.2, I have to  
>make sure that no method manage_afterAdd redoes a recursion that one  
>of its base classes was doing, as we have to be prepared to have the  
>base class monkey-patched to use events, and have recursion done with  
>events.
> ...
>Does someone have a problem with me doing that in the CMF 1.5 branch?  

Test with with Archetypes and Plone...
Archetypes does a nice dance with "manage_afterAdd".
If fact, it gets it wrong (such that objects are indexed much more
than once).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF-checkins] SVN: CMF/branches/tseaver-pkg_resources/ Avoid using __file__ where possible.

[Dieter Maurer]

Chris Withers wrote at 2005-11-11 09:05 +:
>Tres Seaver wrote:
>> Log message for revision 40036:
>>   Avoid using __file__ where possible.
>
>Why? I use this all over the place so need to know why it's bad ;-)

Back in April, I implemented for our local Zope version
to be run from a Zip archive (which lets Zope start significantly faster).

As you probably understand, I had to touch all these "__file__" references
because they point inside the ZIP archive.
It would have been much easier, had all places instead used
"from App.Common import package_home; home = package_home(globals())".
That, what I transformed "dirname(__file__)" references to.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Proposal for hooking rendering

[Dieter Maurer]

Paul Winkler wrote at 2005-11-30 10:33 -0500:
> ...
>When you customize a FSPageTemplate, you get a plain ZopePageTemplate.
>So you'll need to find a way to post-process the output of those
>without requiring a change to core Zope, or this becomes a Zope
>proposal.  Unfortunately I haven't a clue how you could avoid that.

Instead, you change the "makeZODBClone" (or similar method)
of "FSPageTemplate" and create a (new) "CMFPageTemplate".
(rather than a plain "ZopePageTemplate").

This would be a good thing (not only in the light of Paul's
proposal) as a plain "ZopePageTemplate" behaves too differently
from a "FSPageTemplate" (i.e. it is not "Caching Policy Manager" aware).


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Proposal for hooking rendering

[Dieter Maurer]

Sidnei da Silva wrote at 2005-11-30 18:26 -0200:
>On Wed, Nov 30, 2005 at 08:24:56PM +0100, Dieter Maurer wrote:
>| Paul Winkler wrote at 2005-11-30 10:33 -0500:
>| > ...
>| Instead, you change the "makeZODBClone" (or similar method)
>| of "FSPageTemplate" and create a (new) "CMFPageTemplate".
>| (rather than a plain "ZopePageTemplate").
>| 
>| This would be a good thing (not only in the light of Paul's
>| proposal) as a plain "ZopePageTemplate" behaves too differently
>| from a "FSPageTemplate" (i.e. it is not "Caching Policy Manager" aware).
>
>But then again, neither is FSImage/FSFile and OFS.Image/OFS.File.

Indeed, all of them should be fixed.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)

[Dieter Maurer]

Alexander Limi wrote at 2005-12-3 14:27 -0800:
> ...
>Except, the implementation did not end up including the query string -  
>which was the whole idea in the first place, to have ACTUAL_URL be "what  
>is in the address bar right now", so things like anchors work (did you  
>know there is no proper way of getting anchors to work in virtual hosting  
>setups without doing three conditional tests in your template?).

I have difficulties to understand the paragraph:

  What have anchors to do with the query string?

As I understand it, "anchors" (fragments in the URL) are a client
only concept: fragments are not transfered to the server.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: VIRTUAL_URL and ACTUAL_URL (was Re: Collector Issues)

[Dieter Maurer]

Alexander Limi wrote at 2005-12-4 20:04 -0800:
>On Sun, 04 Dec 2005 10:23:25 -0800, Dieter Maurer <[EMAIL PROTECTED]>  
>wrote:
>
>>   What have anchors to do with the query string?
>>
>> As I understand it, "anchors" (fragments in the URL) are a client
>> only concept: fragments are not transfered to the server.
>
>Correct, but it's impossible to construct valid anchors that do not reload  
>the page if you do not have a working ACTUAL_URL because of Zope setting  
>the  value to something else than the current page.
>
>Thus, a link like  will *reload the page*, then go  
>to the anchor - which is clearly not desirable behaviour.

Okay, I understand.

But, that "ACTUAL_URL" does not contain the query string cannot
be the problem because you can easily add it.


Determining the real "ACTUAL_URL" is unfortunately not
that easy because 

  *  HTTP allows proxies to change the URL
 (that's why RFC2617 transfers the uri in 'Authentication'
 and does not trust the request uri)

  *  Apache's mod_proxy is often used to modify the URL
 to include commands for the VHM

  *  Right at the beginning of request processing, before
 VHM has a change to do its job, the URL is
 modified by Zope (executing ":action/method" requests)

  *  The URL is modified again during traversal -- at some
 point of which the VHM does its job

It will not be that easy to get it right with all of these
influences.
Probably the most promising route would be let
VHM determine "ACTUAL_URL" from "PATH_INFO" by
removing/executing its commands on it.
It will probably work only in standard situations (VHM in Zope route, e.g.).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] FS Skins and Last-Modified

[Dieter Maurer]

Doyon, Jean-Francois wrote at 2006-1-25 15:51 -0500:
> ... FSDTMLMethods ...
>But, for some reason, now it seems bobobase_modification_time comes out
>wrong :(
>
>It's stuck at some date in October, even though the files are far more
>recent.

Note that the "methods" (like "bobobase_modification_time")
inside an "FSDTMLMethod" do not act on the "FSDTMLMethod" but
on its (so called) client.

The model is like this:

  The "FSDTMLMethod" is called for an object, its client.

  Most methods used inside the "FSDTMLMethod" from the DTML namespace
  come in fact from "client" (or are acquired by it).

  Therefore, "bobobase_modification_time" give you the
  modification time of the ZODB (!) object that happens
  to be the "FSDMTMMethod"s client.

  When called from ZPublisher (as is apparently your case),
  the client is the object located during URL traversal
  before the "FSDTMLMethod" ("REQUEST.PARENTS[0]", to be precise).

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [DCWorkflow]Problem with initial state

[Dieter Maurer]

Encolpe Degoute wrote at 2006-3-7 20:33 +0100:
>I found something funny yesterday that makes me spend some hours:
>If you delete the state marked as initial state the variable initial_sate 
>always
>contains its id.

Any workflow needs an initial state.

Thus, maybe, you should mark a new state as initial once you deleted
the old one?


In many cases, deleting state is not a good idea (at least not
when there are objects in the deleted state).


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Classes whose instances appear in ZODB

[Dieter Maurer]

George Lee wrote at 2006-3-8 10:17 -0500:
>If I want a class to appear in the ZODB, is that just a matter of
>subclassing SimpleItem?

Usually, classes do not "appear" in the ZODB -- just their instances.

"SimpleItem" is the base class of all (what I call) Zope site building
objects -- the term "Zope site building object" may correspond to
your "may appear in the ZODB".

Perhaps, you will find reading

  

useful.

>What additional attributes do I need to set -- for instance, do I need
>to define 'meta_type' for the class?

"meta_type" is usually used in the so called "add list".
It should be a unique description of your object class such
that you are able to select the object from the add list
when you need it.

You use "ObjectManager._setObject(id, obj)" to put "obj" into
the "ObjectManager". Note, that you must also give "obj" the identical
"id". Otherwise, URL generation will break.


>Can a class be persistent but not have its instances appear in the
>ZODB

Yes.

You can instanciate a class deriving from "Persistent" without
the instance to actually get persisted. It only gets persisted
when you assign it to an attribute of a persisted object.

You may want to read the ZODB guide.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Implicit and Acquirer

[Dieter Maurer]

George Lee wrote at 2006-3-11 00:41 -0500:
> ...
>What is the difference between Implicit and Acquirer? Between Explicit
>and Acquirer?

An acquirer is an object with two components "aq_self" and "aq_parent".
If asked for an attribute, any acquirer passes the request on
to "aq_self" and returns the result if "aq_self" can deliver
the attribute.

The difference between an ImplicitAcquirer and an ExplicitAcquirer
comes only into play when "aq_self" cannot deliver the asked
for attribute. In this case, an ImplicitAcquirer automatically
passed the request on "aq_parent" while an ExplicitAcquirer fails
(with an AttributeError).

>Including, what methods do Implicit and Explicit *add* or *override*?

Both have the same methods (and attribute).

>For instance, does Explicit add an aq_acquire method?

No. But "aq_acquire" is more important for an "ExplicitAcquirer"
than for an "ImplicitAcquirer":

"aq_acquire" supports precise control over the lookup
behaviour of all kinds of acquirers.

With an "ExplicitAcquirer", you (usually) must use "aq_acquire"
to look the attribute up in "aq_parent"; an "ImplicitAcquirer"
would do this automatically (if necessary).

>What else?

Nothing.

>I tried sifting through the C code and the epydoc files but still
>couldn't make sense of it all -- it seems that Implicit and Acquirer
>are really the same, for instance. Answers or references would be very
>appreciated, thanks.

Apparently, you have a reason to use the strange "Implicit and Acquirer"...

In fact, there are two kinds of "Acquirers": "ImplicitAcquirer"
and "ExplicitAcquirer". There is nothing like "Implicit and Acquirer".


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Implicit and Acquirer

[Dieter Maurer]

George Lee wrote at 2006-3-12 00:05 -0500:
> ...
>Other than understanding how Python wraps C classes -- is there anyway
>of seeing where the classes are defined, understanding the methods +
>method definitions, in a Python-looking way?

The "DocFinder" (or "DocFinderTab") shows you the modules
classes are defined in.

If they are defined in Python, you can
directly switch to the code. This does not work for C implemented
classes.




-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [dev] characters allowed in content IDs

[Dieter Maurer]

yuppie wrote at 2006-3-20 18:17 +0100:
> ...
>But I gave up my attempt to fix this in the Zope layer because the 
>related discussion on zope-dev ended without a clear result.

There was a clear result: make the id checker policy configurable --
as Zope 3 does.

>I hope there are no objections against fixing this in PortalFolder's 
>_checkId method for now.

Almost surely, you should make it configurable there, too.

The same arguments apply in CMF land as in Zope land.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] characters allowed in content IDs

[Dieter Maurer]

yuppie wrote at 2006-3-21 21:12 +0100:
>> There was a clear result: make the id checker policy configurable --
>> as Zope 3 does.
>
>Well. That's right but doesn't help us much. We don't have a volunteer 
>for implementing that new feature. And we don't have a consensus what 
>the default policy should be.

If the policy were pluggable, I think that nobody would object
to follow your proposal to use the Zope3 default.

> ...
>Why should I make it configurable?

Because it would be the right way to do it and
because it seems to be the prefered solution by the community.

>I volunteer to fix a serious bug by 
>restoring behavior we had until 6 months ago. An INameChooser based 
>configurable solution would be much more work than just fixing the bug.
>
>> The same arguments apply in CMF land as in Zope land.
>
>You deleted the sentence in which I said what's different IMHO:
>
>> In CMF we plan to use views by default and it's quite common that normal 
>> site members are allowed to add content items.
>
>So it's more urgent to fix the bug in CMF than in Zope.

I would prefer a mechanism as the current CMF uses it:

   Prevent the creation of a content object only when
   it really conflicts with something.

   Or at least, prevent only ids starting with "@@" or "++"
   (as these are the prefixes really used by Zope 3, right?).
   
As mentioned in "zope-dev", I am primarily concerned with WebDAV
integration. And our WebDAV using projects are in fact CMF based.


On the other hand, if I am the only objector, do what you propose.
I am able to change it in our Zope version to fit our needs.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] problem in setting local roles for newly created object

[Dieter Maurer]

Bartek Gorny wrote at 2006-3-29 11:50 +0200:
> ...
>I have a script which creates a new instance of a certain portal_type
>by a method "constructContent", and then calls manage_setLocalRoles.
>And I get an exception:
>
>Module AccessControl.Role, line 362, in manage_setLocalRoles
>AttributeError: __hash__
>
>and the lines in question are:
>361dict=self.__ac_local_roles__ or {}
>362dict[userid]=roles

This means, the "userid" does not have a "__hash__" method
and especially is not as string. But, it should be a string!

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [Optimization] "listFilteredActionsFor"

[Dieter Maurer]

Yuppie already has considerable sped up "listFilteredActionsFor"
for CMF 1.5. However, even after his optimizations "listFilteredActionsFor"
can still consume lots of time.
I found simple situations where it had spend more then 10 percent of
total request time in "testCondition".

I propose to make the category lists lazy objects that perform
condition and permission evaluation only when they are accessed.
This means that action categories not used on a specific page
would not have the expensive "testCondition" evaluated.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CachingPolicyManager and Image/File content

[Dieter Maurer]

Bert Vanderbauwhede wrote at 2006-4-5 15:19 +0200:
> ...
>I'm currently setting up a CMF site for testing purposes. While configuring the
>CachingPolicyManager, I discovered that it didn't work for the Image and File
>content types. However, it worked perfectly for the Document content
>type. I only
>got it working for Image and File after I modified the index_html() method in
>CMFDefault/Image.py and CMFDefault/File.py. Anyone knows what I'm doing
>wrong? Or is this a known problem?

You may look how I made "FSFile" and "FSImage" CachingPolicyManager
aware. The change is now in CMFCore.


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [Optimization] "listFilteredActionsFor"

[Dieter Maurer]

Jens Vagelpohl wrote at 2006-4-8 11:07 +0100:
> ...
>On 2 Apr 2006, at 20:36, Dieter Maurer wrote:
>
>> Yuppie already has considerable sped up "listFilteredActionsFor"
>> for CMF 1.5. However, even after his optimizations  
>> "listFilteredActionsFor"
>> can still consume lots of time.
>> I found simple situations where it had spend more then 10 percent of
>> total request time in "testCondition".
>>
>> I propose to make the category lists lazy objects that perform
>> condition and permission evaluation only when they are accessed.
>> This means that action categories not used on a specific page
>> would not have the expensive "testCondition" evaluated.
>
>Dieter,
>
>I'm sure you have some code samples or ideas for how to make that  
>happen, right?

Up to now, I have only an idea:

  "listFilteredActionsFor" returns a dictionary
  "category --> list of available actions".

  The list is currently a normal list, only available
  actions are appended.

  I want to replace this normal list by a lazy list.
  All actions belonging to the given category are appended
  to it, whether or not they are available.

  The lazy list evaluates action availability as soon as
  one of its "__len__", "__getitem__" or "__getslice__"
  methods are called, filters out unavailable actions
  and then behaves like a normal list.

  The gain: actions in categories not used on the current page
  are not checked for availability.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Trailing Slashes (Or Not) on URLs

[Dieter Maurer]

George Lee wrote at 2006-4-11 03:25 +:
> ...
>When I click on a link with href "#bluh" on a page, it often adds a /#bluh to
>the page.

I think, not Zope but the browsers are to blame.

The "uri" spec dictates that empty urls (apart from the fragment part)
reference the current document.
Browsers, however, somehow seem to use the "base" tag to resolve such
urls (in some circumstances).

Look at the HTML source. When you see "#bluh" in the "href", then
Zope did the right thing but the browser got it wrong.

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [dev] 'request' in expression context

[Dieter Maurer]

yuppie wrote at 2006-4-26 18:25 +0200:
>In createExprContext 'request' is currently set to getattr(object, 
>'REQUEST', None). 'object' might be None, making 'request' None as well.
>
>Would anybody mind if I change that to getattr(portal, 'REQUEST', None)?
>
>AFAICS portal is always available and can acquire REQUEST.
>
>
>If there are no objections I'll fix this in CMF 1.5, 1.6, 2.0 and trunk.

A very good idea!


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Products-less python package support for CMF 1.6

[Dieter Maurer]

yuppie wrote at 2006-6-4 18:12 +0200:
> ...
>AFAIK registerDirectory and registerProfile work only inside of 
>Products.

At least in CMF 1.5, "registerDirectory" works outside "Products", too.

Due to some bad design, it stops working when "Products" is somewhere
inside the path (even if not a complete segment) and this is not
meant as the "Products" directory.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CachingPolicy

[Dieter Maurer]

LESUEUR Frédéric wrote at 2006-6-22 15:08 +0200:
>i have a question about the "_setCacheHeaders" methods inside this
>file CMFCore/utils.py.
>
>Why content is set to aq_parent and not the object itself ?

The model (underlying the caching policy manager) is that
templates (views) access content objects.

In the code above "object" is (usually) the template,
"object.aq_parent" is the object viewed by the template -- i.e.
the content object in the model above.


You are right that the model often does not fit: it does not,
e.g. for "FSFile" and "FSImage" objects (now fixed in the core).

But it also does not fit when the template is used in
its own right and not as a view, e.g. a FSDTMLMethod generating
a style sheet.


The model mentioned above it too narrow. It should be extended
by an additional variable "target" (or something similar)
which is the object traversed to. This might give the policy
handlers enough information to distinguish between the
"template views content" and "template is content itself" cases.

> ...
>The test of a policy is make with parent of object not this object. If
>i have a FSImage, the test is make with this context parent and no
>http cache is set.

This, meanwhile (CMF 1.5 and up) should have been fixed.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CachingPolicy

[Dieter Maurer]

Frédéric LESUEUR wrote at 2006-6-23 10:03 +0200:
>Le Jeudi 22 Juin 2006 20:00, vous avez écrit :
>> LESUEUR Frédéric wrote at 2006-6-22 15:08 +0200:
>
>> This, meanwhile (CMF 1.5 and up) should have been fixed.
>ok thanks, this is what i'm thinking, it fail with object that are call 
>without view (like stylesheet or FSImage ...). Maybe it's ok with newer 
>version of CMF (>=1.5), i can't test at this time.
>It's a CMF (1.4.7) inside a version 3.2.3 of CPS.

If you care, you can backport the change to your older CMF version...

Of course, upgrading might be a better option...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1

[Dieter Maurer]

Rocky Burt wrote at 2006-7-9 10:11 -0230:
> ...
>If we're changing how the keys look, why not simply use full package
>names in front with relative paths after the first slash (although I
>might prefer a colon or something in place of the first slash).
>
>So the new keys would be:
>  "Products.MyProduct/skins/my_skin"
>  "some.long.package/skins/my_skin"
>
>No need to make exception for Products in my opinion.  And the retrieval
>logic would convert the first portion (before the first slash, or as I
>mentioned earlier, perhaps a colon) into an absolute path based on the
>actual package filesystem location.

We have a Zope version where package resources (such as skins)
can come together with the package from a zip archive
(this is a function similar to the newer "egg" Python function).
We identify such resources via "pypackage" urls which have the form

   pypackage:package/path

Here "package" is the full package path (e.g. "path.to.some.package").


This is very similar to your proposal.


I think, when we change something, we should look for a way
that could survive eggification (planned for Zope 2.11).

Something along your proposal might be a very good candidate!



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: DirectoryView, GenericSetup/skins, CMF 2.1

[Dieter Maurer]

yuppie wrote at 2006-7-14 11:30 +0200:
> ...
>> We have a Zope version where package resources (such as skins)
>> can come together with the package from a zip archive
>> (this is a function similar to the newer "egg" Python function).
>> We identify such resources via "pypackage" urls which have the form
>> 
>>pypackage:package/path
>> 
>> Here "package" is the full package path (e.g. "path.to.some.package").
> ...
>Please note that in CMF 2.1 this is just a registry key for looking up 
>DirectoryInformations. It is no longer used for looking up the 
>filesystem resources directly.
>
>The identifiers discussed here are useful for direct lookup, but IMHO 
>they are overkill for registry lookup.

When I remember right, the original question was how these
keys are represented externally -- in a GenericSetup profile.

And there, such a representation may well be adequate...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] returning case insensitive matches for portal_membership.searchMembers()

[Dieter Maurer]

Norbert Marrale wrote at 2006-8-2 17:20 -0400:
>Is there a less expensive way to return case insensitive results when 
>querying portal_membership? (Zope 2.7.5-final / CMF 1.5.5)

The easiest way is to already store the member names lowercase normalized...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: returning case insensitive matches for portal_membership.searchMembers()

[Dieter Maurer]

Norbert Marrale wrote at 2006-8-3 15:22 -0400:
>Upon their initial registration, many users entered their email address 
>in upper or mixed case. The email > username(s) lookup is meant to 
>alleviate the number of support requests, allowing members to receive 
>password reminders even if they forget their registration handles.

This means they have not only forgotten their password but also their
userid?

If they still know the userid, you can directly access the corresponding
user record.

If you did not store the userid normalized, then the best way
would be to do normalization of the userid.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: returning case insensitive matches for portal_membership.searchMembers()

[Dieter Maurer]

Norbert Marrale wrote at 2006-8-4 17:53 -0400:
> ...
>Which brings me to my original Q...
>
>Is there a better way than the two-step approach I'm following:
>
>   emails = context.portal_membership.searchMembers('email','')
>
>and then iterate over emails to find the matches
>
>   if (member==string.lower(emails[n].values()[1])):

You could maintain an additional dictionary mapping the
(normalized) email address to the user id.

If you do not have such a mapping, then your code above is
as efficient as it can be.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] strange problem fixed by _owner

[Dieter Maurer]

Miles Waller wrote at 2006-8-11 16:17 +0100:
> ...
>I stepped through the code and somehow it thinks the user 'admin' is the 
>owner.  I think this is being acquired from somewhere (not sure where). 
>  I added the line _owner = None at the class level in 
>CMFCore.DTMLMethod (analagous to that in CMFCore.FSPythonScript) and 
>everything worked correctly but I'm confused.

If assigning to "_owner" changes something, then the issue
is with the "executable ownership" (this is maintained in "_owner").

An executable object (in this case your DTMLMethod) cannot have
more permissions than its (executable) owner.

In your case, the executing user has more permissions -- but
this does not help.

You may be able to change the executable owner of your DMTLMethod
with the "Take ownership" tab of the object.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: strange problem fixed by _owner

[Dieter Maurer]

Miles Waller wrote at 2006-8-14 09:41 +0100:
> ...
>This is definitely a bug: just returning the result of 
>portal_actions.listFilteredActions( object ) yields different results 
>depending on whether it is done in a python script or a dtml method.

It will not depend on the type of the object (Python script or DTML Method)
but on the object's (executable) owner.


>I'll file a bug report.

And, it is not a bug -- but documented behaviour



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: .metadata files, latin-1 vs. unicode, and encoding errors

[Dieter Maurer]

Florent Guillaume wrote at 2006-9-4 20:38 +0200:
>I'd say it would be cleaner to let the .metadata specify its own encoding, 
>for instance with a
># coding: utf-8
>at the top, and pasrse that in FSMetadata.

I find this a good suggestions -- but would use the declaration syntax
used also in (e.g.) Python.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] caching policy manager

[Dieter Maurer]

Jens Vagelpohl wrote at 2006-9-13 09:15 +0200:
> ...
>It is a long-standing bug that the CMFDefault File index_html (and  
>download, which is obsolete in newer CMF versions) simply defers to  
>index_html from OFS.File. That one doesn't know anything about Cache  
>Policy Managers, it only deals with the Zope ZCacheable cache manager  
>mechanism.

I have defined CMF-aware ZODB object types. The one for "File" looks
like this:

# DM 2005-11-02: added
""" CMF 'File' variant (CMF Cache Policy Manager aware)"""

from OFS.Image import File, manage_addFileForm, cookId

from utils import _setCacheHeaders, _ViewEmulator

class CMFFile(File):
'''CMF cache policy manager aware file.'''
meta_type = 'CPM aware File'

def index_html(self, REQUEST, RESPONSE):
' '
r = File.index_html(self, REQUEST, RESPONSE)
if self.ZCacheable_getManager() is None:
# not none cache manager already taken care of
_setCacheHeaders(self._getCPMCachingWrapper(), extra_context={})
return r

# DM 2006-05-17: more modular CPM caching
def _getCPMCachingWrapper(self):
return _ViewEmulator().__of__(self)
  

# essentially a copy of "OFS.Image.manage_addFile" -- we should probably
# use "ReuseUtils".
def manage_addFile(self,id,file='',title='',precondition='', content_type='',
   REQUEST=None):
"""Add a new File object.

Creates a new File object 'id' with the contents of 'file'"""

id=str(id)
title=str(title)
content_type=str(content_type)
precondition=str(precondition)

id, title = cookId(id, title, file)

self=self.this()

# First, we create the file without data:
self._setObject(id, CMFFile(id,title,'',content_type, precondition))

# Now we "upload" the data.  By doing this in two steps, we
# can use a database trick to make the upload more efficient.
if file:
self._getOb(id).manage_upload(file)
if content_type:
self._getOb(id).content_type=content_type

if REQUEST is not None:
REQUEST['RESPONSE'].redirect(self.absolute_url()+'/manage_main')


def initialize(context):
context.registerClass(
CMFFile,
permission='Add Documents, Images, and Files',
constructors=(manage_addFileForm,
  manage_addFile),
)



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] caching policy manager

[Dieter Maurer]

Dmitry S. Makovey wrote at 2006-9-15 09:04 -0600:
> ...
>> I have defined CMF-aware ZODB object types. The one for "File"
>> looks like this:
>>
>> # DM 2005-11-02: added
>> """ CMF 'File' variant (CMF Cache Policy Manager aware)"""
>...skip...
>
>Dieter, are you saying that it's fixed somwhere in SVN or is it in 
>your "private" repository?

In our private repository.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CachingPolicyManager

[Dieter Maurer]

Miles Waller wrote at 2006-10-11 16:34 +0100:
> ...
>output_page_2:
>==
>Here is the subtitle from template 2
>
>2.  Add a rule to the cpm as follows:
>
>id: "template_test"
>predicate: view.endswith('_2')
>etag: string:"template_test"
>
>3.  Make a request for /output_page_1
>
>4.  Note that the caching rule for output_page_2 is applied
>
>This is because the cpm is called whenever a FSZPT is called - so the 
>call to the second template causes it to check it's rules again.
>
>My question is, does this count as a bug?

I would say "yes"...

Please file a bug report to the CMF collector.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] CachingPolicyManager

[Dieter . Maurer]

Jens Vagelpohl wrote at 2006-10-11 12:03 -0400:
> ...
>I'm not sure this can be called a bug. It is true (and perfectly  
>normal) that rendering a filesystem page template will always call  
>the CPM. You're rendering both here. Since output_page_2 is rendered  
>last as it's calles from output_page_1 the rule for output_page_2  
>fires and will overwrite existing headers/add new headers according  
>to the rule that fires. The problem here is that both happen in the  
>same request, the rendering code does not distinguish betwen the  
>primary and the nested rendering.

Thus, this *is* the bug. It should distinguish between primary and nested
rendering.

Unfortunately, the bug is probably deep -- affecting the complete
cache integration. Even more importantly, for a RAM cache it may
even be a good thing that the "nested" rendering can cache in addition
to the "primary" rendering.



-- 
Viele Grüße
Dieter

Tel: 06894-870 177
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] email_charset: a small proposal

[Dieter Maurer]

Wichert Akkerman wrote at 2006-10-13 15:48 +0200:
>Previously yuppie wrote:
>> Some people still use email clients that don't support utf-8. So you 
>> might have a policy to send iso-8859-1 emails even if your content is 
>> utf-8 encoded. At a later point you might want to change that policy.
>
>Do those people expect to be able to read non-ascii mails? I suspect
>not, in which case utf-8 will not change their situation.

Until quite recently, I belonged to "those people". Yes, I expected to
read non-ascii mails -- until more and more emails used "utf-8" encoding
and were not so easy to read. Then, I invested a day to find out
how to enable "utf-8" decoding...

-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [dev] _checkEmail issues

[Dieter Maurer]

Charlie Clark wrote at 2006-10-20 15:50 +0200:
> ...
>There is a module for testing domains against a DNS  
>which is much more reliable. Regarding the rest I normally check with  
>the responsible MX server as negatives are usually reliable.

DNS queries can take quite a long time -- and we have seen
quite a few cases where the DNS query timed out for
perfectly valid domains.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager

[Dieter Maurer]

Crosspost: 'Reply-To' set to 'zope-cmf'.

We nearly escaped a catastrophy: a page with sensitive personal
information ended in a shared cache and was delivered to arbitrary
people. This happened despite the fact that the template generating
the page contained a "response.setHeader('Cache-Control', 'no-cache')"
(and related headers for non HTTP/1.1 clients).

The analysis quickly revealed broken design in the
CMF Caching Policy Manager (CPM)
as the cause:

  *  it has applied its general policy depite the fact that
 the template itself has provided more adequate decisions with
 respect to caching

  *  the caching policy manager action affects the complete response.
 Therefore, only the top level object, the object that controls
 the response content, should influence the CPM decisions.

 In the concrete case, the primary template did not trigger
 the CPM but the call of a secondary template responsible only for a tiny
 part of the response.

The same problem also affects Zope's HTMLCacheManager.


The description indicates in what direction the CPM should get fixed:

  * If the response already provides cache control, the CPM should
not override it, as it is likely that the specific information
available to the response generating process is more trustworthy
then the general CPM policies.

This is arguable, especially as it changes the current behaviour.
Maybe, it should be controlled by an additional configuration option.

  * The CPM (and Zope's HTTP Cache Manager) must set cache headers
only based on the object that generated the (complete) response
entity and not based on other objects called during the request
(and probably only responsible for part of the entity).


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager

[Dieter Maurer]

Jens Vagelpohl wrote at 2006-12-17 19:57 +0100:
> ...
>I don't know if it is possible to have any sane policy about "what to  
>do if the response already has caching headers". First of all, when  
>should this exception policy trigger? Which headers should tell the  
>CPM that someone else already decided on caching? Secondly, what is  
>the behavior supposed to be? "Do nothing"? "DWIM"? This obviously  
>needs exact specifications and use cases.

The HTTP/1.1 specification tells us what cache-control headers are for
and we can deduce from it how to merge "concurrent" cache controls
when the aims of HTTP/1.1 are respected (ensure "semantic transparency").

I sketched this in the collector issue.

> 
>>   * The CPM (and Zope's HTTP Cache Manager) must set cache headers
>> only based on the object that generated the (complete) response
>> entity and not based on other objects called during the request
>> (and probably only responsible for part of the entity).
>
>As mentioned in my reply to your collector issue, there are fixes on  
>the CMF trunk already and you should look at those to see if they fix  
>your problem.

As I replied in the collector: I improves the state of affairs a lot
but it still only a partial solution...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager

[Dieter Maurer]

Wichert Akkerman wrote at 2006-12-18 08:38 +0100:
>Previously Dieter Maurer wrote:
>> The description indicates in what direction the CPM should get fixed:
>> 
>>   * If the response already provides cache control, the CPM should
>> not override it, as it is likely that the specific information
>> available to the response generating process is more trustworthy
>> then the general CPM policies.
>
>If we want to make CPM smarted wouldn't it make more sense to have it
>select the most restrictive set of caching settings?

Yes, that is something, I called "intelligent merging".



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [Warning] Danger from Zope caching, especially the CMF Caching Policy Manager

[Dieter Maurer]

Miles Waller wrote at 2006-12-18 12:57 +:
> ...
>At the moment, the CPM fires after rendering, so setting it's own 
>headers and overwriting any headers set in the template.  If it fired 
>before rendering, then a template would be free to set whatever policy 
>it wanted.
>
>Is there a special reason why it needs to set the headers after 
>rendering, rather than before?  I can't think of a reason, but then our 
>policies are about as simple as can be.

I expect this was to counter the effect that "recursively" called
templates could trigger the CPM as well. If the CPM is activated
before the actual rendering, then these "recursive" activations
would override the effect of the "top" activation.

The latest CMF version tries to detect "recursive" activations
and suppress them. Nevertheless, your proposal would not be
safe, as shown this this example:

  You have a script "someScript" with the following body

container.REQUEST.response.setHeader('Cache-Control', 'no-cache')
...
context.someTemplate(...)

then the call to "someTemplate" may override the "Cache-Control"
set before, even with your proposal.

Of course, the script could set the header after the template call --
*IF* it were aware of the danger. However, I doubt that this will be the
case


-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Andreas Jung wrote at 2006-12-20 19:34 +0100:
> ...
>Right. The pt_render() should return unicode only. Let's assume 
>FSPageTemplates would use unicode internally and a customized copy (an 
>instance of ZopePageTemplate) wouldn't then we would definitely run
>into UnicodeDecode errors. That's why we should use unicode as internal
>representation where possibly. However applications will likely run into
>UnicodeDecode error for example with scripts returning non-unicode...

Yes, you need "all text is unicode" or non-unicode encoded in a
default encoding. Its up to you, how you define "default encoding".

I would use Python's default encoding. But I know that we disagree
on this solution :-)



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Martin Aspeli wrote at 2007-1-6 22:06 +:
>Hanno Schlichting wrote:
>
>> The idea is to use a specialized persistent component registry, that
>> does the needed AQ-wrapping.
>> 
>> This will however only give us AQ-wrapped local utilities, whereas those
>> registered with the global component registry wouldn't be wrapped. I
>> think this might be an acceptable trade-off.
>
>Are you sure? Does *every* local utility want an aq wrapper?

Some of them want (e.g. the "Catalog" and the proposed "ISiteRoot" "utilitiy").

Thus, it is easier (for all of us) when all utilities with
an "__of__" method are wrapped.

> 
>I'm not even sure if tools that are well-written (do not rely on 
>acquiring things from 'self') need to do so except for security when 
>called TTW, in which case getToolBy(Interface)Name will do the trick.
>
>Bluntly adding acquisition like this seems like a step in the wrong 
>direction, imho.

Currently returned tools (via "getToolByName")
are acquisition wrapped. I think this should stay this way.


In Zope 2, non acquisition wrapped objects behave very strangely.
E.g. most "OFS.Traversable.Traversable" methods no longer
work correctly; and (as you already noted) security fails.
In my view, this indicates that all objects with "__of__" method
should be correctly acquisition wrapped.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Martin Aspeli wrote at 2007-1-6 22:22 +:
> 
>  - Registering the portal as a utility that can be obtained by 
>getUtility(IPortalRoot) is pretty good practice; in my estimation, that 
>should solve all the use cases for utilities where acquisition is used 
>now and where we're not really after an adapter, view.

But the returned object is almost worthless, if it is not
acquistion wrapped (otherwise, it is not even able to determine its
'getPhysicalPath' or 'absolute_url').

Thus, the proposal exhibits an essential example that local
utilities should be returned acquisition wrapped (if the have an '__of__'
method).



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Hanno Schlichting wrote at 2007-1-7 23:42 +0100:
> 
>> Thus, the proposal exhibits an essential example that local
>> utilities should be returned acquisition wrapped (if the have an '__of__'
>> method).
>
>Maybe a compromise would be to only return those utilities back
>acquisition wrapped that where registered as tools?

Why?

When an object implements "__of__", this indicates that it is willing
to play with the "ExtensionClass" context feature (usually used for
acquisition). Why can we not use this indication?



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Martin Aspeli wrote at 2007-1-7 23:40 +:
> ...
>Why not do it a more Zope3 ish way:
>
>class ICMFTool(Interface):
>"""Marker for any CMF tool"""
>
>and then in the subclass of the local component registry:
>
>local_utility = 
>if ICMFTool.providedBy(local_utility):
> local_utility = local_utility.__of__(context)
>
>or so.

No need to invent a new marker interface for this.

  Objects ready to participate in context wrapping indicate this
  by the "__of__" method...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Martin Aspeli wrote at 2007-1-8 21:35 +:
> ...
>No, no need, but I'd argue good reasons.
>
>  - It's an explicit declaration of support

As is the definition of "__of__".

>  - It's a lot less magic

I do not follow you:

  Where is the magic with "if hasattr(local_utilitiy, '__of__')"
  compared to "if ICMFTool.providedBy(local_utilitiy)".

  I feel the "ICMFTool" marker interface (almost like all marker
  interfaces) as more magic.

>  - It's prettier than getattr/hasattr

Your notion of "pretty" is very much different from mine...

>  - If something else has an __of__() for whatever reason, we don't 
>catch it by accident.

If "local_utilitiy" has an "__of__", then it almost surely expects
that it is used in the standard way -- whether or not some magic
marker interface is there

>  - It may not be desirable to wrap everything that *could* be wrapped.

Could you explain?

In the Zope 2 world, non acquisition wrapped objects behave very strange
(as indicated in an earlier message).
Do you want to introduce special cases only that you can use Zope 3 magic?



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode

[Dieter Maurer]

Martin Aspeli wrote at 2007-1-9 20:48 +:
> 
>>>  - It's an explicit declaration of support
>> 
>> As is the definition of "__of__".
>
>Well, not in a formal sense. I could have some non-Zope python object 
>that I wanted to register as a local utility (to override a global one, 
>say) that could have __of__() for some other reason.

Theoretically, you might be right -- but not practically
in the "ExtensionClass" based environment of Zope 2.
There you have: if an object has an "__of__" it is used
for context wrapping -- as soon at it happens to be accessed
as attribute of an "ExtensionClass" instance.

In this environment, it is more homogenous and natural to just wrap 
with "__of__" when it is present than looking for an additional
marker interface.

> ...
>I doubt it matters in this case (I'd guess __of__() is not a very common 
>method name outside Zope, and this would be pretty localised code)...

More precisely, "__of__" has special (documented) meaning for "ExtensionClass".

> 
>>>  - It may not be desirable to wrap everything that *could* be wrapped.
> ...
>What if the method wasn't __of__() but get_size() or something in a 
>different context?

I think, I would not have argued about automatic "get_size" wrapping --
unless it were so common as "ExtensionClass"'s "__of__" wrapping.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: Adding python packages to ProductsPath

[Dieter Maurer]

yuppie wrote at 2007-1-23 18:55 +0100:
> ...
>Yes, I object. This is a hack that resolves the issue just for some 
>special use cases. We need a solution that works with python packages 
>anywhere in the python path.

And "packageresources"
(http://www.handshake.de/~dieter/pyprojects/packageresources.tgz";
can show a way to do it. An alternative could be the upcoming egg's
support for egg local resources.

With "packageresources" a python package/module is identified by
an url of the form "pypackage:", e.g.
"pypackage:Products.CMFCore" or "pypackage:Shared.DC.ZRDB.DA".
A resource (e.g. a file or directory) local to a package
is identified by an url

   "pypackage:/",

e.g. "pypackage:Products.CMFCore/skins"


As you can see: this allows to specifiy location independent
skin directories.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] workflow and deletes

[Dieter Maurer]

Miles wrote at 2007-2-14 14:10 +:
> ...
>I'd like my workflow to be notified when an object is deleted, so it has 
>the chance to veto deletion, or do some tidy-up on related objects. 
>However at the moment, the workflow tool is not wired up to react to 
>deletion at all.

You might be able to proceed as follows:

  *  You restrict the "Delete objects" permission such
 that normal users are no longer able to delete objects

  *  You implement a script that performs the object deletion.
 You give it a proxy role that it *can* delete objects.

  *  You add a "delete" transition to your workflows that
 calls your script to delete the object.

 Due to an outrageously long standing bug, proxy roles
 are not working for "DCWorkflow" workflow scripts.
 You need to use a second script that calls your script.



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Removing ancient LoginManager-compatibility code

[Dieter Maurer]

Jens Vagelpohl wrote at 2007-3-12 10:11 +0100:
>There's some LoginManager compatibility code in  
>CMFCore.MembershipTool (see __getPUS and addMember) that I would like  
>to remove. LoginManager has gone the way of the Dodo several years  
>ago, I'd say at least 4 years ago. IMHO with this stuff there is no  
>need for a deprecation period.
>
>Comments or suggestions? Silence is consent ;)

I often wonder whether you do not have more pressing tasks :-)
Me would never come to the idea to do such cosmetic changes...



-- 
Dieter
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See http://collector.zope.org/CMF for bug reports and feature requests