[Zope-CMF] LazyFilter and Effective Dates

John Morton jwm@plain.co.nz
Mon, 1 Jul 2002 15:33:17 +1200


On Sat, 29 Jun 2002 04:39, Carl Rendell wrote:
> As I started this thread, I'll throw in some comments that reflect
> my thoughts on the matter.
>
> I see effectivity and expiration as global attributes of the
> _object_ itself. I treat them as a primary control mechanism
> regardless of what attributes other processes might be saying about
> the object.
>
> In this situation it is entirely possible that an object could have
> an effectivity and or expiration date that are 'valid' for the
> current view context, but have an additional attribute - say review
> state - that prohibits viewing in this context. However, an item
> with either a future effectivity date, or expiration date in the
> past is _not_ viewed regardless of the review state.

That would tend to be a problem if you happen to own the content :-)
Obviously, you need to set some sort of before, during and after effectiveness
access policy somewhere depending on how you want to treat each 'state'.

> I like the separation here. In my implementations effectivity and
> expiration serve as an _override_ for all other state attributes. I
> would not want to see them get mixed into something like workflow,
> which can be unique to every implementation.

In the use case I mentioned, the effective and expiration dates are still 
separate metadata, but workflows are used to implement a particular 
access policy with regards to them. 

> I would prefer that effectivity and expiration are namespaces that
> are set aside, and _not_ used in any other context.

Agreed, and as it happens, I was mistaken. I don't think those fields are
being misused anywhere.

> Finally, after going through the process I agree with comments from
> Tres and others... The filter on objectValues() is best applied in
> a script. The script may become part of the 'tools' distribution as
> a function in CMFDefault.utils or in the standard _content_ skins
> folder. I remains to be seen if the community wants that as part of
> the distribution.

So if your script is used in the default folder skin, it can support the sort 
of effective date policy you want, while others can disable that behaviour and
implement something with workflows, so it looks like we're both happy :-)

John