[Zope3-dev] ZODB mount points

2005-10-11 Thread Garrett Smith
(I think) rather than use fssync to export multiple 'sites' in a single Zope 
instance, I'd much rather have multiple ZODB file storage instances -- i.e. one 
Data.fs for each site. I have no requirement to share points or UI across these 
sites -- I just want to eliminate having to run a separate processes for each 
site.

I've run into 'mount points' for Zope 2.x and see the ZODB/Mount.py file -- but 
it doesn't look like any of this is in play for Zope 3.

Can someone point me in the right direction?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Exporting and importing specific objects/folders

2005-10-07 Thread Garrett Smith
I can spend some time on the command line tool -- that would be ideal for us 
anyway. Security isn't an issue, at least short term, as this is strictly for 
OS-level backups.

In the next couple weeks I'll take a closer look.

If I understand the gist of the checkin/checkout model, there's profound 
implications for TTW development. Would this not alleviate the SCM problerms of 
code-in-the-ZODB-black-box syndrome that Zope 2 faces?

 -- Garrett

On , [EMAIL PROTECTED] wrote:

 Garrett Smith wrote:
 I have a backup requirement to save a folder (a site) and be able to
 restore it without effecting other sites on a server.
 
 I looked briefly at Zope3's fssync but I'm not sure if it's current,
 
 I don't know if it's current.  It is largely independent of
 Zope so it should
 still work.
 
   or
 exactly how it could be used for this.
 
 Any recommendations?
 
 Sigh.  I wish someone had time to work on this.
 
 It currently has a web-based interface that allows objects
 to be checked out and checked in, with semantics much like
 a version control system.  We aren't using it because it lacks
 an adequate security model to support web-based access.
 
 FWIW, here are some thoughts of where I'd like to see this go:
 
 - I'd like to see 2 different types of interface:
 
o A web based interface like we have now except that you should
  only be able to check out or in if the object being checked out
  or checked in has a fssyn adapter (other than the default) and
  if the user has the necessary permissions.
 
o A command-line tool that opens the database directly. This tool
  would not go through the security system at all and would be able
  to use the default (xml-pickle-based) adapter.
 
 - (at least) Two modes should be supported.
 
o checkout/checkin
 
  When objects are checked out, we make 2 copies (as svn does).
  This allows us to track and merge changes made in zope or 
 on the file system. 
 
o export/import
 
  Here the goal is tranfering things.  We don't make 2 copies.
 
 Jim


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Exporting and importing specific objects/folders

2005-10-07 Thread Garrett Smith
A couple (very) quick observations:

- Annotations aren't serialized because the IAnnotations adapter is not 
trusted. Strangely, IAnnotations(ob) it's returning an empty dict rather than 
raising a Forbidden on __annotations__. I didn't look into that weirdness, but, 
once annotation permissions were set, they get serialized.

- The browser upload interface is quite broken. I was able to get a composite 
XML file with @@toFS.snarf.

I'll post a separate msg to see if there's anyone else interested in this 
functionality. It's too darned functional to go stale like this.

 -- Garrett

On , [EMAIL PROTECTED] wrote:

 Garrett Smith wrote:
 I can spend some time on the command line tool -- that
 would be ideal for us anyway. Security isn't an issue, at
 least short term, as this is strictly for OS-level backups.
 
 In the next couple weeks I'll take a closer look.
 
 Great! Thanks.  The command-line tool should be straightforward.
 In fact, earlier versions only had command-line tools.
 
 If I understand the gist of the checkin/checkout model,
 there's profound implications for
   TTW development. Would this not alleviate the SCM
 problerms of code-in-the-ZODB-black-box
   syndrome that Zope 2 faces?
 
 Yes. That's the idea. :)
 
 In addition, to the degree that file-system representations
 of content can
 be diff friendly, there are some really nice possibilities
 for off-line
 content management and synchronization.
 
 Imagine in a document management system that someone checks
 out a folder
 of documents and works on them off line.  They can later
 check these in,
 merging their changes with any changes made by others.
 Obviously, there's
 lots of hand waving here, since the formats that people often use for
 document management are not particularly diff friendly.  It would
 help if, eventually, the diffing tools could be content type specific.
 
 Jim


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] fssync and export/import for Zope 3

2005-10-07 Thread Garrett Smith
Is anyone interested in using export/import capabilities in Zope 3?

As we get more Zope 3 deployments, I think this will become an important topic. 
It looks like the fssync code has become only slightly stale. With a little 
use, this could be break-out feature for Zope 3 developers.

As Jim just pointed out, there are a couple a 'visions' associated with fssync:

- The export/import functionality people are used to with Zope 2

- A checkin/checkout functionality that would let someone make long-running 
changes to a part of a site, with the option of commiting or aborting those 
changes

I suspect the export/import feature alone will be attractive to anyone with 
production servers, as it enables object-specific backup and restore.

If anyone is interested in using this, let me know. I'll be looking into adding 
a simple command-line tool for object-specific backup/restore (i.e. 
export/import) and it would be helpful to have some other users, if not 
contributors.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] browserDefault uses '@@' for containers

2005-09-26 Thread Garrett Smith
On , [EMAIL PROTECTED] wrote:

 Hi together
 
 Behalf Of Fred Drake
 Sent: Friday, September 23, 2005 4:13 AM
 To: Gary Poster
 Cc: Garrett Smith; zope3-dev
 Subject: Re: [Zope3-dev] browserDefault uses '@@' for containers
 
 On 9/22/05, Gary Poster [EMAIL PROTECTED] wrote:
 I believe that the idea is that the container traverser wants to
 specify that the default view name is a view, not an object in the
 container.  That is, if the default view is named index.html, and I
 have an object in the container named index.html, './index.html'
 will traverse to the object in the container while @@index.html will
 render the container view named 'index.html'.  Sometimes you *want*
 
 That's right.  At one point it wasn't doing that (as best I recall),
 so the default view was traversing when it shouldn't.  We decided to
 change it specifically because it produced unexpected behavior.
 
 I'm running into a bug with this behavior.
 
 If I call myContainer/@@ or myContainer/ and get my registred
 index.html (template) view back. There is the following part
 rendered into the template 'lt;/'.

Does this extra text show up even if your template is empty? I.e. delete the 
template text and see what happens.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] browserDefault uses '@@' for containers

2005-09-22 Thread Garrett Smith
Why does z/a/container/traversal/ContainerTraversal include '@@' in the default 
view name? This is not the case in SimpleComponentTraverser 
(z/a/publication/traversers). Is there something special about containers that 
their default view should be an explicit view lookup? Or should 
SimpleComponentTraverser also include '@@' in the default name?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
Sorry for the long delay in replying.

We've been using widget-specific JS and CSS for some time now and I like our 
approach. It's quite different from the proposal.

We're using the same pattern used by forms/widgets -- i.e. the PT is 
responsible for explicitly including HTML fragments provided by the view. As a 
point of reference, here's a simple example of including widgets:

tal:block repeat=widget view/widgets
  label tal:content=widget/labelName/label
  input type=text tal:replace=widget /
/tal:block

The analog for including header support (i.e. JS and CSS) is:

head
  tal:block repeat=content view/headContent
tal:block content=content /
  /tal:block
/head

This places the burden of managing unique lists of 'head content' with the 
view. I see this as an extension of the widget-management framework.

I would not personally opt for the proposal because it feels a bit magical -- I 
think it's too indirect.

So, here's my argument in brief: Since widgets are driving the requirements of 
a consolidated resource list in the HTML head, the solution should extend the 
existing widget pattern. Yes, this imposes more overhead on the PT and the 
view, but the upside (IMO) is that the scheme is more transparent.

 -- Garrett

On , [EMAIL PROTECTED] wrote:

 I've added a proposal for Zope 3.2.  Read at
 http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitectu
 re/ResourceLibrary. 
 
 WARNING: zope.org exhibiting some serious caching
 strangeness, so please
 comment on the list instead of the wiki.


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
I don't understand what you just said :-)

My fault -- I haven't been plugged into the other discussion.

Is there a branch somewhere that has a simple demo to help with grokability?

 -- Garrett


On Friday, September 16, 2005 12:28 PM, Gary Poster wrote:

 On Sep 16, 2005, at 12:49 PM, Garrett Smith wrote:
 
 Sorry for the long delay in replying.
 
 We've been using widget-specific JS and CSS for some time now and I
 like our approach. It's quite different from the proposal.
 
 We're using the same pattern used by forms/widgets -- i.e. the PT
 is responsible for explicitly including HTML fragments provided by
 the view. As a point of reference, here's a simple example of
 including widgets: 
 
 tal:block repeat=widget view/widgets
   label tal:content=widget/labelName/label
   input type=text tal:replace=widget /
 /tal:block
 
 The analog for including header support (i.e. JS and CSS) is:
 
 head
   tal:block repeat=content view/headContent
 tal:block content=content /
   /tal:block
 /head
 
 This places the burden of managing unique lists of 'head content'
 with the view. I see this as an extension of the widget-management
 framework. 
 
 I would not personally opt for the proposal because it feels a bit
 magical -- I think it's too indirect.
 
 So, here's my argument in brief: Since widgets are driving the
 requirements of a consolidated resource list in the HTML head,
 the solution should extend the existing widget pattern. Yes, this
 imposes more overhead on the PT and the view, but the upside (IMO)
 is that the scheme is more transparent.
 
 If we had a clear division between update and render stages, and all
 template elements had an update call before they were rendered (and
 so were able to register a need) then the approach you suggest would
 be generally sufficient for the kind of story we are interested in
 telling.  Pipelining, possibly combined with a modified templating
 story, can address this in a different way--one of the simplest
 configurations would support something like separate update and
 render stages.  Even there, though, the resourcelibrary API for
 clients could remain the same, whether the JS/CSS were inserted by a
 main template that rendered the gathered JS/CSS calls, in a modified
 version of your approach; or by the XML-munging (or transformation
 to put it in a more politically appealing light) that is the current
 implementation. 
 
 I'd say that this proposal has two thrusts.
 
 First, it proposes that we need a solution to the problem of stand-
 alone display components that need support from the main page.
 That's something that we (ZC) want, and for which other replies to
 the thread have also expressed desire.  It enables a drop-in rich-
 widget story, which is arguably becoming more important as user
 expectations for richer internet experiences rise, and developer
 expectations for simpler integration of rich client technology rise.
 
 Second, it proposes that the given API can support a number of
 rendering implementations, from transforming HTML (as in the current
 implementation) to being a part of a wrapper main template during a
 rendering stage of a pipeline.
 
 The proposal should be evaluated from that perspective, and from the
 perspective of Jim's recent pipeline discussion.  Can you see the
 need?  Can you see how the API can support several rendering
 implementations?  Developers who say yes to both can develop and use
 drop-in rich sub-page components, such as widgets.
 
 Developers who say yes to the first but no to the second are
 urged to
 suggest improvements.
 
 And thanks to the wonder of the more plug-and-play architecture of
 Zope 3, developers who say no to the first question don't have to
 play here, while still joining up elsewhere. :-)
 
 Gary


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
I mean something that illustrates Gary's 'big picture'. I understand the 
resource lib proposal, but I don't have any grasp of the broader vision driving 
it.

If it's just a patch to get 'rich' widgets working, I'll stick with my initial 
impression of it being too magical.

 -- Garrett

On Friday, September 16, 2005 3:15 PM, Benji York wrote:

 Garrett Smith wrote:
 I don't understand what you just said :-)
 
 My fault -- I haven't been plugged into the other discussion.
 
 Is there a branch somewhere that has a simple demo to help with
 grokability? 
 
 http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitectu
 re/ResourceLibraryREADMETxt


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
On Friday, September 16, 2005 4:05 PM, Benji York wrote:

 Garrett Smith wrote:
 If it's just a patch to get 'rich' widgets working, I'll stick with
 my initial impression of it being too magical.
 
 The main reasons why this isn't a problem individual widgets
 can solve
 is that 1) they can't know if things that should only be done once
 have already been done (include JavaScript for example), 2) they can't
 directly add entries to the head section of the page, and 3) the
 components that require the JS or CSS might not be widgets at all.

That's right. But the view can solve these problems easily without a lot of 
other stuff like yet-another-ZCML directive and automagical transformation of 
the HTML head element.

This is what we have:

class IHeadContent(Interface):
Something that provides head content for a page.

def headContent():
Returns a sequence of HTML snippets to be added to the page head.

class SomeView(BrowserView):

def __init__(self, context, request):
...
self.headContent = []
for widget in self.widgets():
hc = zapi.queryAdapter(widget, IHeadContent)
if hc is not None:
for content in hc.headContent:
if content not in self.headContent:
self.headContent.append(content)
...

The applicable PT:

head
tal:block repeat=content view/headContent
tal:block content=structure content /
/tal:block
...
/head

This is a trivial change to the existing Zope code.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
My point is that if rich widgets are the *only* driver here, the solution below 
is a better fit with the existing widgets implementation.

The transformation of the HEAD doesn't jive with existing patterns. If there's 
a new pattern afoot (pipelining?), I hope we get a chance to discuss it. If 
I've just missed the discussion (quite possible), I'll wait for the RC.

FWIW, we would not be able to use this new scheme exclusively as some of our 
IHeadContent providers provide more than file includes. E.g. we have a menu 
component that dynamically builds JavaScript and includes it directly in the 
HEAD.

 -- Garrett


On , [EMAIL PROTECTED] wrote:

 Garrett Smith wrote:
 That's right. But the view can solve these problems easily without a
 lot of other stuff like yet-another-ZCML directive and automagical
 transformation of the HTML head element.
 
 This is what we have:
 
 class IHeadContent(Interface):
 Something that provides head content for a page.
 
 def headContent():
 Returns a sequence of HTML snippets to be added to the
 page head. 
 
 class SomeView(BrowserView):
 
 def __init__(self, context, request):
 ...
 self.headContent = []
 for widget in self.widgets():
 
 Like I said before, they're not always widgets.  For
 something like this
 to work you have to be able to enumerate all the page components no
 matter what type of thing they were.  That's not always convenient or
 even possible and seems more constraining than the proposal.
 
 The applicable PT:
 
 head
 tal:block repeat=content view/headContent
 tal:block content=structure content /
 /tal:block ...
 /head
 
 The proposed solution also does not require any dead chickens in ZPT.


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Garrett Smith
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote:

 You could also be asking about the pipeline ideas, but that's not my
 first guess. :-) 

Yes, I suspect this is what I'm missing.

There was an earlier post about Ajax. It seems an entirely new approach would 
be needed to solidly support Ajax. I.e. we would need an architecture that let 
components interact independently of the browser view, or at least could be 
accessed in isolation of a full page rendering. Is this the sort of thing the 
'pipeline' approach is getting at?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Proxy and __slots__

2005-08-29 Thread Garrett Smith
I ended up using 'type' to create a new proxy with a dynamically created 
__slots__. I haven't run into any weirdness with that approach, so far :)

 -- Garrett

 -Original Message-
 From: Jim Fulton [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 29, 2005 9:03 AM
 To: Garrett Smith
 Cc: 'zope3-dev@zope.org'
 Subject: Re: [Zope3-dev] Proxy and __slots__
 
 Garrett Smith wrote:
  I'd like to create a proxy where __slots__ is determined 
 (or appended to) when the proxy is constructed. E.g.
  
  
 foo = Foo()
 bar = SomeProxy(foo, 'baz')
 bar.baz = 123
 hasattr(foo, 'baz')
  
  False
  
 hasattr(bar, 'baz')
  
  True
  
  Is it possible to do this?
 
 No, at least not using the standard __slot__ mechanism.
 
 Jim
 
 -- 
 Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
 CTO  (540) 361-1714http://www.python.org
 Zope Corporation http://www.zope.com   http://www.zope.org

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Garrett Smith

 I'm uncomfortable with this. Right now, I think fields do too much.
 They have too much application logic.  This would add more.  The whole
 concept of initial value seems to be very application dependent.
 Maybe it would be best to just drop the default field altogether
 and introduce adapters for computing initial values in those special
 cases when we need them.

Funnily, I just faced this dilema earlier today. I nearly created an interface 
like this:

  class IInitialValue(Interface):
  An interface for obtaining an initial value for an object.

  def get():
  Returns the initial value.

IMO, this is superior to field.initial. E.g.

  zapi.getMultiAdapter((field, context), IInitialValue).get()

Perhaps this pattern could be used for getting an ISource from a field. E.g.

  zapi.getMultiAdapter((field, context), ISource)

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Proxy and __slots__

2005-08-27 Thread Garrett Smith
I'd like to create a proxy where __slots__ is determined (or appended to) when 
the proxy is constructed. E.g.

 foo = Foo()
 bar = SomeProxy(foo, 'baz')
 bar.baz = 123
 hasattr(foo, 'baz')
False
 hasattr(bar, 'baz')
True

Is it possible to do this?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Deprecation of NotFoundError (#284)

2005-08-01 Thread Garrett Smith

I think a post to this list is fine.

 -- Garrett

On Jul 31, 2005, at 8:32 AM, Julien Anguenot wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Where would be the best place for this migration notes ?

J.

Garrett Smith wrote:
It's clear that NotFoundError is deprecated, but I'm not sure what to  
use in its place. Looking through your change (skimmed, as it's big)  
it looks like KeyError is is used in some places and  
FactoryNotFoundError in others.


Could you provide some migration notes?

 -- Garrett



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Julien Anguenot
Sent: Thursday, July 28, 2005 8:57 AM
To: zope3-dev@zope.org
Subject: [Zope3-dev] Deprecation of NotFoundError (#284)


I checked in the deprecation of NotFoundError. (rev 37531)
You might want to check the BBB on your existing app.

J.
--
Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform :
http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojav
e-corp.com

- --
Julien Anguenot | Nuxeo RD (Paris, France)
CPS Platform : http://www.cps-project.org
Zope3 / ECM   : http://www.z3lab.org
mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFC7NLtGhoG8MxZ/pIRAqabAJ0Tvdg8CFU8xdSoT+9QhchqpvIUIQCghann
IlUAkcjJhW3B2BFgEm7p2YQ=
=hAg4
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:  
http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojave- 
corp.com




___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] HEADS UP: PrincipalInformation - InternalPrincipal

2005-07-29 Thread Garrett Smith
On the outside chance this effects you, PrincipalInformation should now be 
spelled InternalPrincipal.

(Deprecation warnings had not been added for this BBB class, so its deletion 
may catch some by surprise.)

  -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] HEADS UP: change effecting custom authenticator search UIs

2005-07-29 Thread Garrett Smith
This affects anyone who has created a custom authenticator search UI (and if 
there's anyone who has done this, consider yourself a hyper super power user!)

PAU queriables are now looked up by adapting an authenticator AND the PAU 
(prior to the recent change, only the authenticator was adapted). You'll need 
to rewire your current queriable accordingly. (See 
z/a/authentication/authentication/QuerySchemaSearchAdapter for an example of 
such a queriable and its use.)

If anyone has any questions, please let me know.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Debugging deadlocks in Zope3

2005-07-24 Thread Garrett Smith
Is there any info published on debugging Zope3 deadlocks? I'd like to see 
tracebacks of a couple threads. Has anyone done this w/Zope3?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] What is zope3-dev-bounces?

2005-07-23 Thread Garrett Smith
I'm getting mail from this list from

  [EMAIL PROTECTED]

We just moved to a different mail server -- the word 'bounces' would seem to be 
a bad thing (yet I'm still receiving posts from the list).

Does anyone know why I'm getting mail in this way?

 -- Garrett

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Formatting dates

2005-07-21 Thread Garrett Smith
 That application of the user's timezone might be done before the  
 datetime is actually generated, or with a datetime.replace 
 (tzinfo=ITZInfo(request)) call.  (The immutable nature of strings,  
 datetimes, and other similar types doesn't prevent us from 
 performing  
 operations with them or from replacing one attribute value with  
 another, of course).

Of course :-)

I guess my question was whether you see the widget handling the setting of the 
time zone, or the application. My vote would be that the widget deal with this, 
using adaptation to black box the process of finding the implicit tzinfo 
(assuming the widget doesn't have a UI for explicitly setting it).

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Formatting dates

2005-07-21 Thread Garrett Smith
 

 -Original Message-
 From: Fred Drake [mailto:[EMAIL PROTECTED] 
 Sent: Thursday, July 21, 2005 12:25 PM
 To: Garrett Smith
 Cc: Zope3-Dev (zope3-dev@zope.org)
 Subject: Re: [Zope3-dev] Formatting dates
 
 On 7/21/05, Garrett Smith [EMAIL PROTECTED] wrote:
  I guess my question was whether you see the widget handling the 
  setting of the time zone, or the application. My vote would be that 
  the widget deal with this, using adaptation to black box 
 the process 
  of finding the implicit tzinfo (assuming the widget doesn't 
 have a UI for explicitly setting it).
 
 I'll agree that adaptation should be used to get the implied tzinfo.
 
 Whether the widget should be responsible for filling in a 
 tzinfo at all depends on how the application is going to use 
 the value; there should be a way for a field to indicate 
 whether the value contains a tzinfo as well as whether the 
 actual value should be normalized to a specific timezone.
 
 It should still be up to the application to specify what kind 
 of timezone handling is needed (via the schema).

Good point -- that should definitely be in the schema.

I just want to avoid applying special handing for time zones outside the 
widget/schema framework.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Formatting dates

2005-07-19 Thread Garrett Smith
So this will specifically impact:

- The use of date/time formatters
- Date/time widgets

Anything else?

Since datetime values are immutable, I assume you're envisioning that widgets 
create tz-aware values. With that in mind, I don't understand  'collected 
timezone-less times from our forms'.

 -Original Message-
 From: Gary Poster [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, July 19, 2005 11:47 AM
 To: Garrett Smith
 Cc: Zope3-Dev (zope3-dev@zope.org)
 Subject: Re: [Zope3-dev] Formatting dates
 
 
 On Jul 19, 2005, at 12:22 AM, Garrett Smith wrote:
 
  Now that dates have UTC time zones associated with them, will we be 
  adjusting how they're displayed in various views? Somehow 
 it doesn't 
  seem appropriate to display UTC by default. I'd assume Zope 
 would use 
  the server's timezone offset.
 
 Here's an excerpt of me describing our plan for ZC software 
 on IRC, which Stephan has approved for post-3.1 Zope (taken 
 from http://
 zope3.pov.lt/irclogs/%23zope3-dev.2005-07-15.log.html):
 
 GaryPosterso we already agree on tz-aware storage.  My intent is  
 to always expect an adapter of request to tzinfo.20:49
 GaryPosterwe plan to have our apps allow specifying tz in the  
 zope 3 preferences stuff20:49
 GaryPosterso a logged-in user would have a default 
 timezone20:50
 GaryPosterThis would affect collected timezone-less times from  
 our forms,20:50
 GaryPosterand affect the astimezone for the display of 
 the stored  
 utc datetimes.20:50
 GaryPosterWe're stubbing this for our current apps, since it  
 hasn't been high-priority enough20:51
 
 We go on (in the log) to talk about strategies for 
 unauthenticated users.
 
 Gary

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] zope.security.interfaces.ForbiddenAttribute: ('utcoffset', UTC)

2005-07-18 Thread Garrett Smith
This might be something on my end, but I figure I'd throw it out in case it's 
related to any changes related to naïve/non-naïve time zones.

Here's the relevant part of the traceback:

  File /opt/aktari/zope/src/zope/i18n/format.py, line 175, in format
info = buildDateTimeInfo(obj, self.calendar, bin_pattern)
  File /opt/aktari/zope/src/zope/i18n/format.py, line 603, in 
buildDateTimeInfo
tz_secs = tzinfo.utcoffset(dt).seconds

I'll dig further, but at a casual glance I couldn't turn up any security 
declarations for UTC objects. Could this be a case where datetime values are 
suddenly spouting proxied tzinfos?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Formatting dates

2005-07-18 Thread Garrett Smith
Now that dates have UTC time zones associated with them, will we be adjusting 
how they're displayed in various views? Somehow it doesn't seem appropriate to 
display UTC by default. I'd assume Zope would use the server's timezone offset.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Broken ZODB (was SVN: Zope3/trunk/src/zope/app/authentication/Eliminated all old-style classes)

2005-06-22 Thread Garrett Smith
This change has broken presisted SessionCresentials. I'm not sure why,
but the unpickler is calling SessionCredentials __init__.

I'm not sure what the right course is here, but I think something should
be done. One of these perhaps:

- Revert to old style class
- Write a conversion script
- Provide a BBB signature of __init__ with default values for login and
password

Also, since SessionCredentials is stored as session data, should it not
be Persistent?

 -- Garrett

Dmitry Vasiliev wrote:
 Log message for revision 30881:
   Eliminated all old-style classes
 
 
 Changed:
   U   Zope3/trunk/src/zope/app/authentication/README.txt
   U   Zope3/trunk/src/zope/app/authentication/groupfolder.py
   U   Zope3/trunk/src/zope/app/authentication/principalfolder.py
   U   Zope3/trunk/src/zope/app/authentication/principalplugins.py
   UU  Zope3/trunk/src/zope/app/authentication/session.py
 
 -=-
 Modified: Zope3/trunk/src/zope/app/authentication/README.txt
 ===
 --- Zope3/trunk/src/zope/app/authentication/README.txt
2005-06-22
 12:02:55 UTC (rev 30880) +++
 Zope3/trunk/src/zope/app/authentication/README.txt2005-06-22
12:05:52 UTC (rev 30881) @@ -46,7 +46,7 @@  from zope import
interface  from zope.app.authentication import interfaces
 
 -   class MyCredentialsPlugin:
 +   class MyCredentialsPlugin(object):
...
... interface.implements(interfaces.ICredentialsPlugin)
...
 @@ -56,7 +56,7 @@
... def challenge(self, request):
... pass # challenge is a no-op for this plugin
...
 -  ... def logout(request):
 +  ... def logout(self, request):
... pass # logout is a no-op for this plugin
 
  As a plugin, MyCredentialsPlugin needs to be registered as a named
 utility: @@ -83,7 +83,7 @@
 
  Our authenticator uses this type when it creates a principal info:
 
 -   class MyAuthenticatorPlugin:
 +   class MyAuthenticatorPlugin(object):
...
... interface.implements(interfaces.IAuthenticatorPlugin)
...
 @@ -688,4 +688,4 @@
  the PAU will provide it as a queriable:
 
 list(pau.getQueriables()) # doctest: +ELLIPSIS
 -  [('Queriable', ...QueriableAuthenticatorPlugin instance...)]
 +  [('Queriable', ...QueriableAuthenticatorPlugin object...)]
 
 Modified: Zope3/trunk/src/zope/app/authentication/groupfolder.py
 ===
 --- Zope3/trunk/src/zope/app/authentication/groupfolder.py
2005-06-22
 12:02:55 UTC (rev 30880) +++
 Zope3/trunk/src/zope/app/authentication/groupfolder.py
2005-06-22
  12:05:52 UTC (rev 30881) @@ -90,7 +90,7 @@ )
 
 
 -class GroupInfo:
 +class GroupInfo(object):
  An implementation of IPrincipalInfo used by the group folder.
 
  A group info is created with id, title, and description:
 
 Modified: Zope3/trunk/src/zope/app/authentication/principalfolder.py
 ===
 ---
 Zope3/trunk/src/zope/app/authentication/principalfolder.py
2005-06-22
 12:02:55 UTC (rev 30880) +++
  Zope3/trunk/src/zope/app/authentication/principalfolder.py
2005-06-22
 12:05:52 UTC (rev 30881) @@ -126,7 +126,7 @@ PrincipalInformation =
 InternalPrincipal  
 
 
 -class PrincipalInfo:
 +class PrincipalInfo(object):
  An implementation of IPrincipalInfo used by the principal
 folder. 
 
  A principal info is created with id, login, title, and
 description: @@ -195,7 +195,7 @@
 
  Create a principal with 1 as id
  Add a login attr since __setitem__ is in need of one
 -
 +
   principal = Principal(1)
   principal.login = 1
 
 @@ -267,7 +267,7 @@
  i += 1
 
 
 -class Principal:
 +class Principal(object):
  A group-aware implementation of
 zope.security.interfaces.IPrincipal. 
 
  A principal is created with an ID:
 @@ -303,7 +303,7 @@
  return 'Principal(%r)' % self.id
 
 
 -class AuthenticatedPrincipalFactory:
 +class AuthenticatedPrincipalFactory(object):
  Creates 'authenticated' principals.
 
  An authenticated principal is created as a result of an
 authentication @@ -369,7 +369,7 @@
  return principal
 
 
 -class FoundPrincipalFactory:
 +class FoundPrincipalFactory(object):
  Creates 'found' principals.
 
  A 'found' principal is created as a result of a principal lookup.
 
 Modified: Zope3/trunk/src/zope/app/authentication/principalplugins.py
 ===
 ---
 Zope3/trunk/src/zope/app/authentication/principalplugins.py
2005-06-22
 12:02:55 UTC (rev 30880) +++
  Zope3/trunk/src/zope/app/authentication/principalplugins.py
2005-06-22
 12:05:52 UTC (rev 30881) @@ -28,5 +28,5 @@ from
 zope.app.authentication import interfaces  
 
 
 -class PrincipalFactory:
 -pass
 \ No newline at end of file
 +class PrincipalFactory(object):
 +pass
 
 Modified: Zope3/trunk/src/zope/app/authentication/session.py
 

[Zope3-dev] Traversal permission vs read permission

2005-06-20 Thread Garrett Smith
I'd like to be able to grant permission to traverse a folder, but not
permission to view folder contents.

This could be handled in Zope by making
container.traversal.ItemTraverser a trusted adapter and protecting it
with a zope.Traverse permission.

I suspect this problem has been discussed before given Zope's maturity
-- and there must be a good reason this isn't done.

The obvious work around is to grant zope.View for the traversable folder
and then to take great pains to deny zope.View for every innaccessible
object in that folder. But having done this, I can say it's very likely
that an admin will forget this, leaving part of a site wide open to
unauthorized reads.

Any thoughts on this? What are the problems with the the zope.Traverse
idea?

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Choose-a-name strategy and write conflicts

2005-06-18 Thread Garrett Smith
Jim Fulton wrote:
 Garrett Smith wrote:
 The use of INameChooser is useful for picking names that don't
 conflict across serial transactions. But this approach is
 problematic when two or more transactions are tying to add objects
 to a container at the same time. Because 'choose name' relies on its
 isolated version of a container, multiple threads are destined to
 choose the same name (assuming non-random algorithm), resulting in a
 write conflict. 
 
 In some cases a write conflict is a normal and healthy thing to get,
 particularly if you let users edit the same object at the same time
 without care. But adding new objects to a container when the names
 are chosen by the system should not cause this problem. E.g. if the
 objects use unique keys, the BTree conflict resolution should
 gracefully handle the concurrent adds. 
 
 The only solution that occurs to me is to use an alternate
 persistence mechanism (e.g. a file or database) for 'next name'
 sequences and control access to it via a thread lock.
 
 Is there a way to do this in the ZODB without the use of some
 external file-locking/update mechanism?
 
 Does this problem even make sense to people, or have I lapsed into
 garbled nonsense (again) :-)
 
 It's only a problem for large shared containers that people are
 very likely to add to at the same time, so it's a somewhat
 specialized problem.

This would apply to the issue tracker, wouldn't it? 

 If people don't actually care about ids, you could generate them
 randomly.
 
 Another common scheme is to use high-precision times in th names.

Unfortunately, we need to keep the ids small because they show up in the
URLs.

I ended up implementing a secondary ZODB that serves next-in-sequence
values per container (ala an RDB generator). This turned out to be more
straight forward that I thought it would be.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Utility Registration was:RE: [Zope3-Users] pluggableauthentication utility

2005-06-18 Thread Garrett Smith
Roger Ineichen wrote:
 pluggableauthentication utility
 
 
 Hi Garrett
 
 From: Garrett Smith [mailto:[EMAIL PROTECTED]
 Sent: Saturday, June 18, 2005 7:52 PM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Cc: zope3-users@zope.org; zope3-dev@zope.org
 Subject: RE: [Zope3-dev] Utility Registration was:RE:
 [Zope3-Users] pluggableauthentication utility
 
 [...]
 
 What do yo think about that? Any other ideas?
 
 It looks like you've identified a common enough use case: PAUs are
 typically used with a common set of plugins. The current PAU design
 accommodates all sorts of use cases that most users would never face.
 
 Rather than add more complexity to the registration process with
 utilityPolicy (even though it's an attempt to make things easier
 for the user), I'd suggest creating a
 SimplePluggubleAuthenticationUtility that supported the most common
 use cases. 
 
 Something like this perhaps:
 
 class ISimplePAU(Interface):
   authentication = Choice(values=('HTTP-Auth', 'Session'))
   allowUserChangeOnUnauthorized = Bool()
   principals = Attribute(A PrincipalsFolder plugin.)
 
 This would be far easier to deal with than the current PAU for those
 that don't need PAU's flexibility.
 
 I think this isn't a solution, because of three things:
 
 - You need to do this for every other utility simplification.

I guess I'm not aware of anything that has anywhere near the
configuration complexity of the PAU.

 - I dont' like to have more then one implementation if not
   absolutly needed only for configuration reason.

I don't see this as a configuration issue. For most applications, the
PAU is too flexible/powerful and I think this is source of lots of
usability questions. A SimplePAU could be implemented using adaptation
so that a new PAU type wouldn't be necessary.

 - The activation part on the registration process is still
   the same. The most problem is that we implement components
   where using the utility and lookup this utilities by a special
   name or unnamed. But nobody tells you what name should be used
   during registration.

I think the delineation is named vs. unnamed. I agree with Stephan and
Jim that utilities that are used without names should not ask for names
-- those that use names should require them. I would add (this has
probably already been added, don't recall) a utility should have some
way of communicating that interface or interfaces that it could be
registered for. E.g. it doesn't make much sense to register the PAU for
IAnnotations.

But to reiterate -- the PAU registration does *not* accept a name value
and does *not* let the user register for anything other than
IAuthentication. I haven't heard anyone complain about the registration
issues of PAU since that change.

 I still think a policy (somthing like a add wizard) whould solve
 the problem. Developers can develope the registration process in
 a pytho class and register tehm as a utilityPolicy. Then
 administrators or scripters can add the utility witha simple klick
 on a add predefined utility button.

This sounds like a lot of work for the developer.

 On nice sideeffect whould be,
 You could also add a policy Add all utility I need for a site.
 Or even call this policy during makeSite on your special
 implementation of IPossibleSite.

I do like this idea. This is in the spirit of the server bootstrap
module that ensures that a particular set of utilties are available and
configured on startup.

I definitely think something likethis is needed for the Make a Site
action.

So, perhaps something like this:

  siteconfig
name=foo.bar.mysite
title=My Site
description=Create my cool new site.
configurator=.configMySite /

This would setup a menu and register an adapter to something like
ISiteConfig that would be used to configure a newly created site.

 I think this is what we need at the enduser level and should be
 possible to implement. Of corse the way we register utilites whould
 be still available.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Choose-a-name strategy and write conflicts

2005-06-17 Thread Garrett Smith
The use of INameChooser is useful for picking names that don't conflict
across serial transactions. But this approach is problematic when two or
more transactions are tying to add objects to a container at the same
time. Because 'choose name' relies on its isolated version of a
container, multiple threads are destined to choose the same name
(assuming non-random algorithm), resulting in a write conflict.

In some cases a write conflict is a normal and healthy thing to get,
particularly if you let users edit the same object at the same time
without care. But adding new objects to a container when the names are
chosen by the system should not cause this problem. E.g. if the objects
use unique keys, the BTree conflict resolution should gracefully handle
the concurrent adds.

The only solution that occurs to me is to use an alternate persistence
mechanism (e.g. a file or database) for 'next name' sequences and
control access to it via a thread lock.

Is there a way to do this in the ZODB without the use of some external
file-locking/update mechanism?

Does this problem even make sense to people, or have I lapsed into
garbled nonsense (again) :-)

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-06-01 Thread Garrett Smith
Jim Fulton wrote:
 Garrett Smith wrote:
 :-) I guess this approach is *so* endemic to Zope 3, I must be
 missing something huge.
 
 What we're talking about is not very different from the way that
 composition is used to prevent explosition of field types.
 
 For example, we use: List(Int()) rather than IntegerList.
 
 Note that we use a combination of type and composition,
 hopefully striking a good balence.

I see your point.

But events are essentially an API and a well defined contract is better
than an implicit one. I think we're going to see a lot code that looks
like this:

  if not 'my stuff' in event.extra:
 return
  doSomething()

OTOH, if we're talking about different event types, only the applicable
handlers gets called.

I also think this is being driven by the I can imagine... syndrome.

Anyway, I'm done spouting :-)

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-06-01 Thread Garrett Smith
Garrett Smith wrote:
 Jim Fulton wrote:
 Garrett Smith wrote:
 :-) I guess this approach is *so* endemic to Zope 3, I must be
 missing something huge.
 
 What we're talking about is not very different from the way that
 composition is used to prevent explosition of field types.
 
 For example, we use: List(Int()) rather than IntegerList.
 
 Note that we use a combination of type and composition,
 hopefully striking a good balence.
 
 I see your point.
 
 But events are essentially an API and a well defined contract is
 better than an implicit one. I think we're going to see a lot code
 that looks like this:
 
   if not 'my stuff' in event.extra:
  return
   doSomething()

I take this back -- we can always provide a multi-adapter delegator.
That's actually pretty nice.

 I also think this is being driven by the I can imagine... syndrome.

I'm still concerned about WHUI. What in the core can be replaced with
this new model?
 
 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-05-30 Thread Garrett Smith
Jim Fulton wrote:
 Uwe Oestermeier wrote:
 ...
 Alternatively, all mentioned usages could be easily subsumed under
 an extended ObjectModifiedEvent definition. Some optional keywords
 (for the interface and the attribute that was used to change the
 object, and additional infos about the changed values if available)
 are probably sufficient: 
 
 1-3: ObjectModifiedEvent(obj, interface=schema, attr=field,
 oldvalue=old, newvalue=new) 4: ObjectModifiedEvent(obj,
 interface=IObjectFile, attr=setBody) 5:
 ObjectModifiedEvent(obj, interface=IContainer,
 attr=__setitem__) 6: ObjectModifiedEvent(obj,
 interface=IContainer, attr=__delitem__) 7:
 ObjectModifiedEvent(obj, interface=IZopeDublinCore, attr=title)  
 
 Since the keywords are optional, these changes could be easily made
 in a backward compatible way.
 
 Based on the discussion so far, I'm convinced that something like this
 would be useful, at least as an optional feature, as you suggest.
 
 I suggest we generalize this a bit.  I suggest that the ObjectModified
 event could accept one or more modification descriptions (hints?).
 Some examples:
 
ObjectModifiedEvent(obj, IObjectFile)
 
 This says that we modified the objects file data.  Note that
 an interface is an acceptable description.  In fact, we
 might allow pretty muich anything as a description.
 
ObjectModifiedEvent(obj, IObjectFile,
Attributes(IZopeDublinCore, 'title',
'description'), )
 
 This says we modified the file data and the DC title and description.
 
 This information would be a hint that subscribers could use, or not
 use as appropriate.
 
 We could change the form machinery in an obvious way to generate
 attribute descriptions.

A couple questions:

- How is a 'better' (loaded term, feel free to interpret) arrangement
than using application-specific event types that clearly define a) when
the event is generated and b) what information the event conveys?

- What new burdens does this place on application developers? Does Zope
core now have to keep track of what extra information is conveyed in
various scenarios? What about library vendors?

I've viewed the current ObjectModifiedEvent as being appropriate for
simple interfaces like the ZMI. In many cases, this simple event model
works perfectly. Different applications are free to layer new event
models on top of that.

The way to add new event models (at least in my experience) is to create
new event types -- not embed extra information in an otherwise clearly
defined data structure.

It seems to me that we're trying to make the ZMI anticipate
application-specific requirements without knowing that those might be.

I'd rather see something like this:

- If a utility (or some other pluggable component) uses specific
information from an event, it should provide an event interface that
describes what it needs.

- An application that's aware of that component type can fire an event
that provides that interface.

:-) I guess this approach is *so* endemic to Zope 3, I must be missing
something huge.

 -- Garrett

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-05-09 Thread Garrett Smith
Uwe Oestermeier wrote:

...very good analysis of current modified event usage...

 Alternatively, all mentioned usages could be easily subsumed under an
 extended ObjectModifiedEvent definition. Some optional keywords (for
 the interface and the attribute that was used to change the object,
 and additional infos about the changed values if available) are
 probably sufficient: 
 
 1-3: ObjectModifiedEvent(obj, interface=schema, attr=field,
 oldvalue=old, newvalue=new) 4: ObjectModifiedEvent(obj,
 interface=IObjectFile, attr=setBody) 5:
 ObjectModifiedEvent(obj, interface=IContainer,
 attr=__setitem__) 6: ObjectModifiedEvent(obj,
 interface=IContainer, attr=__delitem__) 7: ObjectModifiedEvent(obj,
 interface=IZopeDublinCore, attr=title)  
 
 Since the keywords are optional, these changes could be easily made
 in a backward compatible way.

I certainly like the idea of getting rid of ObjectContentModifiedEvent
and ObjectAnnotationsModifiedEvent  -- they're both WHUI (we haven't use
it) as you've shown.

I'd be concerned about making ObjectModifiedEvent too burdensome for
developers. For most, cases, it's sufficient to just say this object
has changed and be done with it.

As for your goals of maintaining versioning for any possible third part
product added to Zope, I think you'll need another strategy -- there's
no guarentee that you'll get all the change info you need. Someone may
choose, for example, not to use the default forms machinery (assuming
that's even changed to support the proposed scheme).

I do think a 'property changed' scheme -- one that let subscribers veto
changes -- would be an excellent addition to the object change
lifecycle.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-05-04 Thread Garrett Smith
Uwe Oestermeier wrote:
 Garrett Smith wrote:
 
 I'd see this being something like a ValueChangedEvent that specified
 the object, schema, field name, old value, and new value. This would
 be a nice way to bolt on validation without modifying the schema.
 
 Yes, that's exactly what I need for versioning.
 
 Anyone needing more information in ObjectModified can just create a
 new event type with the additional info. This seems application
 specific to me.
 
 But there is a major problem: How can you reuse an existing
 infrastructure then? You have to write all editing views or other
 components that modify the content objects anew.

It wouldn't be that hard. You would extend EditView (in
zope/app/form/browser) and insert your own event firing as needed. Then
just specify your new view as the class attribute in ZCML. You can
redefine the standard Zope views for the handful of content types they
provide using overrides.zcml.

 In my view
 ValueChangedEvents are usefull in many applications and for many
 purposes (reindexing catalogs, updating views in standalone
 applications, triggering external processes etc.). Would it be too
 much overhead to have them in the framework from the beginning? 

I think ValueChangedEvent would be a good addition to the forms
machinery. But if you need something like that now, I'd recommend using
your own edit view class.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-05-03 Thread Garrett Smith
From the interface docs, it's not clear to me what the difference
between the events are:

class IObjectModifiedEvent(IObjectEvent):
An object has been modified

class IObjectContentModifiedEvent(IObjectModifiedEvent):
An object's content has been modified

What is the difference between 'content' that gets modified and the
object that gets modified.

How might I interpret receiving both events for a 'modify' operation on
the same operation?

 -- Garrett


Jim Fulton wrote:
 Uwe Oestermeier wrote:
 Hi,
 
 I'm working on a versioning system that creates a new version for
 each changed file content. I tried to listen  to
 zope.app.event.interfaces.IObjectContentModifiedEvents,
 but unfortunately no such event seems to be generated.
 
 Editing an existing zope.app.file.File via the edit view leads only
 to an ObjectModifiedEvent, uploading new content produces no object
 event at all. 
 
 Should this be fixed by generating ObjectContentModifiedEvents in
 both cases (which I would prefer),
 
 Yes.
 
 or should the less informative ObjectModifiedEvent be used? In the
 later case, the misleading IObjectContentModifiedEvent should
 probably removed from the list of objectevents. 
 
 In general, missing events are difficult to detect and I'm quite sure
 that file editing and uploading
 are not the only relevant cases (e.g. WebDAV and FTP are other ways
 to modify file contents). Wouldn't it be the best solution to
 generate an IObjectContentModifiedEvent in the File._setData method
 and not the view classes?
 
 I think this would be OK for this specific case.
 
 What I don't want to see is some general implicit event-generation
 scheme.
 
 Jim

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Sublocation notifications

2005-05-03 Thread Garrett Smith
We currently dispatch some object events to sublocations. I think
there's a problem with the current approach.

If I subscribe to IObjectModifiedEvent with something like this:

  def handle(object, event):
   ...

I'll get notifications where object and event.object are different. This
happens for sublocation dispatches. This was very surprising, but it
makes sense -- there are cases when you'd want to get notifications like
that.

But most of my code looks like this:

  def handle(object, event):
  # ignore Zope's sublocation dispatches
  if object != event.object:
  return
  ...

I propose that we dispatch using both the original object and the
sublocation, along with the event. Handlers for these sublocation
dispatches would then look like this:

  def handle(object, sublocation, event):
  ...

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Sublocation notifications

2005-05-03 Thread Garrett Smith
Gary Poster wrote:
 On May 3, 2005, at 5:39 PM, Garrett Smith wrote:
 
 We currently dispatch some object events to sublocations. I think
 there's a problem with the current approach.
 
 ...
 
 Why not just have your own app listen for (object, event) and then do
 this additional dispatch?  That's the usual pattern, and I'm guessing
 that we have use cases for the current (object, event) spelling.
 
 Gary

The dispatch is already being done in zope\app\container\contained.py --
it's not something I have any control over. We could tear it out I
suppose and require applications to handle it.

IIRC, there are a few places in zope/app that rely on this dispatching
though.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Missing ObjectContentModifiedEvent

2005-05-03 Thread Garrett Smith
Uwe Oestermeier wrote:
 But I could also live with ObjectModifiedEvents only.

IMO, the second event type, if it doesn't have a clear distinction,
should be removed.

 A more radical approach would be to specify in each
 ObjectModifiedEvent which aspects of an object changed. By aspect I
 mean the schema and the modified field within the schema:

I'd see this being something like a ValueChangedEvent that specified the
object, schema, field name, old value, and new value. This would be a
nice way to bolt on validation without modifying the schema.

Anyone needing more information in ObjectModified can just create a new
event type with the additional info. This seems application specific to
me.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Input widgets do too much

2005-04-25 Thread Garrett Smith
Jim Fulton wrote:
 I'd like to make some changes to the widget API.
 
http://www.zope.org/Zope3/MoreCleanupOfWidgets
 
 proposes some cleanup, but I'd like to go farther.
 
 I think widgets, especially IInputWidget have too much
 responsibility, namely:
 
 - validation
 
 - applying changes
 
 Widgets should be responsible for
 
 - getting/managing user inputs, including
conversion from raw input (but not validation).
 
 - Rendering HTML
 
 Giving widgets this responsibility makes them harder
 to implement (leading to complex base classes) and
 a bit hard to use when more control is needed.
 
 I'd like to remove this functionality from widgets,
 moving it to form code.
 
 Thoughts? Questions?  Any objections to getting this into
 3.1?  If not, I'll write a more detailed proposal.

Isn't there some pressure to get 3.1 out? I'm all for refactoring
widgets to simplify (or eliminate) the hefty baseclasses, but I had the
impression that the release was heading into its final stages.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Data manager interface -- tpc_begin and other changes

2005-04-25 Thread Garrett Smith
Jim Fulton wrote:
 This is for people who've implemented ZODB data managers.  Data
 managers are components that manage persistent data under transaction
 control, 
 
 We've recently tried to clean up and document the data-manager
 interfaces.  In addition, over the weekend, I implemented savepoints
 and was able to simplify the interfaces quite a bit.  See IDataManager
 and ISavePointDatamanager in:
 
   

http://svn.zope.org/ZODB/trunk/src/transaction/interfaces.py?view=markup
 
 In particular, note that:
 
 - The subtransaction APIs have disappeared fro data managers, and
 
 - tpc_begin no longer takes a second subtransaction argument.
 
 I *could* try to provide support for data managers with tpc_begin
 taking 2 arguments, but I'm guessing that I don't need to.  I'm
 guessing that no one has written data managers that require a second
 argument. If this is not true and you have a data manager that
 requires a second argument that I need to support, please let me know.
 
 Jim

This looks outstanding...thanks for the communiqué :-)

For my part, I'm not using substransactions, so the simplified tpc_begin
is not a problem.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Changes to transaction management API

2005-04-16 Thread Garrett Smith
Jim Fulton wrote:
 Garrett Smith wrote:
 Recent changes to the transaction management API seem to have come
 out of the blue and without warning. Perhaps I missed an
 announcement. 
 
 Are we to expect breakages of this sort on occasion?
 
 Was there breakage? If there was, it was unintended.
 
 Jim

IDataManager was completely restructured. Anyone plugging into the
transaction management facility will be broken by these changed.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Changes to transaction management API

2005-04-16 Thread Garrett Smith
Tim Peters wrote:
 [Jim Fulton]
 Was there breakage? If there was, it was unintended.
 
 [Garrett]
 IDataManager was completely restructured.

This was not accurate -- the restructuring happened a while ago and I
didn't catch it. I assumed this change was made along with the one I
list below.

 If you don't have specific breakage to report, then I'm afraid I'm not
 going to take a lesson from this, cuz I just don't know what you mean
 here.

Change 29961 -- I was using the 'savepoint' function along with
NoSavepointSupportRollback, which disappeared.

 As a pragmatic matter, I'd avoid even importing the interfaces defined
 in ZODB, because they're still so inadequate and crude (as above, even
 ZODB mostly ignores them now).  ZODB was a very late starter in the
 interface game, and there's not enough resource to play intense
 interface catchup in that project -- this gets poked at in slow
 motion, by forcing it briefly from time to time at the expense of more
 urgent ZODB tasks.

I don't think this has anything to do with the ZODB.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] problems with Win buildinstall

2005-04-06 Thread Garrett Smith
Adam Groszer wrote:
 I'm trying to build  install the Zope 3 trunk on Win2K.
 I'm having some problems with it.
 
 May I post them here or is it too early for the upcoming release?
 
 Adam
 
 ___
 Zope3-dev mailing list
 Zope3-dev@zope.org
 Unsub:

http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojave-corp.com

Feel free to post here. A few of us use WIndows, shunned as we are ;)

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] RFC: Change in automatic detection of providedinterfaces

2005-04-06 Thread Garrett Smith
Jim Fulton wrote:
 A recent simplification was made to adapter and utility registration.
 When registering adapters, the provided interface can be ommitted
 if the registered factory implements a single interface.  Similarly,
 when registering utilities, the provided interface can be ommitted
 if the registered component provides a single interface.
 
 The intent is that if you have something like:
 
class MyClass:
implements(IFoo)
 
...
 
 you do not have to repeat IFoo in the registration.
 
 The current scheme runs into problems if you use inheritence:
 
class MyClass(SomeBase):
implements(IFoo)
 
 Then declarations in the base class cause the subclass
 to implement multiple interfaces.
 
 I'd like to make the following change to algorithm for determing
 the provided interface if nothing is specified in the rgistration:
 
For adapters, if the registered factory directly implements
a single interface, then that interface will be used.  Inherited
interfaces will not be considered.  If the factory directly
implements no interfaces or more than one interface, then a
provided interface must be provided in the registration.
 
For utilities, if the registered component directly provides no
interfaces and its class directly implements
a single interface, then that interface will be used.  Inherited
interfaces will not be considered.  If the component directly
provides any interfaces or if its class directly implements
no interfaces or more than one interface, then a provided interface
must be provided in the registration.
 
 So, for example, if we have:
 
class B:
   implements(IB)
 
class S(B)
   implements(IS)
 
 we can register S or an instance of S without specifying a provided
 interface.  The interface IS will be used.
 
 However, with:
 
class S2(B):
   pass
 
 You would have to sp[ecify a provided interface if you registered S2
 or an instance of S2.
 
 Thoughts?

Seems straight forward enough. Personally, I view the implements clause
in these cases as a substitute for the provides in ZCML, so I always
list a single interface anyway in such cases.

 -- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



RE: [Zope3-dev] Form framework, adapters and pau

2005-04-05 Thread Garrett Smith
Jim Fulton wrote:
 Garrett Smith wrote:
 I don't understand the pushback against location proxying
 security-proxied objects. LocationProxy does actually play well with
 security-proxied objects.
 
 That was not our experience in the recent past.  I'll have to document
 the problems, assuming that I can reproduce them.

Are you referring to the problems Gary ran into when he modified the
form setup machinery? I ran into the same problems in our application,
which led to the mods to make LocationProxy work with security proxied
objects.

 I wonder if it would make sense for the trusted adapter machinery to
 simply set __parent__ on adapters if either the adapter provides
 ILocation 
 *or* the adapter doesn't already have a __parent__.  This would solve
 the problem and avoid the proxy.

Apart from the works/doesn't work issue (your previous point), are you
concerned that we'll see LocationProxy popping up whenever we need
location-sensitive lookups? Would that be a bad thing?

I've found LocationProxy to be essential providing location-specific
lookup capability in more than forms. E.g. I often location-proxy
objects in events where handlers perform operations that want local
authentication facilities.

 -- Garrett

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com