Re: [Zope-CMF] Pending pull requests GenericSetup
Hi Maurits, Maurits van Rees wrote: > Just a friendly reminder that there are two pending pull requests by me > for GenericSetup. > > Pep8, mostly in tests: > https://github.com/zopefoundation/Products.GenericSetup/pull/21 > > Add unsetLastVersionForProfile and purgeProfileVersions. Call > purgeProfileVersions for base profiles: > https://github.com/zopefoundation/Products.GenericSetup/pull/18 > > I know, everyone is busy, no problem. what exactly are you waiting 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] GenericSetup: Apply profile dependencies only once
Hi Maurits, Maurits van Rees wrote: > Op 25-09-15 om 10:31 schreef yuppie: >> But I hope these assertions are true: >> >> - a profile that depends on more than one base profile is broken anyway > > Agreed. > >> - if there is a base profile in the chain, it is always the first in the >> chain > > Not necessarily, though I do hope so. > > I am expecting that the base profile is the first and only profile in > the chain. > > But in the tests I explicitly test what would happen if the base profile > itself has a dependency, although this makes no sense to me. In this > case the base profile would be the second in the chain. why are you testing features that don't make sense to you? Are the names BASE and EXTENSION not clear enough? Why would someone expect that you can use an EXTENSION profile as the base and extend it with a BASE profile? > Then the purge > of all versions should happen right before applying the base profile, so > after its dependency profile. Why would someone want to import the first profile in the chain (version is set automatically) and remove the version data again in the next step? >> So it might be ok to purge versions inside the loop. But I don't think >> it makes sense to purge versions if we don't reapply the base profile in >> purge mode. I would make the change after the BeforeProfileImportEvent. > > Problem may then be that this part of the code is never reached. Between > those two spots are the checks to see whether the profile that is about > to be imported has already been applied previously. And we use the > profile upgrade versions for this. When a base profile is in this way > applied a second time, the checks would conclude it has already been > applied and will continue with the next profile in the for loop, without > purging the versions. Why would an upgrade step (re-)apply a complete base profile in purge mode? Why should we purge the versions if the code that purges the old configuration is never reached? >> In that place it should be possible to use the shouldPurge method >> instead of checking the profile type. Or is anyone running extension >> profiles in purge mode? In that case we have to check for both. > > Let me think. [...] > So I would say: we purge the profile upgrade versions only if a base > profile is imported, and should_purge is None or True. I have updated > the pull request with that. > > Does that sound reasonable? Well, I would say: There are several ways to use the import machinery. Only a few ways should normally be used. All other options are some kind of expert mode that allows to (re-)apply selected parts of all kinds of profiles. You should use those options only if you know exactly what you do. I started the discussion about purging versions automatically. And I think we should do that only in the normal use case where someone obviously wants to start from scratch. And that's the case if we are in purge mode and (re-)apply a "complete" profile. Base profiles, snapshots and tarballs are usually complete profiles. But snapshots and tarballs don't care about versions and upgrades, so it might be ok to ignore them. Your updated pull request still purges versions if we depend on a base profile, but don't (re-)apply it. That's not what I would expect. 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: Apply profile dependencies only once
Hi Maurits, Maurits van Rees wrote: > Op 23-09-15 om 16:53 schreef yuppie: >> if you run a base profile in purge mode, shouldn't that purge profile >> versions automatically? > > GenericSetup itself is not doing this currently. > It might be good to do that, but I guess it is not always needed. > Then again, I have never written a base profile myself, only extension > profiles, so I'm not sure what creators of base profiles expect here. if you run a base profile in purge mode, you usually want to undo all previous configuration and start from scratch. In theory you could do that just with some setup handlers and keep the rest of the configuration. But I doubt someone uses it that way. If you start from scratch, old profile versions data becomes incorrect. So I think GenericSetup should delete that data automatically. >> Sorry, but I'm still not convinced. >> >> I agree the negative effect is smaller in the tests. I would not object >> if you make automated cleanups in tests before you modify them. > > If you mean you want me to only cleanup an individual test file or even > an individual test method when I touch it, then: no way. Then pep8 > fixes and real fixes will get thrown together making it harder to judge > a pull request. Let's just get it over with for the tests in one go. > Otherwise: never mind, let's not worry about pep8 for this package ever > at all. But maybe I misinterpret your words. I meant: Clean up the files you plan to touch, commit that change directly without PR, create your PR. > Anyway, let's not lose too much sleep arguing over this. > I have created a new pull request, superseding the other pep8 one. > https://github.com/zopefoundation/Products.GenericSetup/pull/21 > > This cleans up pep8 in the tests. The first commit is only white space. > The second commit is more aggressive, but far, far smaller. > > Plus in the rest of the code this fixes only pep8 issues in comments or > in empty lines: removing or adding a line or removing white space on an > otherwise blank line. This would be a compromise I can live with. But I was not the only one who voted against your first PR. 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: Apply profile dependencies only once
Hi Maurits,
Maurits van Rees wrote:
> Adding 'purgeProfileVersions' is also on my wish list now, which is
> really simple:
>
> portal_setup._profile_upgrade_versions = {}
>
> There were a few problems in Plone due to my change with the dependency
> strategies. I found that those were caused by importing the base Plone
> profile (so no extension profile), so this ran in purge mode, which
> meant several settings of add-ons were overwritten. Only a problem you
> really ever encounter in test code that tries to do to much.
>
> Purging the profile versions from portal setup helped solve this. And I
> would rather call an official method than accessing the private
> _profile_upgrade_versions from within Plone code.
if you run a base profile in purge mode, shouldn't that purge profile
versions automatically?
> But actually, it is not that bad I think. When I look at the top level
> files at how many lines of them are to 'blame' on my pep8 change, I get
> this table. Not sure if this gets across nice in email:
>
> FilenameBlameLinesPercentage
> __init__.py5559%
> components.py285595%
> content.py254176%
> context.py16272322%
> differ.py6419633%
> events.py0550%
> exceptions.py0210%
> interfaces.py638477%
> metadata.py207726%
> permissions.py0160%
> registry.py447466%
> rolemap.py4421920%
> testing.py01780%
> tool.py10514267%
> upgrade.py142745%
> utils.py499275%
> zcml.py203725%
>
> So the file with the biggest percentage of lines changed, is differ.py
> with 33 percent. We have context.py, metadata.py and rolemap.py between
> 20 and 26 percent. The rest is below 10 percent.
> The biggest and most central one, tool.py, has 7 percent of its lines
> changed.
>
> In the tests directory things are very different, given that there are
> about 5000 pep8 errors there. git itself says for three files that it
> completely rewrote them:
>
> rewrite Products/GenericSetup/tests/test_differ.py (66%)
> rewrite Products/GenericSetup/tests/test_registry.py (78%)
> rewrite Products/GenericSetup/tests/test_rolemap.py (64%)
>
> But I would say for the tests a 'git blame' is less needed.
Sorry, but I'm still not convinced.
I agree the negative effect is smaller in the tests. I would not object
if you make automated cleanups in tests before you modify 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] GenericSetup: Apply profile dependencies only once
Hi Jens, Jens W. Klein wrote: > On 2015-09-22 12:30, yuppie wrote: > [...] >>> - pep8. This fixes over 6000 pep8 errors... Most of them fixed with the >>> autopep8 command line tool. Small in scope yes, but due to all those >>> errors a *very* large pull request. All tests pass. >> >> -1 >> >> I agree with the goal to try to respect pep8 rules and to use tools that >> help doing this. But this is a massive reformatting that adds a lot of >> noise if you use blame or similar techniques. And I use often diffs >> between different versions to understand the history of the code. >> >> There might be a subset of pep8 rules that is already respected in most >> parts of the code and where fixing the rest wouldn't add much noise. > > I dont agree. The noise is one commit. Blame does not make sense without > looking at the whole history anyway. So its one more diff in a whole series. why would you look at the whole history? Blame tells you which revision modified the lines you are interested in. So you can jump directly to that revision. It's annoying if this revision is just a code cleanup. > My only point is to not make code pep8 is to not affect other peoples > branches/ open pull requests, because rebase/merge after any massive > change is indeed lot of work. This is not an issue with GenericSetup, but if you have several release branches, it also makes it hard to port changes from one branch to an other. I'm not completely against code cleanups, but I don't think touching thousands of lines just to do massive automated cleanups is the right way to do it. 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: Apply profile dependencies only once
Hi Maurits, Maurits van Rees wrote: > Meanwhile, I have added two more pull requests, far smaller in scope: > > - Add 'unsetLastVersionForProfile' method to portal_setup. This removes > the profile id from the profile upgrade versions. +1 > - pep8. This fixes over 6000 pep8 errors... Most of them fixed with the > autopep8 command line tool. Small in scope yes, but due to all those > errors a *very* large pull request. All tests pass. -1 I agree with the goal to try to respect pep8 rules and to use tools that help doing this. But this is a massive reformatting that adds a lot of noise if you use blame or similar techniques. And I use often diffs between different versions to understand the history of the code. There might be a subset of pep8 rules that is already respected in most parts of the code and where fixing the rest wouldn't add much noise. 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: Apply profile dependencies only once
Hi Maurits, Maurits van Rees wrote: > Op 14-09-15 om 09:02 schreef Charlie Clark: >> This sounds like a good idea. The ZMI has traditionally suffered from >> just having more and more knobs to twiddle with little thought of the >> actual UI. I don't think that should block this PR (if it's required to >> solve a common problem at short notice). > > I would like to look at the UI later. An extra tab and some cleanup on > the current Import should not be that difficult. that would be nice, but I agree the UI issues should not block your PR. > Meanwhile, is it okay to merge the current pull request and make a > release? It seems that most people think it is okay, but yuppie is most > on the fence. No 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] GenericSetup: Apply profile dependencies only once
Hi Maurits, Maurits van Rees wrote: > Dependency profiles from metadata.xml that are already applied, are not > applied again. Instead, its upgrade steps, if any, are applied. In code > you can choose the old behavior of always applying the dependencies, by > calling runAllImportStepsFromProfile with always_apply_profiles=True. Or > you can choose to be happy with any applied version and ignore any > upgrade steps, by using upgrade_dependencies=False. Note that these > arguments cannot both be True. assuming that profiles always depend on the latest versions of specified profiles is fine. But wouldn't it be better to make upgrading existing profiles an explicit extra step in the UI? Does it make sense to upgrade only the dependencies, not other applied profiles? I would just raise an error if the dependencies are not up to date and ignoring the problem or running upgrades or re-applying profiles is not explicitly specified. If only one option is allowed, why not using one argument? outdated_dependencies=None|ignore|upgrade|reapply But I can also live with your solution. As long as the behavior doesn't change if the dependencies were not applied before, I have no objections. > Less tricky is the second change: > > Be more forgiving when dealing with profile ids with or without profile- > at the start. All functions that accept a profile id argument and only > work when the id does not have this string at the start, will now strip > it off if it is there. For example, getLastVersionForProfile will give > the same answer whether you ask it for the version of profile id foo or > profile-foo. This doesn't make things clearer to me. IIRC the prefixes were added to have separate namespaces and an easy way to figure out which kind of profile we are dealing with. Do you propose to make these namespaces obsolete in the code? Or only in some places? How do I know if the profile_id argument requires the prefix in a specific 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] GenericSetup: upgrade step ordering with newer setuptools
Maurits van Rees wrote: Can my branch be merged to trunk? And could we get a release please? I would appreciate it. No objections from my side. 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: upgrade step ordering with newer setuptools
Hi Maurits, Maurits van Rees wrote: 1. In January yuppie did a fix on GenericSetup trunk (r130476), which deserves a release, as it fixes upgrade step sort order with setuptools 8 and higher. Thank you, yuppie! my fix was just a quick and dirty solution relying on legacy code in setuptools. 2. But I just created a branch (maurits-versions-setuptools) with a minor fix for that fix, which deserves another pair of eyes. It avoids a warning by pkg_resources. Your refactoring looks fine. The code is still a bit hard to read because we convert versions backwards and forwards: UpgradeEntity.__init__ converts '*' to None and other strings to tuples, but we no longer use None or tuples. We convert them back to strings. Is there any third party code that depends on the old format? 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] DynamicType.portal_type
Hi! yuppie wrote: http://svn.zope.org/?view=revrevision=130422 changes the default value of DynamicType.portal_type from None to an empty string. getPortalTypeName returns this value and the interface still says: def getPortalTypeName(): Return the name of the type information for this object. o If the object is uninitialized, return None. o Permission: Public In several places the code relies on this and checks for None. There is no test that shows what was broken and fixed. AFAICS there is nothing wrong with using None for uninitialized objects. We just have a new requirement in Products.ZCatalog 3: Attributes with None values can no longer be indexed. Wouldn't it be better to adjust the portal_type just for indexing in the IndexableObjectWrapper? Fixed the issue this way: - reverted r130422 - adjusted the IndexableObjectWrapper I guess other indexed attributes can also contain None. Not sure if converting them to an empty string is always the best solution. 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] authoritative copy of Products.GenericSetup
Hi, I can't remember any decision to move the authoritative copy of Products.GenericSetup to the servers of GitHub Inc. So either the place for making authoritative decisions about Products.GenericSetup has also moved somewhere else or the canonical repository is still svn.zope.org . Why was https://pypi.python.org/pypi/Products.GenericSetup/1.7.5 released from a different repository and why was this change made: http://svn.zope.org/?view=revrevision=130433 ? 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] DynamicType.portal_type
Hi, http://svn.zope.org/?view=revrevision=130422 changes the default value of DynamicType.portal_type from None to an empty string. getPortalTypeName returns this value and the interface still says: def getPortalTypeName(): Return the name of the type information for this object. o If the object is uninitialized, return None. o Permission: Public In several places the code relies on this and checks for None. There is no test that shows what was broken and fixed. AFAICS there is nothing wrong with using None for uninitialized objects. We just have a new requirement in Products.ZCatalog 3: Attributes with None values can no longer be indexed. Wouldn't it be better to adjust the portal_type just for indexing in the IndexableObjectWrapper? 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] Products.CMFCore release
Jens Vagelpohl wrote: I have created a new release and uploaded it to PyPI. -2.2.8 (unreleased) +2.2.8 (2014-10-15) You've got a time machine? 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] Products.CMFCore release
Hi Jens! Jens Vagelpohl wrote: On Oct 15, 2013, at 9:09 , yuppie y.2013-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: Jens Vagelpohl wrote: I have created a new release and uploaded it to PyPI. -2.2.8 (unreleased) +2.2.8 (2014-10-15) You've got a time machine? Cheers, Yuppie Sorry, typo. I have corrected the file in SVN, but IMHO a new egg won't be required, right? Yes, that should be sufficient. I have also managed to fix the issue with the svn.zope.org mail hook, even though that's not my job anymore. Great! Thanks! 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] Products.CMFCore release
Hi! Jens Vagelpohl wrote: On 10/11/2013 07:34 AM, Harald Friessnegger wrote: i did a minor change to cmfcore that i'd love to see in the next releases of plone. http://dev.plone.org/ticket/10071#comment:8 could you please review the change and do a new release on pypi? [...] If it was just about making a release I could have done it quickly. However, I see two issues I don't have time to look into right now: - the change has no unit test And the port to trunk was completely broken: http://svn.zope.org/?rev=130319view=rev I fixed it here: http://svn.zope.org/?rev=130321view=rev - two others are failing: snip Failure in test test_getActionObject_oldskool_action_deprecated (Products.CMFCore.tests.test_ActionsTool.ActionsToolTests) Traceback (most recent call last): File /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/unittest/case.py, line 331, in run testMethod() CMF 2.2 requires Python 2.6, not 2.7. 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 area / home folder changes
Hi Charlie! Charlie Clark wrote: Am 01.08.2013, 11:46 Uhr, schrieb yuppie y.2...@wcm-solutions.de: First a few words about names: CMF uses sometimes 'member area' and sometimes 'home folder'. IMembershipTool has 'getHomeFolder' and 'getHomeUrl' methods as well as 'createMemberArea' and 'deleteMemberArea' methods. If there is a difference between the two names, 'home folder' is just the folder and 'member area' the folder including all subobjects. In my proposal I proposed to add portal types named 'Members' and 'MemberArea', but I now changed this to 'Members Folder' and 'Home Folder'. Hope that's ok. I think this is clearer: users are interested in their own or others (home) folder. The Members Folder is really only of interest to admins. Do the new types have any special functions or attributes? Or are they purely semantic? You mention a proposal - did that go to the list and I missed it? Or did you put something up on launchpad? I didn't write a full proposal. Just mentioned the planed changes in this mail: https://mail.zope.org/pipermail/zope-cmf/2013-July/030754.html - 'Home Folder' is a special folder type that uses the normal Portal Folder class, but a different factory that replaces parts of the old createMemberArea() code. - 'Members Folder' is a special folder type that uses the normal Portal Folder class, but limits sub-items to 'Home Folder' objects and has a special default view that replaces the 'index_html' DTML Method currently added to the members folder. 'createMemberArea' now uses separate factories for creating member areas. This allows to use the same method in CMFCore and CMFDefault. The MembershipTool in CMFDefault no longer has a customized version of 'createMemberArea'. I'm not sure what the separate factories are for member areas and…? But it certainly makes sense to remove a customisation in CMFDefault. I meant the actual factories are now separated from the rest of the createMemberArea code. The new factories implementing zope.component.interfaces.IFactory are now looked up and used by createMemberArea. The only thing I have here is that changes should probably come in a new release. I think we've (well, you've) done most of the work for moving from TTW and we can look to faster releases than in the past because of the improved test coverage. No objections. I'd just like to do some small polishing before we create 2.3 branches. 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 area / home folder changes
Hi Charlie! Charlie Clark wrote: Okay. Is there any of my stuff outstanding that you haven't already fixed for me? Last time I checked the syndication views had some issues. Two things I remember: - The folder syndication form seems to allow enabling folder syndication if portal syndication is disabled. This is confusing. - syndication.pt exists but is not used. 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] CMFDefault: renaming type action urls
Hi!
Charlie Clark wrote:
Am 13.05.2013, 10:06 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
Types: File, Image
Action: object/view
old: url_expr=string:${object_url}/file_view
old: url_expr=string:${object_url}/image_view
new: url_expr=string:${object_url}/view
I think this is possibly the only one I would question: why the explicit
view as opposed to /? Is this difference between viewing the file or
image with metadata and when it is used as a resource elsewhere?
Yes. Default view and 'view' are identical for other content types, but
File and Image have a download view and a preview.
Otherwise it's a very sensible clean up of a wart of the old style
Meanwhile this is checked in. But if there are no objections I'd like to
make a small modification:
We have 'view' (not 'viewing') and 'edit' (not 'editing'), so I think we
should use 'share' instead of 'sharing' for local roles.
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] CMFDefault: renaming type action urls
Hi!
This just affects configuration. If you use your own profile, you can
use different names. But nevertheless names shouldn't be changed too
often and without a good reason. So I'd like to make sure there are no
objections:
We are in the process of replacing skin methods by browser views, but we
still show the old skin method names in Action URLs. I'd like to get rid
of type specific names and would prefer more generic names. A detailed
list is at the bottom of this mail.
Part of that change would be adjusting the Method Aliases and adding an
upgrade step to make migration easier.
Cheers,
Yuppie
Types: Discussion Item, Document, Favorite, Link, News Item
Action: object/view
old: url_expr=string:${object_url}/discussionitem_view
old: url_expr=string:${object_url}/document_view
old: url_expr=string:${object_url}/favorite_view
old: url_expr=string:${object_url}/link_view
old: url_expr=string:${object_url}/newsitem_view
new: url_expr=string:${object_url}
Types: File, Image
Action: object/view
old: url_expr=string:${object_url}/file_view
old: url_expr=string:${object_url}/image_view
new: url_expr=string:${object_url}/view
Types: File
Action: object/download
old: url_expr=string:${object_url}
new: =
Types: Document, Favorite, File, Image, Link, News Item
Action: object/edit
old: url_expr=string:${object_url}/document_edit_form
old: url_expr=string:${object_url}/file_edit_form
old: url_expr=string:${object_url}/image_edit_form
old: url_expr=string:${object_url}/link_edit_form
old: url_expr=string:${object_url}/newsitem_edit_form
new: url_expr=string:${object_url}/edit
Action: object/metadata
old: url_expr=string:${object_url}/metadata_edit_form
new: url_expr=string:${object_url}/properties
Types: Folder, CMF BTree Folder
Action: object/view
old: url_expr=string:${object_url}
new: =
Action: object/folderContents
old: url_expr=string:${object_url}/folder_contents
new: =
Action: object/new (Action is deprecated)
old: url_expr=string:${object_url}/folder_factories
new: =
Action: object/localroles
old: url_expr=string:${object_url}/folder_localrole_form
new: url_expr=string:${object_url}/sharing
Action: object/rename_items (Action is obsolete with browser views)
old: url_expr=string:${object_url}/folder_rename_form
new: =
Action: object/edit
old: url_expr=string:${object_url}/folder_edit_form
new: url_expr=string:${object_url}/properties
___
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] CMFDefault: renaming type action urls
Hi Tres,
thanks for the feedback.
Tres Seaver wrote:
Types: Discussion Item, Document, Favorite, Link, News Item Action:
object/view old: url_expr=string:${object_url}/discussionitem_view
old: url_expr=string:${object_url}/document_view old:
url_expr=string:${object_url}/favorite_view old:
url_expr=string:${object_url}/link_view old:
url_expr=string:${object_url}/newsitem_view new:
url_expr=string:${object_url}
Types: File, Image Action: object/view old:
url_expr=string:${object_url}/file_view old:
url_expr=string:${object_url}/image_view new:
url_expr=string:${object_url}/view
Types: File Action: object/download old:
url_expr=string:${object_url} new: =
Types: Document, Favorite, File, Image, Link, News Item Action:
object/edit old: url_expr=string:${object_url}/document_edit_form
old: url_expr=string:${object_url}/file_edit_form old:
url_expr=string:${object_url}/image_edit_form old:
url_expr=string:${object_url}/link_edit_form old:
url_expr=string:${object_url}/newsitem_edit_form new:
url_expr=string:${object_url}/edit Action: object/metadata old:
url_expr=string:${object_url}/metadata_edit_form new:
url_expr=string:${object_url}/properties
Types: Folder, CMF BTree Folder Action: object/view old:
url_expr=string:${object_url} new: = Action: object/folderContents
old: url_expr=string:${object_url}/folder_contents new: = Action:
object/new (Action is deprecated) old:
url_expr=string:${object_url}/folder_factories new: = Action:
object/localroles old:
url_expr=string:${object_url}/folder_localrole_form new:
url_expr=string:${object_url}/sharing Action: object/rename_items
(Action is obsolete with browser views) old:
url_expr=string:${object_url}/folder_rename_form new: = Action:
object/edit old: url_expr=string:${object_url}/folder_edit_form new:
url_expr=string:${object_url}/properties
+1 overall. I've lost some context, so a couple of questions:
Guess I have to explain my list:
- - An empty value for 'new' means that the alias is being deleted?
You mean in my list? Using new: = I meant same as old, not empty.
If so,
do we make a distinction between a download view for files / images
(setting 'Content-disposition: attachment') vs. the bare URL?
- - Why have an alias from 'object/edit' to 'string:${object_url}/edit
Types: Document, Favorite, File, Image, Link, News Item
Action: object/edit
old: url_expr=string:${object_url}/document_edit_form
old: url_expr=string:${object_url}/file_edit_form
old: url_expr=string:${object_url}/image_edit_form
old: url_expr=string:${object_url}/link_edit_form
old: url_expr=string:${object_url}/newsitem_edit_form
new: url_expr=string:${object_url}/edit
'object/edit' specifies the Action: 'edit' Action in category 'object'
url_expr=string:${object_url}/edit specifies the URL of the Action
'edit' isn't a skin method or a browser view, so we have to define
Method Aliases which are not shown in my list:
in a profile for browser views:
alias from=edit to=@@edit.html/ (for all types)
in a profile for old-style skins:
alias from=edit to=document_edit_form/ (for Document)
alias from=edit to=file_edit_form/ (for File)
alias from=edit to=image_edit_form/ (for Image)
alias from=edit to=link_edit_form/ (for Link, Favorite)
alias from=edit to=newsitem_edit_form/ (for News Item)
Hope things are a bit clearer now.
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] Move to github?
Hi! Martin Aspeli wrote: I mean, there's no tangible cost (financial or otherwise) of using GitHub; and git's architecture pretty much ensures that there's no lock-in (especially if mirroring is set up). [...] I don't see it as supporting GitHub. I see it as using a service that is free to us and rather good. It saves resources (e.g. the time spent managing svn.zope.org http://svn.zope.org; the cost of bandwidth) that can be better spent elsewhere (e.g. working on Zope/CMF). It helps make it easier for others to contribute, because so many people already know how to use GitHub. GitHub Inc. is too successful. It already has too much power. That's not good for the open source community. Because? GitHub is on the best way to become a monopoly in the area of social coding platforms. Just like Facebook and Twitter already are in their markets. And all these platforms benefit from the network effect: Each additional user makes the monopoly more stable and powerful. As you say above, the fact other people use them as well makes them so valuable. Monopolies are bad. (At least if they are in private hand.) There is no technical lock-in for the Git repositories. But there are economic lock-in mechanisms. If you use a platform, you invest in it: You have to wrap your head around it. Maybe you helped improving the platform by reporting bugs, making feature requests or writing tools for it. You spend time trying to convince other people to use that platform. All these investments get lost if you switch to an other platform. And even if an other platform would be technically better you wouldn't switch because of the network effect that let's you stay where all the other people are. So GitHub Inc. has to make really bad decisions before people have an incentive to go somewhere else. What's the worst that could happen? GitHub goes belly-up and we starting using a different remote in our repos? GitHub tries to violate the license terms of our software somehow (that seems very unlikely)? Companies like GitHub Inc. want to maximize their profit. As soon as they are big enough, they become arrogant. One day they will start making money by placing ads everywhere. If I did get the discussion correctly, people didn't lobby for moving to GitHub just to use it as a cheap hosting service. They did it because of the proprietary features GitHub is building around the repositories. I don't want to give the responsibility for the way I collaborate with other contributers into the hands of a company. 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] Should object paste check FTI?
Hi!
Wichert Akkerman wrote:
PortalFolderBase overrides _verifyObjectPaste to add some extra checks
on top of OFS's CopyContainer to check if content may be pasted: it
copies the permission checking (why doesn't it call the base class for
that?)
It does call the base class *if* support for the deprecated
multi-factories is not required.
and adds code to check for allowed types. There is one check
missing there that is checked when creating new object: the FTI may
block creation of new content as well through
its isConstructionAllowed method. Is there any reason
_verifyObjectPaste check this as well? This should be simple to do:
portal_type = getattr(aq_base(obj), 'portal_type', None)
if portal_type:
fti = queryUtility(ITypeInformation, name=portal_type)
if fti is not None and not fti.isConstructionAllowed(self):
raise ValueError('You can not add the copied content here.')
The change is actually much simpler: replace the current workflow guard
check with a call to objType.isConstructionAllowed(self). The FTI checks
for workflow guards already so you won't need to duplicate that code
anymore either.
isConstructionAllowed just returns a boolean value, _verifyObjectPaste
tells you what went wrong. Maybe there should be a new method that
raises errors and can be used by isConstructionAllowed and
_verifyObjectPaste?
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: 5, UNKNOWN: 3
CMF tests summarizer wrote: Non-OK results -- [1]UNKNOWN FAILED (failures=7) : CMF-2.3 Zope-trunk Python-2.6.8 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-September/016701.html I guess the label is wrong: If this is using http://svn.zope.org/CMF/branches/2.3/buildout.cfg?rev=127672 , it is testing CMF-2.3 on Zope 2.13 branch, not on Zope trunk. [2]UNKNOWN FAILED (failures=7) : CMF-trunk Zope-trunk Python-2.6.8 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-September/016704.html [3]UNKNOWN FAILED (failures=7) : CMF-trunk Zope-trunk Python-2.7.3 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-September/016705.html All the failures are caused by Zope changes, see this thread: https://mail.zope.org/pipermail/zope-dev/2012-September/044791.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] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: Am 07.09.2012, 09:01 Uhr, schrieb yuppie y.2...@wcm-solutions.de: And I have a quick and dirty view implementation for local role/sharing. Reimplementing it based on formlib would be a lot of work, so maybe I should just check in my code. As I'm not even sure what it does I'd definitely suggest you check it in. Ok. I'd also be very interested in your skinless workaround. As luck would have it I was discussing CMF with someone and I think we should have it in the docs somewhere. Well. Basically it works out of the box. If you have a complete ZTK skin, you can delete the skins tool. The sites I converted just use the features that already have browser views in CMFDefault or customized browser views in my own code, so missing views like those for discussion were no problem. The biggest issue I had to fight with is the fact that zope.browserresource (or the Zope 2 specific version in Five) is much harder to use than static resources in a CMF DirectoryView. Some packages exist that try to provide better resources support, but I'm not aware of any package that resolves my issues. I really don't want to register each icon separately in zcml, but I want to be able to override single icons. And I want to have some control over the urls of the resources. I want files like 'robots.txt' and 'favicon.ico' in the root, other resources in subdirectories like 'images' or 'resources'. Currently I use browser:resourceDirectory to register one resources directory per layer, and a special view that walks through directlyProvidedBy(request).__iro__ to find the first layer that contains the requested resource. This is an expensive hack, but does what I need. I'm still fighting with HEAD and PROPFIND requests for resources. So far I wasn't able to figure out how ZTK handles these. The errors returned by Zope 2 are not useful. Some clients retry those requests several times because they interpret the errors as temporary. I would also like to add a quick install guide for anyone wanting to use CMFDefault as a springboard. Not sure what exactly you mean by springboard in this context. I didn't propose to pack all this in CMF 2.3. My list also contains the next steps after the release. Where is the list? I didn't mean a big list. Just the few steps I mentioned in the previous mail. 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 Laurence! Laurence Rowe wrote: On 5 September 2012 19:21, Laurence Rowe l...@lrowe.co.uk wrote: Instead of removing the RequestContainer, it could be replaced with a zope.globalrequest aware RequestContainer. That might be cleaner than rewrapping in individual utilities, and would work with Zope 2.13. I gave this a go in http://zope3.pov.lt/trac/changeset/127722/five.localsitemanager/branches/global-request-container It seems to work fine with the CMF trunk tests even when I remove all RequestContainer wrapping from both CMFCore and CMFDefault (the CMFDefault tests then fail with five.localsitemanage trunk.) http://zope3.pov.lt/trac/changeset/127724/Products.CMFCore/branches/global-request-container http://zope3.pov.lt/trac/changeset/127726/Products.CMFDefault/branches/global-request-container Nice! Unfortunately there's a trade-off: Modernizing the RequestContainer concept makes it possible to move forward in some areas without breaking existing code. That's a good thing. But on the other hand it makes it easy to write bad code. New code should not rely on this. People should write views if their code depends on the request, not utilities. I think this discussion is closely related to your plans for Zope 4: If Zope 4 will (re-)enable the get-request-by-acquisition pattern everywhere, it doesn't make much sense to be more restrictive in CMF 2.3 on Zope 2.13. Please consider providing tools for people who want to write clean code. Documentation, warnings, maybe even a switch for disabling the legacy behavior. 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] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: Am 05.09.2012, 09:07 Uhr, schrieb yuppie y.2...@wcm-solutions.de: The setup of your doctest looks fine, you just have to enable syndication for the folder (app.site) to get the view. Tests landed yesterday and I also ran them with the oldstyle implementation. Good. What is, in your view, missing from a final release? Laurence proposed some changes for the utilities: https://mail.zope.org/pipermail/zope-cmf/2012-September/030381.html If we agree that's the way to go, I'd like to have his changes in CMF 2.3 before the final release. All the other unfinished tasks can be deferred to CMF 2.4. The last beta was at the end of March so maybe it's time for another one to include all the formlib stuff you've worked on? I use CMF trunk in production, so I don't need a beta release. But it might be a good idea if other people want a beta 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] Security declarations on adapters
Hi Charlie! Charlie Clark wrote: * is there an easy way to write the test for something that requires a tool and some content? The setup of your doctest looks fine, you just have to enable syndication for the folder (app.site) to get the view. * backporting the changes to the PythonScript I hit a roadblock that I can't use security declarations on the adapter. Fortunately, I was able to use the tool as a workaround but, apart from ripping out the PythonScript, I can't think of a better solution. I think CMF 2.3 should ship with a complete oldstyle skin. So it would be nice if you could get this working. But I guess it will be the last release with the oldstyle skin as default. In the long run it will become unmaintained. Any ideas? I'm also struggling with a convenient way of handling the difference in time formatting arising form using native datetime and DateTime with it's convenient rfc822 method Removing DateTime completely has no high priority. If you need it as a formatting tool, just use it. 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! Charlie Clark wrote: Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver tsea...@palladion.com: I'd rather not add any cruft to support .zexp imports, which have seemed fundamentally broken to me for a long time. I'd agree on that. Occasionally, and on a strict, per object basis, they have their use but not at the same as updates. Or what do you have in mind? I use a single Zope instance for several small CMF sites and I use .zexp export and import for moving CMF sites from one Zope instance to an other. Works fine for me. Even with Plone sites. The nastiest part of the bootstrapping issue is the fact that without the fallbacks currently in place you can't navigate to the Setup Tool of a CMF 2.2 instance and run the upgrades. The ZMI folder listing calls code that depends on CMF tools. But fixing these issues is not on the top of my list. I just mentioned them for the sake of completeness. 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. getToolByName is no option because it is part of the machinery that should become obsolete. getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient. But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root. 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 Laurence! Laurence Rowe wrote: On 5 September 2012 11:48, yuppie y.2012-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: 2.) Site root lookup: = In several tools we still assume aq_parent(aq_inner(self)) is the portal. Or other code uses the tool as context object, expecting root and request in its acquisition chain. These should be identified and replaced by getUtility(IURLTool).getPortalObject() or other suitable code. Maybe we could add a convenience API for that? getToolByName can be used instead as it does the lookups. getToolByName is no option because it is part of the machinery that should become obsolete. getUtility(IURLTool).getPortalObject() might be overkill because it adds the request to the context. All the code that needs the request should be fixed already. Using queryUtility(ISiteRoot) should be sufficient. But AFAICS the only way to find all the places where this needs to be fixed is to set up a site with tools that are not stored in the site root. How about introducing a new getPortal() function? It could simply use getSite() then walk back down the acquisition chain until finding an object that directlyProvides ISiteRoot. In Plone KSS can introduce another 'component site' between its view and the portal itself. Not sure why the discussion takes this direction. My point was that several CMF tools/utilities might not work correctly if the site root is not their parent. The difficult part is not to look up the site root. The difficult part is to figure out where a lookup is required. I don't think relying on getSite() is a good idea. As you mention it doesn't always return the portal object. And the fact it is stored with the request in its context is just an accidental side effect. What would be the advantage compared to using getUtility(ISiteRoot)? 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! Charlie Clark wrote: Am 05.09.2012, 11:48 Uhr, schrieb yuppie y.2...@wcm-solutions.de: getToolByName is no option because it is part of the machinery that should become obsolete. Not sure that is should actually ever become obsolete. Much as I am in favour of the interface-based lookup, these tools are an essential part of the CMF. That's why getToolByName isn't marked as deprecated. I guess we will support it for a long time. But I wouldn't recommend to use getToolByName in new code. If we need getToolByName in CMF (and there are still some places where it is used), that's a sign that we haven't finished the 'tools as utilities' project. 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! Laurence Rowe wrote: On 5 September 2012 13:26, yuppie y.2012-E2EsyBC0hj3+aS/vkh9...@public.gmane.org wrote: I don't think relying on getSite() is a good idea. As you mention it doesn't always return the portal object. And the fact it is stored with the request in its context is just an accidental side effect. What would be the advantage compared to using getUtility(ISiteRoot)? While it's an accidental side effect, it is something we could make use of. Once I merge my parent pointers branch into Zope 4 (hopefully soon), RequestContainer wrapping is completely removed and all objects with __parent__ pointers to the Application root will always have their correct context (and be able to acquire the REQUEST.) This will allow getUtility(ISiteRoot) to function correctly, along with any other tools/utilities that have their __parent__ pointer set. The branch lives on a temporary repository at https://github.com/zopefoundation/Zope/tree/elro-parent-pointers, I expect some problems with CMF trunk following the removal of RequestContainer, but I hope to address these once I get it merged. I'll try and post a proper writeup of its state and how to make it run in the next few days. Great! Making the REQUEST attribute of the app object a shortcut for using globalrequest looks like a good BBB solution. But - this is still a Zope 2 (Zope 4) specific feature. I hope you don't plan to recommend using it in new code. A PendingDeprecationWarning might be useful to figure out which code is using that legacy feature. - that doesn't explain why you propose using getSite() instead of getUtility(ISiteRoot). - CMF 2.3 targets Zope 2.13 as primary platform. So we can't rely on Zope 4 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] [dev] tools as utilities
Hi! Laurence Rowe wrote: Precisely because CMF 2.3 targets Zope 2.13 - persistent local utilities returned by getUtility lack any sort of acquisition context in Zope2, so the result of getUtility(ISiteRoot) will return aq_base(portal), which is unlikely to be useful. getSite() instead returns the component site set as a thread local during traversal. Assuming that has an acquisition context including the portal then we have the portal object with its correct acquisition context so can call portal.absolute_url(). Another alternative would be to set the portal directly as a thread local during the traversal (just as setSite() is called) and clear it at the end of the request. Now I see your point. But - getUtility(IURLTool).getPortalObject() also returns the portal with a complete acquisition chain. - if tools are looked up as utilities, they don't have the request in their acquisition chain. That might cause trouble if Plone switches to CMF 2.3, but in CMF itself all code that tries to get the request by acquisition from a tool was fixed. That also means that tools depending on the portal as parent *don't* depend on a portal with request in the acquisition chain. So if this has to be fixed inside the tools, getUtility(ISiteRoot) is sufficient. 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
Laurence Rowe wrote: Maybe I'm missing something, but the various methods of IURLTool rely on portal.getPhysicalPath() returning the correct result. Take getRelativeContentPath for example: portal is at /folder/portal content is at /folder/portal/content getUtility(IURLTool).getPortalObject().getPhysicalPath() will be ['portal'] getUtility(IURLTool).getRelativeContentPath(content) will be ['porta', 'content'] instead of ['content'] You'd need to stop having any portals contained in folders, something that's fine for new sites but will prevent upgrades. Not sure who is missing something and what. Just a wild guess: Are you aware of the fact that five.localsitemanager just removes the RequestContainer, not the complete acquisition chain? And that CMF 2.3 adds a RequestContainer in getPortalObject()? 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.CMFDefault/trunk/ Add dependency on zope.app.locales.
Hi! Maurits van Rees wrote: Log message for revision 127521: Add dependency on zope.app.locales. [...] Modified: Products.CMFDefault/trunk/setup.py === --- Products.CMFDefault/trunk/setup.py 2012-08-18 16:05:00 UTC (rev 127520) +++ Products.CMFDefault/trunk/setup.py 2012-08-18 16:09:30 UTC (rev 127521) @@ -52,6 +52,7 @@ 'Products.MailHost', 'Products.PythonScripts', 'zope.formlib', + 'zope.app.locales', ], tests_require=[ 'zope.testing = 3.7.0', Is it really necessary to declare that dependency? AFAICS CMFDefault depends on zope.app.locales[extract], but only if used with z3c.recipe.i18n for extracting i18n messages. In production we don't need zope.app.locales and its dependencies. Maybe this could/should be declared in an extra if you want to be explicit? 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
CMF tests summarizer wrote: [1]UNKNOWN FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.8 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-August/016633.html This was caused by changes in zope.formlib 4.1. I added ignoreContext=True in CMFDefault to restore the old behavior. 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/branches/2.2/Products/CMFCore/ Add GenericSetup export/import support for type information action
Hi Ross! Ross Patterson wrote: Log message for revision 125311: Add GenericSetup export/import support for type information action descriptions. Two questions: - Why didn't you merge this into trunk? - Why didn't you add ZMI support for descriptions? 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: 2, UNKNOWN: 2
Hi Charlie! Charlie Clark wrote: Am 11.04.2012, 17:06 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: I can't reproduce the other failures. Thanks for looking. I'll do clean checkout and buildout and see if that makes any difference. I can reproduce the errors on CMF trunk with Zope trunk on Mac OS, Debian and FreeBSD. Today I saw these errors in one of my buildouts. I was able to fix them by improving the tear down in MembershipToolTests. Can you confirm this is fixed? 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: 2, UNKNOWN: 2
Hi Charlie! Charlie Clark wrote: Am 11.04.2012, 03:00 Uhr, schrieb CMF tests summarizer nore...@zope.org: [1] UNKNOWN FAILED (failures=1) : CMF-trunk Zope-2.13 Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016076.html [2] UNKNOWN FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016077.html I noticed this the other day but thought it might be related to my configuration. Even though I'm on Python 2.6.7 Failure in test test_parseHeadersBody_embedded_blank_line (Products.CMFDefault.tests.test_utils.DefaultUtilsTests) Traceback (most recent call last): File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py, line 279, in run testMethod() File /Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_utils.py, line 85, in test_parseHeadersBody_embedded_blank_line self.assertEqual( desc_len, 3, desc_lines ) File /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py, line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: ['this description spans multiple lines.'] This is weird because all of a sudden blank lines in headers are being treated as separators, as they should. Why wasn't the test failing earlier? It wasn't a blank line. You removed whitespace in rev 125119: Modified: Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py === --- Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:16:46 UTC (rev 125118) +++ Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:30:40 UTC (rev 125119) @@ -27,7 +27,7 @@ MULTIPARAGRAPH_DESCRIPTION = \ '''Description: this description spans multiple lines. - + It includes a second paragraph''' I can't reproduce the other failures. 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! Charlie Clark wrote: I suppose we could also migrate the old Zope Help docs to docs for Sphinx generation? I know much of the docs are inaccurate and outdated but this might help expose the worst bits which should then be exorcised or at least pruned. +1 Is CMFDefault/help now obsolete? Could it be deleted? Not sure if this would be for 2.3 but I think that CMFCalendar should be rolled into CMFDefault. The main reason being that the default profile for CMFCalendar uses browser views and explicitly requires the CMFDefault skin layer. You then can't use CMFCalendar if you override the default skin layer. Plus, CMFCalendar's functionality is extremely limited and intimately tied to CMFDefault. -1 CMFCalendar is an example add-on. It should be possible to write add-ons like CMFCalendar. So if there are any issues with keeping it in a separate optional package they should be fixed instead of giving 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] [dev] working on the trunk
Charlie Clark wrote: Am 04.10.2011, 10:55 Uhr, schrieb yuppiey.2...@wcm-solutions.de: 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] [dev] working on the trunk
Hi Charlie! Charlie Clark wrote: Am 30.09.2011, 10:55 Uhr, schrieb yuppiey.2...@wcm-solutions.de: 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
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] 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 yuppiey.2...@wcm-solutions.de: 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] CatalogTool as utility
Hi Hanno! Hanno Schlichting wrote: On Mon, Sep 19, 2011 at 3:56 PM, yuppiey.2011-E2EsyBC0hj3+aS/vkh9...@public.gmane.org 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
[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] cmf-tests - OK: 3, UNKNOWN: 1
Charlie Clark wrote: Am 23.08.2011, 07:00 Uhr, schrieb CMF tests summarizernore...@zope.org: [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] 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] 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
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] [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=120512view=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 yuppiey.2...@wcm-solutions.de:
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] 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] 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=120180view=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
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
[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] 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
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] 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] CMF 2.1 releases
Hi Charlie! Charlie Clark wrote: Am 22.09.2010, 14:31 Uhr, schrieb Jens Vagelpohlj...@dataflake.org: 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 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] 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=revrev=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
Re: [Zope-CMF] Test setup problems with Zope 2.13
Hi!
Hanno Schlichting wrote:
On Sat, Jul 24, 2010 at 3:26 PM, Hanno
Schlichtinghanno-+xqisr9sqhvsq35pwsn...@public.gmane.org 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] 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=113940view=markup http://svn.zope.org/Products.CMFDefault/trunk/Products/CMFDefault/browser/content/tests/test_image.py?rev=113947view=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] 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] 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 @@ metal:slot metal:fill-slot=body i18n:domain=cmf_calendar div metal:define-macro=calendarBox 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] Minor cleanup in browsers
Hi! Charlie Clark wrote: Am 21.04.2010, 12:57 Uhr, schrieb Charlie Clark charlie.cl...@clark-consulting.eu: 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
[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] More browser views
Hi! Charlie Clark wrote: Am 07.04.2010, 14:27 Uhr, schrieb yuppiey.2...@wcm-solutions.de: 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=110737view=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] 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 yuppiey.2...@wcm-solutions.de: 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] 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] 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] 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] [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] CMF 2.2.0-beta reminder
Hi Charlie!
Charlie Clark wrote:
Am 02.12.2009, 20:51 Uhr, schrieb yuppie y.2...@wcm-solutions.de:
-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:
adapter
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:
object name=Document
property name=add_view_exprstring:${folder_url}/newDoc/property
/object
object name=Folder
alias from=newDoc to=++add++Document/
/object
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
