Re: [Zope-CMF] Generic Setup upgrade steps
Hi! Godefroid Chapelle wrote: > I am surprised that `manage_doUpgrades` method of the tool does not > check if the step is applicable : AFAICS the `isProposed` method is only > used by the ZPT UI. > > I would suggest that `doStep` method of `upgradeStep` class should check > applicability or at least that the tool should check before running the > step. > > Opinions ? -1 'isProposed' just gives a recommendation. Sometimes it is useful to (re-)run steps that are not proposed. The ZMI page and 'manage_doUpgrades' intentionally allow to ignore 'isProposed' restrictions. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 release?
Hi Eric! Eric Steele wrote: > Assuming we don't hit any further delays, we're looking at having a > Plone 4.0 alpha available in about 6 weeks. Would it be possible to > have a 2.2 release of CMF cut by then? What can I do to help that > happen? These are the issues related to milestone CMF 2.2.0: https://bugs.launchpad.net/zope-cmf/+bugs?field.milestone%3Alist=1977 https://bugs.launchpad.net/zope-cmf/+bug/308947 has the same issue as this unmerged branch: http://svn.zope.org/Products.CMFCore/branches/wichert-constructionfilter/ Both create inconsistent behavior because they don't implement the same restrictions for adding new objects and adding copied or moved objects. IMHO the change should be reverted if nobody resolves that issue. https://bugs.launchpad.net/zope-cmf/+bug/397795 doesn't look very complicated, but someone has to complete that change. https://bugs.launchpad.net/zope-cmf/+bug/161664 is just a reminder to myself that I want to revisit the add actions machinery. If I don't find a better solution I'll make the types tool an ordered container. That makes add actions at least sortable. https://bugs.launchpad.net/zope-cmf/+bug/411732 is harmless but annoying. I hope someone fixes the class directive in Five. In CMF we would have to move the security declarations back into the Python code or use some special view interfaces without 'context' and 'request' attributes. Don't know how you can help. But #411732 is assigned to nobody and I'm not sure if #308947 and #397795 are assigned to people who feel responsible for those issues. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Releasing GenericSetup 1.5.0b1
Tres Seaver wrote: > I would like to push out a beta for GS 1.5 today: any outstanding > issues or features nearly-ready-to-commit which should block that? None I'm aware of. But 2 things would be nice to have before a final release: - A 2.0 release of five.localsitemanager. Some components handler improvements in GenericSetup depend on 2.0dev. - https://bugs.launchpad.net/zope-cmf/+bug/388380 Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2 icon_expr vs. content_icon
Martin Aspeli wrote: > What's the reasoning behind having both a content_icon and an icon_expr > property on FTIs in CMF 2.2? > > Apart from being really confusing, it seems that DynamicType.getIcon() > returns fti.getIcon() (with some mangling), which returns self.content_icon. > > Hence, if you set an icon with icon_expr and leave content_icon, > getIcon() always returns an empty string. > > This sounds like a bug to me, but I'm not sure how best to fix it: > > - remove one of content_icon and icon_expr? > - make TypeInfo.getIcon() check both? If so, which takes precedence? > - make Dynamictype.getIcon() check both? If so, which takes precedence? See https://bugs.launchpad.net/zope-cmf/+bug/397795 Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF 2.2.0-alpha: getIcon
Hi! CMF 2.2.0-alpha has some getIcon changes based on what I proposed here: https://mail.zope.org/pipermail/zope-cmf/2009-January/028059.html Unfortunately the issue is more complicated than I thought and some things are now broken in CMF 2.2.0-alpha: The return values of getIcon() and icon() are not backwards compatible, breaking e.g. the ZMI icons if REQUEST['BASEPATH1'] exists. There are 4 ways to specify icons: 1.) absolute URL: - "http://www.example.org/zope_instance/cmf_instance/icons/foo.png"; CMF 2.1: - CMF 2.2.0-alpha: getIcon(), icon() 2.) URL relative to REQUEST['BASEPATH1']: - "cmf_instance/icons/foo.png" CMF 2.1: getIcon(), icon() CMF 2.2.0-alpha: - 3.) URL relative to portal: --- "icons/foo.png" CMF 2.1: getIcon(relative_to_portal=1), icon(1) CMF 2.2.0-alpha: - 4.) icon id: "foo.png" CMF 2.1: - CMF 2.2.0-alpha: getIcon(relative_to_portal=1), icon(1) Proposal In CMF we always need the absolute URL. Since getIcon() and icon() already have a different meaning and something like getIcon(absolute=True) looks too complicated for the default, I propose to add a new method: getIconURL() getIcon() and icon() should get the same behavior as they had in CMF 2.1. Any thoughts? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-alpha: getIcon
Hi! Charlie Clark wrote: > Am 16.11.2009, 18:24 Uhr, schrieb yuppie : > >> In CMF we always need the absolute URL. Since getIcon() and icon() >> already have a different meaning and something like >> getIcon(absolute=True) looks too complicated for the default, I propose >> to add a new method: getIconURL() > >> getIcon() and icon() should get the same behavior as they had in CMF 2.1. > >> Any thoughts? > > getIconURL() would work for me. I'm not sure if I understand your e-mail > correctly but we shouldn't be keeping four different ways of accessing the > icon. Are any of them to be marked as to be deprecated? AFAICS we need 2 of them in DynamicType: icon() is part of OFS.interfaces.IItem and should return the URL relative to BASEPATH1. This is required to show the icons correctly in the ZMI. getIconURL() should become part of IDynamicType and return the absolute URL. This is the only version we need in CMF. getIcon() is an alias of icon() and could become deprecated. I don't know if it's worth the effort to mark the 'relative_to_portal' argument of icon() as well as deprecated. I already started implementing these changes. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-alpha: getIcon
Hi!
Charlie Clark wrote:
> Am 17.11.2009, 14:41 Uhr, schrieb yuppie :
>
>> getIcon() is an alias of icon() and could become deprecated. I don't
>> know if it's worth the effort to mark the 'relative_to_portal' argument
>> of icon() as well as deprecated.
>> I already started implementing these changes.
>
> now that I have my first project working on buildout I can see the impact
> of your changes! No icons in the ZMI or in folder_contents. But simply
> turning the content_type.png into a string:${portal_url}/content_type.png
> does the trick!
The content_icon property ('Icon' in the ZMI) is obsolete and should be
empty right now. I still have to work on removing it completely.
The icon_expr property ('Icon (Expression)' in the ZMI) should have the
string:${portal_url}/ prefix.
There is an upgrade step available that moves the icon setting to
icon_expr and adds the prefix.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi Charlie! Charlie Clark wrote: > Hooking everything together is, however, a bit clunky: > >name="myproduct.content_type_factory" > factory=".myproduct.MyAddView" > /> > > >permission="cmf.AddPortalContent" >interface="zope.formlib.interfaces.IPageForm" >/> > > > For the sake of clarity it would be nice to have a directive that ties > this together. Particularly the juxtaposition of the adapter name (which > has to be the same as the named content type factory utility) and the view > acting as a factory is a definite possible source of confusion. And, while > I much prefer the security declaration outside of the view class, the > combination is a bit unintuitive. > > I would find something like: > >factory="myproduct.content_type_factory" > class=".myproduct.MyAddView" > permission="cmf.AddPortalContent" > required-inteface="zope.formlib.interfaces.IPageForm" > /> > > easier to work with. -1 The real issue here is the fact that the permission argument of the adapter directive is not supported in Zope 2. Otherwise we could simply use this: Using the class directive instead is just a workaround for a generic problem that needs a generic solution, not a new addView directive. > I'm also not sure if the add view URL couldn't be simpler because the > ++add++ContentTypeId is a must, why this can't be interpolated either on > type registration or in the add_action look-up. Is there any reason why > this couldn't or shouldn't be the case? We need a prefix to make sure there are no conflicts with existing names and we need something in the name that specifies the portal type. The ++ around the prefix indicates that it is implemented as traverser. I currently use method aliases defined for the container to customize the names shown in the URL. But that's not perfect because you can't define the aliases together with the portal type and you have to define them for each container type used. If you have a better idea, please let me know. > Having finally taken the plunge into buildout I've been able to upgrade > one of our projects onto Zope 2.12 and CMF 2.2 with no real problems just > the odd "surprise". Thank you all very much for your help with Zope + CMF! Thanks for testing and feedback! Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi Charlie!
Charlie Clark wrote:
> Am 02.12.2009, 20:51 Uhr, schrieb yuppie :
>
>> -1
>> The real issue here is the fact that the permission argument of the
>> adapter directive is not supported in Zope 2. Otherwise we could simply
>> use this:
>> > name="myproduct.content_type_factory"
>> factory=".myproduct.MyAddView"
>> permission="cmf.AddPortalContent"
>> />
>> Using the class directive instead is just a workaround for a generic
>> problem that needs a generic solution, not a new addView directive.
>
> I have to agree with you on that. But the current solution remains clunky.
> Having initially been against it I think it would be easier on the eye to
> have the security declaration (I'm assuming this would work for subclasses
> where it can be overwritten if needs be) in ContentAddFormBase until the
> permissions directive is supported. It was only from working with the new
> add form that I realised how little needs to be done to work with this.
+1
Actually it would make sense to get the permission checks in sync with
the _checkAllowed method used by add actions. And _checkAllowed has a
hardcoded check for AddPortalContent.
So it is indeed superfluous to configure the AddPortalContent permission
for each add view in ZCML. And the __call__ method of ContentAddFormBase
seems to be a good place for checking the AddPortalContent permission
*and* the isConstructionAllowed method.
>> I currently use method aliases defined for the container to customize
>> the names shown in the URL. But that's not perfect because you can't
>> define the aliases together with the portal type and you have to define
>> them for each container type used.
>
> I'm not sure I understand what you mean by that - you have a situation
> where string:${folder_url}/++add++${object_id} needs changing?
Here is an example:
string:${folder_url}/newDoc
>> If you have a better idea, please let me know.
>
> I think that we could work with a sensible default which might be
> overwritable in the aliases?
The problem is: The indirection has to be done on container level, but
it would be clearer to set the alias in the type info of the new object.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi Charlie! yuppie wrote: > Charlie Clark wrote: >> Am 02.12.2009, 20:51 Uhr, schrieb yuppie >> : >>> Using the class directive instead is just a workaround for a generic >>> problem that needs a generic solution, not a new addView directive. >> I have to agree with you on that. But the current solution remains clunky. >> Having initially been against it I think it would be easier on the eye to >> have the security declaration (I'm assuming this would work for subclasses >> where it can be overwritten if needs be) in ContentAddFormBase until the >> permissions directive is supported. It was only from working with the new >> add form that I realised how little needs to be done to work with this. > > +1 > > Actually it would make sense to get the permission checks in sync with > the _checkAllowed method used by add actions. And _checkAllowed has a > hardcoded check for AddPortalContent. > > So it is indeed superfluous to configure the AddPortalContent permission > for each add view in ZCML. And the __call__ method of ContentAddFormBase > seems to be a good place for checking the AddPortalContent permission > *and* the isConstructionAllowed method. This change is now checked in: http://svn.zope.org/?rev=106203&view=rev Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] CMF 2.2: upgrade steps
Hi!
CMFDefault 2.2.0-beta ships with several upgrade steps. The goal is to
make migrating old CMF sites easier without using write-on-read
migration code or special migration scripts.
This is how the upgrade steps can be used:
1.) Make a backup of your site. Update Zope and CMF to the latest
version and restart Zope.
2.) In the ZMI, go to the 'upgrades' tab of portal_setup and select the
profile ('Products.CMFDefault:default' in CMF).
3.) Older CMF versions didn't set the profile version of the site, so
the tab says "The profile 'Products.CMFDefault:default' is currently
upgraded to version unknown." If you did create the site in CMF 2.1 all
'2.0 -> 2.1' steps should be marked as done and it should be save to run
"Mark 2.1 upgrade as finished". After that the tab says "The profile
'Products.CMFDefault:default' is currently upgraded to version 2.1." and
shows only '2.1 -> 2.2' steps.
4.) You can now run the '2.1 -> 2.2' steps and test your site. Some
additional manual upgrade steps might be necessary.
5.) If you are done with the upgrade of your site, run "Mark 2.2 upgrade
as finished". Now the filesystem version and the profile version of the
site are the same. No upgrade steps are shown.
6.) If something did go wrong or if you already upgraded to an alpha
version of CMFDefault 2.2, you can show th old upgrade steps using the
'Show' button. If one of those steps is not marked as done, it might be
necessary to (re-)run that step.
This is just the first cut. Several improvements are possible:
- Real world testing: If people report difficulties, the upgrade steps
can be improved based on the feedback.
- Unit testing: The steps currently have no tests. In theory a site
created in CMF 2.1 and migrated to CMF 2.2 should produce exactly the
same snapshot as a new CMF 2.2 site. Maybe someone can write a test for
that.
- The MetadataTool has write-on-read migration code in _get_DCMI. That
should be converted into two migration steps: One from CMF 1.6 to CMF
2.0 and one from 2.1 to 2.2.
- The upgrade scripts in CMFCore/Extensions and CMFDefault/Extensions
should be converted to upgrade steps.
- An upgrade step for adding the new singlestate_workflow should be written.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CMF 2.2: upgrade steps
Hi! Jens Vagelpohl wrote: >> - The MetadataTool has write-on-read migration code in _get_DCMI. That >> should be converted into two migration steps: One from CMF 1.6 to CMF >> 2.0 and one from 2.1 to 2.2. > > This is done on the trunk and the 2.2 branch. Great! I think it would be good to catch in .to22.check_dcmi_metadata *all* tools that don't have a 'DCMI' attribute. CMF 2.0 and 2.1 did not add '_DCMI' in __init__, I just changed that before the 2.2 beta. If the old migration code was never triggered the tools are broken without an upgrade step. >> - The upgrade scripts in CMFCore/Extensions and CMFDefault/Extensions >> should be converted to upgrade steps. > > All scripts in CMFDefault were obsolete, those I deleted. The script in > CMFCore is a good candidate for upgrade steps, but I am thinking the step > should be in CMFDefault, correct? Yes. All migration code is now linked to the default profile of CMFDefault. At the moment I have no idea how to make these upgrade steps available for people who use e.g. only CMFCore. >> - An upgrade step for adding the new singlestate_workflow should be written. > > This is done on the trunk and the 2.2 branch. Nice! Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi!
Charlie Clark wrote:
> Am 02.12.2009, 21:04 Uhr, schrieb Charlie Clark :
>
>> I think that we could work with a sensible default which might be
>> overwritable in the aliases?
>
> I can think of two solutions here.
>
> 1) Sensible default:
>
> replace
>
> if self.add_view_expr:
> lazy_map['url'] = self.add_view_expr_object
> lazy_keys.append('url')
> else:
> lazy_map['url'] = ''
>
> with
>
> if not self.add_view_expr:
> url = "string:${folder_url}/++add++%s" % self.getId()
> self._setPropValue('add_view_expr', url)
> lazy_map['url'] = self.add_view_expr_object
> lazy_keys.append('url')
>
> This leaves add_view_expr as an editable property but will create it if
> required and it can be edited afterwards. This means you don't need to
> worry about typos when creating or copying new portal types, you just have
> to make it an empty string.
-1
I don't think a write-on-read solution is acceptable.
> 2) Uneditable TypeInfo method
>
> Apart from transparency I can't see any reason for making this value
> editable so it could be implemented as a property doing much the same as
> above.
-1
For several reasons I think this should be an expression:
- At the moment you can specify any kind of add view name and
implementation. E.g. you can use a skin method or set an alias.
- The traverser is configured in ZCML and its name can easily be
changed. I don't think it is a good idea to hardcode assumptions about
configuration in the type info code.
- Type infos are now also Action objects and should be configured in a
similar way as normal Actions.
> Thoughts?
I'm afraid any attempt to make this simpler also makes it less explicit
and less flexible.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.2.0-beta reminder
Hi!
Charlie Clark wrote:
> Am 09.12.2009, 19:22 Uhr, schrieb yuppie :
>> -1
>> I don't think a write-on-read solution is acceptable.
>
> Okay. How about on creation?
There are different ways to create type infos. I don't think the class
constructor should contain any magic that sets computed defaults.
But I would be fine with some kind of wizard in the ZMI that helps to
create icon and add view URL expressions based on the type info id.
>> I'm afraid any attempt to make this simpler also makes it less explicit
>> and less flexible.
>
> I'm a big fan of "explicit is better than implicit" but only part of the
> expression is flexible. The traverser and TypeInfo id are not but they are
> also not interpolable when the expression is evaluated which goes against
> the spirit of expressions, I think.
The only part that is not flexible - at least in the use cases I'm aware
of - is the 'string:${folder_url}/' prefix. The traverser and TypeInfo
id can replaced by something different.
'string:${folder_url}/addDoc.html' works perfectly if you make sure
'addDoc.html' returns an add view for 'Document'.
The main reason to use expressions is to interpolate names that can only
be resolved on runtime, e.g. folder_url.
> BTW. how do addViews cross the CMFCore CMFDefault divide? Shouldn't the
> traverser be part of CMFDefault?
Type infos are part of CMFCore, so the general concept of add views is
part of CMFCore as well.
Skins and views are part of CMFDefault.
The traverser belongs somewhere in between. I can't see why it would be
better to have it in CMFDefault. If you really think it belongs into
CMFDefault: Why do you think CMFCore's type infos should create add view
URLs that are especially made for that specific traverser?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCore/trunk/ - fixed Zope 2.12 compatibility
Hi! Hanno Schlichting wrote: > Just to make this explicit: CMF trunk should continue to run with Zope > 2.12 and not only with 2.13, correct? Yes. At least until there is an explicit decision to drop 2.12 compatibility. So far I can't see a good reason for dropping BBB. > If so, I'll add a second test > runner to the buildout, so it's easier to ensure this. Looks like you did that already. > On a related note, if I'm going to backport the five.formlib > extraction to 2.12, it would it be ok to depend on a 2.12.3 release > for CMF 2.2 with this stuff in it, right? I can live with dropping support for Zope 2.12.2 if 2.12.3 is released. It's always recommended to use the latest bugfix release of Zope. On the other hand we would just need a few try except imports to keep BBB. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Making GenericSetup property import less strict
Hi! Wichert Akkerman wrote: > I am running into an interesting problem: it appears to be impossible to > write a FTI that works in both CMF 2.1 and 2.2. The problem are content > icons: CMF 2.1 requires a content_icon property in the FTI to configure > the icon, while CMF 2.2 requires icon_expr. Unfortunately you can not > have both in your FTI since GenericSetup will abort when it encounters > an unknown property. The only two possible solutions are to have > separate FTIs for CMF 2.1 an CMF 2.2, or to not use icons at all. This should work: Just add 'content_icon'. CMF 2.1 knows that property and CMF 2.2 has some migration code that converts this to an 'icon_expr' property. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.GenericSetup/trunk/Products/GenericSetup/ Don't bomb out with an AttributeError when encoding an attribute
Maurits van Rees wrote: > Wichert Akkerman, on 2010-03-03: >> On 3/3/10 11:48 , Maurits van Rees wrote: >>> Log message for revision 109595: >>> Don't bomb out with an AttributeError when encoding an attribute >>> with value None that is being exported; just use an empty string then. >>> Case in point: create a Plone Site, set the MailHost settings through >>> the Site Setup; an export of the mailhost settings would then fail if >>> some of the values (e.g. smtp_uid) were blank (None). >> >> Might I suggest not exporting anything instead of an empty string? There >> is a big difference between None and "". > > I just tried that; this would generate a file like this: > > smtp_port="25"/> > > An import of this file in a Plone Site worked. But then the export > would become this: > > smtp_port="25" smtp_pwd="" smtp_uid=""/> > > So then an import of an export gives a slightly different result; and > the tests do not like that, failing either in test_body_set or in > test_body_get, depending on how you define as self._BODY in > MailHost/tests/test_exportimport.py > > So I say we keep it like this. > > > Alternatively, Plone could be fixed to not set None values in the mail > settings (in plone.app.controlpanel). But I think this general fix in > GenericSetup is fine. I think the fix is in the wrong place. I doubt None is a valid value for a DOM attribute. So instead of working around invalid data we should make sure only valid data is written to the DOM. AFAICS MailHostXMLAdapter._exportNode is the right place to fix this. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup creates exports with bad directory permissions
Hi Maurits! Maurits van Rees wrote: > Using a checkout of CMF.buildout/branches/zope212-cmf22 (or Plone > 4.0a5 or latest from plone-coredev) I see that portal_setup generates > tarball exports where the permissions on directories are wrong: the > executable bit has not been set, so you cannot cd into that > directory. > > This is with python 2.6, so there might have been changes to the > tarfile module that cause this. > > yuppie, you did some changes in Products/GenericSetup/context.py on 13 > December that might be related. Does this behaviour ring a bell for > you? Aha, if I revert to revision 106439, right before your changes, > the export goes fine, at least on my machine (Ubuntu Linux 9.04). > > I can always open a bug report, but sometimes a mailing list works > faster. At least it prompted me to try and revert some recent changes > to see if that helped. :-) https://bugs.launchpad.net/zope-cmf would > be the correct place for that, right? Yes. But if you fix it yourself you don't need to report it on launchpad ;) Looks like r106440 contains a bug. The default value of TarInfo.mode is not suitable here. I guess this can easily be fixed by setting a different 'info.mode' for directories. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 1 Failed
Hi! Tres Seaver wrote: > I also don't know why the 'instance' and 'i18n*' parts are configured in > these buildouts -- does somebody have a memory of why, or a reason to > keep them? I don't use the 'instance' part. For manual testing I prefer using mkzopeinstance. The 'i18n*' parts provide an easy way to create .pot files for CMF. Maybe we should not run those parts by default. Either by removing them from parts= of the [buildout] section or by moving them to a separate .cfg file. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
Hi! Tres Seaver wrote: > Log message for revision 110361: >Don't use http:// externals for CMF externals. > >This buildout is for developers: making them do the >dance is silly. > > Changed: >_U CMF.buildout/trunk/src/ > > -=- > > Property changes on: CMF.buildout/trunk/src > ___ > Modified: svn:externals > - Zope2 http://svn.zope.org/repos/main/Zope/trunk > Products.CMFCalendar http://svn.zope.org/repos/main/Products.CMFCalendar/trunk > Products.CMFCore http://svn.zope.org/repos/main/Products.CMFCore/trunk > Products.CMFDefault http://svn.zope.org/repos/main/Products.CMFDefault/trunk > Products.CMFTopic http://svn.zope.org/repos/main/Products.CMFTopic/trunk > Products.CMFUid http://svn.zope.org/repos/main/Products.CMFUid/trunk > Products.DCWorkflow http://svn.zope.org/repos/main/Products.DCWorkflow/trunk > Products.GenericSetup > http://svn.zope.org/repos/main/Products.GenericSetup/trunk > five.localsitemanager > http://svn.zope.org/repos/main/five.localsitemanager/trunk > > + Zope2 http://svn.zope.org/repos/main/Zope/trunk > Products.CMFCalendar > svn+ssh://svn.zope.org/repos/main/Products.CMFCalendar/trunk > Products.CMFCore svn+ssh://svn.zope.org/repos/main/Products.CMFCore/trunk > Products.CMFDefault > svn+ssh://svn.zope.org/repos/main/Products.CMFDefault/trunk > Products.CMFTopic svn+ssh://svn.zope.org/repos/main/Products.CMFTopic/trunk > Products.CMFUid svn+ssh://svn.zope.org/repos/main/Products.CMFUid/trunk > Products.DCWorkflow > svn+ssh://svn.zope.org/repos/main/Products.DCWorkflow/trunk > Products.GenericSetup > svn+ssh://svn.zope.org/repos/main/Products.GenericSetup/trunk > five.localsitemanager > svn+ssh://svn.zope.org/repos/main/five.localsitemanager/trunk I propose to use the new svn:externals format instead. That makes the discussion http:// vs. svn+ssh:// vs. svn:// obsolete because it allows to specify relative externals. IIRC the general policy for the Zope repository is to switch to relative externals after the release of Ubuntu 10.04 LTS, but I guess all people using CMF.buildout have already Subversion >=1.5 available. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
Jens Vagelpohl wrote: > On 4/1/10 12:10 , yuppie wrote: >> IIRC the general policy for the Zope repository is to switch to relative >> externals after the release of Ubuntu 10.04 LTS, but I guess all people >> using CMF.buildout have already Subversion>=1.5 available. > > Huh? Since when do we make repository policy based on the release of a > particular Linux distribution? Where is this policy described? April > fools joke maybe? I might be wrong, but AFAIR this was the last discussion about it on Zope-dev and nobody objected to this mail: https://mail.zope.org/pipermail/zope-dev/2009-September/037693.html Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: CMF.buildout/trunk/src/ Don't use http:// externals for CMF externals.
Hi! Jens Vagelpohl wrote: > On 4/1/10 12:28 , yuppie wrote: >> Jens Vagelpohl wrote: >>> On 4/1/10 12:10 , yuppie wrote: >>>> IIRC the general policy for the Zope repository is to switch to relative >>>> externals after the release of Ubuntu 10.04 LTS, but I guess all people >>>> using CMF.buildout have already Subversion>=1.5 available. >>> Huh? Since when do we make repository policy based on the release of a >>> particular Linux distribution? Where is this policy described? April >>> fools joke maybe? >> >> I might be wrong, but AFAIR this was the last discussion about it on >> Zope-dev and nobody objected to this mail: >> https://mail.zope.org/pipermail/zope-dev/2009-September/037693.html > > Like Charlie says, you may be overinterpreting that email. There is no > such "general policy" for svn.zope.org. Obviously "general policy" was the wrong term because both of you interpreted it not how I meant it. I agree this decision is not set in stone. > Bringing up that question again certainly doesn't do any harm. I > personally have no objections to using relative SVN URLs. I don't plan to bring it up again on Zope-dev. I just proposed to make an exception for CMF. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
Hi! Charlie Clark wrote: > I'm currently working on a project which will hopefully have no TTW code > so I was hoping to be do without skins - currently I have a my skin on top > of CMFDefault but it is just main_template and some CSS. If I drop the CMF > skins entirely I hit some problems as quite a few forms exist only in the > skins so I'd like to start work on views where required. I suggest keeping > all the views in "browser" but adding some packages such as "content", > "membership" and "workflow". I started work on login and logout but I hit > some problems with CookieCrumbler expecting the login form to have a URL. > What does a view need to provide to work nicely with this? I have a LoginFormView and a MailPasswordFormView in my private repository. They allow to insert the email address instead of the member id. The views look up the first user that matches the email address. Maybe I should add them to CMFDefault? I guess they need just a few changes to be ready for checkin. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
Hi! Charlie Clark wrote: > Am 07.04.2010, 14:27 Uhr, schrieb yuppie: > >> I have a LoginFormView and a MailPasswordFormView in my private >> repository. They allow to insert the email address instead of the member >> id. The views look up the first user that matches the email address. > > No changes required to CookieCrumber? Where is auto_login_page used? A quick look at the code tells me it is only used for the unauth redirect. And that seems to be generally broken, at least on trunk :( Never noticed that. Doesn't work with my view either. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
yuppie wrote: > Where is auto_login_page used? A quick look at the code tells me it is > only used for the unauth redirect. And that seems to be generally > broken, at least on trunk :( > > Never noticed that. Doesn't work with my view either. See https://bugs.launchpad.net/zope-cmf/+bug/558340 Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Portal type actions
Hi! Better late than never... Charlie Clark wrote: > it now says in the actions tab of a portal type: > """Storing actions here is deprecated. Please move to using Action and > Action Category objects. See the CMF ActionsTool implementation for > details. Starting with CMF 2.4, the "Actions" tab will no longer be shown > for tools provided by the CMF.""" > > This might be glaringly obvious but how do I add a type-specific action to > the CMF such as "Rename Items" for folders without adding this to the type > information? That warning should not show up for type-specific Actions. They are not deprecated. This is a bug. There were different opinions how to modernize these Actions, so we are still stuck with the old implementation. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Portal type actions
Hi! Charlie Clark wrote: > Am 09.04.2010, 10:07 Uhr, schrieb yuppie: > >> That warning should not show up for type-specific Actions. They are not >> deprecated. This is a bug. > > I'll remove it from editToolsActions.dtml then. Can we backport this to > CMF 2.2? That warning is correct for all the tools, just not for type Actions. Please don't remove the warning completely. I propose to use a condition or to override the form for type Actions if necessary. >> There were different opinions how to modernize these Actions, so we are >> still stuck with the old implementation. > > In my work on the Absolut skin I noticed that Actions don't enforce icon > expression deprecation as TypeTools do. I don't know if anybody's looked > at this but I'd like to make icons as CSS images. I hope we find a way to use the new implementation for type Actions as well. Maintaining the old code for ever was not my plan. Cheers Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
Hi! Charlie Clark wrote: > Am 07.04.2010, 13:47 Uhr, schrieb Jens Vagelpohl: > >> I think I would change the cookie crumbler to expect both: Either a page >> with an ID that the cookie crumbler can traverse to (which is what it >> does right now), or an ID for a view that you could traverse to using >> the "@@" notation. > > Sort of: > > try: > page.getId() > except AttributeError: > page.restrictedTraverse() # or getMultiAdapter((context, request), > name=) > > I'm a bit hazy on traversal. Actually I'm a bit useless on it! getUnauthorizedURL is already using restrictedTraverse. This only fails because it starts from self instead of the parent (=portal root) and the login form is usually not registered for the cookie crumbler. And it tries to call absolute_url(). Views don't have that method. An other approach would be to look up the URLs in the Actions tool. The login URL is already specified in the 'user/login' Action, an invisible logged_out Action could be added. Long time ago the cookie crumbler had a stand alone version, so there are no dependencies on other tools. But now I would prefer to avoid redundant settings. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Portal type actions
Hi Charlie! Charlie Clark wrote: > Am 09.04.2010, 11:12 Uhr, schrieb yuppie: > >> That warning is correct for all the tools, just not for type Actions. >> Please don't remove the warning completely. I propose to use a condition >> or to override the form for type Actions if necessary. > > Ah, I see it - the actions, types, catalog, and skins too have an Actions > tab all to themselves. I've never noticed that before and never used them > and by the Actions tool that's down right confusing! I'd better revert the > change. Can't think of an easy condition to check for. Type Actions are the *only* place where the old Actions are not deprecated. So a check for ITypeInformation (or an attribute specific to that interface) should be sufficient. If you don't want to fix this: Could you please revert your change on the trunk and make a bug report? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] More browser views
Hi! Charlie Clark wrote: > Am 07.04.2010, 14:27 Uhr, schrieb yuppie: >> Maybe I should add them to CMFDefault? I guess they need just a few >> changes to be ready for checkin. > > Sounds great. As Tres has noted with ursine_globals - Views can have their > own tests. Oops, more work! ;-) At least I have some functional doctests. I hope that's sufficient. LoginFormView and MailPasswordFormView are now checked in on the trunk. But so far they are not hooked up by a profile. http://svn.zope.org/?rev=110737&view=rev These issues still need to be resolved: - Someone has to modify CookieCrumber to make it work with views. - Maybe the "Constraint not satisfied" error for invalid member IDs or email addresses gives too much information: Anonymous users can check that way if a user with a specific email address or member ID exists. What do others think? Is that a security hole big enough to care about? - Maybe the code makes some implicit assumptions about the authentication process that are not always correct. Would be nice if some people could test the views in their customized context. Right now you have to call "path/to/siteroot/login.html" directly for testing. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 2 Failed
Hi! Charlie Clark wrote: > Am 15.04.2010, 13:59 Uhr, schrieb CMF Tests Summarizer > : > >> Subject: FAILED (failures=3) : CMF-trunk Zope-2.12 Python-2.6.4 : Linux >> From: CMF Tests > > One of these is caused by my CookieCrumbler. AFAICS all 3 failures were caused by that change. > My mistake as I only tested > against CMFCore although I don't quite understand how the import_export > tests pass but this fails. Removing UniqueObject as base class fixes this > so I'll commit that. Although, as I do think the CookieCrumbler should be > unique in a site I'd be interested in fixing these tests so it can go back > in. UniqueObject is derived from ImmutableId. I think you have to set this for the class: id = 'cookie_authentication' Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 3 OK, 2 Failed
Hi Charlie! Charlie Clark wrote: > Am 15.04.2010, 15:03 Uhr, schrieb yuppie: >> UniqueObject is derived from ImmutableId. I think you have to set this >> for the class: >> id = 'cookie_authentication' > > Okay, makes sense if the tests are patched accordingly. Need to check what > was causing your new doctest to fail. I doubt you need to understand the failure and patch the tests for this. With the id on class level they should work as before. And please don't forget to remove the _create_forms code as well if CookieCrumbler is no longer a Folder. > I'll pick this up when I've made CookieCrumbler able to handle views. The > plan on this is > > 1) Proper interface for CookieCrumbler > > 2) Use actions for login/logout That also means you have to change the profile and add an upgrade step. > 3) Announce the deprecation (from CMF 2.4?) of the login/logout properties > as these will be replaced by action lookups. Is there any point in > maintaining the other properties as variables? After spending hours trying to understand the exception handling in Zope, I think the unauth redirect code should be completely removed from CookieCrumbler. An exception view seems to be a much more appropriate solution. I'll write a prototype and report back. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] getActionObject() deprecated?
Hi!
Charlie Clark wrote:
> this may just be another case of me being thick but whilst working on
> CookieCrumler I took a look at the best way for getting the "user/login"
> and "user/logout" actions. getActionObject("user/login") would seem to be
> best approach. However, it will not work with any straight actions as none
> of them have a category. As things stand this method will only work with
> Type actions. Is this correct?
Yes. You don't need that method for newstyle Actions. Just use this if
you want to get the Action object:
atool.user.login
But you don't need the Action itself. You need the ActionInfo object.
Use this to get the login url:
target = atool.getActionInfo('user/login')['url']
And please don't forget that I plan to replace the unauth redirect code
completely.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] Unauthorized handling - a proposal
Hi! Current situation: - By default Zope publishes Unauthorized exceptions as "HTTP/1.1 401 Unauthorized" responses including a basic authentication challenge. - If the user is not logged in, CMF converts Unauthorized exceptions into redirects. The redirect sends them to the login form and has a "came_from=" in the query string. - If the user is already logged in, the default Zope behavior is used. Or the request is redirected to the unauth_page if specified. I don't know if anybody is using the unauth_page feature. I think a good default behavior would be to return "HTTP/1.1 403 Forbidden" responses for authenticated users without enough privileges. - The Unauthorized handling is currently done by the CookieCrumbler. It hooks into the error handling process by overriding some methods of the HTTPResponse objects. Internal Zope changes did partially break this in Zope < 2.12.5, there is no guarantee the hooks will work in future. Proposal: Meanwhile a much better hook exists for exception handling: Exception views. I propose to move most of the Unauthorized handling to a new exception view in the ICMFDefaultSkin layer. All Unauthorized exceptions inside a CMF site are converted by the view. Into a Redirect exception for anonymous users and into a Forbidden exception for authenticated users. The redirect target is looked up in the 'user/login' Action, making CookieCrumbler's auto_login_page setting obsolete. The unauth_page setting will no longer be supported. CookieCrumbler and therefore CMFCore will loose the redirect feature. If there are no objections, I'll check in that change on CMF trunk. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Unauthorized handling - a proposal
Hi!
Charlie Clark wrote:
> Please add a separate folder for these views. We need to separate them
> from the content ones.
Why? 'browser' is a generic name, that folder is usually used for *all*
browser views. Which folder names would you propose?
> BTW. (For pedagogic reason I'm not too keen on
> EditForms being used when objects aren't being edited.)
Why? Is this about names or implementation? EditFormBase is for all
kinds of editable forms, ContentEditFormBase for content objects.
> So +1 from me but as per my other e-mails - what will the CookieCrumbler
> do afterwards?
>
> Using a view means that there is a hardcoded relation between the login
> form and the login cookies.
That doesn't have to be hardcoded. We could look up the cookie settings
in the CookieCrumbler.
> This is the current interface for ICookieCrumbler with proposed
> deprecation decorators
>
>
> class ICookieCrumbler(Interface):
>
> """Reads cookies during traversal and simulates the HTTP auth headers.
> """
>
> @deprecate auth_cookie = Attribute("""The key of the authorisation
> cookie""")
> @deprecate name_cookie = Attribute("""They key of the authorised user
> cookie""")
> @deprecate pw_cookie = Attribute("""The key of the password cookie""")
Why deprecated? We can keep these 3 configurable and look them up.
> persist_cookie = Attribute("""The key of the persistent cookie""")
> local_cookie_path = Attribute("""If True, the cookie tied to the local
> path?""")
> cache_header_value = Attribute("""If present, the login page will not
> be cached""")
> log_username = Attribute("""If True, the username will in appear in
> Zope's log""")
>
> def delRequestVar(req, name):
>"""No errors of any sort may propagate, and we don't care *what*
> they are, even to log them."""
>
> def getCookiePath():
> """Get the path for the cookie
> the parent URL if local_cookie_path is True otherwise /"""
> return path
>
> @deprecate
> def getCookieMethod(name, default=None):
> """ Allow overridable cookie set/expiration methods."""
> return getattr(name, default)
Why deprecated?
> def defaultSetAuthCookie(resp, cookie_name, cookie_value):
> """Set the authorisation cookie"""
>
> def defaultExpireAuthCookie(resp, cookie_name):
> """Expire the cookie"""
>
> def _setAuthHeader(ac, request, response):
> """Set the auth headers for both the Zope and Medusa http request
> objects.
> """
>
> @deprecate
> def modifyRequest(req, resp):
> """Copies cookie-supplied credentials to the basic auth fields.
>
> Returns a flag indicating what the user is trying to do with
> cookies: ATTEMPT_NONE, ATTEMPT_LOGIN, or ATTEMPT_RESUME. If
> cookie login is disabled for this request, raises
> CookieCrumblerDisabled.
> """
Why deprecated?
> def __call__(container, req):
> """The __before_publishing_traverse__ hook."""
>
> @deprecate
> def credentialsChanged(user, name, pw):
> """# XXX: this method violates the rules for tools/utilities:
> # it depends on self.REQUEST """
Why deprecated?
> @deprecate
> def _cleanupResponse():
> """# XXX: this method violates the rules for tools/utilities:
> # it depends on self.REQUEST"""
+1 for deprecating (or maybe just removing) it
> @deprecate
> def unauthorized():
> """Remove authentication cookies and redirect to standard
> unauthorized"""
+1 for deprecating (or maybe just removing) it
> @deprecate
> def _unauthorized():
> """Remove authentication cookies and redirect to standard
> _unauthorized"""
+1 for deprecating (or maybe just removing) it
> @deprecate
> def getUnauthorizedURL():
> """
> Redirects to the login page.
> """
+1 for deprecating (or maybe just removing) it
> @deprecate
> def logout():
> """
> Logs out the user and redirects to the logout page.
> """
Why deprecated?
> def propertyLabel(id):
> """Return a label for the given property id
> """
>
> I'm more than happy to help with this if there is anything I can do that
> doesn't mean you spend more time answering my questions than it would take
> to do the work! :-)
I'm only working on the login process. Could you perhaps start working
on the logout process before we bring everything together?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] Unauthorized handling - a proposal
Hi!
Charlie Clark wrote:
> Am 20.04.2010, 14:19 Uhr, schrieb yuppie:
>> Charlie Clark wrote:
>>> Please add a separate folder for these views. We need to separate them
>>>from the content ones.
>
>> Why? 'browser' is a generic name, that folder is usually used for *all*
>> browser views. Which folder names would you propose?
>
> It makes it more manageable. Anyone looking at this for the first time is
> likely to get a shock when trying to work out which views are where.
>
> I'd like to have separate folders for "content", "login" or
> "authentication", "workflow", etc.
You mean subfolders of browser? At the top level I would expect more
than just the browser views inside folders with these names.
For now I'll keep it where it is. If we agree on a new structure, things
can be easily moved around.
>>> Using a view means that there is a hardcoded relation between the login
>>> form and the login cookies.
>
>> That doesn't have to be hardcoded. We could look up the cookie settings
>> in the CookieCrumbler.
>
> Would there be any advantage in this? CookieCrumbler doesn't seem to need
> them itself if the authentication is handled in a view.
For now I plan to move less out of CookieCrumbler than you seem to expect.
>>>@deprecate
>>>def getCookieMethod(name, default=None):
>>>""" Allow overridable cookie set/expiration methods."""
>>>return getattr(name, default)
>
>> Why deprecated?
>
> I'm assuming that this related to Methods that could be stored within the
> CookieCrumbler when it was still a folder.
Could be. +1 if you are sure it is useless.
>>>@deprecate
>>>def modifyRequest(req, resp):
>>>"""Copies cookie-supplied credentials to the basic auth
>>> fields.
>>>
>>>Returns a flag indicating what the user is trying to do with
>>>cookies: ATTEMPT_NONE, ATTEMPT_LOGIN, or ATTEMPT_RESUME. If
>>>cookie login is disabled for this request, raises
>>>CookieCrumblerDisabled.
>>>"""
>> Why deprecated?
>
> I'm assuming that the login happens outside of CookieCrumbler. Please
> correct me if I'm wrong on this.
For now I just want to remove these lines from __call__:
@@ -261,12 +260,6 @@
if req.get('disable_cookie_login__', 0):
return
-if (self.unauth_page or
-attempt == ATTEMPT_LOGIN or attempt == ATTEMPT_NONE):
-# Modify the "unauthorized" response.
-req._hold(ResponseCleanup(resp))
-resp.unauthorized = self.unauthorized
-resp._unauthorized = self._unauthorized
if attempt != ATTEMPT_NONE:
# Trying to log in or resume a session
if self.cache_header_value:
>>>@deprecate
>>>def credentialsChanged(user, name, pw):
>>>"""# XXX: this method violates the rules for tools/utilities:
>>># it depends on self.REQUEST """
>> Why deprecated?
>
> Look at the docstring.
But is it obsolete?
>>>@deprecate
>>>def logout():
>>>"""
>>>Logs out the user and redirects to the logout page.
>>>"""
>> Why deprecated?
>
> Surely this should be handled directly by the logout form or view? If it
> is kept to do the logging out, then the signature can be changed to
> require the request to be passed in. Redirection should be handled by the
> logout page.
Right. If you write a view for that, the method might become useless.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Minor cleanup in browsers
Hi! Charlie Clark wrote: > Am 21.04.2010, 12:57 Uhr, schrieb Charlie Clark > : > >> Additionally I'd like to rename the view folder/@@edit.html to >> folder/@@contents.html. I kept the view name to match the PythonScript >> but >> I think it is both misleading - you cannot "edit" the folder with this >> view and it causes problems with classes derived from PortalFolder which >> are contentish (a not unusual or unreasonable thing but which currently >> forces a new name for an edit view or some hacking to have a dedicated >> contents view). Apart from updating the profiles and, presumably, an >> upgrade step I don't see any side-effects. > > aagh! wrong again! > > edit -> @@properties.html, folder_contents -> @@edit.html I agree this is confusing. I think this would be better: object/metadata -> @@properties.html, object/edit -> @@edit.html and folder/folderContents -> @@edit.html of the parent > Gets me every time! I can just about live with "edit" referring to the > metadata view although this is different from all other content objects > but I'd prefer folders not to have edit views unless dedicated ones exist. > Do we need an edit view to conform with actions/object? Well. 'folder_contents' *is* an edit view. If you add, move or delete subobjects you *edit* the folder. Because besides metadata this is the only thing you edit in plain folders, I chose this generic name for that view. This is about dividing editing into different pages. You can edit properties, subobjects and other content on the same page or on different pages. I personally use just "object/edit -> @@edit.html" and a modified @@edit.html that allows to edit Title and Description as well. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Unicode for ReST?
Hi Charlie! Charlie Clark wrote: > one thing that bothered me on a recent project was that even in a browser > view I have to decode "cooked_body" for those Satanic browsers Safari and > Internet Explorer. Actually *all* strings passed to PageTemplates should be decoded, no matter which browser you use. That's the only sane way to mix encoded strings with unicode strings. > I looked a bit into the system and saw that we still use ReST in a very > Wallace& Gromit way: ReST encodes the generated HTML using the default > encoding from zope.conf and we promptly decode it back to unicode every > time we want to display it, and make sure default-encoding and > rest-encoding match. Adding "output='unicode' to Document's CookedBody() > removes the double-encoding and doesn't break any tests. Would it be okay > to add this for Document and News objects and adjust the views > accordingly? Not sure I understand what you propose. Would that mean calling CookedBody(output='unicode') converts the persistent cooked_text to unicode and calling CookedBody() converts it back? > I assume an upgrade step would need to run CookedBody() to > convert existing "cooked_text" to unicode. CookedBody() is meant to *get* the cooked body. It only updates cooked_text if you use a new STX or ReST level. (BTW a nasty write-on-read.) _edit() normally *sets* cooked_text. On interface level, I think we can explicitly allow CookedBody() to return encoded strings *or* unicode. I'd prefer that strategy over adding an 'output' argument to all get methods. On implementation level, content types shipped with CMF could always set cooked_text as unicode. The most work would be to write an upgrade step (including tests) that works reliable. So far we don't have any upgrade steps that update content items. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] CookieCrumbler cleanup
Hi! The refactoring on the cookiecrumbler_with_views branch is almost done. There are 3 small CookieCrumbler 'features' I'd like to remove before merging the changes into CMF trunk: 1.) insufficient privileges page (unauth_page property) === Logged in users are usually redirected to a view that tells them they don't have sufficient privileges. Anonymous users are usually redirected to a login form. AFAICS PAS has no built in support for that distinction and Plone uses require_login as dispatcher. By default CookieCrumbler only redirects anonymous users to the login form. But allows to specify a redirect target for logged in users in the unauth_page property. I propose to remove that feature because all redirection logic is moved to the UnauthorizedView. By default Forbidden is raised with a message similar to Plone's insufficient_privileges. If you want to customize that, you have to override the UnauthorizedView. 2.) redirect loop detection (disable_cookie_login__ parameter) == AFAICS the special disable_cookie_login__=1 behavior is only used to prevent redirect loops caused by unauthorized exceptions in the login_form. This can only happen in mis-configured sites. And browsers are responsible for ending infinite redirect loops, so even in the case of misconfiguration nothing bad happens. I propose to remove that feature completely. I there is a reason why we have to detect redirect loops, we should at least do it without a special query parameter. CookieAuthHelper.unauthorized of PAS checks if ACTUAL_URL is the login_form URL. 3.) retry detection (retry parameter) = AFAICS no special retry=1 behavior is implemented, so I can't see a reason why we should set the retry parameter. PAS also works without that feature. I propose to remove that feature completely. Please let me know if there are any objections. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCalendar/trunk/Products/CMFCalendar/browser/templates/calendar_widgets.pt - made sure we don't call views inadvertently
Tres Seaver wrote: >> Modified: >> Products.CMFCalendar/trunk/Products/CMFCalendar/browser/templates/calendar_widgets.pt >> === >> --- >> Products.CMFCalendar/trunk/Products/CMFCalendar/browser/templates/calendar_widgets.pt >> 2010-06-17 07:45:21 UTC (rev 113582) >> +++ >> Products.CMFCalendar/trunk/Products/CMFCalendar/browser/templates/calendar_widgets.pt >> 2010-06-17 07:50:44 UTC (rev 113583) >> @@ -4,7 +4,7 @@ >> >>>class="CalendarBox" >> - tal:define="calendar_box_view context/@@calendar_box_view; >> + tal:define="calendar_box_view nocall:context/@@calendar_box_view; >>yearmonth calendar_box_view/getMonthAndYear; >>year python:yearmonth[0]; >>month python:yearmonth[1]; > > How was this template working at all before? If it was, do we have a > backwards-compatibility issue on these nocall; changes -- that is, will > this change break compatibility with a still-supported older version of > Zope? This is related to upgrading zope.formlib and zope.app.form to 4.x. A new base class seems to have a __call__ method that did not exist before. But I didn't try to figure out what exactly changed because nocall: is anyway what we always wanted. As long as the view can't be called it doesn't make a difference, so I don't think we have a BBB issue. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] How do you add an action in python code?
Suresh V. wrote: > I have been looking at the Action* related code and have not been able > to figure it out completely. > > I tried portal_actions.addAction(...) but this adds it under the > "Actions" tab with the big RED deprecation warning. > > I am able to add it from the ZMI correctly, but can't trace the code > that does the real adding (Ended up getting lost in GenericSetup browser > views). > > Can someone give me a pointer? There is no special API. ActionCategory inherits from OFS.OrderedFolder, you can use the _setObject method. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] View permissions not triggering
Hi! Charlie Clark wrote: > I'm working on a view for "logged_in". I thought I could simply replace > the current check for an anonymous Which "current check" do you mean? Right now there is no logged_in view so there is no permission check for a logged_in view. > by a view permission such as > "cmf.AddPortalContent" but no matter what I set the view remains callable > by a non-authenticated user. Are the permissions being ignored or have I > got the wrong end of the stick? In case you are modifying the permission for the logged_in *action* you've got the wrong end. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Getting i18n to fire
Hi! Charlie Clark wrote: > I've noticed that the CMF now does not do i18n work, ie. all > notifications, form values, etc. are the default values. At the same time > I've noticed the new buildout directives in trunk related to i18n. I think > I'm just not joining the dots - what do I need to do if I want a CMF site > with i18n running? The only thing missing are (publicly available) translations. CMF/trunk is currently unmaintained, maybe we should merge CMF.buildout back into CMF. But that's a different discussion. Anyway the "Installing Translations for CMF" part of INSTALL.txt is still correct: http://svn.zope.org/CMF/trunk/INSTALL.txt?rev=82766&view=auto Maybe with the addition that zope.app.locales is no longer part of Zope trunk. So you have to add it as a dependency to get formlib messages translated. The i18n parts in buildout.cfg are just necessary for updating the .pot files. Translations are not shipped with CMF because so far nobody wanted to be responsible for maintaining them. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Hi! Charlie Clark wrote: > as you may have noticed, I've been doing some work on the browser views. > Unfortunately in my eagerness I've trashed a couple of histories and > properties. If possible I'd like to restore them but my svn knowledge is > still fairly rudimentary so if I could be pointed in the right direction. > I think Products.CMFDefault/browser/utils.py is the main victim. In general the svn history is quite useful for understanding old and complex code. But browser/utils.py isn't that old and that complex so I think it would be fine if you just add the correct svn properties. > I'm currently working on a view for member preferences. One of the > advantages of views over PythonScript is the support for unit testing and > how that gives you the chance to think carefully about what you want your > view to do and while, like most of the CMF code, the scripts are easy > enough to understand it's noticeable how important some kind of narrative > is for a reimplementation. I guess what we're missing at the moment would > be functional testing of the various PythonScript combinations. In the > absence of either I have a couple of questions: > > * the preferences form points the user in the direction of the password > change form. Shouldn't this also be a user action? I usually disable the preferences action completely and use change_password and change_email actions instead. But I was never in the mood to start a discussion about the CMFDefault policy. > * where are the user folder security settings? local_roles for a user's > home folder? Don't understand these questions. First you talk about the user folder and than about user's home folders. What kind of security settings are you looking for? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Hi! Charlie Clark wrote: > Am 30.06.2010, 12:26 Uhr, schrieb yuppie: >> In general the svn history is quite useful for understanding old and >> complex code. But browser/utils.py isn't that old and that complex so I >> think it would be fine if you just add the correct svn properties. > > On my checkout (CMF.buildout) the properties are set: > > fuchsia:browser charlieclark$ svn propget svn:eol-style utils.py > native > fuchsia:browser charlieclark$ svn propget svn:keywords utils.py > Id ??? I just did a brand-new checkout and still can't see any properties. >>> * the preferences form points the user in the direction of the password >>> change form. Shouldn't this also be a user action? >> I usually disable the preferences action completely and use >> change_password and change_email actions instead. But I was never in the >> mood to start a discussion about the CMFDefault policy. > > I don't see this as policy but a necessity for proper skin support. If the > join form has an action for the preferences, then change_password should > be an action. I'm thinking of this in removing hard-coded urls from > templates where possible. The _setRedirect() method you wrote for forms is > a good example of the power of actions. > > From a policy point of view: changing passwords is probably of greater use > than changing the other settings. But you're right, there's little to be > gained from a discussion of this. FWIW I never really understood the > "portal" mania and I disable joining on all my sites. But I will add > change_password to user actions. I had *visible* actions in mind, but you didn't say that you want to add a *visible* action. +1 for an invisible change_password action >>> * where are the user folder security settings? local_roles for a user's >>> home folder? >> Don't understand these questions. First you talk about the user folder >> and than about user's home folders. What kind of security settings are >> you looking for? > > Sorry: "Your Member folder will still be publicly accessible unless you > change its security settings." > > If we're linking to other forms like change_password then we should do the > same here. This has to be local_roles form for the member's folder, hasn't > it? Although I don't see how you can hide your folder there. Now I see what you mean. And I also have no idea how a normal member could make his home folder inaccessible. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Charlie Clark wrote: > Am 30.06.2010, 14:52 Uhr, schrieb Tres Seaver: > >> To check the properties as stored in the repository:: >> $ env | grep ZSVN >> ZSVN=svn+ssh://svn.zope.org/repos/main >> $ svn propget svn:eol-style \ >>$ZSVN/Products.CMFDefault/trunk/Products/CMFDefault/utils.py >> native >> $ svn propget svn:keywords \ >>$ZSVN/Products.CMFDefault/trunk/Products/CMFDefault/utils.py >> Author Date Id Revision I can confirm this for CMFDefault/utils.py, but we were talking about CMFDefault/browser/utils.py. And for that file I get nothing. > Thanks very much, Tres. Looks like I need to make sure Author, Date, Id, > and Revision are added for new files. No. We don't use Author, Date or Revision. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Charlie Clark wrote: > Am 30.06.2010, 14:32 Uhr, schrieb Charlie Clark > : > >> Why do you think it should be kept invisible? To avoid clutter? Or >> minimise the effect on the existing layout? I don't think we need the link in preferences *and* in the menu. But that's just a -0.5 vote, not a strong -1. > Whether visible or not, it seems something needs to be done in the > upgrade_step to reflect it and I confess my complete ignorance of upgrade > steps. Do I need to add a check and handler that adds a change_password > Action instance? Similar to _singlestate_workflow in to22.py? See check_actions_tool/upgrade_actions_tool in to21.py. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Hi!
Charlie Clark wrote:
> _ACTIONS_XML = """\
>
> xmlns:i18n="http://xml.zope.org/namespaces/i18n";>
>
>
No need to reset the title of the 'user' category. That's not the
purpose of your upgrade step.
The tests just make sure an unmodified site is upgraded correctly. But
usually sites are customized. And if someone uses category titles he
would not expect that your step deletes them.
[...]
> def upgrade_actions_tool(tool):
> """2.2.x to 2.3.0 upgrade step handler
> """
> logger = logging.getLogger('GenericSetup.upgrade')
> atool = getToolByName(tool, 'portal_actions')
> environ = SetupEnviron()
> environ._should_purge = False
> getMultiAdapter((atool, environ), IBody).body = _ACTIONS_XML
> logger.info("'change_password' action added.")
>
> But if change the actions.xml I still get the error when I run the tests.
And that error shows you a nice diff that tells you that the
change_password action is added, but in the wrong position. Right? Or
did you forget to register the upgrade step?
> Do I need to tell the upgrade to do the insert before preferences?
Yes. "environ._should_purge = False" gives you the extension profile
behavior. By default new objects are added to the end of the container.
If you want them in a different place, you have to specify that using an
update directive ('insert-before' or 'insert-after').
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Hi Tres! Tres Seaver wrote: >> Am 30.06.2010, 15:09 Uhr, schrieb Tres >> Seaver: >> >>> As a general rule, I would actually prefer that we strip out the >>> keywords currently in the code -- they are CVS-era fossils which no >>> longer add any value in the SVN + eggs world. Why are they "CVS-era fossils"? What special value did they add in the CVS world? I always thought we use the Id keyword because CVS or SVN metadata is not always available. In tarball or egg releases that kind of metadata is missing. > Not only redundant to the data available in 'svn log' / 'svn info', 'svn log' and 'svn info' are not available inside released eggs. > but > actively harmful: keyword expansion makes merging branches / applying > patches harder. I guess the reason this causes problems for you is related to your attempts to use Bazaar instead of Subversion. I'm fine with removing the Id keywords if it makes the transition to Bazaar easier, but I don't think this is related to the the transition from CVS to Subversion. > I would say that we should be removing the keywords > themselves from source code opportunistically; I don't really care > about the property itself. I would prefer if you would propose that on the zope-dev list. It doesn't make sense to remove them in CMF and to keep them in ZTK or Zope headers. And it doesn't make sense if just a few people remove them in a few places and other people follow the old policy. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Hi! Wichert Akkerman wrote: > On 7/1/10 11:37 , yuppie wrote: >> Why are they "CVS-era fossils"? What special value did they add in the >> CVS world? >> >> I always thought we use the Id keyword because CVS or SVN metadata is >> not always available. In tarball or egg releases that kind of metadata >> is missing. > > FWIW I have never felt a need for that information inside a tarball or > egg, and agree with Tres that they make generating diffs between trees > needlessly difficult. I don't want to discuss the pros and cons. I'm fine with changing the policy. My point is that: 1.) We did have a policy to add Id keywords. 2.) The old policy is not obviously out-dated, and the term "CVS-era fossil" doesn't make it more obvious. 3.) In a case like that a transparent decision and a clear announcement are necessary to avoid discussions like this one and to make sure everybody pulls in the same direction. >> I would prefer if you would propose that on the zope-dev list. It >> doesn't make sense to remove them in CMF and to keep them in ZTK or Zope >> headers. And it doesn't make sense if just a few people remove them in a >> few places and other people follow the old policy. > > I thought they already disappeared from most places by now. Most Python files in Zope 2 and Zope 2 Products (e.g. GenericSetup, CMF, PAS) use the Id keyword. But also z3c packages like z3c.form. > I'm can't > remember seeing them for newly added code either. Recently there has not been added much new code in the Zope repository. But here are two examples from the last few days: http://svn.zope.org/Zope/trunk/src/Testing/ZopeTestCase/zopedoctest/testPackageAsProduct.py?rev=113940&view=markup http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/content/tests/test_image.py?rev=113947&view=markup And nobody who touches code and makes other cleanups seems to remove Id keywords. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Member preferences
Charlie Clark wrote: > Am 01.07.2010, 11:37 Uhr, schrieb yuppie: > >> I would prefer if you would propose that on the zope-dev list. It >> doesn't make sense to remove them in CMF and to keep them in ZTK or Zope >> headers. And it doesn't make sense if just a few people remove them in a >> few places and other people follow the old policy. > > I agree that I don't remember a policy statement on this - it might be in > the coding guidelines. But it did come up in my aforementioned thread: I don't think it is sufficient that it comes up in a thread like this one. Or to check in a change like that: http://svn.zope.org/?rev=113074&view=rev > If necessary I'll make sure this is on the agenda of next week's IRC > meeting. I'm not in the mood to take responsibility for that. But it would be great if someone else wants to make sure policy changes are better communicated. And the IRC meeting would indeed be a good place for making coding style decisions. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Getting i18n to fire
Charlie Clark wrote: > Am 30.06.2010, 12:23 Uhr, schrieb yuppie: >> Maybe with the addition that zope.app.locales is no longer part of Zope >> trunk. So you have to add it as a dependency to get formlib messages >> translated. > > I've done this and the i18n still isn't firing - it's pretty much just the > formlib stuff that needs translating as the rest of the site is in German. Well. It works for me. Do you have registrations like these in your product? HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi Hanno!
Hanno Schlichting wrote:
> Looks like nobody feels like jumping into the test layers waters.
Finally found some time to look into this.
> Unless someone does in the next days, I'll revert the OFS / OFSP
> refactoring on Zope trunk.
AFAICS this is the point where you went astray:
http://svn.zope.org/?rev=114576&view=rev
If you revert that revision and fix installPackage instead of trying to
work around the bug everything seems to work fine. I'm not in the mood
to write tests for installPackage and to figure out what else needs to
be reverted, so I just attached my patch.
Cheers,
Yuppie
Index: Zope2/src/Testing/ZopeTestCase/ZopeLite.py
===
--- Zope2/src/Testing/ZopeTestCase/ZopeLite.py (revision 114921)
+++ Zope2/src/Testing/ZopeTestCase/ZopeLite.py (working copy)
@@ -194,6 +194,7 @@
from OFS.metaconfigure import has_package
return has_package(name)
+...@layer.onsetup
def installPackage(name, quiet=0):
'''Installs a registered Python package.'''
quiet = 1 # Ignore argument
@@ -218,6 +219,7 @@
if not quiet: _print('Installing %s ... NOT FOUND\n' % name)
installProduct('PluginIndexes', 1) # Must install first
+installPackage('OFS', 1)
# So people can use ZopeLite.app()
app = Zope2.app
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
yuppie wrote: > +...@layer.onsetup >def installPackage(name, quiet=0): >'''Installs a registered Python package.''' Oops! For some unknown reason @layer.onsetup was explicitly removed here: http://svn.zope.org/?view=rev&rev=89898 ???, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi!
Hanno Schlichting wrote:
> On Sat, Jul 24, 2010 at 3:26 PM, Hanno
> Schlichting wrote:
>> Hhm. This all looks like a can of worms to me. I think I'll still
>> revert my changes for 2.13 and see if I find the proper motivation to
>> fix this for 2.14 instead.
The whole registerPackage concept is a can of worms. We need real ZCML
directives for *all* the stuff currently done in initialization
functions. And to deprecate the usage of initialize instead of expanding
that old concept to non-product packages.
> I reverted this now and all tests pass again. Both CMF 2.2 and CMF
> trunk against Zope 2.13.
I guess some more changes should be reverted. There is at least a
ZopeTestCase.installPackage('OFS') in the FunctionalLayer of CMFCalendar.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi! Hanno Schlichting wrote: > Zope2 has: > > registerClass > registerIcon registerIcon is defined in CMFCore, not in Zope2. > HelpSys (effectively deprecated) > > CMF brings in: > > ToolInit > ContentInit ContentInit is only used for BBB. It registers oldstyle constructors. > I'd love to see someone tackle registerClass and at the same time > decouple ZMI add menu visibility and the OFS.CopySupport stuff. You mean the CopySupport issue I fixed 5 years ago? Or something different? http://svn.zope.org/?view=rev&rev=40552 five:registerClass doesn't require to specify an 'addview'. CopySupport works for all CMF content types without adding them to the ZMI add menu. We just can't use five:registerClass in OFS/OFSP because it doesn't support oldstyle constructors and legacy methods. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF vs. CMF.buildout
Hi! One of these two seems to be redundant: http://svn.zope.org/CMF/ http://svn.zope.org/CMF.buildout/ Both have basically the same purpose. CMF.buildout started as a playground, but meanwhile that 'fork' supersedes CMF. CMF/trunk seems to be unmaintained and I doubt anybody is still using it. I propose to merge CMF.buildout back into CMF and to delete CMF.buildout in the long run. (Zope2.buildout did have a similar purpose and was merged back into Zope.) All CMF.buildout branches can be copied to CMF. Most stuff in CMF/trunk can be deleted and replaced by CMF.buildout/trunk. People will need some time to switch their checkouts to the new locations. But after a while we can delete CMF.buildout completely. Any thoughts? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
Hi! Charlie Clark wrote: > I'm actively abstaining as while I understand the need to clean things up, > I'm not sure I understand the whole context (my lack of understanding > rather than any lack of explanation). CMF is actually empty, isn't it? > Apart from the history that is. Well. It has svn:externals for the CMF Products, similar to CMF.buildout. I would not change or delete HISTORY.txt. AFAICS these things in CMF/trunk can be deleted: - 'docs' (ancient docs) - 'functest' (ancient functional tests) - RELEASE.txt and slurp_release.py (used for abandoned tarball releases) - CHANGES.txt, EXTERNALS.txt and __init__.py And these files might still contain some useful information, but need to be cleaned up: - INSTALL.txt and INSTALL_SVN.txt - README.txt Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
Hi! Jens Vagelpohl wrote: > On 8/5/10 16:52 , yuppie wrote: >> Charlie Clark wrote: >>> I'm actively abstaining as while I understand the need to clean things up, >>> I'm not sure I understand the whole context (my lack of understanding >>> rather than any lack of explanation). CMF is actually empty, isn't it? >>> Apart from the history that is. >> >> And these files might still contain some useful information, but need to >> be cleaned up: >> >> - INSTALL.txt and INSTALL_SVN.txt >> >> - README.txt > > Hi Yuppie, > > You do realize if you're trying to create one "supported" buildout for > developers and end users there's a new support burden to shoulder. > CMF.buildout was explicitly billed as a developer convenience. What's it > going to be for a central CMF package? What do you mean by "central CMF package"? svn.zope.org/CMF was never a real Python package. It was a container for all the CMF Products as well as for developer tools, developer documents and some end user documents. I think INSTALL.txt and README.txt could make the focus on developers explicit. I can't see any additional burden caused by the proposed change. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF vs. CMF.buildout
Hi Jens! Jens Vagelpohl wrote: >> I can't see any additional burden caused by the proposed change. > > The burden will appear when people are told or get the impression that > the package represents the official sanctioned buildout for the CMF as > opposed to being a developer convenience :-) It's a matter of > communication. Think of someone who doesn't have a clue and sees a > package named "CMF". What are they going to think? I guess they will think exactly the same as they think right now if they see the package named "CMF.buildout". If they have no clue, the ".buildout" will make no difference for them. "CMF.buildout" sounds like it would be "the official sanctioned buildout for the CMF". How should they know it is a developer convenience? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF 2.1 releases
Hi Charlie! Charlie Clark wrote: > Am 22.09.2010, 14:31 Uhr, schrieb Jens Vagelpohl: > >> Are there any outstanding issues or blockers that need resolving or can >> I go ahead and publish the new releases? > > While I'd like my fixes to CMFDefault/browser/folder.py to be in as soon > as possible, I'm planning to get some more stuff over the next few days. > Can we wait until next Wednesday (bug day?) Are you sure you want to make these changes in CMF 2.1? Jens is not talking about CMF 2.2 or trunk. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] CMF dev buildouts
Hi! I started moving the dev buildouts from CMF.buildout to CMF. (see https://mail.zope.org/pipermail/zope-cmf/2010-August/029284.html) If you are using CMF.buildout/trunk or CMF.buildout/branches/zope212-cmf23, please switch to CMF/trunk and let me know if it causes any trouble. My goal is to have *one* branch for each CMF version. (Except of CMF 2.1, which has also a non-buildout branch.) I think we have always a primary target platform that is used for development (e.g. Zope trunk for CMF trunk). And some additional supported platforms that are just used for running tests (e.g. latest Zope 2.12 release for CMF trunk). AFAICS it is sufficient to have additional cfg files instead of additional branches for the additional platforms. If that concept works for everybody, I'll migrate the rest of the CMF.buildout branches. BTW: CMF/trunk has some txt files with "OLD_" as prefix. AFAICS about 20% of their content is still useful, so I did not delete them. But it would be nice if someone would clean them up. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Bug in i18n-cmfdefaultextract?
Charlie Clark wrote: > ImportError: No module named PythonScripts.PythonScript > > This is, of course, humbug: > > fuchsia:CMF charlieclark$ bin/zopepy >>>> from Products.PythonScripts.PythonScript import PythonScript Zope 2.14 doesn't ship with Products.PythonScripts. 'zopepy' was fixed, 'i18n-cmfdefault' not. But now everything should work again. Ciao, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Trouble adding a new site
Charlie Clark wrote: > Traceback (innermost last): > Module ZPublisher.Publish, line 127, in publish > Module ZPublisher.mapply, line 77, in mapply > Module ZPublisher.Publish, line 47, in call_object > Module Products.CMFDefault.factory, line 59, in addConfiguredSite In line 59 you just have a bare CMFSite object without any tools. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Trouble adding a new site
Charlie Clark wrote: > Am 08.12.2010, 14:48 Uhr, schrieb yuppie: > >> In line 59 you just have a bare CMFSite object without any tools. > > Hi Yuppie, > > thanks for the quick reply. How come I don't have any tools? Is this > related to more recent buildouts not magically including Products.* stuff? > Products.CMFDefault (2.2.0) is installed. No. Have a look at the addConfiguredSite function: It first adds a bare CMFSite object, then adds the setup tool and importing the profile that adds the types tool is the last step. Your event handler just tries too early to look up the tool. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 4 OK, 3 Unknown
CMF Tests Summarizer wrote: > Subject: UNKNOWN : CMF-trunk Zope-2.12 Python-2.6.5 : Linux > From: CMF Tests > Date: Mon Dec 27 01:36:23 EST 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014001.html > > Subject: UNKNOWN : CMF-trunk Zope-2.13 Python-2.6.5 : Linux > From: CMF Tests > Date: Mon Dec 27 01:38:23 EST 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014002.html > > Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.6.5 : Linux > From: CMF Tests > Date: Mon Dec 27 01:40:23 EST 2010 > URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014003.html This is the traceback: > Running /usr/local/python2.6/bin/python ./bin/test > Traceback (most recent call last): > File "./bin/test", line 20, in > import zope.testrunner > ImportError: No module named zope.testrunner I updated the testrunner version. This no longer works: /usr/local/python2.6/bin/python ./bin/test Should now be: /usr/local/python2.6/bin/python -S ./bin/test or just: ./bin/test Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF dev buildouts
Hi!
Godefroid Chapelle wrote:
> I even added the missing buildout (copied from trunk - see revision 119553).
You know http://svn.zope.org/CMF/branches/2.2/ and
http://svn.zope.org/CMF/trunk/ ?
These buildouts are used for developing and testing all CMF Products. Do
we also need bootstrap and buildout files on each branch of each
Product? Who is using and maintaining them?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF dev buildouts
Godefroid Chapelle wrote: > One buildout per package is the practice in ZTK world. > > I have come to really appreciate it; it really lowers the barrier for > contributions. > > checkout > bootstrap > buildout > run tests to check state before changes > fix > run tests > commit That only works if someone makes sure bootstrap.py and buildout.cfg are up to date. You just did have to update buildout.cfg on CMFCore trunk. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] TypesTool and contruction permissions
Godefroid Chapelle wrote: > I always thought I could register two portal types based on the same > class with different add permissions. > > I read TypesTool code today. If I understand well, when using new style > ZTK factories, construction permissions are looked up in meta_types > registration. > > I came to the following conclusion : > > to register separate portal_types that share class implementation but > have different contruction permissions, I need to register meta_types > with separate permissions then use those meta_types in the FTIs to > relate the permissions and the portal_types. > > Is this correct ? I'm afraid you can use five:registerClass only once per class. The directive modifies the class. meta_type to class is a 1:1 relationship. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] working on the trunk
Hi!
I'm not happy with the current state of CMF trunk. Especially the
syndication related changes cause trouble in different ways:
- SyndicationInformation was replaced by SyndicationInfo without
providing migration code. Local syndication settings get lost in
existing sites.
- In the ZMI the SyndicationTool no longer has a tab that allows to
inspect and modify tool settings. The form that replaces the ZMI tab is
broken: It uses datetime objects instead of DateTime objects and mixes
them with existing DateTime settings.
Last week I reviewed parts of the new code and fixed some small issues.
But the bigger issues still exist. Based on what I encountered I wrote
this small guide: http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt
Please keep the the trunk stable and use your own branch for unfinished
changes.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: > Am 26.01.2011, 16:50 Uhr, schrieb yuppie: > >> I'm not happy with the current state of CMF trunk. Especially the >> syndication related changes cause trouble in different ways: >> - SyndicationInformation was replaced by SyndicationInfo without >> providing migration code. Local syndication settings get lost in >> existing sites. >> - In the ZMI the SyndicationTool no longer has a tab that allows to >> inspect and modify tool settings. The form that replaces the ZMI tab is >> broken: It uses datetime objects instead of DateTime objects and mixes >> them with existing DateTime settings. >> Last week I reviewed parts of the new code and fixed some small issues. >> But the bigger issues still exist. Based on what I encountered I wrote >> this small guide: >> http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt >> Please keep the the trunk stable and use your own branch for unfinished >> changes. > > I think this applies almost entirely to my work on browser views. Yuppie's > been in touch with me privately but I haven't found time to do the tidying > up. > > I agree with nearly all the points. I'm not certain that SchemaAdapters > are always necessary. zope.formlib is not made for DateTime values and encoded strings. So you *always* have to make sure these values are converted correctly. And it is hard to do that inside the form code. Obviously you did have trouble to get it right that way. After I started using adapters for the edited objects I had much less trouble using formlib. Of course you don't need an adapter if your objects already provide the right interface. And one more benefit: Inside the form code you can completely ignore the old-fashioned implementation of the edited objects and write nice modern code. > In my defence I hope it's worth noting that we now > have tests for a heap of stuff in CMFDefault which previously didn't exist. > > Regarding SyndicationInfo - I'd appreciate any pointers on writing a > migration step. Given the hopelessly outdated state of the current > implementation I'm not convinced anyone will need to do the migration What was wrong with the old implementation? I never had trouble using the old configuration objects and forms. The old RSS template didn't work for me, but that's a different issue. > but > then, of course, one of the aims of CMFDefault is to provide exactly this > kind of example. I'm sure I'm not the only one who has existing CMF sites with SyndicationInformation objects in it. Making sure these sites can be upgraded without trouble is essential. And not a nice to have extra. Especially if the old implementation did work and the new one doesn't provide any new features. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
Hi! Tres Seaver wrote: > On 02/02/2011 06:17 PM, Nikolay Kim wrote: >> well, we tested on modern windows, everything seem to work. >> but problem is, it is not possible to develop on windows without this >> patch. it just too slow. removing 'os.path.walk' makes development mode >> as fast as on linux [...] >>>>> -if platform == 'win32': >>>>> -# some Windows directories don't change mtime >>>>> -# when a file is added to or deleted from them :-( >>>>> -# So keep a list of files as well, and see if that >>>>> -# changes [...] > Can anybody else comment who is doing CMF-based work on Windows? AFAIK this is primarily a file system issue, not an operating system issue. 'Last modified' time is updated on NTFS, but not on FAT32. Not sure what we need to support: I guess everybody is working with Windows versions that support NTFS, but maybe some people still develop on FAT32 partitions. Maybe there is an easy way to detect the file system? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
yuppie wrote: > AFAIK this is primarily a file system issue, not an operating system > issue. 'Last modified' time is updated on NTFS, but not on FAT32. > > Not sure what we need to support: I guess everybody is working with > Windows versions that support NTFS, but maybe some people still develop > on FAT32 partitions. DebugModeTests have been disabled by default. Now I see 3 errors on FAT32 and one error on NTFS: Error in test test_DeleteAddEditMethod (Products.CMFCore.tests.test_DirectoryView.DebugModeTests) Traceback (most recent call last): File "...\Python26\lib\unittest.py", line 279, in run testMethod() File "...\src\Products.CMFCore\Products\CMFCore\tests\test_DirectoryView.py", line 290, in test_DeleteAddEditMethod self.assertEqual(self.ob.fake_skin.test2(),'test2.2') AttributeError: test2 Someone has to figure out if this can be fixed without using the old code for NTFS as well. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
yuppie wrote: > yuppie wrote: > DebugModeTests have been disabled by default. Now I see 3 errors on > FAT32 and one error on NTFS: > > Error in test test_DeleteAddEditMethod > (Products.CMFCore.tests.test_DirectoryView.DebugModeTests) > Traceback (most recent call last): > File "...\Python26\lib\unittest.py", line 279, in run > testMethod() > File > "...\src\Products.CMFCore\Products\CMFCore\tests\test_DirectoryView.py", > line 290, in test_DeleteAddEditMethod > self.assertEqual(self.ob.fake_skin.test2(),'test2.2') > AttributeError: test2 > > Someone has to figure out if this can be fixed without using the old > code for NTFS as well. Just for the record: The test was broken, not the tested feature. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode
Alan Runyan wrote: > just for record, having the behavior makes development a complete nightmare. > adding an additional environment variable is probably best way. I hope this resolves the issue: http://svn.zope.org/?rev=120180&view=rev If someone knows a better way to detect NTFS, please let me know. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] wrapping users - a proposal
Hi! MemberData objects are currently persistent objects for storing member data *and* wrappers for user objects. I propose to split this up into a persistent MemberData object that is just used for storing member data and a new non-persistent MemberAdapter that provides all the methods currently provided by MemberData objects. MemberAdapter would be a multi-adapter for IUser and IMemberDataTool. self.__parent__ would be the user folder. Pros: - The member objects can easily be customized without replacing persistent MemberData objects. - Users from different types of user folders can get different adapters. No MemberData objects are needed if the user (or user folder) can store the member properties. (Adapted is the user, so the user's interface has to indicate the capabilities of the user folder). - For some methods like changeOwnership() AccessControl expects that the parent of a user is the user folder. MemberAdapter will have the same parent as the original user object. - There is no need to migrate persistent objects. Cons: - The API of customized MemberData objects will no longer be available. The customized API has to be moved to a new adapter. - Code that expects the user object or the member-data tool in the aquisition chain of members will no longer work. - Code that bypasses setProperties/setMemberProperties and getProperty methods of members will no longer work. If there are no objections or better ideas, I'll implement that on the trunk. IUser is only available in Zope 2.13.2+, so I'll have to make that Zope version required for CMF trunk. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] CMF Tests: 6 OK, 1 Unknown
Hi! CMF Tests Summarizer wrote: > Unknown > --- > > Subject: UNKNOWN : CMF-trunk Zope-2.12 Python-2.6.5 : Linux buildout-zope212.cfg no longer exists. I removed Zope 2.12 support on CMF trunk. > Tests passed OK > --- > > Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux This buildout was moved to CMF/branches/2.1-zope210. > Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux This buildout was moved to CMF/branches/2.1-zope211. Please make sure you use the new locations before I delete the old ones. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] wrapping users - a proposal
Hi!
yuppie wrote:
> I propose to split this up into a persistent MemberData object that is
> just used for storing member data and a new non-persistent MemberAdapter
> that provides all the methods currently provided by MemberData objects.
Done: http://svn.zope.org/?rev=120512&view=rev
There are two new issues caused by that change:
1.) MemberData factory lookup
-
CMF 2.2 has a new feature that allows to register customized MemberData
factories: https://bugs.launchpad.net/zope-cmf/+bug/377208
That feature seems to be obsolete in CMF 2.3 because the MemberAdapter
is now responsible for creating MemberData objects and AFAICS using
customized MemberData with an un-customized MemberAdapter doesn't make
much sense.
Because CMF 2.3 will anyway break customized MemberData implementations
I propose to remove the factory lookup completely in CMF 2.3.
2.) direct MemberData property access
-
Wrapped users are now MemberAdapter objects. So wrapped users no longer
have attributes like 'email' or 'listed'. This is a security improvement
because you can't bypass the API with its permission checks.
But 'member.email' is more convenient than 'member.getProperty('email')'
and used in many places. I fixed these in CMF itself, it I'm afraid that
change will break a lot of third party code.
I propose to add read-only properties that return the values in a modern
format (datetime instead of DateTime, unicode instead of encoded strings).
Question:
Should we support a fixed schema with the default member data properties
or should we use a customized __getattr__ method?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] wrapping users - a proposal
Hi!
Charlie Clark wrote:
> Am 22.02.2011, 11:46 Uhr, schrieb yuppie:
>> 2.) direct MemberData property access
>> -
>> Wrapped users are now MemberAdapter objects. So wrapped users no longer
>> have attributes like 'email' or 'listed'. This is a security improvement
>> because you can't bypass the API with its permission checks.
>> But 'member.email' is more convenient than 'member.getProperty('email')'
>> and used in many places. I fixed these in CMF itself, it I'm afraid that
>> change will break a lot of third party code.
>> I propose to add read-only properties that return the values in a modern
>> format (datetime instead of DateTime, unicode instead of encoded
>> strings).
>
>> Question:
>> Should we support a fixed schema with the default member data properties
>> or should we use a customized __getattr__ method?
>
> If the access is always via the adapter then I would prefer a customised
> __getattr__
I'm still not sure how to resolve this.
MemberAdapter objects are used in untrusted code and it might be
complicated to set permissions correctly for __getattr__ access. (At
least I never tried that.)
It also would be nice to have a well defined interface for default
member properties.
So I tend to a fixed schema. People still can add custom properties, but
they would have to use getProperty or override MemberAdapter.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.GenericSetup/trunk/ Refactored global registries to use global named utilities.
Hi Godefroid!
A few questions:
Godefroid Chapelle wrote:
> Log message for revision 120850:
>Refactored global registries to use global named utilities.
>
>merge of branch gotcha-registries-use-utilities
[...]
> Modified: Products.GenericSetup/trunk/Products/GenericSetup/registry.py
> ===
> --- Products.GenericSetup/trunk/Products/GenericSetup/registry.py
> 2011-03-10 15:13:48 UTC (rev 120849)
> +++ Products.GenericSetup/trunk/Products/GenericSetup/registry.py
> 2011-03-10 16:56:57 UTC (rev 120850)
[...]
> @@ -721,13 +758,26 @@
> # metadata.xml description trumps ZCML description... awkward
> info.update( metadata )
>
> -self._profile_info[ profile_id ] = info
> +sm.registerUtility(info, provided=IProfile, name=profile_id)
>
> +def _computeProfileId(self, name, product):
> +profile_id = '%s:%s' % (product or 'other', name)
> +return profile_id
> +
> +security.declareProtected( ManagePortal, 'unregisterProfile' )
> +def unregisterProfile( self, name, product=None):
> +profile_id = self._computeProfileId(name, product)
> +sm = getGlobalSiteManager()
> +sm.unregisterUtility(provided=IProfile, name=profile_id)
> +
> security.declarePrivate( 'clear' )
> def clear( self ):
> +sm = getGlobalSiteManager()
> +profile_ids = [profile_id for profile_id, profile_info
> +in sm.getUtilitiesFor(IProfile)]
> +for profile_id in profile_ids:
> +sm.unregisterUtility(provided=IProfile, name=profile_id)
>
> -self._profile_info = {}
> -self._profile_ids = []
Does GlobalRegistryStorage not work for the ProfileRegistry?
> Modified:
> Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
> ===
> --- Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
> 2011-03-10 15:13:48 UTC (rev 120849)
> +++ Products.GenericSetup/trunk/Products/GenericSetup/tests/test_registry.py
> 2011-03-10 16:56:57 UTC (rev 120850)
> @@ -1014,6 +1014,8 @@
> , ConformsToIProfileRegistry
> ):
>
> +
> +
> def _getTargetClass( self ):
>
> from Products.GenericSetup.registry import ProfileRegistry
> @@ -1045,7 +1047,7 @@
> , PRODUCT
> , PROFILE_TYPE
> )
> -
> +
> self.assertEqual( len( registry.listProfiles() ), 1 )
> self.assertEqual( len( registry.listProfileInfo() ), 1 )
You touched test_registry.py just to add some extra whitespace in
strange places?
> Modified: Products.GenericSetup/trunk/Products/GenericSetup/zcml.py
> ===
> --- Products.GenericSetup/trunk/Products/GenericSetup/zcml.py 2011-03-10
> 15:13:48 UTC (rev 120849)
> +++ Products.GenericSetup/trunk/Products/GenericSetup/zcml.py 2011-03-10
> 16:56:57 UTC (rev 120850)
[...]
> def cleanUpImportSteps():
> -global _import_step_regs
> -for name in _import_step_regs:
> -try:
> -_import_step_registry.unregisterStep(name)
> -except KeyError:
> -pass
> +pass
>
> -_import_step_regs = []
> -
> def cleanUpExportSteps():
> -global _export_step_regs
> -for name in _export_step_regs:
> -try:
> -_export_step_registry.unregisterStep(name)
> -except KeyError:
> -pass
> +pass
Why didn't you remove cleanUpImportSteps and cleanUpExportSteps?
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] RFC: Removing svn:externals from buildouts
Tres Seaver wrote: > I went to investigate fixing the SourceForge / setuptools build failures > this monring and again bumped up against the use of svn:externals in the > buildouts. My preferred mode for dealing with the Zope SVN server is > via bzr-svn, but the svn:externals defeat that pattern. > > Since we are now using mr.developer anyway to pull in other > dependencies, could we go ahead and switch to using it for all the > checkouts? +0 Don't know who uses mr.developer for CMF development. I added that configuration recently and only on trunk. I still have some trouble using mr.developer in Eclipse. But if it works for everybody else and the nightly tests don't break I'm fine with replacing the svn:externals. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] member data - a small proposal
Hi! This is the current list of member data properties added by default: 'email', 'portal_skin', 'listed', 'login_time', 'last_login_time' On CMF trunk I would like to - add 'fullname' to that default list - show fullname instead of member id *if* fullname is not empty - make the related MemberDataTool properties undeletable (only the 6 basic ones - of course you can still change and delete all property values and you can add or remove other properties) Any objections? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] member data - a small proposal
Hi!
Wichert Akkerman wrote:
>> - make the related MemberDataTool properties undeletable (only the 6
>> basic ones - of course you can still change and delete all property
>> values and you can add or remove other properties)
>
> +0
>
> I'm not entirely sure what the benefit of that change is?
In many places we use the related member properties. At least the
default MemberAdapter/MemberData implementation uses the MemberDataTool
properties as some kind of schema definition. I'd like to make sure the
6 basic member properties are always available.
E.g. member.getProperty('email') would always work. You don't have to
use member.getProperty('email', '') and in a next step attribute access
(member.email) could be implemented reliable.
Cheers,
Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMF - changed property modes to 'w' and added 'fullname' property
Wichert Akkerman wrote: >> Log message for revision 122395: >> - changed property modes to 'w' and added 'fullname' property > > Would it make sense to make this a unicode property instead of a string > property? We use string properties in many places. I don't think it's worth the trouble to do it differently in just one place: - Plone uses string for 'fullname' - If we add a 'fullname' Python property to IMemberData, it can still return the decoded value. In CMF 2.3 IMemberData objects are just adapters and the property values are stored somewhere else. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1
Charlie Clark wrote: > Am 23.08.2011, 07:00 Uhr, schrieb CMF tests summarizer: > >> [1]UNKNOWN FAILED (failures=16, errors=13) : CMF-trunk Zope-trunk >> Python-2.6.6 : Linux >> https://mail.zope.org/pipermail/cmf-tests/2011-August/015153.html > > This one is beyond my feeble powers. It looks like all the doctests are > failing. > > Charlie Zope trunk is broken, it has similar failures and errors: https://mail.zope.org/pipermail/zope-tests/2011-August/048589.html Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] tools as utilities
Hi! 5 years ago we started converting CMF tools into local utilities, and we are still stuck in the middle of that task. The problem is that local utilities don't have REQUEST in their acquisition chain. A few tool methods use self.REQUEST and the plan was to replace these methods by view code. But that never happened. So these tools and all tools depending on these tools are still not converted. I propose to use 'five.globalrequest' instead of self.REQUEST inside tools. AFAICS that allows to convert *all* tools into utilities. What do you think? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] tools as utilities
Hi! Jens Vagelpohl wrote: > On Sep 12, 2011, at 11:52 , yuppie wrote: >> I propose to use 'five.globalrequest' instead of self.REQUEST inside >> tools. AFAICS that allows to convert *all* tools into utilities. > > Why would you want to add a dependency for 3 lines of code? All that package > does is register a 1 line event handler. I'd rather do that in the CMF itself. Because it provides an API that is also used and maintained by other people. Plone 4.1 depends on it. > IMHO the "cleaner" way would be to make sure the request object is explicitly > passed into any code that needs it. Sure. But that requires either API changes in the tools or new view code. The last 4 years nobody did work on this because it is much more work than 'just' converting tools to utilities. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] [dev] CatalogTool as utility
Hi! Converting the CatalogTool is not so easy because it is just a small subclass of ZCatalog. And ZCatalog expects REQUEST in its acquisition context. AFAICS the only place where this causes trouble is the AbstractCatalogBrain API. But I might be missing other issues. Maybe some people can test CMF trunk with their code? Is there a Plone branch that is tested against CMF trunk? Currently CMF trunk contains some hacks to work around the catalog brain issues. But I hope there is a better solution. Maybe the ICatalogBrain methods getURL, _unrestrictedGetObject and getObject should have a REQUEST argument that is used instead of self.REQUEST? Any kind of feedback and help is welcome. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
Hi! Hanno Schlichting wrote: > On Mon, Sep 19, 2011 at 11:57 AM, > yuppie wrote: >> Currently CMF trunk contains some hacks to work around the catalog brain >> issues. But I hope there is a better solution. Maybe the ICatalogBrain >> methods getURL, _unrestrictedGetObject and getObject should have a >> REQUEST argument that is used instead of self.REQUEST? >> >> Any kind of feedback and help is welcome. > > Mmh, why don't we just use zope.globalrequest in ZCatalog directly? > And create a new ZCatalog 2.14 release series with this. Then we don't > have to wait for Zope 4.0 to include it. Using an explicit argument is always cleaner than using zope.globalrequest. And getObject() already has a (currently unused) REQUEST argument. And we might be able to provide a migration path for the API change: If we don't use registerToolInterface, we don't have to change getObject/getURL calls in places where we still use getToolByName. But with zope.globalrequest we can avoid modifying the API. So if it is fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
Hi Hanno! Hanno Schlichting wrote: > On Mon, Sep 19, 2011 at 3:56 PM, > yuppie wrote: >> But with zope.globalrequest we can avoid modifying the API. So if it is >> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might >> be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF? > > I meant ZCatalog 2.14 only for CMF. > > Having independent distributions allows us to evolve them at a different pace > :) But an additional ZCatalog branch is an additional maintenance burden. And the required change is small and 100% backwards compatible. The zope.globalrequest dependency could be made optional. Do we really need an extra ZCatalog branch for that? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
Hi! Hanno Schlichting wrote: > On Tue, Sep 20, 2011 at 12:19 PM, > yuppie wrote: >> But an additional ZCatalog branch is an additional maintenance burden. >> And the required change is small and 100% backwards compatible. The >> zope.globalrequest dependency could be made optional. >> >> Do we really need an extra ZCatalog branch for that? > > If there's a completely backwards compatible way of doing, we should do that. > > I was under the impression, that we had to do an API change for some > methods and add a new request argument to those. If that argument is > required depending on how the tool was retrieved, that's confusing to > me and I'd rather go the zope.globalrequest route. I no longer consider modifying ICatalogBrain. The big advantage of using zope.globalrequest is that we can move forward without discussing API changes. I plan to use zope.globalrequest as fallback if self.REQUEST is not available. What's the best approach for the five.globalrequest dependency? Just use zope.globalrequest if it is available? Or specify it in extras_require? Or add it to install_requires, making it an indirect dependency of the next Zope 2.13 release? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] CatalogTool as utility
Hi! Hanno Schlichting wrote: > On Wed, Sep 21, 2011 at 1:57 PM, > yuppie wrote: >> I plan to use zope.globalrequest as fallback if self.REQUEST is not >> available. >> >> What's the best approach for the five.globalrequest dependency? Just use >> zope.globalrequest if it is available? Or specify it in extras_require? >> Or add it to install_requires, making it an indirect dependency of the >> next Zope 2.13 release? > > Adding it to the setup.py of what project? I meant Products.ZCatalog. > I consider using zope.globalrequest as a feature change - primarily > because its interaction with tests is a bit unclear. Introducing more > module global state for the request variable will probably lead to > some changes to test isolation code somewhere. > > So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just > put it as a hard dependency into install_requires. Ok. Products.CMFCore trunk already has a hard dependency. My checkin for Products.ZCatalog has an optional dependency on five.globalrequest. If five.globalrequest is not installed, Products.ZCatalog behaves exactly as before. I hope we don't need a Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without five.globalrequest. See http://svn.zope.org/?rev=122892&view=rev Is that ok? Should I add an explicit extra in the setup.py of Products.ZCatalog? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Switching to Chameleon
Hi Laurence! Laurence Rowe wrote: > Plone tends to wait for CMF to stabilise before thinking of moving to > a new version. I doubt that strategy will work for Plone: Most CMF installations are part of Plone installations. And Plone uses CMF in different ways than other CMF installations. So the best way to get a battle-tested CMF release is to help testing. Besides that: Did you ever see trouble with unstable CMF releases? > At least when I last looked around a year ago (after > adding some workflow pluggability into CMF) CMF trunk broke far too > much in Plone to consider it for a minor revision. Was the Plone version you used for testing Zope 2.13 compatible? At that time CMF trunk didn't have many changes that affect Plone. The tools-as-utilities changes I recently made might require more work on the Plone side. Especially in test setups. > Hopefully someone > will put the effort in to port Plone to CMF 2.3 in time for Plone 5. Who ever that is: The upgrade steps for CMFDefault might give some hints what needs to be upgraded. And you are always welcome to ask questions on this list if you have trouble with upgrading. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: > Am 27.01.2011, 17:05 Uhr, schrieb yuppie: > >> zope.formlib is not made for DateTime values and encoded strings. So you >> *always* have to make sure these values are converted correctly. And it >> is hard to do that inside the form code. Obviously you did have trouble >> to get it right that way. After I started using adapters for the edited >> objects I had much less trouble using formlib. Of course you don't need >> an adapter if your objects already provide the right interface. > >> And one more benefit: Inside the form code you can completely ignore the >> old-fashioned implementation of the edited objects and write nice modern >> code. > > Finally have made the time to look at this. I've written a schema adapter > for the forms and it looks like SettingsEditForm handles the conversion to > Zope's DateTime nicely. Now, I'm stuck with the problem of getting my view > unit tests to work. Looks like I need a few adapters registered. :-/ SettingsEditFormBase has a getContent() method similar to that in z3c.form. This allows a clean distinction between 'content' and 'context'. For content objects they are usually the same, but in your case the site root is the context and the (adapted) SyndicationTool is the edited "content". Please have a look at the membership views. They show how to use getContent(). In your case the method would look like this: @memoize def getContent(self): syndtool = getUtility(ISyndicationTool) return SyndicationToolSchemaAdapter(syndtool) This example uses a hardcoded adapter. You can still register it and look it up, but I guess that's overkill. I doubt anybody wants to use a customized adapter. And if it is hardcoded, you don't need to register it for testing ;) Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Charlie Clark wrote:
> SettingsEditFormBase landed after my sturm and drang work last year. So
> you generally replace my explicit calls to tools with getContent? I guess
> I just need some proxyFields for enabling and disabling.
Yes.
> I still need to set view.adapters = {} for some reason but that's okay.
zope.formlib expects that setUpWidgets is always called before
handle_change. If you test handle_change isolated, you have to set
adapters by hand.
Cheers, Yuppie
___
Zope-CMF maillist - Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: > I've hit a bit of a problem with folder syndication - I already have an > annotations adapter for storing the values on the folder and I can extend > this to be able to handle individual values rather than a dictionary but > ProxyFieldProperties don't work because the adapter itself doesn't support > properties. I also have some additional methods on the adapter that I use > from the view. What do you think is the best way to proceed here? Subclass > the SchemaAdapter so that the encoding and DateTime stuff works okay? For > the methods I don't see any alternative but to expose the annotations > adapter explicitly within the view. Bit of a muddle, I guess. If you want to modernize SyndicationInformation, why do you still store DateTime objects in the database? (And why don't you use zope.annotation?) Quoting the docstring of schema.py: "SchemaAdapterBase and ProxyFieldProperty are legacy code. They should only be used to adapt old content types that can't handle unicode and datetime correctly." AFAICS only the getUpdateBase method of ISyndicationTool needs to be backwards compatible. Everything else is new API or doesn't return DateTime objects. Wouldn't it be better to use datetime internally? You already need an upgrade step for SyndicationInformation. Writing an additional upgrade step for SyndicationTool wouldn't be much extra work. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: > Am 30.09.2011, 10:55 Uhr, schrieb yuppie: > >> >> AFAICS only the getUpdateBase method of ISyndicationTool needs to be >> backwards compatible. Everything else is new API or doesn't return >> DateTime objects. Wouldn't it be better to use datetime internally? You >> already need an upgrade step for SyndicationInformation. Writing an >> additional upgrade step for SyndicationTool wouldn't be much extra work. > > ISyndicationInfo is a new interface. I'm tempted to use zope.schema > directly on this but I suppose that does tie any implementation to > zope.schema rather maybe annotated Python tyes. Thoughts? I think in general it's fine to use zope.schema for CMFCore interfaces. But if you use properties instead of separate accessors and mutators, you can't set different read/write permissions in Zope 2. So please make sure modifying the settings is protected sufficiently. > Regarding zope.annotation - IAttributeAnnotatable creates a new object > within the folder Why do you think so? AFAICS the default implementation stores all annotations in the __annotations__ attribute. > but I'd rather not have the SyndicationInfo visible > within the ZMI but IAnnotations only uses a dictionary and so less > suitable for storing multiple values. If I go the AttributeAnnotatable way > is it okay to use Persistent rather than SimpleItem as long as > manage_fixupOwnershiAafterAdd is provided? Or is that too kludgy and > preferable to work on my current adapter to provide attribute access to an > Annotations dictionary? Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] working on the trunk
Charlie Clark wrote: > Am 04.10.2011, 10:55 Uhr, schrieb yuppie: >>> Regarding zope.annotation - IAttributeAnnotatable creates a new object >>> within the folder >> Why do you think so? AFAICS the default implementation stores all >> annotations in the __annotations__ attribute. > > Running some tests with the most recent version and it definitely creates > child objects that are visible in the ZMI. I guess I need to test this a > bit more but I suspect I might have to provide my own implementation. Strange! Your container implements IAttributeAnnotatable and AttributeAnnotations is registered correctly? Are you trying to use zope.annotation.factory? Last time I checked that didn't work with Zope 2. But the AttributeAnnotations adapter works for me without showing anything in the ZMI. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] Towards a 2.3 Release
Hi! Charlie Clark wrote: > * apparently the "absolut" skin can cause problems with used in > combination with profiles. Yuppie, do you have any more information on > this? Not sure what you mean. I had some problems getting rid of oldstyle skins completely (including main_template), but that is not what the the "absolut" skin does. I gave up after a short try, so I can't provide any further details. > * the views only profile is no longer experimental. I would like to be > able to make this a base profile (with the "absolut" skin) but have hit > problems with CMFCalendar requiring the standard CMFDefault skin -1 for adding a second base profile We can do the same as in CMFCalendar: Use views in the default profile and provide an extension profile for people who want to switch back to oldstyle skins. I propose to do this step by step. We have views with different levels of maturity: Some exist for a while and are battle proofed. Others are new without any real world testing. Each view should be reviewed if it is ready for becoming default. > In Berlin we decided against a beta but I would actually like to test my > existing sites against a new version, so a beta would probably be a good > idea. I'm fine with a beta *if* that brings additional testing and feedback before the final release. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
Hi! Charlie Clark wrote: I'm testing with some existing sites and getting the following error even before I run the upgrades: ComponentLookupError: (, '') I'm obviously missing a registration but my site includes Products.CMFCore package. The tools are *local* utilities. Including the ZCML doesn't fix this issue. You have to run the upgrade step. It should be possible to use the ZMI without this kind of errors. In some places I added fallbacks like this one: try: utool = getUtility(IURLTool) except ComponentLookupError: # BBB: fallback for CMF 2.2 instances utool = aq_get(self, 'portal_url') If you can't run the upgrades from the ZMI it might be necessary to add more fallbacks in CMF. HTH, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
