Re: [Zope-CMF] Proposal: Action expression contexts

[Dieter Maurer]

Miles wrote at 2009-3-31 10:10 +0100:
>One of the things that we find slightly cumbersome here in our 
>applications is that when defining actions, there's no easy way to 
>adjust the variables available to an expression.  This tends to make the 
>expressions longer and harder to read, plus commonly used variables are 
>calculated multiple times.
>
>For example, my application has a concept of a "page", and I would like 
>to make this available as a variable rather than work it out each time.
>
>Therefore I think it would be useful to adjust getExprContext in 
>CMFCore.Expression so that it is pluggable, by using a factory to create 
>the ExpressionContext.  In that way I can register different ones as 
>required.
>
>Is this a desirable change?

I like it.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] IndexableObjectWrapper

[Dieter Maurer]

Wichert Akkerman wrote at 2009-3-10 10:01 +0100:
> ...
>The debate is currently focusing on GPL versus BSD license. Any opinions
>on a choice between those two would be very welcome.

I like BSD more, but could live with LGPL as well.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] .zexp imports and notifyWorkflowCreated

[Dieter Maurer]

Wichert Akkerman wrote at 2009-2-18 21:51 +0100:
> ...
>> That's how copy and paste resets the workflow state.
>
>Which is argueably a mis-feature: it means you are not just doing a copy
>and paste, but a copy, paste and modify.

> ...
>In my opinion a copy should produce a full copy, including all state and
>history.

For some workflows, it may not be adequate to retain the state
after a copy.

Consider a publication workflow with a site organized
along subjects with different subject reviewers.
Object "o" is released in subject "s1". Now it is copied
to subject "s2". I think it is obvious that "o" needs a review
at its new place.


In addition: I is highly doubtfull that the "creation_date"
of the copy should be the same as the creation date of the original.

At least in our contexts, copies are usually made to be modified
later (slightly). For this use case, the "creation_date" should
be set to the time the copy was created *and* the copy
should start in the initial state.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup

[Dieter Maurer]

Jens Vagelpohl wrote at 2009-2-16 13:48 +0100:
> ...
>Does anyone else have a specific opinion for this case, disregarding  
>the five.localsitemanager discussion?

Dependancies should be as loose as possible.

  If a component uses "CMFDefault" but only indirectly "CMFCore",
  it should specify "CMFDefault" as a dependency but not "CMFCore".

  If it explicitely uses both "CMFDefault" as well as "CMFCore", specifying
  both may be more future proof.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] five.localsitemanager: dependencies

[Dieter Maurer]

Tres Seaver wrote at 2009-2-14 20:31 -0500:
> ...
>For all its flaws, setuptools fixes a lot of what is horribly broken in
>distutils:  most of the flaws arise from the choice to stay
>pseudo-compatible with distutils, and reuse it, rather than starting
>from scratch.

But the dependancy handling is obviously introduced by "setuptools".



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] five.localsitemanager: dependencies

[Dieter Maurer]

Charlie Clark wrote at 2009-2-14 16:22 +0100:
> ...
>I'm not that familiar with Buildout but I would have thought that any  
>direct import dependencies should be listed - and zope.location  
>doesn't seem to be (neither are zope.event or zope.site for that  
>matter). OTOH the condition >= seems to be being incorrectly  
>interpreted. If this is a bug then it should be filed.

You are right, but unfortunately this is quite a deep problem
in "setuptools". "setuptools" does not determine the complete
dependancy graph and then looks for a global solution to the
set of restrictions.
Instead it satisfies restrictions incrementally thereby committing
some versions -- and may later find that they conflict with other
requirements.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

yuppie wrote at 2009-1-19 22:54 +0100:
> ...
>Products.Five.browser.decode.setPageEncoding sets the response content 
>type charset based on zope.publisher.http.HTTPCharsets. And 
>setPageEncoding is called by the update method of formlib forms in Zope 
>2. So in this case the response encoding has something to do with the 
>"Accept-Charset" request header.

Wow. Some magic in "formlib" deviating from the Zope2 standard behaviour

But, if this is true, we do not understand Charlie's observations:

  When I understood him right, he is using formlib and he is observing
  problems with the charsets.

  He found out that this has to do with IE browsers sending an
  empty "Accept-Charsets" header which is turned by Zope's
  "preferredCharset" into "iso-8859-1".

  But when the same charset is used on both form delivery and
  on form processing he should not see a problem with mismatched
  encodings.

Of course, "iso-8859-1" may not be approriate for form delivery --
and may result in funny special characters in non-western countries.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

Charlie Clark wrote at 2009-1-18 22:30 +0100:
>Am 18.01.2009 um 20:36 schrieb Dieter Maurer:
> ...
> From the current HTML specification:
>
>"accept-charset = charset list [CI]
>This attribute specifies the list of character encodings for input  
>data that is accepted by the server processing this form. The value is  
>a space- and/or comma-delimited list of charset values. The client  
>must interpret this list as an exclusive-or list, i.e., the server is  
>able to accept any single character encoding per entity received."
>
>ie. exactly as you have suggested: it is possible to force a client to  
>encode data in a particular charset before sending it to the server.  
>All references I have come across suggest that this, together with the  
>meta tag content-type can and should be used to coerce browsers to use  
>UTF-8.

I fear that the "accept-charset" form control attribute
can easily only be used for "method=post content-type=multipart/form-data"
as only then the browser has a chance to specify how it has
encoded the value.

I am not sure whether Zope handles the "charset" information
in this case correctly.


As the "Accept-Charset" request header has (almost) nothing to do
with the "accept-charset" form control attribute, it must of course
not be used to interpret form data even when this was created
based on an "accept-charset".


If the server chooses its output encoding based on the "Accept-Charset"
request header (and Yuppie indicated that the Zope 3 publisher does this),
then the same algorithm can be used for "normal" form data
(where "normal" means, you do not explicitely specify an "accept-charset"
form control attribute).
That's one sensefull mode of operation.
Another one is choosing a fixed encoding and using it as input and
output encoding.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

yuppie wrote at 2009-1-19 11:32 +0100:
>Charlie Clark wrote:
>> Am 18.01.2009 um 23:00 schrieb yuppie:
>> I agree that there shouldn't be implemented in a different way than  
>> for Zope 3. And if we can solve the problems by fixing form encoding  
>> I'm happy. Although I'd like to see UTF-8 always the first charset  
>> returned if * the quality is the same.
>
>zope.publisher.http.HTTPCharsets explicitly prefers utf-8. Are you sure 
>getPreferredCharsets()[0] is iso-8859-1 with your browser?

This might be true for the Zope 3 publisher
however, Zope 2 "HTTPResponse" uses "default_encoding" (configured
in "zope.conf") unless an encoding is prescribed by the response
content type -- and this has nothing to do with the "Accept-Charset"
request header.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

Charlie Clark wrote at 2009-1-18 15:49 +0100:
> ...
>I would suggest that we work towards enforcing UTF-8 in where possible  
>but at the very least add the accept-charset attribute to forms and  
>use the portal's default_charset for this.
>
>I'd very much appreciate your comments on this.

The "Accept-Charset" request header should *never* be used
to guess a charset at the server side:

  "Accept-Charset" is a user preference which does not know
  anything about charsets used by the server.

If "utf-8" would not be treated with preference in the
current code, the code base would see massive problems.

Only the server knows which charsets it is using -- and it should
use a single one (with very few exceptions).
There should be a configuration option that tells this charset
and this should be used to decode form data.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Running functional tests in a buildout environment

[Dieter Maurer]

Charlie Clark wrote at 2009-1-12 17:54 +0100:
> ...
>bin/test -vv -fs ~/CMF-Sandbox/cmf-trunk/src/Products.CMFDefault/ 
>Products/CMFDefault/browser/ tests.py
>Running tests at level 1
>Total: 0 tests, 0 failures, 0 errors in 0.000 seconds.

For modern Zopes the value for the "-s" option is a module
(e.g. "Products.CMFDefault").
You would use "--package_path" when you want to specify
a location for a package (likely).

There is BBB code that tries to handle paths also for
"-s" but this code is highly dubious (and probably not
working in all cases).

The "zope.testing" experts are Jim and Christian (Th.).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Cleaning up imports, question about odd "feature"

[Dieter Maurer]

Charlie Clark wrote at 2008-12-30 13:17 +0100:
>Am 29.12.2008 um 19:20 schrieb Tres Seaver:
>
>> As Jens noted, this change is for FSProperties and FSSQLMethods only.
>
>Yep, and these aren't generally objects that need to be changed  
>frequently in the FS.

But if possible, all FS* objects should behave identically with respect
to "debug-mode on". It should not be the case that, e.g., "FSPageTemplate"
is reread in debug mode but "FSProperties" is not.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

Charlie Clark wrote at 2008-12-19 11:35 +0100:
> ...
>> Usually, the client will use the charset it has found in the
>> page containing the form. Thus, unless this charset has been
>> determined automatically from the "Accept-Charset" header,
>> it is merely accidental when the client preferences ("Accept-Charset")
>> is able to guess the charset correctly.
>
>
>Right. So I must be doing something wrong if all Zope has to go on for  
>decoding the form is the Accept-Charset? How can I set an encoding for  
>the form?

The site should deliver all pages containing forms (if possible even
all pages) with a single charset, let's call it the "site charset".
Then it uses this same charset to interpret form data.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Charsets

[Dieter Maurer]

Charlie Clark wrote at 2008-12-14 12:32 +0100:
>Am 13.12.2008 um 18:40 schrieb Charlie Clark:
>
>> Hi,
>>
>> I'm struggling with the way formlib forms handle decoding from forms.
>> It looks like this gets set in BrowserView using an
>> IUserPreferredCharsets adapter. The default adapter seems to be in
>> zope.publisher.http and it looks like latin-1 will be set if there is
>> no other charset and I'm having problems with the em-dash and en-dash
>> (u'\u2013' and u'\u2013') characters automatically being converted
>> from latin-1 when they are being entered as cp1252. For content that
>> doesn't through this decoding I have no problems if zpublisher- 
>> default-
>> encoding is set to cp1252 and the default_charset is set to cp1252 as
>> well: decoding with CMFDefault.utils.decode() works just fine.
>>
>> I suspect I'm missing something basic in the way charsets are handled
>> but as it's a windows only IE6 environment, is the easiest solution
>> writing an adapter that defaults to cp1252 if there is no
>> HTTP_ACCEPT_CHARSET in the request header?
>
>
>Overriding the adapter works fine. I'm still a bit confused by the  
>original code:

It is usually insane to use client preferences to guess the encoding
used in form data.

Usually, the client will use the charset it has found in the
page containing the form. Thus, unless this charset has been
determined automatically from the "Accept-Charset" header,
it is merely accidental when the client preferences ("Accept-Charset")
is able to guess the charset correctly.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] adding 'context' as an alias for 'object' in action expressions

[Dieter Maurer]

Ross Patterson wrote at 2008-11-30 11:25 -0800:
> ...
>I'm not really up on the historical considerations, but I'm definitely
>in favor of "context" and definitely opposed to "object".  "object" is
>too generic, the request is an object after all, everything is an
>object.  "context" reads more like what it is.

+1

Of course, it should be consistent (as Yuppie noted), i.e.
"context" everywhere (the same way in scripts, views, actions,
templates, ).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF write performance as poor as Plone?

[Dieter Maurer]

Andreas Jung wrote at 2008-11-23 09:24 +0100:
> ...
>> Have you profiled an individual request to learn what the time is spent for?
>>
>> If the time is dominated by client side activity, you need client side
>> skaling to increase the throughput significantly.
>
>>
>> If, on the other hand, the time is heavily dominated by server side activity,
>> you would need backend skaling (which is currently quite difficult
>> to get) or get the backend significantly faster (I assume that
>> the bandwidth is not the limiting factor).
>>
>
>This issue is independent of the client-side. ab2 and cmf/plone were
>running on the same (fast) machine.

The other responses you have gotten indicate that client side
activity (especially indexing) can significantly influence
the observed "write performance" (going down by one order of magnitude).

That means: it might be worth to check explicitely that this is not
the case in your setup.

If indexing is suppressed/delayed (as indicated in the other responses),
the number of "store" operations also decrease. Each "store" operation
may account for a few ms (I have observed a general ZEO overhead
of about 3 ms -- however some years ago and therefore on an older
hardware geneation; things may be faster nowadays).
Looking at the number of your "store"s (and the time they take),
you may check whether this may account for the pure write performance
you observe.
In this case, optimizations would be possible. In principle, the
"store"s could be batched rather than transmitted individually (of course,
this would require ZODB modifications).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF write performance as poor as Plone?

[Dieter Maurer]

Andreas Jung wrote at 2008-11-21 07:31 +0100:
> ... write performance ...
>However the transaction size does not 
>seem to have any impact on the number of simulataneous writes.

Have you profiled an individual request to learn what the time is spent for?

If the time is dominated by client side activity, you need client side
skaling to increase the throughput significantly.

If, on the other hand, the time is heavily dominated by server side activity,
you would need backend skaling (which is currently quite difficult
to get) or get the backend significantly faster (I assume that
the bandwidth is not the limiting factor).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Dieter Maurer]

Charlie Clark wrote at 2008-11-20 20:33 +0100:
> ...
>Agreed. If third party tools have problems, then they should provide  
>the solutions.

The Plone people are much more open to integrate third party solutions
(a good thing in principle). But, they have only limited control
over third party solutions. Therefore, they changed their CMF version
to give third parties more time to adapt to a more Zope 3 style
of doing things (e.g. accessing request only on code paths specifically
designed for request processing).

Note, that not everybody finds a more Zope 3 style of doing a worth
in itself -- with corresponding reluctance to change something just
for this purpose.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Dieter Maurer]

Martin Aspeli wrote at 2008-11-18 16:25 +:
> ...
>This won't solve this particular problem, but it may be worth looking at 
>how other frameworks work. Pylons, for example, has the request 
>available as "global" variable - actually a thread-local. Zope could set 
>the request as a thread local in the same way that it sets the site 
>manager (so you can get it via getSite()). Calling getRequest() would in 
>many ways be cleaner than doing self.context.REQUEST or whatever, and 
>would work regardless of whether the context was acquisition wrapped.

That, too, would be a solution to access the often needed request --
just not the typical Zope2 one: i.e. lots of rewrites would be necessary.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Dieter Maurer]

yuppie wrote at 2008-11-18 12:00 +0100:
>Dieter Maurer wrote:
>> Thus, why do local utilities registered by Five (i.e. these utilities are
>> for Zope2 use) do not provide access to the request in the normal
>> Zope2 way?
>
>That's what we tried first. But it turned out that Zope 3's site manager 
>code caches the utilities across request boundaries. AFAICT it would 
>have been necessary to rewrite the registry code completely to make sure 
>we return always the right request.
>
>> If they would, local utilities were much nearer to tools and
>> the transition would be facilitated.
>
>They would be nearer to tools, but also more distant from zope 3 
>utilities. I doubt that would really be a win.

Then, maybe, Zope 3 utilities are inadequate at many places in
to Zope 2 world: e.g. any tool that uses TALES expressions may
want to access the (current, of course) request -- especially
when they are destined for user interaction (as actions are).

In view of this, one can understand that Plone has problems with
the "setup_tool" utility registration.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] Should portal_setup be registered as utility?

[Dieter Maurer]

Wichert Akkerman wrote at 2008-11-17 08:21 +0100:
> ...
>I'm sure CMF import/export steps are fine. The CMF tools are not, and
>third party products use those in their steps. That is exactly the
>problem we where seeing in Plone, and which is why I removed the utility
>registration.

Zope is a Web application framework.
Obviously, the request is quite important for many tasks related
to Web processing.

Zope3 may have other, cleaner ways to access the request.
But Zope2 has just two ways -- explicit passing and request access
via the acquisition context.
Thus, why do local utilities registered by Five (i.e. these utilities are
for Zope2 use) do not provide access to the request in the normal
Zope2 way?

If they would, local utilities were much nearer to tools and
the transition would be facilitated.


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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?

[Dieter Maurer]

Jens Vagelpohl wrote at 2008-10-11 09:21 +0200:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>
>On Oct 11, 2008, at 08:16 , Dieter Maurer wrote:
>
>> Jens Vagelpohl wrote at 2008-10-8 14:57 +0200:
>>> ...
>>> As far as the feature itself is concerned, I've never seen a  
>>> situation
>>> where this is useful or needed.
>>
>> As so often -- we need it :-)
>> Our "MembershipTool" instance is (together with the portal)
>> in a read only mounted storage
>> while the "Members" folder obviously has to be in a read/write mounted
>> storage.
>
>As so often, you have never mentioned that this is useful or  
>needed ;-)

I did -- in the message you have reponded to ;-)
I did this to support Raphael's extension request.

For us, there was no need to change "CMFDefault" (which we do not use
at all) nor "CMFCore". Instead, we implemented the additional
flexibility in a class derived from "CMFCore.MembershipTool.MembershipTool".

> Seriously, I know you may have some use cases that few of  
>use will ever see or need, but if there's no feedback at all then it's  
>not possible to consider them.

Sure. And my response had not the intension to blame the CMF developpers
why a much needed feature is still not available
but only to threnghen Raphaels request for a minor extension :-)

>If you have a fully-tested patch I'll be happy to look at it.

As I understood, Raphael has one. I do not as we have a separate
"MembershipTool" (only derived from that of "CMFCore").

@Raphael: I suggest to put the extra flexibility into "CMFCore" (and not
only into "CMFDefault").



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?

[Dieter Maurer]

Jens Vagelpohl wrote at 2008-10-8 14:57 +0200:
> ...
>As far as the feature itself is concerned, I've never seen a situation  
>where this is useful or needed.

As so often -- we need it :-)
Our "MembershipTool" instance is (together with the portal)
in a read only mounted storage
while the "Members" folder obviously has to be in a read/write mounted
storage.



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] MembershipTool: Using traversal to look up the Members folder?

[Dieter Maurer]

Raphael Ritz wrote at 2008-10-8 13:36 +0200:
>Currently, CMF(Default - and Plone for that matter) does not support
>this OOTB because CMFDefault's MembershipTool uses a simple getattr
>call for the 'membersfolder_id' on the site object.
>Changing this to use 'unrestrictedTraverse' instead resolves
>the problem including the possibility to specify the path (or
>relative content URL) to the folder in ZMI.

We are using this -- with our own implementation of the "MembershipTool",
derived from the one provided by "CMFCore".



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] 'add' actions and views - a proposal

[Dieter Maurer]

yuppie wrote at 2008-9-21 13:48 +0200:
> ...
>>> Proposed CMFCore TypesTool changes
>>> --
>>>
>>> 7.) listActions of the types tool returns add actions for *all* portal 
>>> types.
>> 
>> +1 - this change is already done, right?
>
>Yes. Checked in yesterday.

But hopefully, the different "add" actions can be grouped
easily. We have portals with many dozens of add actions and
do not want to present them on a single page (but have them
grouped on several pages according to foci -- we are currently
use appropriate "category"s for the grouping).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMFActionIcons vs. new-style actions

[Dieter Maurer]

yuppie wrote at 2008-9-18 11:13 +0200:
> ...
>I personally prefer to move all type info Actions to the actions tool. I 
>can't see a need to specify separate 'view', 'edit' or 'metadata' 
>Actions for each content type. That just makes it necessary to maintain 
>a lot of redundant configuration data. In how many places did you have 
>to set "string:${portal_url}/edit_icon.png"?

Not all of my content types have all actions from "view/edit/metadata".
Some of my content types have two different "view" actions (one
which shows the metadata and one which shows the content).



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

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Re: five.intid and DirectoryView

[Dieter Maurer]

Ross Patterson wrote at 2008-6-30 10:34 -0700:
> ...
>> Creating a savepoint seems to do the trick:
>>
> from persistent import Persistent
> import transaction
> app.pob = Persistent()
> app.pob._p_oid is None
>> True
> s = transaction.savepoint()
> app.pob._p_oid
>> '\x00\x00\x00\x00\x00\x00E\xfa'
>
>Would that be a problem causing ZODB bloat?

"savepoint" does not write to the main storage.
The main storage is only modified after the final "commit".



-- 
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] [GenericSetup] "easy_install" reports "SyntaxError"

[Dieter Maurer]

"easy_install"ing the current PyPI version of "Products.GenericSetup" (1.4.0)
reports:

  File 
"/home/dieter/z211/z11python/lib/python2.4/site-packages/Products.GenericSetup-1.4.0-py2.4.egg/Products/GenericSetup/doc/SampleSite/profiles/default/siteroot/bar.py",
 line 22
return printed
SyntaxError: 'return' outside function


-- 
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] CMFCore badly registered on PyPI

[Dieter Maurer]

I tried to easy_install CMFCore from PyPI -- this failed.

Apparently, "CMFCore" is only registered on "PyPI", not uploaded (this
is okay).

Moreover, the url registered as home page
("http://www.zope.org/Products/CMFCore";) apparently does not exist.
I do not think that this is a good sign...

-- 
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 does Zope know the name of the session cookie it should refer to?

[Dieter Maurer]

Alex Man wrote at 2008-4-8 13:37 -0700:
>My apologies if this isn't the correct mailing list I should post 
>this question to. Please let me know if I should post on another list.
>
>I'm using Shibboleth as the authentication system in Plone

Maybe, the Plone mailing list might be better.

>and is 
>wondering how Zope knows the name of the session cookie it should refer to.

Zope calls the session id "browser id" (do not ask)
and manages (configures) it in its "browser_id_manager".



-- 
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: What is the status of GS wiping catalog indexes on catalog.xml import?

[Dieter Maurer]

Andreas Jung wrote at 2008-2-29 06:43 +0100:
> ...
>> When the export handler is able to extract all relevant configuration
>> parameters for an index, why should the import handler
>> not be able to check the configuration parameters in a profile
>> against an existing index and determine that it needs to do nothing?
>
>Huh? Because we're looking for a clean solution and not for a hack!

Why is it a hack when the import handler uses as much detail about
an object as the export handler does?

As I understood Wichert, we can currently export indexes reliably but
we cannot import it without removal and recreation of the index.
I cannot understand this.



-- 
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: What is the status of GS wiping catalog indexes on catalog.xml import?

[Dieter Maurer]

Andreas Jung wrote at 2008-2-28 07:13 +0100:
>--On 27. Februar 2008 21:59:58 + Maurits van Rees 
><[EMAIL PROTECTED]> wrote:
>
>> greenman, on 2008-02-27:
>>> So, for the catalog.xml importer, why can't the trigger for reindexing
>>> an index be a flag on the catalog index declaration itself? Is it
>>> really generic setups role to determine if changes to an index
>>> invalidate the values it already holds? If you were to change
>>> properties of an index through code and not GS, then it would be up to
>>> you whether you reindexed all your objects or not.
>>
>> The problem is that GenericSetup does not know if your current index
>> is of the same type and has the same settings/properties as the index
>> that you specify in catalog.xml.  Apparently it is hard/impossible to
>> reliably compare the existing and the wanted index.  So GenericSetup
>> has no choice but to remove the existing index and make a new one.
>>
>>
>
>How about the following idea:
>
> - within the Zope core we define an _optional_ interface for indexes -
>   something like:
>
>  class IIndexConfiguration(Interface):
>
>  def getConfiguration():
>  """ Returns a dict with index specific configuration
>  parameters.
>  """
>
> - on the CMF/GS side we could register adapter for each index type
>   we know (basically the Zope 2 core indexes, ExtendedPathIndex,
>   TextIndexNG 3) and retrieve the related information

I do not understand why something like this should be necessary.

When the export handler is able to extract all relevant configuration
parameters for an index, why should the import handler
not be able to check the configuration parameters in a profile
against an existing index and determine that it needs to do nothing?



-- 
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] change ownership on Zope objects

[Dieter Maurer]

Marie Robichon wrote at 2008-2-6 08:42 +0100:
>One of the administrators of our Plone site has changed services.  Given 
>that our user authentication is via LDAP and that this person has write 
>access to some parts of our site I now want to change the ownership of 
>the pages he created in order to remove his write access.

Ownership is managed with methods in "AccessControl.Owned.Owned".
Note, however, that its use is restricted. Its sole purpose
is to help against trojan horse attacks and it affects only
executable objects (scripts, templates).

The "Owner" role (it affects permissions on objects) is
a local role managed with methods in "AccessControl.Role.RoleManager".



-- 
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.1 release

[Dieter Maurer]

Jens Vagelpohl wrote at 2007-12-29 19:03 +0100:
> ...
>  - CMFCore (the foundation which may be used by itself to develop  
>other kinds of portal software)
>
>  - CMFDefault + DCWorkflow + (maybe) CMFTopic (a "finished" sample  
>for a CMFCore-based portal software bundle)

"DCWorkflow" is very valuable without "CMFDefault".

I would put it into "CMFCore" or give it its own egg.



-- 
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] Move CMF collector to Launchpad (redux)

[Dieter Maurer]

Andreas Jung wrote at 2007-10-27 21:01 +0200:
> ...
>> I still have a similar issue: in my browser (Mozilla 1.5), launchpad pages
>> are unreadable: almost the complete page is covered by red signs of
>> the form --\.
>>
>
>You can solve this by upgrading to a more recent browser.

But, I probably will not use Launchpad instead



-- 
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] Move CMF collector to Launchpad (redux)

[Dieter Maurer]

Jens Vagelpohl wrote at 2007-10-25 12:37 +0200:
> ...
>I personally had one remaining issue, namely the fact that my main  
>browser (OmniWeb) could not display Launchpad at all due to a CSS bug  
>in OW itself.

I still have a similar issue: in my browser (Mozilla 1.5), launchpad pages
are unreadable: almost the complete page is covered by red signs of
the form --\.



-- 
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] [CMF2.1/Plone 3.0] Random recataloging errors

[Dieter Maurer]

Andreas Jung wrote at 2007-10-22 08:07 +0200:
>while recataloging a Plone 3.0.1 site I encounter sometimes the following
>error with _some_ ATDocument instances (while other ATDocument instances
>indexing properly)...known bug?
> ...
>007-10-22 01:04:46 ERROR Zope.ZCatalog Recataloging object at 
>/fml-migrated/fml failed
>Traceback (most recent call last):
> 
>  File 
>"/home/blohn/fml/parts/zope2/lib/python/Products/ZCatalog/ZCatalog.py", 
>line 296, in refreshCatalog
> ...
>  File 
>"/home/blohn/fml/parts/zope2/lib/python/Products/ZCatalog/Catalog.py", line 
>417, in recordify
>if(attr is not MV and safe_callable(attr)): attr=attr()
>  File "/home/blohn/fml/parts/plone/CMFDynamicViewFTI/browserdefault.py", 
>line 80, in __call__
>return template(context, context.REQUEST)
>AttributeError: REQUEST

Your catalog "metadata table" accesses an attribute (maybe "view")
that calls for "browserdefault". This is a very strange entry
in a "metadata table" -- it should not be there.

Try to find out which entry in the "metadata table" causes this
behaviour and think whether you really need it


-- 
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] howto avoid loading of datetime-objects when accessing a portal_catalog brain

[Dieter Maurer]

Joachim Schmitz wrote at 2007-10-19 10:03 +0200:
>If one iterates over the result of a portal_catalog search, for each 
>brain there are about 8 datetime objects loaded (one for each 
>dateindex), which quickly fills the memory.
>how can I access only the brain id

You can get the brain id via "brain.getRID()".

While it would not be necessary in principle (the "rid" is not part of
the meta data tuple) I am not sure whether access to the "rid"
nevertheless loads the tuple (and thereby your "DateTime" objects).

But you can access the rids avoiding the brains altogether:

  The usual catalog result is a "Products.ZCatalog.Lazy.LazyMap"
  instance. Its "_seq" attribute (obviously private) contains
  the sequences of rids corresponding to the query hits.



-- 
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] Controlling permissions for actions

[Dieter Maurer]

Charlie Clark wrote at 2007-9-27 21:33 +0200:
> ...
>I'm used to restrictions in the ZODB: I usually put these kind of  
>things in a folder with I then restrict. Can you tell me more about  
>metadata?

I always look at the unit tests for the syntax:

  .../CMFCore/tests/fake_skins/fake_skin/test6.py.metadata



-- 
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] Controlling permissions for actions

[Dieter Maurer]

Jens Vagelpohl wrote at 2007-9-27 12:40 +0200:
> ...
>If you have a script somewhere in the skins or in your site it will  
>*always* be available for people who call it up directly by URL.  

You can, of course, restrict its "View" permission --
via its "Security" tab, if it is in the ZODB, or
with a "*.metadata" files for an "FSObject".



-- 
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: [Zope3-dev] Re: Known working sets II [was: Eggification redux]

[Dieter Maurer]

Martijn Faassen wrote at 2007-9-25 19:57 +0200:
> ...
>If you choose for flexibility first, people will need to think about
>versions all the time.

I follow Tres argumentation: somehow the Linux distributors
have this problem mostly solved:

  Standard distributions come with a set of known working components
  and quite weak dependancy declarations.

  When I install additional components, I will be told about
  potential conflicts (based on the weak dependancies) and
  asked what to do (install nevertheless, upgrade more things to
  get dependancies right or abort).

  Usually, I do not have to worry about versions -- only
  occationally (when I see conflict lists) or even more rarely,
  when something breaks even though there has not been a conflict.


We currently made bad experiences with weak dependancies.

I see several reasons for this:

  *  not yet ready distributions (insufficiently tested,
 alpha quality) have been uploaded to PyPI

 We are now aware that we must not do things like this

  *  installation tools have prefered newer versions over
 older ones, even when the newer versions were development/alpha
 while the older ones have been stable

 The tools meanwhile have changed and stick preferably to
 stable versions

  *  The installation tools work incrementally with dependancies
 rather than based on a global dependancy graph.

 This is not yet changed.


Maybe, our bad experience are drastically reduced when the above
reasons are taken care of -- even with weak dependancies?



-- 
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: [Zope3-dev] Re: Known working sets II [was: Eggification redux]

[Dieter Maurer]

Martijn Faassen wrote at 2007-9-25 17:22 +0200:
> ...
>Should we then encourage everyone to hardcode version numbers in their
>setup.py's dependencies list?

I think this goes against building applications from components --
as it drastically increases the probability of conflicts.

Components should are week dependancy requirements to be
maximally usable -- not fixed dependancies.

I think, this holds for frameworks, too, as they are also components.



-- 
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] Design approach questions: unique content-ish items?

[Dieter Maurer]

Doyon, Jean-Francois wrote at 2007-9-17 15:10 -0400:
> ...
>But, its more generic purpose is essentially as a "utility" for the site, at 
>least conceptually.  The only difference might be that it's NOT placeless.

But "utilities for a site" have a natural location: the site root.

A "utility" you place deep inside the site are not "utilities for
a site" but "utilities for part of a site".



-- 
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] is there a conflict error resistent index

[Dieter Maurer]

Perry wrote at 2007-6-18 13:56 +0200:
> ...
>I didn't find any application specific conflict resolution in the 
>fieldindex ? Are you saying, that once there is one document created 
>within a review_state, conflict errors for that review_state are very 
>unlikely, even under heavy load.

Yes. Due to the "conflict resolution" in "IITreeSet" (which
is used to hold the document id list belonging to a given review state).

"FieldIndex" does not need to have its own conflict resolution
as the "IITreeSet" handles most on the document id set level.



-- 
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: SVN: CMF/branches/2.1/C - changed the way skins are set up, using __before_publishing_traverse__ instead of __of__

[Dieter Maurer]

yuppie wrote at 2007-6-18 11:29 +0200:
> ...
>Please let me know if you think this checkin causes too much trouble and 
>should be reverted.

We are using portals and their skins widely in scripts executed
outside of Zope. Especially, they do not use the ZPublisher
to traverse to the objects but use more direct methods (which
do not look for "__before_publishing_traverse__").

Your change will break all these scripts



-- 
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] is there a conflict error resistent index

[Dieter Maurer]

Joachim Schmitz wrote at 2007-6-16 13:35 +0200:
> ...
>during our recent search for the cause of the many conflict errors, we 
>discovered that nearly all of them where caused during indexing the 
>portal_catalog, when the same values are indexed. This can happen easily 
>with date_indexes, since the dates are only stored with a resolution of 
>1 minute.

Usually, this will not cause a conflict -- only when in addition
the first objects that use a new date value are created
in concurrent transactions. I expect that the probability is not
too high for this

>Even more conflict error prone is the reviewstate. Since there 
>are only a few reviewstates.

Again, only the initial "filling" of the document list for
a given state is critical. Once there is a document list,
this list (an "IITreeSet", usually) can concurrently add elements
(using application specific conflict resolution -- reducing the
conflict probability by a factor of about 120).


For one of our internal projects, I have created a set
of "conflict reduced indexes". These indexes do not delete
a document list one it has been created. However, it turned
out that this additional conflict protection is not worth the effort.
My special indexes have been phased out meanwhile



-- 
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] reindexObject updates modification time?

[Dieter Maurer]

Darryl Dixon - Winterhouse Consulting wrote at 2007-5-28 22:30 +1200:
> 
>Which lends even more weight to my original query - why on earth
>does reindexObject() update the modification time?  I can see utterly no
>reason why it should...

When the object is changed, the modification time should be reset.

Now, there are many many ways to change an object.

The author of the above hack reasoned:

  When an object is changed then not only its modification time
  should be changed but the object should also be reindexed.
  Reindexation is only one place. Therefore, he implemented
  modification time update in the "reindexObject" method.

  Soon it became apparent that it is not good to change the
  modification time whenever "reindexObject" is called.
  Therefore, the change was limited to called of "reindexObject" with
  an empty set of indexes (i.e. all indexes should be updated).


I do not say that I like the reaoning or the current state.
But, at least, this is the historical cause.


The author has discussed the solution on "zope-cmf" and
nobody objected earnestly. That's why I know the reasons and the history.



-- 
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] unresolved site manager related issues

[Dieter Maurer]

Martin Aspeli wrote at 2007-4-25 19:58 +0100:
> ...
>If the root of your CMF/Plone site contains content items, they need to 
>avoid collision with magical objects that are there primarily to make 
>our lives easier as programmers (since you can acquire them, and they 
>interact with Zope security easily, and they give a somewhat simple 
>place to hook configuration UI into, and they give a somewhat simple 
>place to stick configuration data).
>
>> Most CMF tools are location specific configurations (catalog, skins,
>> actions, types, ...) with a bit of functionality.
>> I do not see a big gain in implementing
>> them as local utilities rather than their current implementation.
>
>I'd like them not to be there as attributes/keys/ids of the portal. In 
>Zope 3, this is solved by using namespace traversal adapters giving 
>access to persistent components only under a special namespace 
>(++etc++site).

That looks like a trivial naming convention you could use in Zope 2, too:

  Forbid ids with a special naming pattern for the ids of your content
  objects and use this naming pattern for your "magic object"s.



-- 
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] unresolved site manager related issues

[Dieter Maurer]

Martin Aspeli wrote at 2007-4-15 16:45 +0100:
> ...
>Aesthetics were not the original reason for moving down this route, so 
>it's a little unfair to cast it in that light. The main drivers, as I 
>recall, were to encourage API usage that would allow us to move tools 
>out of content space eventually

Probably, I do not understand "content space". At least, I do not
understand why you want to get tools out of it.

Most CMF tools are location specific configurations (catalog, skins,
actions, types, ...) with a bit of functionality.
I do not see a big gain in implementing
them as local utilities rather than their current implementation.

> and to make code depending on CMF tools 
>more consistent with "newer" code which may depend on new utilities (at 
>least in the Plone world, there is a general consensus that we'd rather 
>not have any more content-space tools from now on).

Hm: is their really that big a difference to call "getToolByName"
or "getUtility"?



-- 
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] unresolved site manager related issues

[Dieter Maurer]

Alec Mitchell wrote at 2007-4-12 06:59 -0700:
> ...
> ... deprecation of "getToolByName" ...
>which is that there's no practical reason other than
>aesthetics to deprecate getToolByName at this point.

A very good point: let's deprecate deprecations done just for
aethetical reasons :-)

> This still seems
>like we're creating a lot of developer pain with minimal benefit
>(tools already allow for local customization by acquisition).

for precisely this reason.



-- 
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] Re: Delete trouble

[Dieter Maurer]

Philipp von Weitershausen wrote at 2007-3-28 08:16 +0200:
> ...
>What makes you think you can make that assumption? This is Zope 2 all  
>over again, where things just have to be there. That won't help  
>making things more flexible.

Hiding exceptions (or avoiding them at all costs) might be seen as
more flexible -- but this approach caused several quality problems in
Zope 2.

>> We have this situation here: there should be (and is) a unique
>> id tool but the local registrations have not been performed.
>
>Nope, we're just not operating in a place where we can get to the  
>tool. It's standard acquisition semantics.

With standard acquisition semantics, you get an AttributeError
when the object is not there.

You propose something similar (okay, a bit less drastic) to
silently ignoring the "AttributeError".

I argue that (in general, there are exceptions) we should get the exception.

>
>> An exception is better than silently omit the update of the existing
>> unique id tool.
>> You could argue that the local id tool does not need to be updated
>> as the complete site (including the tool) gets deleted.
>
>Indeed.
>
>> But would the effect be different, if I used:
>>
>> plone_site.some_folder.manage_deleteObjects().
>>
>> Or in other words, is attribute lookup entailed in traversal?
>
>No.
>
>> If it is not (which I assume), then your "defensive programming"
>> would hide inconsistencies in the unique id tool -- similar
>> to a "defensive try:  except: pass".
>
>What kind of inconsistencies? We're deleting the thing anyway, what's  
>the point to update it?

If you carefully look at the example, it no longer deletes "plone_side"
(and its "unique id tool") but something below "plone_side".
Therefore, consistency of the "unique_id_tool" may be an issue (it is
not deleted and would know about an object with no longer exists).



-- 
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] Derived Content Types & WebDAV

[Dieter Maurer]

Charlie Clark wrote at 2007-3-27 13:28 +0200:
>having made my own content type which is derived from Document with  
>three additional attributes, I've moved onto the exciting world of  
>editing content via webDAV. It seems some methods have to be extended/ 
>overwritten for this to work so I have added customised versions of  
>the following
>getMetadataHeaders() # Document.py
>setMetadata() # Document.py
>getMetadataHeaders() # DublinCore.py
>_editMetaData() # DublinCore.py
>
>Is this a correct assumption?

I would be quite surprised if these methods had much to do
with WebDAV editing. Instead, I would look for "PROPPATCH"
(and how it is implemented).



-- 
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: Delete trouble

[Dieter Maurer]

Philipp von Weitershausen wrote at 2007-3-26 14:24 -0600:
> ...
>> I would not find is a good approach, if exceptions were silently
>> suppressed.
>
>Let's look at this closer:
>
>- There's probably an event subscriber for IObjectBeforeDeleteEvent on 
>all Plone or CMF objects that makes sure that the deleted item is also 
>purged from the unique ID tool. So far so good.
>
>- If that subscriber uses getUtility() calls and doesn't catch a 
>ComponentLookupError, it bluntly assumes that all such content objects 
>must live in an environment that has a unique ID utility. That's asking 
>for a lot (it's almost as bad as simply wanting to be able to acquire 
>portal_uuid or whatever it's called).
>
>- To make reuse easier, the suggested pattern is to check if such a 
>utility can be found and then do the unregistering (or even registering 
>when the object is added). If the utility can't be found, then that's 
>too bad but shouldn't impact the actual use of the content type. After 
>all, it's just a dumb content type.
>
>This isn't about silently suppressing exceptions, it's defensive 
>programming to increase flexibility.

As so often, we have completely different views on how things should be:

  When I have an "IObjectBeforeDeleteEvent" subscriber which
  should update the unique ID tool, then it can assume that
  there is indeed a unique ID tool. And if the assumption is
  wrong, an exception should result.

We have this situation here: there should be (and is) a unique
id tool but the local registrations have not been performed.
An exception is better than silently omit the update of the existing
unique id tool.

You could argue that the local id tool does not need to be updated
as the complete site (including the tool) gets deleted.

But would the effect be different, if I used:

plone_site.some_folder.manage_deleteObjects().

Or in other words, is attribute lookup entailed in traversal?


If it is not (which I assume), then your "defensive programming"
would hide inconsistencies in the unique id tool -- similar
to a "defensive try:  except: pass".



-- 
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: Delete trouble

[Dieter Maurer]

Martin Aspeli wrote at 2007-3-25 12:46 +0100:
> ...
>I agree, except I think there could potentially be lots of places where 
>this could be happening. In the general case, it's probably safe for 
>that code to assume the utility is there, and treat it as an error if 
>it's not, but during site deletion, it is probably at the mercy of the 
>order of deletions. At least that's my guess.

I would not find is a good approach, if exceptions were silently
suppressed.

If we know that during deletions exceptional cases could happen,
we should inform the component lookup process that we are doing
deletions such that it can be less strict in its behaviour.

However, usually the "I am going to be deleted" event is
signalled before the actual deletion takes place. Therefore, the
event processing still should find all utilities around.



-- 
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

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

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

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

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

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] 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] 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] 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] 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] 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] 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] 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: 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] 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] 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

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

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

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

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