Re: [Zope-CMF] Pending pull requests GenericSetup

[yuppie]

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

[yuppie]

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

[yuppie]

Hi Maurits,

Maurits van Rees wrote:
> Op 24-09-15 om 13:54 schreef yuppie:
>> 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.
> 
> I have updated my pull request to add that purgeProfileVersions method
> and to run this before running the import steps of a base profile.
> 
> See https://github.com/zopefoundation/Products.GenericSetup/pull/18

it looks a bit strange to have that new code inside the loop because
versions should only be purged once before applying the first profile in
the chain.

But I hope these assertions are true:

- a profile that depends on more than one base profile is broken anyway

- if there is a base profile in the chain, it is always the first in the
chain

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.
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.

Looking at that code, I think a better approach (but also much bigger
change) would be to make the version handling an extra export/import
step for metadata.xml. That would allow to export/import complete
profiles (the merged result from base and extension profiles) without
loosing version information.

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

[yuppie]

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

[yuppie]

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

[yuppie]

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

[yuppie]

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

[yuppie]

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

[yuppie]

Hi Maurits,

Maurits van Rees wrote:
> Someone has a site with profile hoopyfrood up to date.  He has no idea
> what this does, it was just applied as a dependency of another add-on.
> 
> He adds an addon with profile towel to the buildout config.  This
> requires a new version of the package that has profile hoopyfrood. Fine,
> he updates the version pins,  runs buildout and restarts the site.
> 
> He installs the towel add-on.

I didn't think this would be the normal procedure: Upgrading packages
just because a new add-on depends on new version of these packages. But
maybe I'm just not using as many add-ons as other people do.

> Old answer: no matter what the state of the hoopyfrood profile, we apply
> it.  This may be mostly harmless (I swear I did not plan this culture
> reference), but it does more than necessary and may be harmful in some
> cases.
> 
> My answer: apply the upgrade step of hoopyfrood.  Everybody happy.
> 
> Your answer: give an error, pointing to the Upgrades tab, telling him to
> run the upgrades of hoopyfrood first?  Then nothing happens.
> 
> Your answer may be fine when applying a profile in the ZMI, but then
> again, I have updated the pull request to give the user more options in
> the ZMI so that may be fine already.  So maybe you are happy with that
> already.

Your mail with the screen shot was delayed, so I didn't see it before I
wrote my reply.
X-Mailman-Approved-At: Fri, 11 Sep 2015 15:20:01 +0200
Did someone have to approve that manually?
Anyway: Looks like a tab that tries to make everybody happy. It's too
complex, but that's not your fault.

> From the point of view of existing code in add-ons that call
> runAllImportStepsFromProfile and expect it to maybe do too much but at
> least work, your answer would be a regression: either nothing is done or
> you get an exception.

I see: The old implementation of runAllImportStepsFromProfile wasn't
written with upgrades in mind, but obviously it did that job good enough
that people started to use it for that purpose. And it did that job bad
enough that you started to improve the implementation.

> BTW, the add-ons control panel in Plone 5 lists the available upgrades
> first, and then the installable new add-ons.  We could improve the ZMI
> similarly, like:
> - add a warning at the top of the Imports tab if there are upgrades
> - Show on the Upgrades tab which profiles actually have upgrades that
> need to be applied. Now I sometimes click through the entire list to
> check this.
> Maybe something for another pull request.
> 
> But, for me, this is not about how it works in the ZMI.  I am sure with
> some back and forth like this we can work something out.  It is mostly
> about: what happens when in code you do runAllImportStepsFromProfile
> with the default settings.
> 
> BTW 2, Plone 5 is still also using CMFQuickInstaller, but that is going
> the way of the dodo.  Slowly.

I didn't have a look at the Plone 5 control panel, but as you describe
it, something similar would be quite useful in the portal_setup UI. But
the Import tab has already too many options for rare use cases. It might
be better to add a new tab for importing add-ons.


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

[yuppie]

Hi Maurits,

Maurits van Rees wrote:
> Basically I am thinking: we used to reapply the entire profile, let's
> instead not do nothing at all, but meet halfway: run the upgrade steps.

in the beginning there were just base profiles. I added the concept of
extension profiles 10 years ago. Someone else added upgrade steps later.
Extension profiles were added to allow splitting up profiles in
different parts that are shipped with different products. Nobody ever
thought about how this should work with different profile versions and
upgrades.

> I guess we could add an extra option in the UI, making use of these new
> options.  The user already has the option 'Include dependencies' there,
> default Yes.  An extra option might be 'Apply upgrade steps of already
> applied profiles instead of reapplying them completely', with default
> Yes.  We might then need to make it possible to select all possible
> combinations of what I now made possible.  Danger is that it gets
> confusing for the end user (well, site admin).
> 
> Unrelated profiles should be left alone.  Possibly a method
> 'applyAllUpgradeStepsOfAllProfile' could be useful, with a big button on
> the Upgrades tab.  But not in this pull request.

The Import tab wasn't built with extension profiles and upgrade steps in
mind. It is not exactly the UI you expect for installing add-ons.

One issue you want to fix is this:

Someone installs an add-on on a site that has outdated configuration.
Because nobody warns him, he messes up the configuration of his site.

Your answer is: Don't bother him with this detail, I'm sure he wanted to
upgrade his dependencies first. I'll do that for him silently.

My answer is: His site is in a bad state if he didn't run the upgrades.
He should fix that before he starts installing add-ons.

> Basically I want to avoid that GenericSetup says "No, there is no
> profile with id X" and silently thinks "You should have asked me for
> profile-X instead, I have got that one lying around here just fine."
> 
> The 'profile-' and 'snapshot-' prefixes are still used.  Most methods
> only cared about 'profile-', but some of those expected the stripped id
> and others the id with the prefix.  I found that frustrating to deal with.
> 
> Some methods handle both 'normal' profiles and snapshots.  With my
> changes, these now have:
> - if profile starts with 'snapshot-': do A.
> - elif profile starts with 'profile-': do B.
> - else: same as 'profile-'
> 
> Is that clearer?

In other words: 'profile-' is the default prefix. All methods handle ids
without prefix the same way as ids with the default prefix. Correct?


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

[yuppie]

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] A Tale of Two Repositories

[yuppie]

Hi Tres,

Tres Seaver wrote:
> The CMF projects are in this state because one of the main developers is
> unwilling to participate in the project if it moves entirely to
> Github[2], but is willing to continue if a proposal is in place to
> maintain a second public repository, against which his contributions
> would be made[3].  This proposal aims to satisfy that request by hosting
> the second, synchronized repository for each project using the new
> Launchpad Git hosting option[4].

thanks for working on this issue. I'm not very happy about the proposed
solution because it makes the GitHub repository the primary repository
and the canonical location for bug reports. But compromises never make
everybody happy.

I'm happy about your proposal because it looks like a practicable
solution everybody can live with.

> 1) Create a Git repository from its Subversion history, and push that
>repository to Github;  this step will use the same scripts used for
>other ZF repositories.  E.g., the branches, tags, and trunk for
>``Products.CMFCore`` will be hosted on Github at
>https://github.com/zopefoundation/Products.CMFCore

There is one problem with the existing procedure: author information is
lost for contributers without GitHub account. I don't know if this is a
bug in the scripts or if the GitHub universe is a closed universe that
has no provisions for handling information about people existing outside.

Would be nice if this could be resolved. I consider it an unfriendly act
to remove my name from all my contributions just because I'm no customer
of GitHub Inc. And it makes history information less useful.

Please note https://github.com/zopefoundation/Products.GenericSetup
already exists, but is not in sync with the version in the Subversion
repository.

And please don't forget the dev buildouts in http://svn.zope.org/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: upgrade step ordering with newer setuptools

[yuppie]

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

[yuppie]

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] CMF on something git like? Was: Products.PluggableAuthService to github?

[yuppie]

Hi Patrick,

thanks for bringing this up!

Patrick Gerken wrote:
> is anybody against moving CMF to
> - gitlab.com
> - git repos on bitbucket.org
> - self hosted gitlab run by me?
> 
> If not, what are prefered options?

The Zope Foundation maintains the infrastructure used by the CMF
community and I have no ambitions to change that. So in the end it's a
decision of the Zope Foundation.

In the beginning moving to GitHub was optional and decided for each
project separately, but blocking write access for new contributers and
ssh keys makes it hard to use the old infrastructure. As a result only
GitHub Inc. customers can now become Zope contributers.

Here is my wish list:

A self hosted solution would be my preferred option. Something with a
zope.org URL and no other terms and conditions besides the Committer
Agreement. I would be happy to use GitLab run by you or any other
solution the Zope Foundation provides. If I can help to make this
happen, please let me know.

AFAICS GitLab B.V. is a better cooperation partner for open source
projects than Atlassian (bitbucket.org), but I might be wrong about that.

I guess to convince the Zope Foundation any proposal for a second git
repository has to include a concept for keeping both repositories in sync.


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] New release in 2.2 line?

[yuppie]

Matthew Wilkes wrote:
> I'd very much appreciate a release in the 2.2 series to make this code
> available to them (and others) without them having to pin their own
> release, what do others think?

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] DynamicType.portal_type

[yuppie]

Hi!


yuppie wrote:
> http://svn.zope.org/?view=rev&revision=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

Re: [Zope-CMF] authoritative copy of Products.GenericSetup

[yuppie]

Hi!


yuppie wrote:
> 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=rev&revision=130433 ?

Fixed the issue this way:

- synced the svn repository with the released code:
http://svn.zope.org/Products.GenericSetup/tags/1.7.5 contains now the
same files as https://pypi.python.org/pypi/Products.GenericSetup/1.7.5

- on CMF trunk I switched the Products.GenericSetup source back to svn

Please make Products.GenericSetup releases only from svn.zope.org or
discuss it on this list if you want to move the canonical repository
somewhere else.


Cheers,

Yuppie

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] DynamicType.portal_type

[yuppie]

Hi,

http://svn.zope.org/?view=rev&revision=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

[Zope-CMF] authoritative copy of Products.GenericSetup

[yuppie]

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=rev&revision=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

Re: [Zope-CMF] Products.CMFCore release

[yuppie]

Hi Jens!


Jens Vagelpohl wrote:
> 
> On Oct 15, 2013, at 9:09 , yuppie 
>  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

[yuppie]

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

[yuppie]

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=130319&view=rev

I fixed it here:
http://svn.zope.org/?rev=130321&view=rev

> - two others are failing:
> 
> 
> 
> 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

[yuppie]

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] member area / home folder changes

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> Am 01.08.2013, 11:46 Uhr, schrieb yuppie :
>> 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

[Zope-CMF] member area / home folder changes

[yuppie]

Hi!


Just want to explain the changes I made on CMF trunk.

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.

'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'.

For backwards compatibility I added two factories that are used if no
'Home Folder' portal type exists. 'cmf.folder.home.bbb1' is compatible
with the old CMFCore code, 'cmf.folder.home.bbb2' with the old
CMFDefault code. In that case the portal type of new home folders is
'Folder' as before.

The recommended factory is 'cmf.folder.home'. It no longer supports the
'createMemberContent' hook. It is now recommended to use a customized
factory instead. The two new portal types 'Members Folder' and 'Home
Folder' allow to customize factories and behavior.

For existing sites you can either switch to the new behavior by using
the two upgrade steps or just keep 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

[Zope-CMF] [dev] some small changes

[yuppie]

Hi!


I plan to work on the following changes. Please let me know if you have
questions or objections.


Fix dotted names of CMF interfaces:
===

CMF defines many interfaces, so we added some submodules like _content
and _tools. This was meant as a transparent implementation detail, it's
recommended to import from interfaces, not from the submodules. But
unfortunately the full path shows up in several places, e.g. on the
Interfaces tab you see Products.CMFCore.interfaces._content.IFolderish
instead of Products.CMFCore.interfaces.IFolderish.

GenericSetup has a special _getDottedName() method that tries to find
the short version. This hides the issue in profile exports.

AFAICS this could be fixed by setting __module__ explicitly for each
interface, e.g. for IFolderish

__module__ = 'Products.CMFCore.interfaces'

Is this the right approach or will this cause new trouble?


Add 2 new portal types for member areas in CMFDefault:
==

- 'MemberArea' will be a special folder type that uses the normal Portal
Folder class, but a different factory that replaces parts of the
createMemberArea() method. And a different default view that replaces
the 'index_html' Document currently added by createMemberArea().

- 'Members' will be a special folder type that uses the normal Portal
Folder class, but limits sub-items to 'MemberArea' objects and has a
special default view that replaces the 'index_html' DTML Method
currently added to the members folder.


Simplify content views in CMFDefault:
=

- remove registration and lookup of "schema adapters" (e.g.
DocumentSchemaAdapter, LinkSchemaAdapter). Use these adapters directly
in getContent().

- rename '@@view.html' to '@@view', '@@properties.html' to
'@@properties' and so on. This allows to remove some method aliases.


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

[yuppie]

Hi!


Charlie Clark wrote:

Am 13.05.2013, 10:06 Uhr, schrieb yuppie :


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

Re: [Zope-CMF] [dev] CMFDefault: renaming type action urls

[yuppie]

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:
  (for all types)

in a profile for old-style skins:
  (for Document)
  (for File)
  (for Image)
  (for Link, Favorite)
  (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

[Zope-CMF] [dev] CMFDefault: renaming type action urls

[yuppie]

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] Move to github?

[yuppie]

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] Move to github?

[yuppie]

Hi!


Martin Aspeli wrote:

On 2 March 2013 16:18, yuppie
mailto:y.2013-E2EsyBC0hj3+aS/vkh9...@public.gmane.org>> wrote:

Yes. I have objections.

I'd like to keep contributing to CMF. But I'm not going to support
GitHub Inc. by using its services


Seriously?


Yes.


You do realise it's:

  a) free (for us)
  b) decentralised


What do you mean by "it"? What by "free"? What is "decentralised"? Why 
do your points a) and b) make supporting GitHub Inc. a good decision?


GitHub Inc. is too successful. It already has too much power. That's not 
good for the open source community.



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?

[yuppie]

Hi!


Hanno Schlichting wrote:

Stephan Richter has volunteered to do SVN to Github conversions for all Zope
projects and has already completed all of Zope 2 "core" and some actively used
projects like five.localsitemanager.

Does anyone have objections if I ask him to convert the CMF packages?


Yes. I have objections.

I'd like to keep contributing to CMF. But I'm not going to support 
GitHub Inc. by using its services.



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?

[yuppie]

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

[yuppie]

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

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 07.09.2012, 09:01 Uhr, schrieb yuppie :

 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] Security declarations on adapters

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 07.09.2012, 09:01 Uhr, schrieb yuppie :


[-] means that we don't want/need to convert this
[?] means that we still have to decide if and how this should be
converted
[/] means unfinished


Regarding RSS: you've written

[/] ISyndicatable @@rss.xml (not hooked up):

- [x] RSS.py -> rss.View
- [x] RSS_template.pt -> rss.pt
- [?] rssDisabled.pt

What do you mean by not hooked up? There's not an appropriate action but
the template is configured. As syndicatability is determined by a marker
interface I don't think we need to have a disabled view for it.


Maybe there are better words for this. It's not really relevant at the 
moment. I have plans to use the same todos for the related changes in 
profiles or code that links to the views. It just means that no Action 
or code in CMFDefault links to the RSS feed, so there is nothing that 
needs to be updated.


I'm fine with not providing a disabled view.

BTW: If scripts or templates like TitleOrId.py show up in different 
contexts, that doesn't have to be a mistake. I did this if I expect 
they'll become part of different views instead of sharing one 
implementation.



Cheers,

Yuppie

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Security declarations on adapters

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 06.09.2012, 16:24 Uhr, schrieb yuppie :

 There are the (incomplete) todo lists for browser views. I'd also
like to revisit the names we did choose for the views and make them
the default target of Actions.


hm, I drew up the lists from the existing Scripts/Templates and thought
it was complete. I've just checked again and can only find the following
as not done:

- [?] viewThreadsAtBottom.pt (structure)
- [?] talkback_tree.pt (macros)
- [?] setup_talkback_tree.py
- [?] discitem_delete.py


I have additional data, but still have to verify it and merge it into 
the CMF trunk todos. Just updated the todo for 'content' and added one 
for 'skins'.


[-] means that we don't want/need to convert this
[?] means that we still have to decide if and how this should be converted
[/] means unfinished

Some of the issues mentioned in 'content' might now belong into 
'discussion'. Please update the todos according to your changes.


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.



I thought we'd agreed not to make them the default for this release but
remove the "experimental" label from the profile. Personally, I would
like to see them as the default, not least because they nearly all have
coverage. But, we shouldn't be packing too much into a single release.
Maybe because you work with trunk you notice less?


I didn't propose to pack all this in CMF 2.3. My list also contains the 
next steps after the release.



 Off the top of my head:
correcting the docs.
 There are also duplicate DCWorkflow docs. Someone has to figure out
if the old .stx docs are redundant and obsolete.


There are equivalents for all .stx as .rst. I thought I had moved the
files over but apparently not. I don't know what to do about the
examples. But the .stx files can go.


You moved the docs to the new place, so why didn't/don't you remove the 
obsolete files yourself?



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

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 06.09.2012, 13:11 Uhr, schrieb yuppie :

 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.


Unless something downstream is dependent on these kind of changes I
don't see any reason to including them at this late stage.


These changes provide better backward compatibility for code using CMF 
tools/utilities and better forward compatibility for running CMF on Zope 
4. (*If* the proposed changes become part of Zope 4.)


We don't have to wait for the Zope 4 release, just for the decision 
about the changes and for a five.localsitemanager release. Some small 
changes I made for CMF 2.3 don't play nice with the changes Laurence is 
working on.



 All the other unfinished tasks can be deferred to CMF 2.4.


Do we have a list of these unfinished tasks?


There are the (incomplete) todo lists for browser views. I'd also like 
to revisit the names we did choose for the views and make them the 
default target of Actions.


As soon as we have a complete replacement for the oldstyle skins I'd 
like to move those skins into a separate legacy package.


(I recently removed the complete skins tool from some of my CMF 
instances. That depends on a few hacks, but works quite well.)


We also should consider moving the skins tool and the directory view 
code into a separate package. That code has some dependencies that were 
removed from Zope 2 (Zope 4) and are not required for sites without 
skins tool. In the long run I have no ambitions to maintain that code 
and its dependencies.



Off the top of my head:
correcting the docs.


There are also duplicate DCWorkflow docs. Someone has to figure out if 
the old .stx docs are redundant and obsolete.



I'd also like to see at least minimal support for a WYSIWYG editor for
HTML-text fields. Not sure if this should be part of CMF or a standalone
formlib addition because of the external dependencies.


Some day I want to switch to z3c.form which has more add ons. I wouldn't 
spend too much time on formlib specific 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] Security declarations on adapters

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 05.09.2012, 09:07 Uhr, schrieb yuppie :


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] [dev] tools as utilities

[yuppie]

Hi Laurence!


Laurence Rowe wrote:

On 5 September 2012 19:21, Laurence Rowe  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] [dev] tools as utilities

[yuppie]

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] [dev] tools as utilities

[yuppie]

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

[yuppie]

Hi!


Laurence Rowe wrote:

On 5 September 2012 13:26, yuppie 
 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

[yuppie]

Hi!


Charlie Clark wrote:

Am 05.09.2012, 11:48 Uhr, schrieb yuppie :

 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

[yuppie]

Hi Laurence!


Laurence Rowe wrote:

On 5 September 2012 11:48, yuppie 
 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

[yuppie]

Hi!


Charlie Clark wrote:

Am 04.09.2012, 15:35 Uhr, schrieb Tres Seaver :


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] Security declarations on adapters

[yuppie]

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

[Zope-CMF] [dev] tools as utilities

[yuppie]

Hi!


In CMF 2.3 (beta) all core tools can be looked up using getUtility for 
mandatory tools or queryUtility for optional tools. That's a big step 
forward, but there are still some places where we depend on tool 
characteristics:



1.) Bootstrapping:
==

Importing .zexp files or upgrading old sites some tools are used before 
they are registered as utilities.


Currently there are fallbacks in place that use the old tool lookup. I 
guess some events need to be disabled for .zexp imports.



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.



3.) Action providers:
=

Action providers are still registered and looked up by ID.

Most Actions were moved to the Actions Tool. Only two 2 special Action 
providers are left: Types Tool and Workflow Tool.


I have no plans to convert that registry to something based on utility 
lookup. I guess it would be better to create specialized 'object' and 
'workflow' categories that are linked to the Types Tool and the Workflow 
Tool. But that's a different story.



4.) Skins:
==

The Skins Tool lookup is based on the getSkinsFolderName method.

If there are no objections, I'll replace that by 
queryUtility(ISkinsTool) without providing any backward compatibility 
code for getSkinsFolderName.



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

[yuppie]

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.CMFDefault/trunk/ Add dependency on zope.app.locales.

[yuppie]

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] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/ Add GenericSetup export/import support for type information action

[yuppie]

Hi Ross!


Ross Patterson wrote:

On Fri, Apr 27, 2012 at 2:58 AM, yuppie  wrote:

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?


Because, I'm not at all familiar with trunk and thought it was best
left to someone who knows what's happening on trunk.


Who exactly is "someone"? When is "someone" working on this?


- Why didn't you add ZMI support for descriptions?


Because I was adding support for GenericSetup import/export.


In CMF all settings that can be changed by import steps can also be 
inspected and modified TTW. It's confusing if the Actions have 
additional settings that are invisible 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] SVN: Products.CMFCore/branches/2.2/Products/CMFCore/ Add GenericSetup export/import support for type information action

[yuppie]

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

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 11.04.2012, 17:06 Uhr, schrieb Charlie Clark
:


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

[yuppie]

Hi Charlie!


Charlie Clark wrote:

Am 11.04.2012, 03:00 Uhr, schrieb CMF tests summarizer :


[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

[yuppie]

Hi!


Jens Vagelpohl wrote:


On Apr 9, 2012, at 23:10 , Charlie Clark wrote:


Am 22.03.2012, 13:28 Uhr, schrieb 
yuppie:


The tools are *local* utilities. Including the ZCML doesn't fix this issue. You 
have to run the upgrade step.


Should we add a warning to CMFTools.utils.getToolByName? To use getUtility and 
the interface instead?



Just a general remark: The last time we added a warning to getToolByName it had 
to be taken back out. The protest was too big. No one wanted to spend the time 
on all the third-party packages that still use that API. What's worse, back 
then even the CMF packages were not switched to a pure utility model and would 
emit these warnings as well.


AFAICS the only thing we need to do for backwards compatibility is using 
registerToolInterface. So it isn't urgent to deprecate and remove 
getToolByName.


It might be useful to write a howto for people who want to modernize 
their code.



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

[yuppie]

Hi!


Charlie Clark wrote:

I finally landed my update step for syndication during the PyCon
sprints! I thought I had a few more browser views to update to using the
EditSettingsForm but on a quick check of the files it seems that this
has already been done. Yuppie, I remember that you have commented out
some of my views (portal configuration and membership, I think) because
of the encoding problem, did you correct them yourself last year and I
was simply looking at old source?


Working on my tool and member data changes I touched some of your forms. 
Maybe I fixed all the known issues. But I didn't review all new forms 
systematically.



If that is the case then I think we're good to go with 2.3.


No objections. Today I finished the cleanups I wanted to make before new 
branches are created.



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

[yuppie]

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] 2.3

[yuppie]

Hi!


Charlie Clark wrote:

I'm testing with some existing sites and getting the following error
even before I run the upgrades:

ComponentLookupError: (, '')

I'm obviously missing a registration but my site includes
Products.CMFCore package.


The tools are *local* utilities. Including the ZCML doesn't fix this 
issue. You have to run the upgrade step.


It should be possible to use the ZMI without this kind of errors. In 
some places I added fallbacks like this one:


try:
utool = getUtility(IURLTool)
except ComponentLookupError:
# BBB: fallback for CMF 2.2 instances
utool = aq_get(self, 'portal_url')

If you can't run the upgrades from the ZMI it might be necessary to add 
more fallbacks in CMF.



HTH,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Towards a 2.3 Release

[yuppie]

Hi!


Charlie Clark wrote:
> * apparently the "absolut" skin can cause problems with used in
> combination with profiles. Yuppie, do you have any more information on
> this?

Not sure what you mean. I had some problems getting rid of oldstyle 
skins completely (including main_template), but that is not what the the 
"absolut" skin does. I gave up after a short try, so I can't provide any 
further details.

> * the views only profile is no longer experimental. I would like to be
> able to make this a base profile (with the "absolut" skin) but have hit
> problems with CMFCalendar requiring the standard CMFDefault skin

-1 for adding a second base profile

We can do the same as in CMFCalendar: Use views in the default profile 
and provide an extension profile for people who want to switch back to 
oldstyle skins.

I propose to do this step by step. We have views with different levels 
of maturity: Some exist for a while and are battle proofed. Others are 
new without any real world testing. Each view should be reviewed if it 
is ready for becoming default.

> In Berlin we decided against a beta but I would actually like to test my
> existing sites against a new version, so a beta would probably be a good
> idea.

I'm fine with a beta *if* that brings additional testing and feedback 
before the final release.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] working on the trunk

[yuppie]

Charlie Clark wrote:
> Am 04.10.2011, 10:55 Uhr, schrieb yuppie:
>>> Regarding zope.annotation - IAttributeAnnotatable creates a new object
>>> within the folder
>> Why do you think so? AFAICS the default implementation stores all
>> annotations in the __annotations__ attribute.
>
> Running some tests with the most recent version and it definitely creates
> child objects that are visible in the ZMI. I guess I need to test this a
> bit more but I suspect I might have to provide my own implementation.

Strange! Your container implements IAttributeAnnotatable and 
AttributeAnnotations is registered correctly?

Are you trying to use zope.annotation.factory? Last time I checked that 
didn't work with Zope 2. But the AttributeAnnotations adapter works for 
me without showing anything in the ZMI.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] working on the trunk

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> Am 30.09.2011, 10:55 Uhr, schrieb yuppie:
>
>>
>> AFAICS only the getUpdateBase method of ISyndicationTool needs to be
>> backwards compatible. Everything else is new API or doesn't return
>> DateTime objects. Wouldn't it be better to use datetime internally? You
>> already need an upgrade step for SyndicationInformation. Writing an
>> additional upgrade step for SyndicationTool wouldn't be much extra work.
>
> ISyndicationInfo is a new interface. I'm tempted to use zope.schema
> directly on this but I suppose that does tie any implementation to
> zope.schema rather maybe annotated Python tyes. Thoughts?

I think in general it's fine to use zope.schema for CMFCore interfaces. 
But if you use properties instead of separate accessors and mutators, 
you can't set different read/write permissions in Zope 2. So please make 
sure modifying the settings is protected sufficiently.

> Regarding zope.annotation - IAttributeAnnotatable creates a new object
> within the folder

Why do you think so? AFAICS the default implementation stores all 
annotations in the __annotations__ attribute.

> but I'd rather not have the SyndicationInfo visible
> within the ZMI but IAnnotations only uses a dictionary and so less
> suitable for storing multiple values. If I go the AttributeAnnotatable way
> is it okay to use Persistent rather than SimpleItem as long as
> manage_fixupOwnershiAafterAdd is provided? Or is that too kludgy and
> preferable to work on my current adapter to provide attribute access to an
> Annotations dictionary?

Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] working on the trunk

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> I've hit a bit of a problem with folder syndication - I already have an
> annotations adapter for storing the values on the folder and I can extend
> this to be able to handle individual values rather than a dictionary but
> ProxyFieldProperties don't work because the adapter itself doesn't support
> properties. I also have some additional methods on the adapter that I use
>   from the view. What do you think is the best way to proceed here? Subclass
> the SchemaAdapter so that the encoding and DateTime stuff works okay? For
> the methods I don't see any alternative but to expose the annotations
> adapter explicitly within the view. Bit of a muddle, I guess.

If you want to modernize SyndicationInformation, why do you still store 
DateTime objects in the database? (And why don't you use zope.annotation?)

Quoting the docstring of schema.py: "SchemaAdapterBase and 
ProxyFieldProperty are legacy code. They should only be used to adapt 
old content types that can't handle unicode and datetime correctly."

AFAICS only the getUpdateBase method of ISyndicationTool needs to be 
backwards compatible. Everything else is new API or doesn't return 
DateTime objects. Wouldn't it be better to use datetime internally? You 
already need an upgrade step for SyndicationInformation. Writing an 
additional upgrade step for SyndicationTool wouldn't be much extra work.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] working on the trunk

[yuppie]

Charlie Clark wrote:
> SettingsEditFormBase landed after my sturm and drang work last year. So
> you generally replace my explicit calls to tools with getContent? I guess
> I just need some proxyFields for enabling and disabling.

Yes.

> I still need to set view.adapters = {} for some reason but that's okay.

zope.formlib expects that setUpWidgets is always called before 
handle_change. If you test handle_change isolated, you have to set 
adapters by hand.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] working on the trunk

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> Am 27.01.2011, 17:05 Uhr, schrieb yuppie:
>
>> zope.formlib is not made for DateTime values and encoded strings. So you
>> *always* have to make sure these values are converted correctly. And it
>> is hard to do that inside the form code. Obviously you did have trouble
>> to get it right that way. After I started using adapters for the edited
>> objects I had much less trouble using formlib. Of course you don't need
>> an adapter if your objects already provide the right interface.
>
>> And one more benefit: Inside the form code you can completely ignore the
>> old-fashioned implementation of the edited objects and write nice modern
>> code.
>
> Finally have made the time to look at this. I've written a schema adapter
> for the forms and it looks like SettingsEditForm handles the conversion to
> Zope's DateTime nicely. Now, I'm stuck with the problem of getting my view
> unit tests to work. Looks like I need a few adapters registered. :-/

SettingsEditFormBase has a getContent() method similar to that in 
z3c.form. This allows a clean distinction between 'content' and 
'context'. For content objects they are usually the same, but in your 
case the site root is the context and the (adapted) SyndicationTool is 
the edited "content".

Please have a look at the membership views. They show how to use 
getContent(). In your case the method would look like this:

 @memoize
 def getContent(self):
 syndtool = getUtility(ISyndicationTool)
 return SyndicationToolSchemaAdapter(syndtool)

This example uses a hardcoded adapter. You can still register it and 
look it up, but I guess that's overkill. I doubt anybody wants to use a 
customized adapter. And if it is hardcoded, you don't need to register 
it for testing ;)


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Switching to Chameleon

[yuppie]

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] CatalogTool as utility

[yuppie]

Hi!


Hanno Schlichting wrote:
> On Wed, Sep 21, 2011 at 1:57 PM, 
> yuppie  wrote:
>> I plan to use zope.globalrequest as fallback if self.REQUEST is not
>> available.
>>
>> What's the best approach for the five.globalrequest dependency? Just use
>> zope.globalrequest if it is available? Or specify it in extras_require?
>> Or add it to install_requires, making it an indirect dependency of the
>> next Zope 2.13 release?
>
> Adding it to the setup.py of what project?

I meant Products.ZCatalog.

> I consider using zope.globalrequest as a feature change - primarily
> because its interaction with tests is a bit unclear. Introducing more
> module global state for the request variable will probably lead to
> some changes to test isolation code somewhere.
>
> So in Zope itself, this can only go into trunk. For CMF 2.3, I'd just
> put it as a hard dependency into install_requires.

Ok. Products.CMFCore trunk already has a hard dependency.

My checkin for Products.ZCatalog has an optional dependency on 
five.globalrequest. If five.globalrequest is not installed, 
Products.ZCatalog behaves exactly as before. I hope we don't need a 
Products.ZCatalog 2.14 release for that. Zope 2.13 can use it without 
five.globalrequest.

See http://svn.zope.org/?rev=122892&view=rev

Is that ok? Should I add an explicit extra in the setup.py of 
Products.ZCatalog?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] CatalogTool as utility

[yuppie]

Hi!


Hanno Schlichting wrote:
> On Tue, Sep 20, 2011 at 12:19 PM, 
> yuppie  wrote:
>> But an additional ZCatalog branch is an additional maintenance burden.
>> And the required change is small and 100% backwards compatible. The
>> zope.globalrequest dependency could be made optional.
>>
>> Do we really need an extra ZCatalog branch for that?
>
> If there's a completely backwards compatible way of doing, we should do that.
>
> I was under the impression, that we had to do an API change for some
> methods and add a new request argument to those. If that argument is
> required depending on how the tool was retrieved, that's confusing to
> me and I'd rather go the zope.globalrequest route.

I no longer consider modifying ICatalogBrain. The big advantage of using 
zope.globalrequest is that we can move forward without discussing API 
changes.

I plan to use zope.globalrequest as fallback if self.REQUEST is not 
available.

What's the best approach for the five.globalrequest dependency? Just use 
zope.globalrequest if it is available? Or specify it in extras_require? 
Or add it to install_requires, making it an indirect dependency of the 
next Zope 2.13 release?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] CatalogTool as utility

[yuppie]

Hi Hanno!


Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 3:56 PM, 
> yuppie  wrote:
>> But with zope.globalrequest we can avoid modifying the API. So if it is
>> fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might
>> be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?
>
> I meant ZCatalog 2.14 only for CMF.
>
> Having independent distributions allows us to evolve them at a different pace 
> :)

But an additional ZCatalog branch is an additional maintenance burden. 
And the required change is small and 100% backwards compatible. The 
zope.globalrequest dependency could be made optional.

Do we really need an extra ZCatalog branch for that?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] CatalogTool as utility

[yuppie]

Hi!


Hanno Schlichting wrote:
> On Mon, Sep 19, 2011 at 11:57 AM, 
> yuppie  wrote:
>> Currently CMF trunk contains some hacks to work around the catalog brain
>> issues. But I hope there is a better solution. Maybe the ICatalogBrain
>> methods getURL, _unrestrictedGetObject and getObject should have a
>> REQUEST argument that is used instead of self.REQUEST?
>>
>> Any kind of feedback and help is welcome.
>
> Mmh, why don't we just use zope.globalrequest in ZCatalog directly?
> And create a new ZCatalog 2.14 release series with this. Then we don't
> have to wait for Zope 4.0 to include it.

Using an explicit argument is always cleaner than using 
zope.globalrequest. And getObject() already has a (currently unused) 
REQUEST argument. And we might be able to provide a migration path for 
the API change: If we don't use registerToolInterface, we don't have to 
change getObject/getURL calls in places where we still use getToolByName.

But with zope.globalrequest we can avoid modifying the API. So if it is 
fine to smuggle a zope.globalrequest dependency in Zope 2.13, that might 
be the better solution. Or did you mean to use ZCatalog 2.14 only in CMF?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] [dev] CatalogTool as utility

[yuppie]

Hi!


Converting the CatalogTool is not so easy because it is just a small 
subclass of ZCatalog. And ZCatalog expects REQUEST in its acquisition 
context.

AFAICS the only place where this causes trouble is the 
AbstractCatalogBrain API. But I might be missing other issues. Maybe 
some people can test CMF trunk with their code? Is there a Plone branch 
that is tested against CMF trunk?

Currently CMF trunk contains some hacks to work around the catalog brain 
issues. But I hope there is a better solution. Maybe the ICatalogBrain 
methods getURL, _unrestrictedGetObject and getObject should have a 
REQUEST argument that is used instead of self.REQUEST?

Any kind of feedback and help is welcome.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] tools as utilities

[yuppie]

Hi!


Jens Vagelpohl wrote:
> On Sep 12, 2011, at 11:52 , yuppie wrote:
>> I propose to use 'five.globalrequest' instead of self.REQUEST inside
>> tools. AFAICS that allows to convert *all* tools into utilities.
>
> Why would you want to add a dependency for 3 lines of code? All that package 
> does is register a 1 line event handler. I'd rather do that in the CMF itself.

Because it provides an API that is also used and maintained by other 
people. Plone 4.1 depends on it.

> IMHO the "cleaner" way would be to make sure the request object is explicitly 
> passed into any code that needs it.

Sure. But that requires either API changes in the tools or new view 
code. The last 4 years nobody did work on this because it is much more 
work than 'just' converting tools to utilities.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] [dev] tools as utilities

[yuppie]

Hi!


5 years ago we started converting CMF tools into local utilities, and we 
are still stuck in the middle of that task.

The problem is that local utilities don't have REQUEST in their 
acquisition chain. A few tool methods use self.REQUEST and the plan was 
to replace these methods by view code. But that never happened. So these 
tools and all tools depending on these tools are still not converted.

I propose to use 'five.globalrequest' instead of self.REQUEST inside 
tools. AFAICS that allows to convert *all* tools into utilities.

What do you think?


Cheers,

Yuppie

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] cmf-tests - OK: 3, UNKNOWN: 1

[yuppie]

Charlie Clark wrote:
> Am 23.08.2011, 07:00 Uhr, schrieb CMF tests summarizer:
>
>> [1]UNKNOWN FAILED (failures=16, errors=13) : CMF-trunk Zope-trunk
>> Python-2.6.6 : Linux
>> https://mail.zope.org/pipermail/cmf-tests/2011-August/015153.html
>
> This one is beyond my feeble powers. It looks like all the doctests are
> failing.
>
> Charlie

Zope trunk is broken, it has similar failures and errors:

https://mail.zope.org/pipermail/zope-tests/2011-August/048589.html

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMF - changed property modes to 'w' and added 'fullname' property

[yuppie]

Wichert Akkerman wrote:
>> Log message for revision 122395:
>> - changed property modes to 'w' and added 'fullname' property
>
> Would it make sense to make this a unicode property instead of a string
> property?

We use string properties in many places. I don't think it's worth the 
trouble to do it differently in just one place:

- Plone uses string for 'fullname'

- If we add a 'fullname' Python property to IMemberData, it can still 
return the decoded value. In CMF 2.3 IMemberData objects are just 
adapters and the property values are stored somewhere else.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] member data - a small proposal

[yuppie]

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

[Zope-CMF] [dev] member data - a small proposal

[yuppie]

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] RFC: Removing svn:externals from buildouts

[yuppie]

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.

[yuppie]

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

[yuppie]

Hi!


Charlie Clark wrote:
> Am 22.02.2011, 11:46 Uhr, schrieb yuppie:
>> 2.) direct MemberData property access
>> -
>> Wrapped users are now MemberAdapter objects. So wrapped users no longer
>> have attributes like 'email' or 'listed'. This is a security improvement
>> because you can't bypass the API with its permission checks.
>> But 'member.email' is more convenient than 'member.getProperty('email')'
>> and used in many places. I fixed these in CMF itself, it I'm afraid that
>> change will break a lot of third party code.
>> I propose to add read-only properties that return the values in a modern
>> format (datetime instead of DateTime, unicode instead of encoded
>> strings).
>
>> Question:
>> Should we support a fixed schema with the default member data properties
>> or should we use a customized __getattr__ method?
>
> If the access is always via the adapter then I would prefer a customised
> __getattr__

I'm still not sure how to resolve this.

MemberAdapter objects are used in untrusted code and it might be 
complicated to set permissions correctly for __getattr__ access. (At 
least I never tried that.)

It also would be nice to have a well defined interface for default 
member properties.

So I tend to a fixed schema. People still can add custom properties, but 
they would have to use getProperty or override MemberAdapter.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] [dev] wrapping users - a proposal

[yuppie]

Hi!


yuppie wrote:
> I propose to split this up into a persistent MemberData object that is
> just used for storing member data and a new non-persistent MemberAdapter
> that provides all the methods currently provided by MemberData objects.

Done: http://svn.zope.org/?rev=120512&view=rev


There are two new issues caused by that change:


1.) MemberData factory lookup
-

CMF 2.2 has a new feature that allows to register customized MemberData 
factories: https://bugs.launchpad.net/zope-cmf/+bug/377208

That feature seems to be obsolete in CMF 2.3 because the MemberAdapter 
is now responsible for creating MemberData objects and AFAICS using 
customized MemberData with an un-customized MemberAdapter doesn't make 
much sense.

Because CMF 2.3 will anyway break customized MemberData implementations 
I propose to remove the factory lookup completely in CMF 2.3.


2.) direct MemberData property access
-

Wrapped users are now MemberAdapter objects. So wrapped users no longer 
have attributes like 'email' or 'listed'. This is a security improvement 
because you can't bypass the API with its permission checks.

But 'member.email' is more convenient than 'member.getProperty('email')' 
and used in many places. I fixed these in CMF itself, it I'm afraid that 
change will break a lot of third party code.

I propose to add read-only properties that return the values in a modern 
format (datetime instead of DateTime, unicode instead of encoded strings).

Question:

Should we support a fixed schema with the default member data properties 
or should we use a customized __getattr__ method?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF Tests: 6 OK, 1 Unknown

[yuppie]

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

[Zope-CMF] [dev] wrapping users - a proposal

[yuppie]

Hi!


MemberData objects are currently persistent objects for storing member 
data *and* wrappers for user objects.

I propose to split this up into a persistent MemberData object that is 
just used for storing member data and a new non-persistent MemberAdapter 
that provides all the methods currently provided by MemberData objects.

MemberAdapter would be a multi-adapter for IUser and IMemberDataTool. 
self.__parent__ would be the user folder.


Pros:

- The member objects can easily be customized without replacing 
persistent MemberData objects.

- Users from different types of user folders can get different adapters. 
No MemberData objects are needed if the user (or user folder) can store 
the member properties. (Adapted is the user, so the user's interface has 
to indicate the capabilities of the user folder).

- For some methods like changeOwnership() AccessControl expects that the 
parent of a user is the user folder. MemberAdapter will have the same 
parent as the original user object.

- There is no need to migrate persistent objects.


Cons:

- The API of customized MemberData objects will no longer be available. 
The customized API has to be moved to a new adapter.

- Code that expects the user object or the member-data tool in the 
aquisition chain of members will no longer work.

- Code that bypasses setProperties/setMemberProperties and getProperty 
methods of members will no longer work.


If there are no objections or better ideas, I'll implement that on the 
trunk. IUser is only available in Zope 2.13.2+, so I'll have to make 
that Zope version required for CMF trunk.


Cheers,

 Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode

[yuppie]

Alan Runyan wrote:
> just for record, having the behavior makes development a complete nightmare. 
> adding an additional environment variable is probably best way.

I hope this resolves the issue:
http://svn.zope.org/?rev=120180&view=rev

If someone knows a better way to detect NTFS, please let me know.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode

[yuppie]

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

[yuppie]

yuppie wrote:
> AFAIK this is primarily a file system issue, not an operating system
> issue. 'Last modified' time is updated on NTFS, but not on FAT32.
>
> Not sure what we need to support: I guess everybody is working with
> Windows versions that support NTFS, but maybe some people still develop
> on FAT32 partitions.

DebugModeTests have been disabled by default. Now I see 3 errors on 
FAT32 and one error on NTFS:

Error in test test_DeleteAddEditMethod 
(Products.CMFCore.tests.test_DirectoryView.DebugModeTests)
Traceback (most recent call last):
   File "...\Python26\lib\unittest.py", line 279, in run
 testMethod()
   File 
"...\src\Products.CMFCore\Products\CMFCore\tests\test_DirectoryView.py", 
line 290, in test_DeleteAddEditMethod
 self.assertEqual(self.ob.fake_skin.test2(),'test2.2')
AttributeError: test2

Someone has to figure out if this can be fixed without using the old 
code for NTFS as well.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/ Removed os.path.walk call in windows development mode

[yuppie]

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] [dev] working on the trunk

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> Am 26.01.2011, 16:50 Uhr, schrieb yuppie:
>
>> I'm not happy with the current state of CMF trunk. Especially the
>> syndication related changes cause trouble in different ways:
>> - SyndicationInformation was replaced by SyndicationInfo without
>> providing migration code. Local syndication settings get lost in
>> existing sites.
>> - In the ZMI the SyndicationTool no longer has a tab that allows to
>> inspect and modify tool settings. The form that replaces the ZMI tab is
>> broken: It uses datetime objects instead of DateTime objects and mixes
>> them with existing DateTime settings.
>> Last week I reviewed parts of the new code and fixed some small issues.
>> But the bigger issues still exist. Based on what I encountered I wrote
>> this small guide:
>> http://svn.zope.org/*checkout*/CMF/trunk/CODINGSTYLE.txt
>> Please keep the the trunk stable and use your own branch for unfinished
>> changes.
>
> I think this applies almost entirely to my work on browser views. Yuppie's
> been in touch with me privately but I haven't found time to do the tidying
> up.
>
> I agree with nearly all the points. I'm not certain that SchemaAdapters
> are always necessary.

zope.formlib is not made for DateTime values and encoded strings. So you 
*always* have to make sure these values are converted correctly. And it 
is hard to do that inside the form code. Obviously you did have trouble 
to get it right that way. After I started using adapters for the edited 
objects I had much less trouble using formlib. Of course you don't need 
an adapter if your objects already provide the right interface.

And one more benefit: Inside the form code you can completely ignore the 
old-fashioned implementation of the edited objects and write nice modern 
code.

> In my defence I hope it's worth noting that we now
> have tests for a heap of stuff in CMFDefault which previously didn't exist.
>
> Regarding SyndicationInfo - I'd appreciate any pointers on writing a
> migration step. Given the hopelessly outdated state of the current
> implementation I'm not convinced anyone will need to do the migration

What was wrong with the old implementation? I never had trouble using 
the old configuration objects and forms. The old RSS template didn't 
work for me, but that's a different issue.

> but
> then, of course, one of the aims of CMFDefault is to provide exactly this
> kind of example.

I'm sure I'm not the only one who has existing CMF sites with 
SyndicationInformation objects in it. Making sure these sites can be 
upgraded without trouble is essential. And not a nice to have extra. 
Especially if the old implementation did work and the new one doesn't 
provide any new features.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] [dev] working on the trunk

[yuppie]

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

[yuppie]

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

[yuppie]

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] CMF dev buildouts

[yuppie]

Hi!


Godefroid Chapelle wrote:
> I even added the missing buildout (copied from trunk - see revision 119553).

You know http://svn.zope.org/CMF/branches/2.2/ and 
http://svn.zope.org/CMF/trunk/ ?

These buildouts are used for developing and testing all CMF Products. Do 
we also need bootstrap and buildout files on each branch of each 
Product? Who is using and maintaining them?


Cheers,

    Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF Tests: 4 OK, 3 Unknown

[yuppie]

CMF Tests Summarizer wrote:
> Subject: UNKNOWN : CMF-trunk Zope-2.12 Python-2.6.5 : Linux
> From: CMF Tests
> Date: Mon Dec 27 01:36:23 EST 2010
> URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014001.html
>
> Subject: UNKNOWN : CMF-trunk Zope-2.13 Python-2.6.5 : Linux
> From: CMF Tests
> Date: Mon Dec 27 01:38:23 EST 2010
> URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014002.html
>
> Subject: UNKNOWN : CMF-trunk Zope-trunk Python-2.6.5 : Linux
> From: CMF Tests
> Date: Mon Dec 27 01:40:23 EST 2010
> URL: http://mail.zope.org/pipermail/cmf-tests/2010-December/014003.html

This is the traceback:
> Running /usr/local/python2.6/bin/python ./bin/test
> Traceback (most recent call last):
>   File "./bin/test", line 20, in 
> import zope.testrunner
> ImportError: No module named zope.testrunner

I updated the testrunner version. This no longer works:

   /usr/local/python2.6/bin/python ./bin/test

Should now be:

   /usr/local/python2.6/bin/python -S ./bin/test

or just:

   ./bin/test

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Trouble adding a new site

[yuppie]

Charlie Clark wrote:
> Am 08.12.2010, 14:48 Uhr, schrieb yuppie:
>
>> In line 59 you just have a bare CMFSite object without any tools.
>
> Hi Yuppie,
>
> thanks for the quick reply. How come I don't have any tools? Is this
> related to more recent buildouts not magically including Products.* stuff?
> Products.CMFDefault (2.2.0) is installed.

No. Have a look at the addConfiguredSite function: It first adds a bare 
CMFSite object, then adds the setup tool and importing the profile that 
adds the types tool is the last step. Your event handler just tries too 
early to look up the tool.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] Trouble adding a new site

[yuppie]

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] Bug in i18n-cmfdefaultextract?

[yuppie]

Charlie Clark wrote:
> ImportError: No module named PythonScripts.PythonScript
>
> This is, of course, humbug:
>
> fuchsia:CMF charlieclark$ bin/zopepy
>>>> from Products.PythonScripts.PythonScript import PythonScript

Zope 2.14 doesn't ship with Products.PythonScripts. 'zopepy' was fixed, 
'i18n-cmfdefault' not.

But now everything should work again.

Ciao, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

[Zope-CMF] CMF dev buildouts

[yuppie]

Hi!


I started moving the dev buildouts from CMF.buildout to CMF.
(see https://mail.zope.org/pipermail/zope-cmf/2010-August/029284.html)

If you are using CMF.buildout/trunk or 
CMF.buildout/branches/zope212-cmf23, please switch to CMF/trunk and let 
me know if it causes any trouble.

My goal is to have *one* branch for each CMF version. (Except of CMF 
2.1, which has also a non-buildout branch.) I think we have always a 
primary target platform that is used for development (e.g. Zope trunk 
for CMF trunk). And some additional supported platforms that are just 
used for running tests (e.g. latest Zope 2.12 release for CMF trunk). 
AFAICS it is sufficient to have additional cfg files instead of 
additional branches for the additional platforms.

If that concept works for everybody, I'll migrate the rest of the 
CMF.buildout branches.

BTW: CMF/trunk has some txt files with "OLD_" as prefix. AFAICS about 
20% of their content is still useful, so I did not delete them. But it 
would be nice if someone would clean them up.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF 2.1 releases

[yuppie]

Hi Charlie!


Charlie Clark wrote:
> Am 22.09.2010, 14:31 Uhr, schrieb Jens Vagelpohl:
>
>> Are there any outstanding issues or blockers that need resolving or can
>> I go ahead and publish the new releases?
>
> While I'd like my fixes to CMFDefault/browser/folder.py to be in as soon
> as possible, I'm planning to get some more stuff over the next few days.
> Can we wait until next Wednesday (bug day?)

Are you sure you want to make these changes in CMF 2.1? Jens is not 
talking about CMF 2.2 or trunk.


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF vs. CMF.buildout

[yuppie]

Hi Jens!


Jens Vagelpohl wrote:
>> I can't see any additional burden caused by the proposed change.
>
> The burden will appear when people are told or get the impression that
> the package represents the official sanctioned buildout for the CMF as
> opposed to being a developer convenience :-)  It's a matter of
> communication. Think of someone who doesn't have a clue and sees a
> package named "CMF". What are they going to think?

I guess they will think exactly the same as they think right now if they 
see the package named "CMF.buildout". If they have no clue, the 
".buildout" will make no difference for them.

"CMF.buildout" sounds like it would be "the official sanctioned buildout 
for the CMF". How should they know it is a developer convenience?


Cheers,

Yuppie
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Re: [Zope-CMF] CMF vs. CMF.buildout

[yuppie]

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