Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
On Mon, Aug 17, 2009 at 7:56 AM, Jens Vagelpohlj...@dataflake.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 17, 2009, at 16:45 , Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.2 : Linux From: CMF Tests Date: Sun Aug 16 21:17:25 EDT 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-August/011888.html This test appears to be due to changes which Alec made in fixing the MailHost product on the Zope trunk. I think these doctests themselves are largely bogus (they are breaking on bits we don't care about), but maybe there is an easy fix? These failures have been brought up in a zope-dev thread about the MailHost changes, they are related to a switch from base64 to quoted-printable encoding for some headers. There has not been any final determination if this change is OK. Alec has promised to fix the tests once this has been decided. Exactly. The failures are essentially cosmetic, I can fix them either by removing the Quoted Printable configuration from MailHost or by changing the CMF tests to expect Quoted Printable instead of Base64. Quoted Printable is easily readable/debuggable and doesn't get penalized by spam filters, base64 is more compact. It may make the most sense to remove the Quoted Printable config from MailHost and just punt this decision to some future release. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Re: tools, utilities, and getToolByName
On 4/22/07, Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky wrote: On Apr 19, 12:52 pm, Martin Aspeli [EMAIL PROTECTED] wrote: -1 to relying on five.localsitemanager, especially if it means other site managers somewhere inside the CMF site will need to be five.lsm aware. Not sure what relying on five.lsm means... because if we don't use five.lsm, then having sub-ISite's beneath a CMF site will break the site due to the fact that current Five doesn't produce __bases__'s properly. This was the primary reason for doing five.lsm, to make sure sub-ISite's work. In effect, having a cmf portal be an ISite but not having a working __bases__ actually does more harm than good. Subsites are a pretty rare case, actually, and have *no* BBB considerations, as they weren't really possible before. I wouldn't say we should hold up anything on that account, if no easy fix is available. I think sub-ISites are actually going to become quite common (I believe Plone 3.0 uses them extensively, and other extant products that utilize local components do as well). Unfortunately, the interface name ISite was a somewhat poorly chosen one, since it really has little to do with a Site in the portal sense, but is just a location where persistent component registrations can happen. I imagine that complex content objects (blogs, mailing lists, forums) and features that require placeful configuration (the portlets infrastructure) will need to allow for local registrations of this sort. As far as the vote goes: +1 on undeprecating getToolByName +1 on removing acquisition wrapping from five.lsm and putting it in getToolByName Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [dev] unresolved site manager related issues
On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Alec Mitchell wrote: On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. I suppose it depends on how you look at it. If we agree that the way to get tools out of content space is to make them utilities, and we want to be able to promise the normal semantics for global and local utilities. In that case, moving to getUtility as the API and interfaces as keys seems to be a long term goal. As for consistency, call it aesthetics, but I know it's becoming quite hard to explain to new developers that various things are semantically similar, but there is an old way that applies to cases X, Y and Z, and then a new way that applies to all other cases. It's a nice idea, but we're just not there. CMF tools aren't used in the way that utilities are intended, they are not utilites, and using the utility machinery to look them up doesn't make them into utilities. Many, if not most, tool methods take a context argument of some sort, most of these should probably be implemented in adapters, which would give much more flexibility in customizing/overriding behavior and would avoid a lot of the issues that we're currently seeing. Those that also lookup or require a request should of course be implemented in views. Things like the registry of actions (but probably not the lookup of actions available on an object) and the undo tool make sense as utilities, but a lot of the rest just doesn't. Rather than refactor these things into appropriate sets of components (which is admittedly a tremendous undertaking and a compatibility nightmare), we seem to be taking a shortcut that provides no real benefits and a lot of potential headaches. Anyway, the point here is the consistency/flexibility/ease of migration in the future benefit vs. the cost of time/complexity and indeed whether it's possible to achieve all the benefits with the current tool implementations. We're creating migration pain right now. When you consider that many if not most of these utilities will vanish or change dramatically as they are factored into more appropriate and flexible components, I see little in the way of eased future migrations. I have yet to see an indication of what the benefits you refer to above might be. Keep in mind that I am a tremendous proponent of the component architecture within Zope and Plone, as are most of the people making these objections. I think there are a huge number of potential benefits to componentizing things, I just don't see them here. I'd go so far as to say that these changes don't really seem to be componentizing anything, just moving and renaming things. This was all nice and pretty when no-one had thought that tools-as-utilities needed to be wrapped at all. If that'd been the case, we'd just be having a deprecation warning discussion. :) I'd be very surprised if anyone thought that the wrapping of tools would be unnecessary in this scenario. There would indeed be nothing wrong with using the utility machinery to look up tools if the addition of acquisition didn't break the local component registry, but that doesn't mean there'd be any non-aesthetic benefit to the change either. There's nothing wrong with making changes for the sake of aesthetics, but breaking applications (both by deprecating a fundamental API, and with what turns out to be a pretty big acquisition mess) for the sake of aesthetics is another matter entirely. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [dev] unresolved site manager related issues
On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. Alec Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [dev] unresolved site manager related issues
On 4/15/07, Tres Seaver [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Mitchell wrote: On 4/15/07, Martin Aspeli [EMAIL PROTECTED] wrote: Dieter Maurer wrote: Alec Mitchell wrote at 2007-4-12 06:59 -0700: ... ... deprecation of getToolByName ... which is that there's no practical reason other than aesthetics to deprecate getToolByName at this point. A very good point: let's deprecate deprecations done just for aethetical reasons :-) Aesthetics were not the original reason for moving down this route, so it's a little unfair to cast it in that light. The main drivers, as I recall, were to encourage API usage that would allow us to move tools out of content space eventually, and to make code depending on CMF tools more consistent with newer code which may depend on new utilities (at least in the Plone world, there is a general consensus that we'd rather not have any more content-space tools from now on). What is it about getToolByName that implies that tools are in content space? Consistency with newer code is an aesthetic concern as far as I understand it. Agreed. I'm fine with having 'getToolByName' issue a deprecation warning if the tool can't be found using the component registry, and therefore the API has to fall back to acquisition to *find* the tool. That is a different problem than *wrapping* the returned tool to give it place (for security, for forward compatibility, whatever): if the tool implements 'Acquisition.interfaces.IAcquirer', then it *needs* wrapping, whether that is done via 'getToolByName', 'five.lsm', or some other voodoo-yet-to-be-written. Failing to wrap objects that expect to be wrapped is a major party foul: in fact, I would class that a showstopper for any final release of CMF 2.1. Yes tools need to be wrapped, because to a great extent their purpose is to allow use of methods from untrusted (ui) code. I'm not sure this pattern really maps well on to the use of utilities in Zope 3, but it's hard to say since Zope 3 doesn't really seem to have the same concept of untrusted code. However, there's Utilities that don't expect to be wrapped had better fall into one of the following categories: - They shouldn't be used by untrusted code at all (i.e,, all their methods are declared private). Such a utilitiy might be registered as a policy hook for some other framework: note that it would *not* be possibile to *configure* such a utility TTW using stock Zope2 ZMI patterns. Is there currently a way to access a utility from untrusted code? Aside from CMF's new getToolByInterfaceName method (which is about wrapped tools not utilities), there isn't AFAIK. My impression is that untrusted code should generally be using methods from views (which could themselves delegate to utilities), not utilities or non-view adapters which are currently inaccessible and insufficiently protected for untrusted code. Currently, Five doesn't support security declarations on utilities or adapters at all (I mean global utilities in this case), and I think the reason is that utilities are generally accessible only from trusted code. I understand that this limitation makes it quite hard to make use of utilities in the way that tools have traditionally been used. To me that's just another reason to consider the introduction of this tool = utility equivalence to have been premature. It may turn out that we need to wrap utilities generally (including the global ones), but that's something that would need to happen at a different level than five.lsm. Many people have made use of global utilities in Zope 2 and not missed the acquisition wrapping. Local utilities shouldn't be any different. In the end, if we need wrappers on the local ones, then we should have wrappers on the global ones too, and we need a solution that capable of providing wrapping for both. - Or they have no expectation that Zope2 protects them (i.e., all their methods are public). Such utilities would either perform their own security checks, *using a passed in context object*, or would provide services which did not require any protection. - Or some mixture of the two. Any use of 'security.declareProtected' in the class of the tool mandates that the tool be given place for Zope2 security purposes, even if nothing else needs wrapping. Trying to come up with an elegant way to avoid the necessity of wrapping is silly at this point: it isn't even better to try to make Zope3-style wrapping (the ILocation stuff) equivalent, because we will have to support implementations which don't know or care about Zope3 indefinitely. For content objects this is probably of dubious utility, because, as you say, there will always be implementations around which don't understand or expect the Zope 3 patterns. Other components like views, adapters, and utilities (none of which generally provide ILocation) would only be accessed from non-legacy code so
Re: [Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
On 4/3/07, yuppie [EMAIL PROTECTED] wrote: Hi! Alec Mitchell wrote: On 4/1/07, yuppie y.2007--E2EsyBC0hj3+aS/[EMAIL PROTECTED] wrote: Philipp von Weitershausen wrote: You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... I don't agree. CMF 2.0's getToolByName() requires context object and tool name as arguments, the tool has to be a content space object. That's quite different to five.lsm's getUtility(): Well you already have a mapping of name to interface that you use for BBB, and a context is required for acquisition wrapping, even it it's done implicitly. You can pass a context to a getUtility call too, that doesn't make the utility live in content space. In this case using a secondary api for doing the wrapping makes it clear that we aren't dealing with real utilities here but context-dependent tools, which the CMF tools still are no matter how we look them up. AFAICS all CMF tool interfaces are valid utility interfaces. The fact they are currently implemented as content space tools is just an implementation detail. Using the utility I don't care how it is implemented. Why should I? All issues reported so far (KSS, GenericSetup) have nothing to do with getUtility not being explicit enough. AFAICS they have to do with the fact that some five.lsm methods return unwrapped tools. Something that has to be fixed. I'm pretty sure this is incorrect. My understanding is that KSS uses a non-five.lsm site manager which is perfectly valid and works in both Zope 2 and 3, but when it needs to delegate utility lookup to a site manager earilier in the traversal chain which is a five.lsm, that delegation breaks. It would be possible to fix this in Zope 3 itself, or as Hanno suggests by essentially monkey-patching Zope 3 so that it was more accepting of unexpected behaviors from 3rd-party site-manager implementations like five.lsm. However, IMO, the better solution is to make five.lsm play nicely with non-five.lsm site managers, which means removing its acquisition magic. ... Using getUtility instead of getToolByName made life easier. You no longer have to care about which utility is implemented z2-style and which z3-style. And you can write less complex code if you don't have to pass in the context. Right, it's easier because, IMO you are hiding the fact that the tools you are using are context dependent and therefore not properly implemented utilities. Components which require a context to function should be adapters, components which additionally require a request should be views, those that require neither should be utilities. ... Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
On 4/1/07, yuppie [EMAIL PROTECTED] wrote: Hi! Philipp von Weitershausen wrote: Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... I don't agree. CMF 2.0's getToolByName() requires context object and tool name as arguments, the tool has to be a content space object. That's quite different to five.lsm's getUtility(): Well you already have a mapping of name to interface that you use for BBB, and a context is required for acquisition wrapping, even it it's done implicitly. You can pass a context to a getUtility call too, that doesn't make the utility live in content space. In this case using a secondary api for doing the wrapping makes it clear that we aren't dealing with real utilities here but context-dependent tools, which the CMF tools still are no matter how we look them up. - You can easily replace z2-style tools by z3-style utilities. getUtility doesn't care about the implementation, just about the interface. We're talking about making getToolByName use getUtility but perform acquisition wrapping using the passed in context so that the tools work and can still be used from restricted code. This benefit is not lost. - You don't have to provide a context object. This makes it easier to write new z3-style code. You still need one, you just get it via implicit magic. The tools all require it still, once they don't there will be no problem with using getUtility for them. It's now possible to write real context-independent z3 code (which is what the KSS stuff was doing when lsm broke it), this implicit context just makes doing so more painful, IMO. ... Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Zope-dev] TypesTool speedup
Looking at the changes rocky made, I don't see why allowing external methods from non-Products should require making the whole process completely dynamic on every call. The old mechanism of storing the product list should be put back in place, along with the addition of non-Product information to these results. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: SVN: CMF/branches/1.6/DCWorkflow/ Fix nasty errors on import of transitions that include variable Expressions
On 8/24/06, yuppie [EMAIL PROTECTED] wrote: Hi Alec! ... Fine. But please use the global CHANGES.txt file. DCWorkflow/CHANGES.txt is discontinued since more than 2 years. Sorry about that, I thought that version number looked a little odd. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Re: CMF roadmap update
CMFEditions makes heavy use of CMFUid, though if an alternate preferred uid generation mechanism were decided upon, it likely wouldn't be hard to switch. Alec On 4/26/06, Jens Vagelpohl [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26 Apr 2006, at 07:40, Martin Aspeli wrote: On Tue, 25 Apr 2006 20:21:09 +0100, Martin Aspeli [EMAIL PROTECTED] wrote: On Tue, 25 Apr 2006 16:33:01 +0100, David Pratt [EMAIL PROTECTED] wrote: Hi Jens. Z3 has it own uid facilities. I guess folks could pick this up through five could they not? Its all moving in that direction in any case. Plone doesn't have UID, but Archetypes does. This is used primarily for the reference engine, and it's one of the things we'd really like to componentise out to make it independent of Archetypes. I'd say we should aim to have one UID implementation at the Zope3 level and all use that, if it's feasible. I'm not quite sure which part of Z3 you're talking about though, so I can't comment on whether it's feasible. ... and Raphael says CMFEditions may depend on this. Depend on what exactly..? Archetypes UIDs? Z3 UIDs? CMFUid? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFETx6qRAx5nvEhZLIRAkghAKCEb5Tenv9CuG9X178ra+01STF6zACfXSMO FM7BWE1o7Opk60iRihzVniM= =7fMZ -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: What's the story for using Z3 content types as first-class citizens in CMF?
On 2/11/06, Martin Aspeli [EMAIL PROTECTED] wrote: On Sat, 11 Feb 2006 10:04:39 -, Jens Vagelpohl [EMAIL PROTECTED] wrote: There is no such code right now and AFAIK no one has even looked at it. If anyone wants to take this up and the proposal/code is accepted the earliest target would be CMF 2.1. I'm not sure how much work is needed for it. It's a matter of experimenting to see how far you can get before hitting walls I suppose. Cc'ing in Alec - I'm sure he has experiences to share from creating and using plone_schemas. Alec - you have indicated that you may be interested in working on plone_schemas more. Perhaps that work should sit at the CMF level? Yes, some of what's there (bugfixes for the add and edit views mostly) needs to be pushed into Five, The views themselves should perhaps be pushed into CMF, and only a couple small bits would be expected to remain plone specific (auto-renaming, some ui stuff for the field display). One thing that we really need on the CMF level is a wayto integrate z3 AddForms (via the addMenuItem declaration) into the CMF add menu, once that is done the FTI will largely be unnecessary (FTI is largely about creating content using a means which is obsoleted by z3 add forms). I would think that to the extent that an FTI remains necessary, it can be provided with a GenericSetup xml profile (some of the types I use in listen, which uses plone_schemas, do not have an FTI at all). At the moment plone_schemas is quite limited because it is designed to work with zope 2.8, which at this point is a bit crippling in terms of doing z3 stuff properly. As a general idea it does sound interesting because it is right on the roadmap towards combining CMF and Zope 3 in order to make CMF a thinner and thinner layer on top of Zope 3 technologies. In the context of Plone, it's also attractive because it may provide us with a lighter and better integrated alternative to Archetypes, which in itself has replaced plain-CMF content type coding in the Plone world almost completely. So it's not only about convergence, it's about making a fairly fundamental task easier and making it sit at a more appropriate level in the stack. +1 Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Archetypes-devel] Re: [Zope-CMF] Re: Re: [Plone-developers] Re: Re: The components of Archetypes
On 1/15/06, Wichert Akkerman [EMAIL PROTECTED] wrote: Previously Sidnei da Silva wrote: On Sun, Jan 15, 2006 at 12:06:43AM -, Martin Aspeli wrote: | So - one problem is that there is a lot of Plone software out there that | just assumes all content types are Archetypes. If you know about software that does this, please speak up. Best I can tell there's no software that depends on content type being Archetypes, though some stuff like the ReferenceBrowser depends on the IReferenceable API. ReferenceBrowser requires the folderlistingFolderContents method as well now which is not in IReferenceable. I stuck a compat method in PloneSite for that to seolve http://trac.plone.org/plone/ticket/5115 . Why not just supply a python script, there used to be one IIRC, and if it serves a valid usecase we might as well bring it back (it should just reuse the getFolderContents script though, and both of these should become views). Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: [Plone-developers] Re: Re: The components of Archetypes
On 1/13/06, Rocky Burt [EMAIL PROTECTED] wrote: Just going to add my 2 cents regarding non-specific-plone_schemas zope 3 functionality. - Ability to make custom views easily Customizing views happens with overrides.zcml today. No plone_schemas required. This should work for widget customizations as well. Obviously as we've all discussed this needs a TTW customization component. The TTW component shouldn't be hard if all we want is to lookup skin templates via acquisition in the traditional manner, plone_schemas could easily be extended with a custom view class/declaration that handles this. If we want a more general z3 way of doing TTW template customization (which we should IMO), then it will take more time. - DC metadata I *hope* Five lets us use IAnnotatable today. As it stands zope3 provides a very nice DC metadata implementation built on top of IAnnotatable adapters/functionality which is quite nice. Although I haven't confirmed if this works using z2+five yet. We can use IAnnotatable in Five, it is used in a few places in listen. I have not tried using the DCMetadata implementation from Five, but I don't forsee any issues with it. I'm not sure if it will handle setting the modified date automatically on emission of IModiified events, but z3 would do so under normal circumstances IIRC. It's simple enough to write a handler which listens for these events on 'content' objects and updates the date. - Things like Modified date are kept up to date automatically Zope 3 events would help out here although I don't know if Five supported IModified events yet. But perhaps alecm has another way of handling this with plone_schemas. - Validators on field level and on the whole object level FieldProperty and related zope3 schema functionality provides terrific per-field validation. Per object validation really only means ensuring field level validation occurred, no? I don't know about 'terrific' but it does do the validation of the basic constraints set on the field, it may need to be extended to support explicitly validating 'invariants' (multi-field/whole object validation), though perhaps this should be done only after edit (with an event equivalent to validate_integrity). - Rename-after-creation (title-to-id generation) The zope3 INameChooser adapter and related functionality should take care of this fine. I don't know if plone_schema's hooks into this to use by default. Although its probably a per-application decision to use in any event. Plone Schemas provides a custom INameChooser that does this. - A way to create custom fields + widgets overrides.zcml in the short (and long term) from the filesystem. But again hopefully there will be a TTW ability also in the long term. You don't need overrides to create custom fields/widgets you just create them and register them. To use them in your schema you just assign the new widget to the field in your configure.zcml content declaration. If you want to change a widget on an existing type then you need overrides.zcml, but this is much nicer than having to change code or monkey patch as we do with AT. To change the field type on an existing class you change the interface/schema. Some of these I think I know the answer to, but I'm just curious how far along this approach is, and more importantly - where there are gaps, how you think they may be closed. Keeping in mind here that the intended actions should result in breaking up archetypes into separate products/components. So a lot of this functionality which is considered standard archetypes functionality probably *shouldn't* be. But gaining that functionality from other standard products is obviously desirable. Thankfully zope3 provides a lot of the starting functionality (or at least a lot more than zope2 did). The main gap right now is references, if we can make a real componentized reference engine then this will go away. The other issue is storage which is not something we necessarily want to replicate in the same manner. Though storage abstraction is important, this is something that z3 technologies should be capable of doing much more nicely than z2. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: [Plone-developers] Re: Re: The components of Archetypes
On 1/11/06, Martin Aspeli [EMAIL PROTECTED] wrote: On Tue, 10 Jan 2006 19:16:11 -, Martijn Faassen [EMAIL PROTECTED] wrote: Additionally, I think sometimes doing some of 1 can be beneficial to 2. In particular, it may be worthwhile to start supporting Z3 widgets in Archetypes (I read somewhere that plone_schema makes this possible already? Cool!). In that case, it may make sense to adapt Archetypes to support them, in turn stimulating people to port their widgets, or write new widgets that way at least. That way, they get immediate functionality while doing the right thing for future development, and Z3 gets lots of cool new widgets. I'm not sure that's what plone_schemas does; I think it rather makes Z3 content objects with schemas defined in interfaces the Z3 way work with some of Plone's machinery and UI. I may be wrong, though, I've only briefly scanned the code. Yes it allows Five add and edit forms to work in a plonish way, it does not do anything related to AT. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] reindexing optimizations
On Monday 21 November 2005 06:30 am, Chris Withers wrote: *) And calls CMFCatalogAware.reindexObjectSecurity() which reindexes the object only on the security index, and doesn't touch metadata. Does reindexObjectSecurity do anything other than just the reindex the security indexes? If not, it can go too ;-) Yes, it recursively reindexes the security of all children. It will be hard to make this go away IMO. ... So we have two full reindexes, and three metadata updates. The last reindex appears to be there only to catch the change to 'portal_type' in _finishConstruction. Well, it's the last one, so I'd argue it should be the _only_ one. Why do things need to be indexed before then? Additionally, almost immediately before this last reindexObject call, another reindexObject call has happened in notifyWorkflowCreated, which included a full catalog metadata update. As a result, updating the catalog metadata here is certainly redundant. Unfortunately, the CMFCatalogAware.reindexObject method provides no means of avoiding the duplicate metadata update, though it would be trivial to add and to use here. That sounds like a good idea :-) Another option suggested by Sidnei on IRC, which would avoid the potential issues with limiting the variables indexed in the final reindex. Would be to let CMFCatalogAware.manage_afterAdd know (presumably via some state variable) Why a state variable rather than just a parameter? How do you propose to pass parameters to manage_after*, monkey-patching _setObject? that it is being invoked through constructInstance/invokeFactory, in which case it could safely skip the initial indexing and allow _finishConstruction to take care of indexing the object fully on it's own at the end. +1 from me. In the long term we will probably be better served by delaying all indexing to transaction boundaries, though it will be a fair bit harder to implement, and may irk some developers who depend on immediate changes to the catalog on reindex. Yeah, it also makes things harder to test. Unit tests require stuff to be indexed, so if this was the way to go, which apart from that one thing I think _should_ be the case, there should be a flush all pending indexing thing, which should keep everyone happy. Just have to make sure that then doesn't get misused and end up being called 100 times per operation ;-) Ben Saller's Eventually product apparently has this type of functionality: delayed events, and methods for coercing them to run immediately. It may be a good place to look. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] reindexing optimizations
Howdy CMFers, So, Sidnei has been plugging away at the AT reindexes things an obscene number of times issue today, and appears to have fixed many of the AT triggered indexing redundancies. There are however still a few places in CMF where some cataloging redundancy might be avoided. One obvious place is during object creation, where the following happens: *) TypesTool.constructInstance() is triggered **) A _setObject call results in CMFCatalogAware.manage_afterAdd() which triggers a full indexObject(). *) This is shortly followed by TypesTool._finishConstruction() *) Which calls CMFCatalogAware.notifyWorkflowCreated() *) Which in turn calls WorkFlowTool._reindexWorkflowVariables() **) Which does a CMFCatalogAware.reindexObject([idxs]) on workflow specific variables (with a full metadata update) *) And calls CMFCatalogAware.reindexObjectSecurity() which reindexes the object only on the security index, and doesn't touch metadata. **) TypesTool._finishConstruction() then does another CMFCatalogAware.reindexObject(). So we have two full reindexes, and three metadata updates. The last reindex appears to be there only to catch the change to 'portal_type' in _finishConstruction. So, this final reindexObject, might safely be changed to reindexObject(['portal_type', 'Type']), though the possibility exists that other indexed attributes added by 3rd parties may depend on the value of portal_type (say, I use an autogenerated Title which includes the Type). Additionally, almost immediately before this last reindexObject call, another reindexObject call has happened in notifyWorkflowCreated, which included a full catalog metadata update. As a result, updating the catalog metadata here is certainly redundant. Unfortunately, the CMFCatalogAware.reindexObject method provides no means of avoiding the duplicate metadata update, though it would be trivial to add and to use here. Another option suggested by Sidnei on IRC, which would avoid the potential issues with limiting the variables indexed in the final reindex. Would be to let CMFCatalogAware.manage_afterAdd know (presumably via some state variable) that it is being invoked through constructInstance/invokeFactory, in which case it could safely skip the initial indexing and allow _finishConstruction to take care of indexing the object fully on it's own at the end. In the long term we will probably be better served by delaying all indexing to transaction boundaries, though it will be a fair bit harder to implement, and may irk some developers who depend on immediate changes to the catalog on reindex. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] CMF 1.6
On Wednesday 16 November 2005 01:41 pm, Florent Guillaume wrote: I'd like to have some clarifications from the Plone team about what they expect to do w.r.t. events in CMF 1.6. I see two possibilities: 1. you guys are prepared to do the work needed for Plone products to use super() in manage_afterAdd co, in which case I can merge my branch into CMF 1.6 2. you feel that's too dangerous and, as Plone intends to use CMF 1.6, I'll merge for CMF 2.0 only. Be aware that if 2. is chosen, you won't be able to use Zope 3 events at all with CMF 1.6. I'm a bit worried about the potential consequences here, so I'd say #2 is probably a necessity. Even then, using super in a such a ubiquitously inherited class seems very dangerous. Though I'm by no means an expert on the pitfalls of super(), my worry is that there are many products out there that subclass CMFCatalogAware, either directly or through BaseObject-CatalogMultiplex-CMFCatalogAware. Even if we move to using super in BaseObject and CatalogMultiplex, we still have the problem of subclasses of BaseObject (i.e. nearly everything in the plone universe these days) needing to use super in any manage_after/before* methods (overriding e.g. manage_beforeDelete and delegating back to the parent class is quite common). Am I misunderstanding here, or is this change going to break any 3rd party product that uses CMFCatalogAware and overrides manage_before* without using super()? The fix for these products would be for them to also use super and possibly reorder their baseclasses so that the super users come first (though according to http://fuhm.org/super-harmful/, that still may result in unexpected behavior). This would seem unacceptable for the next point release of Plone. If this is going into CMF 2.0, then it's yet another reason for plone to stay clear of CMF 2.0 for a little while. The big problem with this move is there's no way to give product developers warning. They can't start using super now, because none of the base classes use it, but once super is in place in the base classes developers will need to start using it immediately or risk strange breakages. Maintaining product compatibility between versions of CMF/Plone will become nearly impossible. Doesn't look like there are any alternatives for getting add/delete/copy events working under zope2 though. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: backporting GenericSetup to CMF-1.5
On Tuesday 15 November 2005 10:43 am, Rob Miller wrote: Florent Guillaume wrote: Rob Miller wrote: CatalogMultiplex is a subclass of CMFCatalogAware which overrides the (un/re)indexObject methods to perform operations in multiple catalogs, if necessary. your patch changes CMFCatalogAware's manage_before* and manage_after* methods so that it delegates to 'super' in order to handle recursion w.r.t. containers, but in this case 'super' ends up being BaseObject, and so the manage_(after|before)* methods in ObjectManager (inherited via PortalFolder) never get called. Can't BaseObject's manage_afterAdd co use super() too? The goal is that everyone uses super() because if one piece of code doesn't, everything may break. yes... i'll play around with this this evening. The problem is that everyone subclasses BaseObject/BaseContent/BaseFolder and explicitly delegates to some of its methods. There's a good chance that many many AT projects will break if BaseObject starts using super. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] CMF 1.5.3 beta?
On Monday 01 August 2005 06:55 am, Florent Guillaume wrote: However I'd like to urge the Plone guys (95% of which don't bother to read or post in this list) to move their collective butts and actually implement forward-compatibility in Plone itself rather that, once more, tying the release of a base software to their own schedule. I'm on here too, though pretty quiet. I've even been subscribed here longer than I have been subscribed to plone-devel. As stated, the only important issues are minor bugfixes in CMF 1.5. We'd be OK without them, but everybody would be better off with them. Maintaining our own monkeypatch set with every svn fix to CMF is a bit untenable. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: New CMFDefault type profiles altering ATCT types
On Thursday 14 July 2005 11:27 am, yuppie wrote: Hi Alec! Alec Mitchell wrote: I recently noticed that the recent addition of default type profiles to CMFDefault (e.g. CMFDefault/profiles/default/types/Topic.xml), has the very unwelcome side-effect of adding extra unwanted actions to the ATCT types in plone 2.1. Perhaps these customizations should check the meta_type of the FTI they are altering before making potentially undesirable changes? Could you please describe what you are exactly doing? When and why does Plone import the CMFDefault profile? Actually, the problem was in ATCT, though it appears to have only become visible because of the new profiles. The profiles are imported in PloneGenerator, which inherits CMFDefault.Portal.PortalGenerator and calls setup. Sorry for the false alarm. :) Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] [Performance] listFilteredActionsFor unnecessarily expensive
On Tuesday 05 April 2005 10:13 pm, Andreas Jung wrote: --On Dienstag, 5. April 2005 22:29 Uhr +0200 Dieter Maurer [EMAIL PROTECTED] wrote: In our case, listFilteredActionsFor spends about 70 percent of its complete time in the checking of action in catlist. I did some profiling last week because Limi complained also about the slowness of the same method. My profiling (with a fresh Plone installation) told me that about 70% of the time is spend within the loop where all action providers are asked to return a list of matching actions. However Plone implements its own listFilteredActionsFor() method which might be different from the original CMF code. The two versions are nearly identical (at least for CMF 1.4.7 v Plone 2.1); Plone has extra checks to handle FactoryTool and to handle broken/missing action providers. I am a bit surprised that this simple check would take 70% of the time as it's only evaluated for actions that pass the condition and permission checks, which would seem to be more expensive. I'd expect the evaluation of the conditions to be much more expensive, but if there are many actions available, looping through a portion of them for each available action could be quite expensive. I'm sure it all depends on the specific use case. Whatever the case, this check is almost certainly unnecessary, whereas the condition checks are unavoidable and difficult to optimize. Alec ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
