[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
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
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
[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] 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 'lt;/'. Does this extra text show up even if your template is empty? I.e. delete the template text and see what happens. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] browserDefault uses '@@' for containers
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
Sorry for the long delay in replying. We've been using widget-specific JS and CSS for some time now and I like our approach. It's quite different from the proposal. We're using the same pattern used by forms/widgets -- i.e. the PT is responsible for explicitly including HTML fragments provided by the view. As a point of reference, here's a simple example of including widgets: tal:block repeat=widget view/widgets label tal:content=widget/labelName/label input type=text tal:replace=widget / /tal:block The analog for including header support (i.e. JS and CSS) is: head tal:block repeat=content view/headContent tal:block content=content / /tal:block /head This places the burden of managing unique lists of 'head content' with the view. I see this as an extension of the widget-management framework. I would not personally opt for the proposal because it feels a bit magical -- I think it's too indirect. So, here's my argument in brief: Since widgets are driving the requirements of a consolidated resource list in the HTML head, the solution should extend the existing widget pattern. Yes, this imposes more overhead on the PT and the view, but the upside (IMO) is that the scheme is more transparent. -- Garrett On , [EMAIL PROTECTED] wrote: I've added a proposal for Zope 3.2. Read at http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitectu re/ResourceLibrary. WARNING: zope.org exhibiting some serious caching strangeness, so please comment on the list instead of the wiki. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
I don't understand what you just said :-) My fault -- I haven't been plugged into the other discussion. Is there a branch somewhere that has a simple demo to help with grokability? -- Garrett On Friday, September 16, 2005 12:28 PM, Gary Poster wrote: On Sep 16, 2005, at 12:49 PM, Garrett Smith wrote: Sorry for the long delay in replying. We've been using widget-specific JS and CSS for some time now and I like our approach. It's quite different from the proposal. We're using the same pattern used by forms/widgets -- i.e. the PT is responsible for explicitly including HTML fragments provided by the view. As a point of reference, here's a simple example of including widgets: tal:block repeat=widget view/widgets label tal:content=widget/labelName/label input type=text tal:replace=widget / /tal:block The analog for including header support (i.e. JS and CSS) is: head tal:block repeat=content view/headContent tal:block content=content / /tal:block /head This places the burden of managing unique lists of 'head content' with the view. I see this as an extension of the widget-management framework. I would not personally opt for the proposal because it feels a bit magical -- I think it's too indirect. So, here's my argument in brief: Since widgets are driving the requirements of a consolidated resource list in the HTML head, the solution should extend the existing widget pattern. Yes, this imposes more overhead on the PT and the view, but the upside (IMO) is that the scheme is more transparent. If we had a clear division between update and render stages, and all template elements had an update call before they were rendered (and so were able to register a need) then the approach you suggest would be generally sufficient for the kind of story we are interested in telling. Pipelining, possibly combined with a modified templating story, can address this in a different way--one of the simplest configurations would support something like separate update and render stages. Even there, though, the resourcelibrary API for clients could remain the same, whether the JS/CSS were inserted by a main template that rendered the gathered JS/CSS calls, in a modified version of your approach; or by the XML-munging (or transformation to put it in a more politically appealing light) that is the current implementation. I'd say that this proposal has two thrusts. First, it proposes that we need a solution to the problem of stand- alone display components that need support from the main page. That's something that we (ZC) want, and for which other replies to the thread have also expressed desire. It enables a drop-in rich- widget story, which is arguably becoming more important as user expectations for richer internet experiences rise, and developer expectations for simpler integration of rich client technology rise. Second, it proposes that the given API can support a number of rendering implementations, from transforming HTML (as in the current implementation) to being a part of a wrapper main template during a rendering stage of a pipeline. The proposal should be evaluated from that perspective, and from the perspective of Jim's recent pipeline discussion. Can you see the need? Can you see how the API can support several rendering implementations? Developers who say yes to both can develop and use drop-in rich sub-page components, such as widgets. Developers who say yes to the first but no to the second are urged to suggest improvements. And thanks to the wonder of the more plug-and-play architecture of Zope 3, developers who say no to the first question don't have to play here, while still joining up elsewhere. :-) Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
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
On Friday, September 16, 2005 4:05 PM, Benji York wrote: Garrett Smith wrote: If it's just a patch to get 'rich' widgets working, I'll stick with my initial impression of it being too magical. The main reasons why this isn't a problem individual widgets can solve is that 1) they can't know if things that should only be done once have already been done (include JavaScript for example), 2) they can't directly add entries to the head section of the page, and 3) the components that require the JS or CSS might not be widgets at all. That's right. But the view can solve these problems easily without a lot of other stuff like yet-another-ZCML directive and automagical transformation of the HTML head element. This is what we have: class IHeadContent(Interface): Something that provides head content for a page. def headContent(): Returns a sequence of HTML snippets to be added to the page head. class SomeView(BrowserView): def __init__(self, context, request): ... self.headContent = [] for widget in self.widgets(): hc = zapi.queryAdapter(widget, IHeadContent) if hc is not None: for content in hc.headContent: if content not in self.headContent: self.headContent.append(content) ... The applicable PT: head tal:block repeat=content view/headContent tal:block content=structure content / /tal:block ... /head This is a trivial change to the existing Zope code. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
My point is that if rich widgets are the *only* driver here, the solution below is a better fit with the existing widgets implementation. The transformation of the HEAD doesn't jive with existing patterns. If there's a new pattern afoot (pipelining?), I hope we get a chance to discuss it. If I've just missed the discussion (quite possible), I'll wait for the RC. FWIW, we would not be able to use this new scheme exclusively as some of our IHeadContent providers provide more than file includes. E.g. we have a menu component that dynamically builds JavaScript and includes it directly in the HEAD. -- Garrett On , [EMAIL PROTECTED] wrote: Garrett Smith wrote: That's right. But the view can solve these problems easily without a lot of other stuff like yet-another-ZCML directive and automagical transformation of the HTML head element. This is what we have: class IHeadContent(Interface): Something that provides head content for a page. def headContent(): Returns a sequence of HTML snippets to be added to the page head. class SomeView(BrowserView): def __init__(self, context, request): ... self.headContent = [] for widget in self.widgets(): Like I said before, they're not always widgets. For something like this to work you have to be able to enumerate all the page components no matter what type of thing they were. That's not always convenient or even possible and seems more constraining than the proposal. The applicable PT: head tal:block repeat=content view/headContent tal:block content=structure content / /tal:block ... /head The proposed solution also does not require any dead chickens in ZPT. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Resource Library Proposal
On Friday, September 16, 2005 3:58 PM, Gary Poster wrote: You could also be asking about the pipeline ideas, but that's not my first guess. :-) Yes, I suspect this is what I'm missing. There was an earlier post about Ajax. It seems an entirely new approach would be needed to solidly support Ajax. I.e. we would need an architecture that let components interact independently of the browser view, or at least could be accessed in isolation of a full page rendering. Is this the sort of thing the 'pipeline' approach is getting at? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Proxy and __slots__
I ended up using 'type' to create a new proxy with a dynamically created __slots__. I haven't run into any weirdness with that approach, so far :) -- Garrett -Original Message- From: Jim Fulton [mailto:[EMAIL PROTECTED] Sent: Monday, August 29, 2005 9:03 AM To: Garrett Smith Cc: 'zope3-dev@zope.org' Subject: Re: [Zope3-dev] Proxy and __slots__ Garrett Smith wrote: I'd like to create a proxy where __slots__ is determined (or appended to) when the proxy is constructed. E.g. foo = Foo() bar = SomeProxy(foo, 'baz') bar.baz = 123 hasattr(foo, 'baz') False hasattr(bar, 'baz') True Is it possible to do this? No, at least not using the standard __slot__ mechanism. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
I'm uncomfortable with this. Right now, I think fields do too much. They have too much application logic. This would add more. The whole concept of initial value seems to be very application dependent. Maybe it would be best to just drop the default field altogether and introduce adapters for computing initial values in those special cases when we need them. Funnily, I just faced this dilema earlier today. I nearly created an interface like this: class IInitialValue(Interface): An interface for obtaining an initial value for an object. def get(): Returns the initial value. IMO, this is superior to field.initial. E.g. zapi.getMultiAdapter((field, context), IInitialValue).get() Perhaps this pattern could be used for getting an ISource from a field. E.g. zapi.getMultiAdapter((field, context), ISource) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Proxy and __slots__
I'd like to create a proxy where __slots__ is determined (or appended to) when the proxy is constructed. E.g. foo = Foo() bar = SomeProxy(foo, 'baz') bar.baz = 123 hasattr(foo, 'baz') False hasattr(bar, 'baz') True Is it possible to do this? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Deprecation of NotFoundError (#284)
I think a post to this list is fine. -- Garrett On Jul 31, 2005, at 8:32 AM, Julien Anguenot wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Where would be the best place for this migration notes ? J. Garrett Smith wrote: It's clear that NotFoundError is deprecated, but I'm not sure what to use in its place. Looking through your change (skimmed, as it's big) it looks like KeyError is is used in some places and FactoryNotFoundError in others. Could you provide some migration notes? -- Garrett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julien Anguenot Sent: Thursday, July 28, 2005 8:57 AM To: zope3-dev@zope.org Subject: [Zope3-dev] Deprecation of NotFoundError (#284) I checked in the deprecation of NotFoundError. (rev 37531) You might want to check the BBB on your existing app. J. -- Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojav e-corp.com - -- Julien Anguenot | Nuxeo RD (Paris, France) CPS Platform : http://www.cps-project.org Zope3 / ECM : http://www.z3lab.org mail: anguenot at nuxeo.com; tel: +33 (0) 6 72 57 57 66 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC7NLtGhoG8MxZ/pIRAqabAJ0Tvdg8CFU8xdSoT+9QhchqpvIUIQCghann IlUAkcjJhW3B2BFgEm7p2YQ= =hAg4 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojave- corp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] HEADS UP: PrincipalInformation - InternalPrincipal
On the outside chance this effects you, PrincipalInformation should now be spelled InternalPrincipal. (Deprecation warnings had not been added for this BBB class, so its deletion may catch some by surprise.) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] HEADS UP: change effecting custom authenticator search UIs
This affects anyone who has created a custom authenticator search UI (and if there's anyone who has done this, consider yourself a hyper super power user!) PAU queriables are now looked up by adapting an authenticator AND the PAU (prior to the recent change, only the authenticator was adapted). You'll need to rewire your current queriable accordingly. (See z/a/authentication/authentication/QuerySchemaSearchAdapter for an example of such a queriable and its use.) If anyone has any questions, please let me know. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Debugging deadlocks in Zope3
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] 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
-Original Message- From: Fred Drake [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 12:25 PM To: Garrett Smith Cc: Zope3-Dev (zope3-dev@zope.org) Subject: Re: [Zope3-dev] Formatting dates On 7/21/05, Garrett Smith [EMAIL PROTECTED] wrote: I guess my question was whether you see the widget handling the setting of the time zone, or the application. My vote would be that the widget deal with this, using adaptation to black box the process of finding the implicit tzinfo (assuming the widget doesn't have a UI for explicitly setting it). I'll agree that adaptation should be used to get the implied tzinfo. Whether the widget should be responsible for filling in a tzinfo at all depends on how the application is going to use the value; there should be a way for a field to indicate whether the value contains a tzinfo as well as whether the actual value should be normalized to a specific timezone. It should still be up to the application to specify what kind of timezone handling is needed (via the schema). Good point -- that should definitely be in the schema. I just want to avoid applying special handing for time zones outside the widget/schema framework. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formatting dates
So this will specifically impact: - The use of date/time formatters - Date/time widgets Anything else? Since datetime values are immutable, I assume you're envisioning that widgets create tz-aware values. With that in mind, I don't understand 'collected timezone-less times from our forms'. -Original Message- From: Gary Poster [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 11:47 AM To: Garrett Smith Cc: Zope3-Dev (zope3-dev@zope.org) Subject: Re: [Zope3-dev] Formatting dates On Jul 19, 2005, at 12:22 AM, Garrett Smith wrote: Now that dates have UTC time zones associated with them, will we be adjusting how they're displayed in various views? Somehow it doesn't seem appropriate to display UTC by default. I'd assume Zope would use the server's timezone offset. Here's an excerpt of me describing our plan for ZC software on IRC, which Stephan has approved for post-3.1 Zope (taken from http:// zope3.pov.lt/irclogs/%23zope3-dev.2005-07-15.log.html): GaryPosterso we already agree on tz-aware storage. My intent is to always expect an adapter of request to tzinfo.20:49 GaryPosterwe plan to have our apps allow specifying tz in the zope 3 preferences stuff20:49 GaryPosterso a logged-in user would have a default timezone20:50 GaryPosterThis would affect collected timezone-less times from our forms,20:50 GaryPosterand affect the astimezone for the display of the stored utc datetimes.20:50 GaryPosterWe're stubbing this for our current apps, since it hasn't been high-priority enough20:51 We go on (in the log) to talk about strategies for unauthenticated users. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.security.interfaces.ForbiddenAttribute: ('utcoffset', UTC)
This might be something on my end, but I figure I'd throw it out in case it's related to any changes related to naïve/non-naïve time zones. Here's the relevant part of the traceback: File /opt/aktari/zope/src/zope/i18n/format.py, line 175, in format info = buildDateTimeInfo(obj, self.calendar, bin_pattern) File /opt/aktari/zope/src/zope/i18n/format.py, line 603, in buildDateTimeInfo tz_secs = tzinfo.utcoffset(dt).seconds I'll dig further, but at a casual glance I couldn't turn up any security declarations for UTC objects. Could this be a case where datetime values are suddenly spouting proxied tzinfos? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Formatting dates
Now that dates have UTC time zones associated with them, will we be adjusting how they're displayed in various views? Somehow it doesn't seem appropriate to display UTC by default. I'd assume Zope would use the server's timezone offset. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Broken ZODB (was SVN: Zope3/trunk/src/zope/app/authentication/Eliminated all old-style classes)
This change has broken presisted SessionCresentials. I'm not sure why,
but the unpickler is calling SessionCredentials __init__.
I'm not sure what the right course is here, but I think something should
be done. One of these perhaps:
- Revert to old style class
- Write a conversion script
- Provide a BBB signature of __init__ with default values for login and
password
Also, since SessionCredentials is stored as session data, should it not
be Persistent?
-- Garrett
Dmitry Vasiliev wrote:
Log message for revision 30881:
Eliminated all old-style classes
Changed:
U Zope3/trunk/src/zope/app/authentication/README.txt
U Zope3/trunk/src/zope/app/authentication/groupfolder.py
U Zope3/trunk/src/zope/app/authentication/principalfolder.py
U Zope3/trunk/src/zope/app/authentication/principalplugins.py
UU Zope3/trunk/src/zope/app/authentication/session.py
-=-
Modified: Zope3/trunk/src/zope/app/authentication/README.txt
===
--- Zope3/trunk/src/zope/app/authentication/README.txt
2005-06-22
12:02:55 UTC (rev 30880) +++
Zope3/trunk/src/zope/app/authentication/README.txt2005-06-22
12:05:52 UTC (rev 30881) @@ -46,7 +46,7 @@ from zope import
interface from zope.app.authentication import interfaces
- class MyCredentialsPlugin:
+ class MyCredentialsPlugin(object):
...
... interface.implements(interfaces.ICredentialsPlugin)
...
@@ -56,7 +56,7 @@
... def challenge(self, request):
... pass # challenge is a no-op for this plugin
...
- ... def logout(request):
+ ... def logout(self, request):
... pass # logout is a no-op for this plugin
As a plugin, MyCredentialsPlugin needs to be registered as a named
utility: @@ -83,7 +83,7 @@
Our authenticator uses this type when it creates a principal info:
- class MyAuthenticatorPlugin:
+ class MyAuthenticatorPlugin(object):
...
... interface.implements(interfaces.IAuthenticatorPlugin)
...
@@ -688,4 +688,4 @@
the PAU will provide it as a queriable:
list(pau.getQueriables()) # doctest: +ELLIPSIS
- [('Queriable', ...QueriableAuthenticatorPlugin instance...)]
+ [('Queriable', ...QueriableAuthenticatorPlugin object...)]
Modified: Zope3/trunk/src/zope/app/authentication/groupfolder.py
===
--- Zope3/trunk/src/zope/app/authentication/groupfolder.py
2005-06-22
12:02:55 UTC (rev 30880) +++
Zope3/trunk/src/zope/app/authentication/groupfolder.py
2005-06-22
12:05:52 UTC (rev 30881) @@ -90,7 +90,7 @@ )
-class GroupInfo:
+class GroupInfo(object):
An implementation of IPrincipalInfo used by the group folder.
A group info is created with id, title, and description:
Modified: Zope3/trunk/src/zope/app/authentication/principalfolder.py
===
---
Zope3/trunk/src/zope/app/authentication/principalfolder.py
2005-06-22
12:02:55 UTC (rev 30880) +++
Zope3/trunk/src/zope/app/authentication/principalfolder.py
2005-06-22
12:05:52 UTC (rev 30881) @@ -126,7 +126,7 @@ PrincipalInformation =
InternalPrincipal
-class PrincipalInfo:
+class PrincipalInfo(object):
An implementation of IPrincipalInfo used by the principal
folder.
A principal info is created with id, login, title, and
description: @@ -195,7 +195,7 @@
Create a principal with 1 as id
Add a login attr since __setitem__ is in need of one
-
+
principal = Principal(1)
principal.login = 1
@@ -267,7 +267,7 @@
i += 1
-class Principal:
+class Principal(object):
A group-aware implementation of
zope.security.interfaces.IPrincipal.
A principal is created with an ID:
@@ -303,7 +303,7 @@
return 'Principal(%r)' % self.id
-class AuthenticatedPrincipalFactory:
+class AuthenticatedPrincipalFactory(object):
Creates 'authenticated' principals.
An authenticated principal is created as a result of an
authentication @@ -369,7 +369,7 @@
return principal
-class FoundPrincipalFactory:
+class FoundPrincipalFactory(object):
Creates 'found' principals.
A 'found' principal is created as a result of a principal lookup.
Modified: Zope3/trunk/src/zope/app/authentication/principalplugins.py
===
---
Zope3/trunk/src/zope/app/authentication/principalplugins.py
2005-06-22
12:02:55 UTC (rev 30880) +++
Zope3/trunk/src/zope/app/authentication/principalplugins.py
2005-06-22
12:05:52 UTC (rev 30881) @@ -28,5 +28,5 @@ from
zope.app.authentication import interfaces
-class PrincipalFactory:
-pass
\ No newline at end of file
+class PrincipalFactory(object):
+pass
Modified: Zope3/trunk/src/zope/app/authentication/session.py
[Zope3-dev] Traversal permission vs read permission
I'd like to be able to grant permission to traverse a folder, but not permission to view folder contents. This could be handled in Zope by making container.traversal.ItemTraverser a trusted adapter and protecting it with a zope.Traverse permission. I suspect this problem has been discussed before given Zope's maturity -- and there must be a good reason this isn't done. The obvious work around is to grant zope.View for the traversable folder and then to take great pains to deny zope.View for every innaccessible object in that folder. But having done this, I can say it's very likely that an admin will forget this, leaving part of a site wide open to unauthorized reads. Any thoughts on this? What are the problems with the the zope.Traverse idea? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Choose-a-name strategy and write conflicts
Jim Fulton wrote: Garrett Smith wrote: The use of INameChooser is useful for picking names that don't conflict across serial transactions. But this approach is problematic when two or more transactions are tying to add objects to a container at the same time. Because 'choose name' relies on its isolated version of a container, multiple threads are destined to choose the same name (assuming non-random algorithm), resulting in a write conflict. In some cases a write conflict is a normal and healthy thing to get, particularly if you let users edit the same object at the same time without care. But adding new objects to a container when the names are chosen by the system should not cause this problem. E.g. if the objects use unique keys, the BTree conflict resolution should gracefully handle the concurrent adds. The only solution that occurs to me is to use an alternate persistence mechanism (e.g. a file or database) for 'next name' sequences and control access to it via a thread lock. Is there a way to do this in the ZODB without the use of some external file-locking/update mechanism? Does this problem even make sense to people, or have I lapsed into garbled nonsense (again) :-) It's only a problem for large shared containers that people are very likely to add to at the same time, so it's a somewhat specialized problem. This would apply to the issue tracker, wouldn't it? If people don't actually care about ids, you could generate them randomly. Another common scheme is to use high-precision times in th names. Unfortunately, we need to keep the ids small because they show up in the URLs. I ended up implementing a secondary ZODB that serves next-in-sequence values per container (ala an RDB generator). This turned out to be more straight forward that I thought it would be. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Utility Registration was:RE: [Zope3-Users] pluggableauthentication utility
Roger Ineichen wrote:
pluggableauthentication utility
Hi Garrett
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Saturday, June 18, 2005 7:52 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: zope3-users@zope.org; zope3-dev@zope.org
Subject: RE: [Zope3-dev] Utility Registration was:RE:
[Zope3-Users] pluggableauthentication utility
[...]
What do yo think about that? Any other ideas?
It looks like you've identified a common enough use case: PAUs are
typically used with a common set of plugins. The current PAU design
accommodates all sorts of use cases that most users would never face.
Rather than add more complexity to the registration process with
utilityPolicy (even though it's an attempt to make things easier
for the user), I'd suggest creating a
SimplePluggubleAuthenticationUtility that supported the most common
use cases.
Something like this perhaps:
class ISimplePAU(Interface):
authentication = Choice(values=('HTTP-Auth', 'Session'))
allowUserChangeOnUnauthorized = Bool()
principals = Attribute(A PrincipalsFolder plugin.)
This would be far easier to deal with than the current PAU for those
that don't need PAU's flexibility.
I think this isn't a solution, because of three things:
- You need to do this for every other utility simplification.
I guess I'm not aware of anything that has anywhere near the
configuration complexity of the PAU.
- I dont' like to have more then one implementation if not
absolutly needed only for configuration reason.
I don't see this as a configuration issue. For most applications, the
PAU is too flexible/powerful and I think this is source of lots of
usability questions. A SimplePAU could be implemented using adaptation
so that a new PAU type wouldn't be necessary.
- The activation part on the registration process is still
the same. The most problem is that we implement components
where using the utility and lookup this utilities by a special
name or unnamed. But nobody tells you what name should be used
during registration.
I think the delineation is named vs. unnamed. I agree with Stephan and
Jim that utilities that are used without names should not ask for names
-- those that use names should require them. I would add (this has
probably already been added, don't recall) a utility should have some
way of communicating that interface or interfaces that it could be
registered for. E.g. it doesn't make much sense to register the PAU for
IAnnotations.
But to reiterate -- the PAU registration does *not* accept a name value
and does *not* let the user register for anything other than
IAuthentication. I haven't heard anyone complain about the registration
issues of PAU since that change.
I still think a policy (somthing like a add wizard) whould solve
the problem. Developers can develope the registration process in
a pytho class and register tehm as a utilityPolicy. Then
administrators or scripters can add the utility witha simple klick
on a add predefined utility button.
This sounds like a lot of work for the developer.
On nice sideeffect whould be,
You could also add a policy Add all utility I need for a site.
Or even call this policy during makeSite on your special
implementation of IPossibleSite.
I do like this idea. This is in the spirit of the server bootstrap
module that ensures that a particular set of utilties are available and
configured on startup.
I definitely think something likethis is needed for the Make a Site
action.
So, perhaps something like this:
siteconfig
name=foo.bar.mysite
title=My Site
description=Create my cool new site.
configurator=.configMySite /
This would setup a menu and register an adapter to something like
ISiteConfig that would be used to configure a newly created site.
I think this is what we need at the enduser level and should be
possible to implement. Of corse the way we register utilites whould
be still available.
-- Garrett
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Choose-a-name strategy and write conflicts
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
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
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: Uwe Oestermeier wrote: ... Alternatively, all mentioned usages could be easily subsumed under an extended ObjectModifiedEvent definition. Some optional keywords (for the interface and the attribute that was used to change the object, and additional infos about the changed values if available) are probably sufficient: 1-3: ObjectModifiedEvent(obj, interface=schema, attr=field, oldvalue=old, newvalue=new) 4: ObjectModifiedEvent(obj, interface=IObjectFile, attr=setBody) 5: ObjectModifiedEvent(obj, interface=IContainer, attr=__setitem__) 6: ObjectModifiedEvent(obj, interface=IContainer, attr=__delitem__) 7: ObjectModifiedEvent(obj, interface=IZopeDublinCore, attr=title) Since the keywords are optional, these changes could be easily made in a backward compatible way. Based on the discussion so far, I'm convinced that something like this would be useful, at least as an optional feature, as you suggest. I suggest we generalize this a bit. I suggest that the ObjectModified event could accept one or more modification descriptions (hints?). Some examples: ObjectModifiedEvent(obj, IObjectFile) This says that we modified the objects file data. Note that an interface is an acceptable description. In fact, we might allow pretty muich anything as a description. ObjectModifiedEvent(obj, IObjectFile, Attributes(IZopeDublinCore, 'title', 'description'), ) This says we modified the file data and the DC title and description. This information would be a hint that subscribers could use, or not use as appropriate. We could change the form machinery in an obvious way to generate attribute descriptions. A couple questions: - How is a 'better' (loaded term, feel free to interpret) arrangement than using application-specific event types that clearly define a) when the event is generated and b) what information the event conveys? - What new burdens does this place on application developers? Does Zope core now have to keep track of what extra information is conveyed in various scenarios? What about library vendors? I've viewed the current ObjectModifiedEvent as being appropriate for simple interfaces like the ZMI. In many cases, this simple event model works perfectly. Different applications are free to layer new event models on top of that. The way to add new event models (at least in my experience) is to create new event types -- not embed extra information in an otherwise clearly defined data structure. It seems to me that we're trying to make the ZMI anticipate application-specific requirements without knowing that those might be. I'd rather see something like this: - If a utility (or some other pluggable component) uses specific information from an event, it should provide an event interface that describes what it needs. - An application that's aware of that component type can fire an event that provides that interface. :-) I guess this approach is *so* endemic to Zope 3, I must be missing something huge. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
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
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
From the interface docs, it's not clear to me what the difference between the events are: class IObjectModifiedEvent(IObjectEvent): An object has been modified class IObjectContentModifiedEvent(IObjectModifiedEvent): An object's content has been modified What is the difference between 'content' that gets modified and the object that gets modified. How might I interpret receiving both events for a 'modify' operation on the same operation? -- Garrett Jim Fulton wrote: Uwe Oestermeier wrote: Hi, I'm working on a versioning system that creates a new version for each changed file content. I tried to listen to zope.app.event.interfaces.IObjectContentModifiedEvents, but unfortunately no such event seems to be generated. Editing an existing zope.app.file.File via the edit view leads only to an ObjectModifiedEvent, uploading new content produces no object event at all. Should this be fixed by generating ObjectContentModifiedEvents in both cases (which I would prefer), Yes. or should the less informative ObjectModifiedEvent be used? In the later case, the misleading IObjectContentModifiedEvent should probably removed from the list of objectevents. In general, missing events are difficult to detect and I'm quite sure that file editing and uploading are not the only relevant cases (e.g. WebDAV and FTP are other ways to modify file contents). Wouldn't it be the best solution to generate an IObjectContentModifiedEvent in the File._setData method and not the view classes? I think this would be OK for this specific case. What I don't want to see is some general implicit event-generation scheme. Jim ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Sublocation notifications
We currently dispatch some object events to sublocations. I think there's a problem with the current approach. If I subscribe to IObjectModifiedEvent with something like this: def handle(object, event): ... I'll get notifications where object and event.object are different. This happens for sublocation dispatches. This was very surprising, but it makes sense -- there are cases when you'd want to get notifications like that. But most of my code looks like this: def handle(object, event): # ignore Zope's sublocation dispatches if object != event.object: return ... I propose that we dispatch using both the original object and the sublocation, along with the event. Handlers for these sublocation dispatches would then look like this: def handle(object, sublocation, event): ... -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Sublocation notifications
Gary Poster wrote: On May 3, 2005, at 5:39 PM, Garrett Smith wrote: We currently dispatch some object events to sublocations. I think there's a problem with the current approach. ... Why not just have your own app listen for (object, event) and then do this additional dispatch? That's the usual pattern, and I'm guessing that we have use cases for the current (object, event) spelling. Gary The dispatch is already being done in zope\app\container\contained.py -- it's not something I have any control over. We could tear it out I suppose and require applications to handle it. IIRC, there are a few places in zope/app that rely on this dispatching though. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Missing ObjectContentModifiedEvent
Uwe Oestermeier wrote: But I could also live with ObjectModifiedEvents only. IMO, the second event type, if it doesn't have a clear distinction, should be removed. A more radical approach would be to specify in each ObjectModifiedEvent which aspects of an object changed. By aspect I mean the schema and the modified field within the schema: I'd see this being something like a ValueChangedEvent that specified the object, schema, field name, old value, and new value. This would be a nice way to bolt on validation without modifying the schema. Anyone needing more information in ObjectModified can just create a new event type with the additional info. This seems application specific to me. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Input widgets do too much
Jim Fulton wrote: I'd like to make some changes to the widget API. http://www.zope.org/Zope3/MoreCleanupOfWidgets proposes some cleanup, but I'd like to go farther. I think widgets, especially IInputWidget have too much responsibility, namely: - validation - applying changes Widgets should be responsible for - getting/managing user inputs, including conversion from raw input (but not validation). - Rendering HTML Giving widgets this responsibility makes them harder to implement (leading to complex base classes) and a bit hard to use when more control is needed. I'd like to remove this functionality from widgets, moving it to form code. Thoughts? Questions? Any objections to getting this into 3.1? If not, I'll write a more detailed proposal. Isn't there some pressure to get 3.1 out? I'm all for refactoring widgets to simplify (or eliminate) the hefty baseclasses, but I had the impression that the release was heading into its final stages. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Data manager interface -- tpc_begin and other changes
Jim Fulton wrote: This is for people who've implemented ZODB data managers. Data managers are components that manage persistent data under transaction control, We've recently tried to clean up and document the data-manager interfaces. In addition, over the weekend, I implemented savepoints and was able to simplify the interfaces quite a bit. See IDataManager and ISavePointDatamanager in: http://svn.zope.org/ZODB/trunk/src/transaction/interfaces.py?view=markup In particular, note that: - The subtransaction APIs have disappeared fro data managers, and - tpc_begin no longer takes a second subtransaction argument. I *could* try to provide support for data managers with tpc_begin taking 2 arguments, but I'm guessing that I don't need to. I'm guessing that no one has written data managers that require a second argument. If this is not true and you have a data manager that requires a second argument that I need to support, please let me know. Jim This looks outstanding...thanks for the communiqué :-) For my part, I'm not using substransactions, so the simplified tpc_begin is not a problem. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Changes to transaction management API
Jim Fulton wrote: Garrett Smith wrote: Recent changes to the transaction management API seem to have come out of the blue and without warning. Perhaps I missed an announcement. Are we to expect breakages of this sort on occasion? Was there breakage? If there was, it was unintended. Jim IDataManager was completely restructured. Anyone plugging into the transaction management facility will be broken by these changed. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Changes to transaction management API
Tim Peters wrote: [Jim Fulton] Was there breakage? If there was, it was unintended. [Garrett] IDataManager was completely restructured. This was not accurate -- the restructuring happened a while ago and I didn't catch it. I assumed this change was made along with the one I list below. If you don't have specific breakage to report, then I'm afraid I'm not going to take a lesson from this, cuz I just don't know what you mean here. Change 29961 -- I was using the 'savepoint' function along with NoSavepointSupportRollback, which disappeared. As a pragmatic matter, I'd avoid even importing the interfaces defined in ZODB, because they're still so inadequate and crude (as above, even ZODB mostly ignores them now). ZODB was a very late starter in the interface game, and there's not enough resource to play intense interface catchup in that project -- this gets poked at in slow motion, by forcing it briefly from time to time at the expense of more urgent ZODB tasks. I don't think this has anything to do with the ZODB. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] problems with Win buildinstall
Adam Groszer wrote: I'm trying to build install the Zope 3 trunk on Win2K. I'm having some problems with it. May I post them here or is it too early for the upcoming release? Adam ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/garrett%40mojave-corp.com Feel free to post here. A few of us use WIndows, shunned as we are ;) -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RFC: Change in automatic detection of providedinterfaces
Jim Fulton wrote: A recent simplification was made to adapter and utility registration. When registering adapters, the provided interface can be ommitted if the registered factory implements a single interface. Similarly, when registering utilities, the provided interface can be ommitted if the registered component provides a single interface. The intent is that if you have something like: class MyClass: implements(IFoo) ... you do not have to repeat IFoo in the registration. The current scheme runs into problems if you use inheritence: class MyClass(SomeBase): implements(IFoo) Then declarations in the base class cause the subclass to implement multiple interfaces. I'd like to make the following change to algorithm for determing the provided interface if nothing is specified in the rgistration: For adapters, if the registered factory directly implements a single interface, then that interface will be used. Inherited interfaces will not be considered. If the factory directly implements no interfaces or more than one interface, then a provided interface must be provided in the registration. For utilities, if the registered component directly provides no interfaces and its class directly implements a single interface, then that interface will be used. Inherited interfaces will not be considered. If the component directly provides any interfaces or if its class directly implements no interfaces or more than one interface, then a provided interface must be provided in the registration. So, for example, if we have: class B: implements(IB) class S(B) implements(IS) we can register S or an instance of S without specifying a provided interface. The interface IS will be used. However, with: class S2(B): pass You would have to sp[ecify a provided interface if you registered S2 or an instance of S2. Thoughts? Seems straight forward enough. Personally, I view the implements clause in these cases as a substitute for the provides in ZCML, so I always list a single interface anyway in such cases. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Form framework, adapters and pau
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
