[Zope3-dev] ZODB mount points
(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
[Zope3-dev] fssync and export/import for Zope 3
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] Exporting and importing specific objects/folders
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
RE: [Zope3-dev] Exporting and importing specific objects/folders
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
[Zope3-dev] Exporting and importing specific objects/folders
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, or exactly how it could be used for this. Any recommendations? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Visualization tool for profiler/hotshot
Does anyone know of a GUI tool for exploring stats files generated by a profiler? -- 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
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 '</'. 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
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
On Friday, September 16, 2005 5:30 PM, Benji York wrote: > Garrett Smith wrote: >> On Friday, September 16, 2005 5:17 PM, Benji York wrote: >>> Garret Smith wrote: >>>> 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. >>> >>> That is a different, but related, problem that should probably be >>> addressed separately. >> >> How is this different? > > Resource library is about including references to (static, > file system > based) resources on an as-needed basis. The use case you > mentioned is > about including dynamically generated JS each time a view is rendered. I thought the use case was rich widgets. If the use case is the proposed solution, then the proposal is spot on ;-) But enough of my whining :-) Let's just make sure this new thing doesn't impact publishing performance. Preferably this would be implemented as pluggable component and be optional. -- 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
On Friday, September 16, 2005 5:17 PM, Benji York wrote: > Jim posted some food for though, but "pipelining" is > tangential to this > discussion. The only relation is that once there is a better way to > manipulate the results of publication the "hacky" parts of > the current > implementation of resource library will get cleaner. That's all. I guess until a fuller design emerges, I'll just feel uncomfortable with the approach. >> 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. > > That is a different, but related, problem that should probably be > addressed separately. How is this different? -- 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
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] Resource Library Proposal
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: >> >> >> >> >> ... >> > > 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
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 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: ... 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
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
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: >> >> >> Name >> >> >> >> The analog for including header support (i.e. JS and CSS) is: >> >> >> >> >> >> >> >> 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
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: Name The analog for including header support (i.e. JS and CSS) is: 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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
On Monday, August 29, 2005 4:33 PM, Gary Poster wrote: >> Couldn't 'initial_getter' just be implemented using a property >> version of 'initial'? > > Yes, it could. The only downside is that it wouldn't be > usable as an > initialization argument. I don't feel very strongly about it > one way > or the other. It sounds like Jim is a definite -1 (as I thought he > might be :-) so I'm happy to drop it. I think I agree with Jim, see my other post. >> Cool. I don't know if this is the same thing, but we have a widget >> that handles editing two related fields. One field is a boolean >> that, when False, renders the other field not-applicable. E.g. when >> the user unselects a checkbox, a list box becomes disabled. Our >> implementation is a bit of a hack, since the widget has to cheat >> and get access to additional fields. > > Huh, interesting. It sounds different. What is the typical use for > this sort of field? It's not a field -- it's a widget that cheats and updates multiple fields because the fields are closely related. Probably not worth worrying about at this point. >> I can probably free up some time to look at SimpleInputWidget. > > That would be great--you mean, during the same time as the > sprint, or > before, or after? If before or during, we should probably coordinate. If the API falls into a collaboration category, I can try to be available via IRC. I suspect it will be more efficient to just have a brainstorm during the sprint, put together a simple proposal and work up a prototype. The SingleInputWidget Jim's talking about will end up looking a lot like SimpleInputWidget. When is the sprint anyway? :-) -- 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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
> 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
RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
To ease our own development, I forked the schema and widgets code a while back. I don't think we've deviated too severely, but I've added whatever 2 cents based on my experience below. > 1 Flesh out the 'source' design and implementation so it can replace > and deprecate vocabularies. Specifically, to match the capabilities > of vocabularies, we'll add an interface that a source can implement > if they want to be bound to a context; and we will make it possible > to have iterable sources (for small collections as would be > appropriate for selections, radio button groups, checkbox groups, > etc.). This will reduce the potential for confusion by letting > sources be the 'one true way' to describe possible options for a > choice, instead of the current overlap of vocabularies and sources. > The primary advantage to sources over vocabularies are that > the model > is cleaner; the only additional feature is the ability to configure > different tokens for a given source. This sounds good. The one main hassle I've faced with vocabularies is the seeming complexity of the queriables UI scheme. I've spent much time tracking down how everything fits together, but unfortunately never spent the time to figure out a simpler approach. If it's already as simple as possible, fine -- sometimes stuff's just hard to simplify. > 2 Clean up the exceptions widget framework. The use of the widget > input error is quite messy: see collector issue 273. The idea would > be to make the use of the errors argument more consistent and more > restricted, and make the 'doc' implementation simpler. I have a ValidationError that looks like this: class ValidationError(zope.schema.interfaces.ValidationError): def __init__(self, msg, *args): zope.schema.interfaces.ValidationError.__init__(self, *args) self.msg = msg def doc(self): return self.msg This was to workaround the strangeness of displaying a class-level description, rather than the specific msg provided with the error. > 3 Make the arbitrary constraints in the schema framework more > powerful: specifically, allow a field to accept more than one > constraint, and have the constraints raise errors (with an i18n doc, > if desired) rather than return an uninformative Boolean. > This can be > done in a backwards (and deprecation) compatible way by keeping the > constraint argument and adding a constraints argument wit the new > semantics; or with another approach. *would need small proposal* > *code exists* > > 4 Recognize and document that the 'default' field argument is > actually 'initial value'. That is, if you set a field with a > default > to the missing_value, the default does not become the field's value: > the 'default' value is only used if the value has never been set > (i.e., during creation or when there is no previous state of the > value). Possibly rename to 'initial_value' (with deprecation > support). *would need proposal* Our version of IField has an 'initial' attribute. We don't use default. I prefer 'initial' to 'initial_value'. > 5 Allow fields to accept a default (or initial_value, as above) *or* > a default_getter (or initial_value_getter, as above). > default_getter/ > initial_value_getter would be a callable passed the field's > context. > It should return the desired initial value. Use cases include > initializing to now, today, the current user, etc. *would > need small > proposal* *code exists* Couldn't 'initial_getter' just be implemented using a property version of 'initial'? > 6 Add union field and widget to schema and form, respectively. A > union field allows a user to fill in one of several types of > values. > Use cases include faux combo boxes (i.e., a choice or a text line), > date/duration choices, etc. Widget is reasonable and has been used > by ZC for more than a year. *would need small proposal* *code exists* > > 7 add combination field and widget to schema and form, > respectively. > A combination field allows a user to fill in multiple values > simultaneously, and returns a tuple of the combined values. Use > cases overlap somewhat with object field/widget, but this is simpler > to use for simple use cases. Use cases include range fields. > *would > need small proposal* *code exists* Cool. I don't know if this is the same thing, but we have a widget that handles editing two related fields. One field is a boolean that, when False, renders the other field not-applicable. E.g. when the user unselects a checkbox, a list box becomes disabled. Our implementation is a bit of a hack, since the widget has to cheat and get access to additional fields. > 8 Add suggestion and MRU (Most Recently Used) widgets. These > widgets > provide a drop down of suggested (specifically most recently > used for > the MRU widget) values for a choice field. They really make using > choice widge
RE: [Zope3-dev] Proxy and __slots__
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
[Zope3-dev] Proxy and __slots__
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
[Zope3-dev] Viewing/downloading large files
>From the looks of the z/a/file/File code, viewing a file will cause all of the >file contents to be loaded into memory (specifically, I'm looking at line 45 >of z/a/file/browser/file.py). Is there a way to provide a file-like object (no pun intended, i.e. something with streaming capabilities) to the response rather than a single block of bytes? -- 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 a production server
Does anyone have some suggestions for debugging a production server? In development mode, I'm quite accustomed to adding set_traces and restarting the server, but this is no good in a production environment. -- 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)
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 R&D (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 R&D (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: change effecting custom authenticator search UIs
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] HEADS UP: PrincipalInformation -> InternalPrincipal
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
RE: [Zope3-dev] Deprecation of NotFoundError (#284)
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) > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I checked in the deprecation of NotFoundError. (rev 37531) > You might want to check the BBB on your existing app. > > J. > - -- > Julien Anguenot | Nuxeo R&D (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 > > iD8DBQFC6OQ4GhoG8MxZ/pIRAmtbAJ9apt6DW+z2GwOAmJXPu0+57Rf8BQCeNjvx > nOYxZto0/swcRfQTw5Db/vg= > =JgwO > -END PGP SIGNATURE- > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojav > e-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] Debugging deadlocks in Zope3
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?
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] [Fwd: SVN: Zope3/trunk/src/zope/app/form/browser/ Fixed a bug in SimpleInputWidget. _getFormValue had an evil side]
As the person who refactored SimpleInputWidget (not the author), I concur that it can be trying to use. We've actually forked that code, so I can't say whether it makes things easier or harder. There's certainly enough collective experience with forms/widgets that we could stand another round of refactoring. Jim, it sounds like you've got some specific ideas in mind. I know you mentioned helper functions at one point. Do you have some widgets at ZC that illustrate your thinking? -- Garrett > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Jim Fulton > Sent: Thursday, July 21, 2005 10:08 AM > To: zope3-dev@zope.org > Subject: [Zope3-dev] [Fwd: SVN: > Zope3/trunk/src/zope/app/form/browser/ Fixed a bug in > SimpleInputWidget. _getFormValue had an evil side] > > > I wanted to call this to attention of the wider list. I > corrected a bug/missfeature in SimpleInputWidget. I had to > comment out some tests that were testing this feature. If > anyone wants to defend the feature that the tests were > testing, I'm willing to discuss it. > See my comments in the forwarded check-in message if you're > interested. > > I strongly dislike SimpleInputWidget. (Apologies to the > author.) I'd love someone to move standard widgets away from using it. > Writing widgets is not very hard, but you wouldn't know it by > looking at this base class. Trying to use this base class > makes widget creation harder (unless you are the author of > SimpleInputWidget :). > > 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] Formatting dates
> -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
[Zope3-dev] Using zopectrl to restart Zope
I noticed some discussion along the line of using CTRL-C to stop Zope. I think the conclusion was that it was okay for development only. We use zopectrl as the base for a Linux service (using chkconfig). Does "zopectrl stop" allow pending transactions to complete (and presumably ignore/reject incoming requests)? -- 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
> 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
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
RE: [Zope3-dev] zope.security.interfaces.ForbiddenAttribute: ('utcoffset', )
This was entirely on my side -- I had a 'funny' in a security checker that
cropped up with the tz change.
-- Garrett
> -Original Message-
> From: Gary Poster [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 19, 2005 11:37 AM
> To: Garrett Smith
> Cc: Zope3-Dev (zope3-dev@zope.org)
> Subject: Re: [Zope3-dev]
> zope.security.interfaces.ForbiddenAttribute: ('utcoffset', )
>
>
> On Jul 18, 2005, at 7:04 PM, Garrett Smith wrote:
>
> > 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?
>
> Hm.
>
> security proxies, of course, can't be persisted, so this
> would only happen if your datetime were proxied (which is
> completely reasonable).
>
> Did you try just making a security declaration and seeing if
> that fixed the issue? I haven't encountered the problem. I
> would think you could just do something like
>
>
>
>
> I'm not sure where to put this in zope.app...maybe zope.app.interface?
>
> Gary
___
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
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] zope.security.interfaces.ForbiddenAttribute: ('utcoffset', )
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] Broken ZODB (was SVN: Zope3/trunk/src/zope/app/authentication/Eliminated all old-style classes)
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 Pr
[Zope3-dev] Traversal permission vs read permission
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] Utility Registration was:RE: [Zope3-Users] pluggableauthentication utility
Roger Ineichen wrote: > Perhaps we can solve the PAU problem with a IFactory called > CreateSimplePAU and this factory can add and configure the PAU. > > Can we use a factory class for creating utilities? Yes. That would be very easy -- and would approximate your utility config idea without adding another 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] Utility Registration was:RE: [Zope3-Users] pluggableauthentication utility
Roger, I wonder if what you're looking for could be accommodated via the
"Tools" idiom. I dont use tools myself, but I've heard they're used by
some. From what I understand, tools might be a way to expose specific
utility configuration settings via a higher level interface.
Anyone?
-- Garrett
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 dont' like to have more then one implementation if not
> absolutly needed only for configuration reason.
>
> - 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 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.
>
> 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 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.
>
> Regards
> Roger Ineichen
>
> Projekt01 GmbH
> www.projekt01.ch
> _
> END OF MESSAGE
>
>> -- 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
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:
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
RE: [Zope3-dev] Utility Registration was:RE: [Zope3-Users] pluggableauthentication utility
Roger Ineichen wrote:
> pluggableauthentication utility
>
>
> Hi Jim,
>
> perhaps we can discuss this on zope3-dev.
>
> From: Jim Fulton [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, June 16, 2005 12:03 PM
>> To: [EMAIL PROTECTED]
>> Cc: 'GMane'; zope3-users@zope.org
>> Subject: Re: [Zope3-Users] pluggable authentication utility
>>
>> Roger Ineichen wrote:
>>> Hi Ricki
>>>
>>> On Behalf Of GMane
>>>
Sent: Wednesday, June 15, 2005 5:52 PM
To: zope3-users@zope.org
Subject: [Zope3-Users] pluggable authentication utility
Hi,
I have a simple question about pluggable authentication.
I created a folder and I made it a site.
In the default Site-Management Folder I created a Pluggable
Authentication Utility (named plaut).
Inside it I made a PrincipalFolder (Partner) and added a user soc1.
>>>
>>>
>>> Don't give a name (plau). Pluggable authentication utilities
>>> are as dfault unnamed. All components right now will lookup the
>>> PAU with name=''.
>>
>> For 3.2, we need to find a way to make this clearer. Either we need
>> to provide a more verbose description of what the name is for or
>> perhaps, as Stephan has suggested, for components that are always
>> looked up without names, we should not provide the option of
>> entering a name and, for others, we should require a name.
>
> We have to totaly hide this part and offer a different concept.
> Of corse the normal registration will be available too.
>
> I propose to add something like a policy. A policy should register
> a utility. This means we can add policies via ZCML and the user can
> only process this policy which registers the utility in a predefind
> way.
>
> Then we can provide a task like. "register PAU" and everything gets
> registred. There could also be a different policy like:
> "register PAU with initial principal folder" etc.
>
> A ZCML directive could look like:
>
> name="Add PAU with principal Folder"
> for=".interfaces.IPluggableAuthentication"
> class=".authentication.AddPAUWithPrincipalFolderPolicy"
> />
>
> Then we can offer adding utilities via this policies.
>
> If somebody likes to register a utility in a different way, he can
> add own policies for a utility.
>
> I use this pattern in a own registry in a different usecase. It makes
> it very simple for anduser and even me to register components in a
> registry. And you don't have to know every little about the
> registration process.
>
> 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.
-- 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
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
[Zope3-dev] Choose-a-name strategy and write conflicts
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
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
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
Florent Guillaume wrote: > On 31 May 2005, at 12:39, Garrett Smith wrote: >>> That looks good to me. Especially because, using interfaces, we >>> could theoretically express more than just a set of attributes that >>> have changed on an object. I'm thinking of: >>> >>> - having the interface itself add semantics to what a subscriber >>> could want to do about the change (i.e., it could recognize >>> IZopeDublinCore and decide to delay its work), >>> >>> - having the interface express more complex object structure than >>> just a set of attributes (I'm thinking about XML Schema-derived / >>> XForms interfaces, where you can represent deep structures). >>> >>> That's all science-fiction of course. >>> >> >> This is my concern :-) >> >> I'm seeing a lot of hypothesizing and we should instead be driven by >> hard requirements/use cases. > > Ah no, I'm saying that in addition to fulfulling existing scenarios I > have, it also fulfills some fantasy ones :) > >> IIR, the one definite requirement is to provide support for object >> versioning. But, as Jim's pointed out, this is probably better >> handled at a lowed level, since there's no guarantee *any* event >> model will be sufficient. > > That's if you want things to be totally transparent, yes. Which is a > valid concern, but I'm not sure it's the most expressive choice for a > system. I wouldn't mind requiring have a small bit of cooperation > from objects if they want to be versioned properly. I see your point. But I think you're asking a lot from the system. It's going to be very hard to accomplish what you want even with this proposed eventing scheme. I'd hate to see this increased complexity without any assurance that it will even meet the one hard requirement driving it. Have you explored looking at versions at the persistence level? I would think the Zope 2 community would have a ton of experience that would be valuable here. -- 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
Florent Guillaume wrote: > Jim Fulton <[EMAIL PROTECTED]> wrote: >> 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. > > That looks good to me. Especially because, using interfaces, we could > theoretically express more than just a set of attributes that have > changed on an object. I'm thinking of: > > - having the interface itself add semantics to what a subscriber could > want to do about the change (i.e., it could recognize > IZopeDublinCore and decide to delay its work), > > - having the interface express more complex object structure than > just a set of attributes (I'm thinking about XML Schema-derived / > XForms interfaces, where you can represent deep structures). > > That's all science-fiction of course. This is my concern :-) I'm seeing a lot of hypothesizing and we should instead be driven by hard requirements/use cases. IIR, the one definite requirement is to provide support for object versioning. But, as Jim's pointed out, this is probably better handled at a lowed level, since there's no guarantee *any* event model will be sufficient. -- 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
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: What is modification, and why do we care? (was Re: [Zope3-dev] MissingObjectContentModifiedEvent)
I'm not wedded to this philosophy, but I think Zope should provide as little application-specific event notifications as possible. I think even the distinction between 'content' and 'metadata' in the current implementation is dubious. (I don't believe the 'metadata' events are even used.) I'd just as soon see a single 'object modified' event that gets fired by the ZMI interfaces as appropriate. The rest (I think) is all application specific. If there are a handful of important indexes (e.g. text), they might publish an applicable set of events that can be fired by applications that want to use them. I don't think this needs to be in the core -- each index (or other utility) needs to provide its own event-API. My take anyway. -- Garrett Jim Fulton wrote: > MissingObjectContentModifiedEvent) > > > > A week or so ago, there was a thread on the distinction between > IObjectModifiedEvent, IObjectAnnotationsModifiedEvent, and > IObjectContentModifiedEvent. > > I'd like to step back a little bit and brainstorm some use cases > that, hopefully, illustrate why we care about this. Here's > a start: > > - A persistence or versioning system wants to know when objects >have changed so that they can save new versions of the object. > >This needs to be pretty much fool proof. To do this, I think you >really need to do something like what the ZODB persistence >mechanism does. Perhaps for versions, once could hook into >this mechanism somehow. > > - Record, as meta data, the time that an object changes. >My original thought was that this would track only >data, not meta-data changes. This is not what we are doing now. >For example, updating an object's DC title changes it's >modification time. > >I'm not sure what we should do here. > > - Update indexes (and other cache-like data structures) > >There is a thought that perhaps the generated event could >contain enough information to eliminate some indexes from >use. This is (mostly) an optimization. > >In one of his proposals, Uwe suggested including an >interface and attributes that were changed as optional >information in an event. In some cases, I think this >information could be pretty useful, however, it probably isn't >useful in as many cases as you might expect. The common pattern >for Zope 3 indexes is that they adapt an object to an interface >of interest. The index can't really know how an adapter >computes it's data. The data are sometimes computed from >data in a completely separate interface. > >Probably the indexes that we *most* want to avoid reindexing are >text indexes. We have a ISearchableText interface that we >commonly adapt objects to to get the text to index. We really >can't predict how this text is computed. > >A safer strategy seems to me to be to have the indexes themselves >responsible for detecting changes that they care about. I'm >pretty sure that some of the Zope 2 indexes are careful to avoid >reindexing, or at least avoid updating indexes if indexed values >haven't changed. Unfortunately, the Zope 3 indexes don't seem to >be doing this fairly straightforward optimization, which is a >shame. > > Given the applications above, I don't think that there's value in > fine-grained modification events that justifies the complecity of > proposals we've thought of so far. > > Thoughts? > > Are there other applications for modification events that > I haven't considered? > > 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] Missing ObjectContentModifiedEvent
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
Jim Fulton wrote: > Garrett Smith wrote: >> Uwe Oestermeier wrote: >> >>> In the meanwhile we need a decision, whether the >>> ObjectContentModifiedEvent should be used in the File._setData >>> method. I would like to check this solution in. Any objections? The >>> ObjectContentModifiedEvent class can be removed later on, if noone >>> else is using it. >> >> >> -1 if ObjectContentModifiedEvent does't have a clear distinction from >> ObjectModifiedEvent. For my part, I don't see a difference in >> modifying a 'data' attribute because it's a large number of bytes, >> versus modifying a 'title' attribute or some other non-'content' >> value. >> >> If ObjectModifiedEvent isn't firewhen when a file's data changes, it >> should be (assuming people buy my previous point :) > > I think the distinction is pretty clear. Clear enough after you explain it. > We divide information into ordinary/intrinsic and meta/extrinsic > informatiom. > > IObjectContentModifiedEvent should indicate that intrinsic information > has changed. > > IObjectAnnotationsModifiedEvent, which isn't well named, should > indicate that extrinsic/meta information has changed. So we shouldn't see ObjectModifiedEvent being fired directly then. It should be one of the two subclasses, correct? This is not the case throughout zope/app. -- 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
Uwe Oestermeier wrote: > In the meanwhile we need a decision, whether the > ObjectContentModifiedEvent should be used in the File._setData > method. I would like to check this solution in. Any objections? The > ObjectContentModifiedEvent class can be removed later on, if noone > else is using it. -1 if ObjectContentModifiedEvent does't have a clear distinction from ObjectModifiedEvent. For my part, I don't see a difference in modifying a 'data' attribute because it's a large number of bytes, versus modifying a 'title' attribute or some other non-'content' value. If ObjectModifiedEvent isn't firewhen when a file's data changes, it should be (assuming people buy my previous point :) -- 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
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
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] Sublocation notifications
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
[Zope3-dev] Sublocation notifications
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] Missing ObjectContentModifiedEvent
>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
RE: [Zope3-dev] Data manager interface -- tpc_begin and other changes
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] Input widgets do too much
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] Changes to transaction management API
Jim Fulton wrote: > You were using? Or implementing? Do you realize that these wern't > actually being used and wern't implemented correctly? Sorry, implementing, not using. > (BTW, One of the reasons for doing this cleanup is to set the stage > for a decent savepoint implementation.) > >>> 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. > > I'm afraid it does. ZODB is in a somewhat uniquely bad > state with regard to it's documentation and documented APIs. > As we can steal little chunks of time, Tim and I (and recently > Christian Theune) are trying to clean them up, but, as Tim says > you shouldn't pay much attention to them at the moment. I > expect that in the not too distant future we'll be able to get > them to a place where they are actually useful. This is good to know -- I'll tread more carefully for the time being. -- 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
Tim Peters wrote: > Maybe we need to stuff this crap back in again, despite that it's > usless (the only thing actually implemented was an elaborate way of > raising NotImplementedError) and misleading (because the ZODB4 scheme > will never be implemented)? I don't know, but it sure isn't > attractive. No need for that, at least not for my sake. >>> 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. > > It does: the transaction package is external (to Zope3) code, and > comes from the ZODB project. That wasn't new in ZODB 3.3 or 3.4, BTW > -- transactions are a database concept, and the core implementation of > transactions has always come from ZODB. Everything you've talked > about here so far is ZODB's code. Alrighty then. I'll keep my eye for changes to those packages then. I wasn't aware that they were still in so much flux. -- 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
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] Changes to transaction management API
Tim Peters wrote: > [Garrett Smith] >> 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? > > Not often. The formal interfaces for the transaction API contained > errors (of omission and commission) and unimplemented nonsense that > was never going to be implemented. It was a mess, and it's still not > entirely correct, although the methods in the interfaces now are fully > supported. > > More pedantically, ZODB 3.4 is still in an alpha release, and yes, > changes in alphas aren't unheard of . Indeed, but a short 'heads up' goes a long 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] Changes to transaction management API
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
[Zope3-dev] Changes to transaction management API
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? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] httpdoc problems
I'm getting this rather uninformative error message when I try to build a doctest using tcpwatch output. Traceback (most recent call last): File "\SCM\zope\Zope3\src\zope\app\testing\dochttp.py", line 224, in ? main() File "\SCM\zope\Zope3\src\zope\app\testing\dochttp.py", line 101, in dochttp assert (request and response) or not (request or response) AssertionError -- 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] New preferences package
Stephan Richter wrote: > On Thursday 07 April 2005 19:43, Garrett Smith wrote: >> I suggest that new packages like this should be as decoupled from >> zope/app as possible until it's clear that they belong in the core. > > If apidoc is in the core, the preference will be too. :-) It's not currently and until there's a light-weight version that makes sense for minimal Zope installations, I would argue that it should never be. Please keep in mind that some of us use Zope as an embedded application server. Zope needs to remain flexible in terms of how it can be distributed. If zope/app/configure.zcml grows unabated, Zope will become unnecessarily brittle. Thanks goodness we have package-includes, right? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] New preferences package
Can we move the config out of zope/app/configure.zcml and move it into package-includes? I suggest that new packages like this should be as decoupled from zope/app as possible until it's clear that they belong in the core. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
zope3-dev@zope.org
I'm not sure offhand what you're running into. I would say it's subversion + your system. If I do a clean checkout of Zope3 I can use bin/mkzopeinstsance to create new instances that work fine. Was your checkout to an empty directory? -- Garrett Adam Groszer wrote: > OK, here they come: > > /bin is not copied to \Scripts > -copied by hand > > /zopeskel is not copied to \zopeskel > -copied by hand > > \zopeskel\etc\securitypolicy.zcml missing > -copied from > > \zopeskel\etc\package-includes empty > -copied from /package-includes > > \Lib\site-packages\buddydemo\locales dir missing > -copied from \src\buddydemo\locales > > dir>\Lib\site-packages\bugtracker\browser\help\tracker_overview.rst > does not exist > -copied from \src\bugtracker\browser\help > > after these and running mkzopeinstance Zope starts fine. > > Adam > > ___ > 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
RE: [Zope3-dev] RFC: Change in automatic detection of providedinterfaces
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
zope3-dev@zope.org
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] Form framework, adapters and pau
Jim Fulton wrote: > Subject: Re: [Zope3-dev] Form framework, adapters and pau > > > Here's an alternate proposal: > > Let's put the proxying in the trusted adapter factory. > > Let's make the trusted adapter factory add the proxy > if the adapter doesn't set ILocation. Then the form code > stays clean and other code will benefit. This would become > part of the definition of trusted adapters. > > If there are no objections, let's do it this way. > > Jim This is definitely better. It follows the pattern of the container machinery wrapping contained objects that don't provide IContained. -- 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
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
RE: [Zope3-dev] Form framework, adapters and pau
I don't understand the pushback against location proxying security-proxied objects. LocationProxy does actually play well with security-proxied objects. -- Garrett Dominik Huber wrote: > Jim Fulton wrote: > >> Dominik Huber wrote: >> >>> A few months ago the following code block was removed in >>> editview.py, editwizard.py and schemadisplay.py (revision 29418): >>> >>>def _setUpWidgets(self): >>>adapted = self.schema(self.context) >>>if adapted is not self.context: >>>if not ILocation.providedBy(adapted): >>>adapted = LocationProxy(adapted) >>>adapted.__parent__ = self.context >>>self.adapted = adapted >>>setUpEditWidgets(self, self.schema, source=self.adapted, >>> names=self.fieldNames) >>> >>> As a consequence each trusted adapter class should now implement >>> ILocation >> >> >> One could, as an alternative, use an non-trusted adapter >> that is public and rely on the underlying object protection. > > We can only use trusted adapters for our use case. > >> >>> that the TrustedAdapterFactory can set the location of adapter >> >>> instances correctly. Otherwise, only the global authentication is >>> involved and the edit view fails if any local principal tries to >>> edit a certain field (security.canWrite(source, name) in >>> zope.app.form.utility line 207). >>> >>> I would like to revert those changes. IMO a framework like the form >>> framework knows the context (location) and adapts that context to a >>> certain schema. If the following procedures depends on location >>> information, the framework itself should pass such informations in a >>> smart way. It's an unnecessary >>> expense >>> to force all schema adapters >>> to implement ILocation: >>> >>> - The solution using the location proxy seems fairly famillar >>> compared with the container framework and containment that does not >>> provide ILocation. >> >> >> Except that the object being location proxied is already security >> proxied. Location proxies were not designed to proxy >> security-proxied objects. > > Theory: > I cannot assess this location-proxied securtiy proxy issue. Therefor I > have a question about the order of containment proxies: > 1. contained proxy > security proxy > component > 2. security proxy > contained proxy > component > So far I thought a component is created and proxied by their factory, > afterwards it is contained proxied by the container if it does not > provide ILocation. Therefor my statemets bases of 1. > > So for me it is not very obvious what the difference should be between > location proxied containement and location proxied trusted adapters: > location proxy > security proxy > trusted adapter > > Practise: > The form framework does not work using trusted adapters which do not > provide ILocation in combination with the local authentication > information. This raises an Unauthorized exception if a local > principal with enough privileges tries to access the edit view. > (Reason: Because the unlocatable adapter invoke the global > authentication only). > > We have three oportunities: > a) status quo > b) location proxy or simalar derivates > c) extend security.canWrite(obj, name, context=None) > d) ... > > History: > Roger removed the location proxy code because at that time the > security information get lost using location proxies (Reason multiple > security proxies: security proxy > location proxy > security proxy > > trusted adapter). Afterward Garret fixed the proxy method of the > Checker class. Since that time proxied object will be only proxied if > their were not already proxied before (location proxy > security > proxy > trusted adapter) > >> >>> - An adapter that implements more than one interface cannot be >>> registered with the implicit adapts and implements informations. >> >> >> True. >> >>> - A regular schema does not extend ILocation therefore it is not >>> obvious to write an adapter implementing ILocation. >> >> >> True. >> > If you answers the last two reasons with True then follows IMO a) is > a bug. > > So we have to choose an other implementation alternative > b), c) or d) would be ok for me. > >>> Any objections? >> >> >> Yes. :) >> >> Why not simply use an untrusted public adapter? > > Use case: > We have within the site 's' an extendable containerish component 'f' > (Class Fasade) that should fasade its containment . Inside 'f' we can > put any component for example component 'any' (Class Any) providing > 'IAny'.The IWriteContainer declaration of 's' requires the permission > 'zope.ManageContent'. The IWriteContainer declaration of 'any' > requires a dedicated permission for example 'zope.ManageInside'. > > Now we should provide an edit-view for 'f' that invokes the contained > component 'any'. The edit-view should be accessable for local > principal of s which have the 'zope.ManageContent' permission. > > Our design goal tries to s
