[Zope-CMF] Re: setSecurityProfile

[yuppie]

Hi Florent!
Florent Guillaume wrote:
I'll be changing MemberData.setSecurityProfile to use 
user._doChangeUser() instead of hitting the attributes directly, if 
nobody sees a problem with that.
Why not userFolderEditUser()?
Shall I also change this in 1.4 branch ?
You are aware of the rules? If you change that branch, you are 
responsible for the 1.4.9 release.

Cheers,
    Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup comments

[yuppie]

Hi Florent!
Florent Guillaume wrote:
- all in all it's quite nice,
Well. It works for some use cases, but there is yet a lot to be done. 
Though its maturity is still alpha, it already contains a lot of cruft.

- writing the code for the import handler is really painful, I wish we 
could use an API like elementtree. Couldn't we include it ?
Could you please elaborate on this? What are the most painful parts? Why 
are they painful? Are you talking about the import handlers themselves, 
the configurator classes or also about export handlers?

The framework doesn't dictate how import handlers are implemented. Did 
you try to write an import handler using ElementTree?

I never used ElementTree, but after looking at the documentation I doubt 
it would be very helpful: ConfiguratorBase.parseXML() converts types, 
sets defaults and maps keys. If we use ElementTree we have to do that in 
an extra step.

- I like and will use the recently added EXTENSION,
Seems some people started experimenting with this feature and didn't 
report any showstoppers, so if there are no objections I'll backport the 
changes into the 1.5 branch.

Of course this is just a first step. E.g. we need a way to specify and 
handle dependencies between profiles.

- has anyone used CMFSetup to import/export content space instead of 
configuration space ?
- really, what about including elementtree ?
+1 if it makes things much easier, -1 if not. I like the fact that CMF 
only depends on Zope.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup comments

[yuppie]

Hi Florent!
Florent Guillaume wrote:
On 3 Apr 2005, at 17:27, yuppie wrote:
Florent Guillaume wrote:
- all in all it's quite nice,

Well. It works for some use cases, but there is yet a lot to be done. 
Though its maturity is still alpha, it already contains a lot of cruft.

Yes, I think I'll be doing some cleanups in it if you don't object.
Go ahead!
And probably apply 
http://www.artima.com/weblogs/viewpost.jsp?thread=101968 to the code in 
general... I really have a problem with Tres's style ;)
Discuss that with Tres ;)
- writing the code for the import handler is really painful, I wish 
we could use an API like elementtree. Couldn't we include it ?

Could you please elaborate on this? What are the most painful parts? 
Why are they painful?

Finding how to write the import mapping.
I have to admit it is not well documented.
For instance I have this stucture:


  
label_members
members
[... more properties ...]
  
  
python:entry_id == 
user_id
  

I would use this structure instead:


  label_members
  members
  [... more properties ...]
  python:entry_id == 
user_id


But I'll explain it for your example.
Which I parse using:
def _getImportMapping(self):
return {
'directory': {
'kind': {},
'properties': {KEY: 'props'},
'entry-local-roles': {KEY: 'elrs', DEFAULT: ()},
To get rid of the intermediate [0], use
'properties': {KEY: 'props',
   CONVERTER: self._convertToUnique},
'entry-local-roles': {KEY: 'elrs', DEFAULT: ((),),
   CONVERTER: self._convertToUnique},
Currently the converter is called after setting the default. I guess it 
would be better not to call the converter in that case.

},
'properties': {
'property': {KEY: 'properties'},
To get rid of the intermediate ['properties'], use
'property': {KEY: None},
},
'entry-local-roles': {
'entry-local-role': {KEY: 'elr'},
To get rid of the intermediate ['elr'], use
'entry-local-role': {KEY: None},
},
'entry-local-role': {
'role': {},
'#text': {KEY: 'expr'},
},
}
And I have to do:
dir_info = dconf.parseXML(dir_text)
dir = tool.manage_addCPSDirectory(dir_id, dir_info['kind'])
for prop_info in dir_info['props'][0]['properties']:
dconf.initProperty(dir, prop_info)
dir._postProcessProperties()
for elr in dir_info['elrs']:
elr = elr['elr'][0]
Did this work? I would have expected a line like this:
for elr in dir_info['elrs'][0]['elr']:
And with the changes proposed above this should work:
for elr in dir_info['elrs']:
res = dir.addEntryLocalRole(elr['role'], elr['expr'])
All the intermediate [0] and ['elr'] are cruft I'd like to get rid of. 
Maybe it's because I don't know how to use it best...
My comments are untested, but I hope they are helpful anyway. See 
rolemap.py for a similar example.

Are you talking about the import handlers themselves, the configurator 
classes or also about export handlers?

I have a question about a pattern used in the configurator classes: many 
times I saw the pattern than only one configurator was instanciated, for 
instance TypeInfoConfigurator, and then in the loop the ZPT called by 
passing, for instance:
   tic.generateXML( type_id=type_id )
and the ZPT itself passes back type_id to getTypeInfo. Why not simply 
have the configurator instanciated once per type, with the type itself 
as an attribute ? Is it just old cruft ?
Don't have strong feelings about that. But the change you propose seems 
to make it easier to implement the next step: Using different 
configurators for different TypeInfo classes.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] failing tests and other unit test issues

[yuppie]

Hi!
1.) CMFStaging tests
For a while now, I see 6 CMFStaging tests failing. Can anybody confirm 
they are broken? Does anybody use CMFStaging and knows how to fix these 
tests?

2.) test_DiscussionReply.py
- while most test modules include tests for a corresponding module of 
the product, these are tests for a single collector issue

- the tests are not really unit tests, more something like integration tests
- they don't work with Zope 2.8
- they are not included in test_all.py
- AFAICS there are other tests that cover the related collector issue
Anybody wants to fix these tests for Zope 2.8? If not, I'd like to 
remove them.

3.) Zope 2.8 warnings
'Zope2' is not available in Zope 2.7 and 'Zope' is deprecated in Zope 
2.8. Same with 'transaction' and 'get_transaction'.

Has anybody a better idea to resolve it than this way:
http://cvs.zope.org/Products/CMFCore/tests/base/testcase.py.diff?r1=1.11&r2=1.12
If not, I'll use that pattern for other files and the 1.5 branch as well.
Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Lennart Regebro wrote:
3.) Zope 2.8 warnings
'Zope2' is not available in Zope 2.7 and 'Zope' is deprecated in Zope
2.8. Same with 'transaction' and 'get_transaction'.
Has anybody a better idea to resolve it than this way:

Well, the deprecation procedures and warning is there to tell you that
you are using a way that works no, but will stop working later. The
standard pattern when you need to support both the version where they
are deprecated, and the version where they are not, is to do
nothing... And then when you no longer need to support the older
version, you move up to the new non-deprecated API.
These deprecation warnings produce *a lot of* noise. All I want is to 
reduce that noise.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Hi Florent!
Florent Guillaume wrote:
yuppie  <[EMAIL PROTECTED]> wrote:
3.) Zope 2.8 warnings
'Zope2' is not available in Zope 2.7 and 'Zope' is deprecated in Zope 
2.8. Same with 'transaction' and 'get_transaction'.

Has anybody a better idea to resolve it than this way:
[...]
I was thinking of:
try:
import transaction
except ImportError:
# BBB: for Zope 2.7
class BBBTransaction:
def begin(self): get_transaction().begin()
def commit(sub=False): get_transaction().commit(sub)
def abort(sub=False): get_transaction().abort(sub)
transaction = BBBTransaction()
And just use transaction.begin() everywhere in the code.
I like that idea and plan to use it with two small modifications:
1.) fixing the bugs in BBBTransaction ;)
2.) adding BBBTransaction to CMFCore.tests.base.utils and using this in 
tests:

try:
import transaction
except ImportError:
# BBB: for Zope 2.7
from Products.CMFCore.tests.base.utils import transaction
Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Hi Florent!
Florent Guillaume wrote:
yuppie  <[EMAIL PROTECTED]> wrote:
2.) test_DiscussionReply.py
- while most test modules include tests for a corresponding module of 
the product, these are tests for a single collector issue

- the tests are not really unit tests, more something like integration tests

Well there are lots of those in CMF anyway, no ?
True.
- they don't work with Zope 2.8
- they are not included in test_all.py

Note, test_all.py should not be used anymore. bin/zopectl test is the
way to go.
I'd rather see those being removed than getting out of sync. They are 
not part of the API, so I don't think we need a long warning period.

- AFAICS there are other tests that cover the related collector issue
Anybody wants to fix these tests for Zope 2.8? If not, I'd like to 
remove them.

If what's tested there is also tested elsewhere, why not...
I'm not sure about that. But there are 2 DiscussionTests that check the 
talkback wrapper, and AFAICS missing wrappers were the problem of 
http://www.zope.org/Collectors/CMF/318

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Sidnei da Silva wrote:
| 2.) adding BBBTransaction to CMFCore.tests.base.utils and using this in 
| tests:
| 
| try:
| import transaction
| except ImportError:
| # BBB: for Zope 2.7
| from Products.CMFCore.tests.base.utils import transaction

Why not just import from CMFCore.test.base.utils straight?
Good question ;)
All I know is that
- CMF uses that pattern in all test files
- 'Products.CMFCore.foo' seems to work with any testing setup
- with my setup 'CMFCore.foo' doesn't work if I run tests outside test.py
Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup configurators

[yuppie]

Florent Guillaume wrote:
CMFSetup.utils.ConfiguratorBase seems to be used as a single base class 
for both import configurators and export configurators. But it seems to 
me that the methods are either for import or for export, never both. I'd 
like to split it in two classes.
There are only configurators. Not import configurators and export 
configurators.

But if you want to split them all, I have no objections.
Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Sidnei da Silva wrote:
| Good question ;)
| 
[...] 

Sorry, I meant instead of the try: except, just import from
Products.CMFCore.tests.utils as there's another try:except in there.
Also a good question ;)
1.) I just want to add the except part to utils, not the try/except
2.) I prefer to see the correct import in each file and to use utils 
just for the fallback.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup comments

[yuppie]

yuppie wrote:
To get rid of the intermediate [0], use
'properties': {KEY: 'props',
   CONVERTER: self._convertToUnique},
'entry-local-roles': {KEY: 'elrs', DEFAULT: ((),),
   CONVERTER: self._convertToUnique},
Currently the converter is called after setting the default. I guess it 
would be better not to call the converter in that case.

FYI: I changed that on HEAD and CMF-1_5-branch. A less cryptic
   DEFAULT: ()
should work now.
Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [Performance] "listFilteredActionsFor" unnecessarily expensive

[yuppie]

Hi Alec!
Alec Mitchell wrote:
This is duplicated in CMFPlone as well, so it can be removed there too.  I 
think the purpose of this may have been to eliminate duplicate actions 
defined in different action containers (so that one could e.g. override an 
object action defined sitewide with one defined on a type).
The order of Action providers determines in which order 
listFilteredActionsFor() returns the Actions. Using the same order for 
overriding behavior doesn't make much sense to me.

But of course 
this check does not actually do that, or apparently anything useful.  
Removing it sounds like an excellent idea.

It would be nice if two actions with the same id and category from different 
action containers did not result in duplication, but the method is slow 
enough as it is.
What would be better than returning both? Maybe raising an error?
If you ask me, the fact that you can define duplicate Actions is a bug, 
not a feature.

CMF HEAD (1.6) has one central Action provider (not yet for all Actions) 
that should be used by all products. Instead of shipping with a tool 
that has predefined Actions, products should ship with a CMFSetup 
extension profile that defines the Actions in an XML file. Conflicts 
between Actions have to be resolved on set-up time, not when 
listFilteredActionsFor() is called.

Cheers,
    Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

Re: [Zope-CMF] Re: [dev] failing tests and other unit test issues

[yuppie]

Dieter Maurer wrote:
yuppie wrote at 2005-4-4 20:59 +0200:
...
2.) I prefer to see the correct import in each file and to use utils 
just for the fallback.

But, then you get a nasty "try: ... except:" in hundred of
files rather than just a single one.
Eight files in CMF, not hundreds of files for 'import transaction'.
It's a different story for 'import Zope2'. All unit test files would 
need a nasty try/except and 'import Zope' makes much less noise than 
'get_transaction()'.

So I'll leave them as they are, at least for now.
Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup profile extensions dependencies

[yuppie]

Hi Florent!
Florent Guillaume wrote:
I'd like to discuss possible improvements to have profile extensions 
check some dependencies. This will require a way to express 
dependencies, which in the general case can be extremely complex -- but 
we probably don't need that.
[...]
Just some general thoughts for now:
1.) In the long run, I'd like to get rid of preconfigured FTIs, tool 
settings and DCWorkflow definitions. All of them should be replaced by 
profile fragments. To avoid redundant profile data, bigger profiles like 
'CMFDefault:default' should depend on these fragments.

Given the potential complexity of dependencies an XML file in the 
profile directory might be a better place for these specifications.

2.) The current CMFSetup implementation merges the selected profiles. 
You can't tell from the result which profiles it contains. Even if we 
keep record of the used profiles - the specific combination and further 
customizations may break working dependencies. So adding extensions 
later based on dependencies would not work.

This means we either have to reload all dependencies if we add 
extensions later or to limit the use cases to new site scenarios.

It might be useful to have a 'show all' option in the UI for adding new 
sites that allows to combine arbitrary profiles. The specified 
dependencies can just be a set of recommendations, advanced users need a 
way to experiment with other combinations.

3.) I propose to use version numbers for profiles. And to use these 
numbers or a range of numbers to specify dependencies.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMF 1.5.1 release schedule

[yuppie]

Jens Vagelpohl wrote:
Just as a heads-up:
I would like to release a second beta (1.5.1beta2) this coming weekend. 
If no serious bugs are found, the final version (to be released 1-2 
weeks later) should not be much different from the beta.

To help this process, once 1.5.1beta2 is out I would like to restrict 
checkins to the CMF-1_5-branch until the final CMF 1.5.1 version is 
released. Only serious bugs or bugs uncovered as part of the beta cycle 
should be checked in between 1.5.1beta2 and 1.5.1 final. Once 1.5.1 
final is out the "normal" rules apply, meaning "no big feature changes 
on the maintenance branch" and "need to be fully backwards compatible 
across minor releases".

Just as Andreas has done with Zope itself, I want to champion a more 
ordered and timely release schedule. This implies that no one will have 
to scramble getting their favorite bug fixes into the CMF before a 
release because it was never clear when the next release came.

Action item for the active developers: Please comment if you see a 
problem with this schedule or the changed release philosophy.
+1
But just to make it explicit:
For CMFSetup the "normal" rules are not suitable. CMFSetup is not as 
mature as the other packages and we still have to change it in 
fundamental ways. Though these changes might not always be fully 
backwards compatible, I believe we should keep merging them into the 
CMF-1_5-branch.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMF 1.5.1 release schedule

[yuppie]

On Apr 11, 2005, at 21:41, Gregoire Weber wrote:
- Florent criticized once that th OpaqueItem stuff loops over all
  attributes of an object on copy/move/delete operations: Instead of
  checking *all* attributes for the ``ICallableOpaqueItem`` interface
  I'd like to just check for attributes registered in a property of
  CMFDefault's PropertyTool.
It does feel wrong that you have to register OpaqueItem attributes to 
make them work correctly. I'd rather like to see a solution similar to 
that for Zope 3 annotations: Storing all opaque items in one attribute.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] anybody using TypesTool._checkViewType?

[yuppie]

Hi!
TypesTool._checkViewType was added for a feature that never worked, see:
http://www.zope.org/Collectors/CMF/114
So unless someone invented an other use case for it, it's just cruft. If 
there are no objections, I'd like to remove it before CMF 1.5.1b2 is 
released.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] anybody using portal_workflow.getActionsFor or WorkflowInformation?

[yuppie]

Hi!
AFAICS ActionProvider.listActionInfos makes 
portal_workflow.getActionsFor obsolete. And WorkflowInformation is just 
used by getActionsFor.

So I'd like to add a deprecation warning on the Zope-2_7-branch and to 
remove them on HEAD/CMF 1.6. (Or in CMF 1.7, if some people are actually 
using them.)

Any objections?
Cheers,
    Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: test failures

[yuppie]

Tres Seaver wrote:
Hmm, if I remove the 'test_all' fossil on the 1.4 branch, and run the
tests using 'bin/zopectl test', all is well -- the tests are actually
failing the second time through, when somebody has stomped on the
'DummyFTI' instance imported from 'Products.CMFCore.tests.base.dummy'.
Would anyone be torqued if we removed all the 'test_all' shims from the
CMF 1.4 branch?  All they are doing now is making it take longer to run
tests, and potentially creating testing bugs.
Note that backporting the test_all.py changes from CMF 1.5 would also 
resolve this issue.

AFAIR Zope 2.6 doesn't ship with test.py and testrunner.py doesn't work 
for the CMF. So people might have trouble running tests on Zope 2.6 
without all_cmf_tests.py.

But *if* all_cmf_tests.py and test_all.py are obsolete on the 1.4 
branch, I can't see why we should keep them on CMF-1_5-branch and HEAD.

Just my 2 cents. Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: test failures

[yuppie]

Hi Tres!
Tres Seaver wrote:
Thanks for clarifying.  Just to double check: these are your changes
from almost a year ago (2004/04/26), right?  I will apply them to the
1.4 branch.
Yes. But 'all_cmf_tests.py' now has to run 'suite' instead of 
'test_suite', so these two related changes are also necessary:

modifying build_test_suite():
http://cvs.zope.org/CMF/CMFCore/tests/base/utils.py.diff?r1=1.2&r2=1.3
and calling it with suite_name='suite':
http://cvs.zope.org/CMF/all_cmf_tests.py.diff?r1=1.9&r2=1.10
I would fix it myself, but I no longer have a CMF-1_4-branch sandbox ;)
Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] listFilteredActionsFor performance

[yuppie]

Hi!
Recently there was some discussion about listFilteredActionsFor performance:
http://mail.zope.org/pipermail/zope-cmf/2005-April/022110.html
and I noticed Tres was experimenting with some CMF 1.5 modifications:
http://mail.zope.org/pipermail/cmf-checkins/2005-April/006014.html
http://mail.zope.org/pipermail/cmf-checkins/2005-April/006015.html
These are my observations:
The time spent in listFilteredActionsFor heavily depends on the specific 
usage of Actions:

- number and kind of Action providers
- number of Actions
- number of expressions
- number of workflow definitions
- anonymous or authenticated users
- size of the site
So it's hard to measure performance. But in general most time is spent 
in expressions and in the WorkflowTool. Within the WorkflowTool, 
worklists are by far the most expensive Actions.

Can anybody confirm these observations?
@Tres: Do you have different results? Were you able to improve the 
performance significantly?

Cheers,
    Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] listFilteredActionsFor performance

[yuppie]

Hi Tres!
Tres Seaver wrote:
yuppie wrote:
[...] Within the WorkflowTool,
worklists are by far the most expensive Actions.

... because they involve catalog queries.  We could perhaps optimize
that query via a dedicated TopicIndex for the 'review_state' portion.
Sounds like a good idea. I guess the news box could also benefit from a 
TopicIndex.

On the other hand there are other issues with worklists:
- They are defined per workflow, but are often not workflow specific. 
This leads to duplicate worklists and removing the duplicates makes 
workflow definitions depend on each other.

- They are the most complex Actions and I'm afraid most of its features 
are YAGNI.

Maybe instead of using Actions CMFDefault should have a box like the 
news box to show worklists?

  - The MembershipTool has ridiculously expensive expressions for its
actions.  I added two new top-level names to the Expression
namespace, 'member_folder' and 'member_url', which made the
expressions both cheaper (the bypass some redundant security
checking) and simpler (therefore cheaper as well).
Looks like a trade-off: If the site uses member folders the related 
Actions are cheaper. But if not, computing these values is waste of time.

  - The action providers all manufacture their own expression contexts,
which might be a hotspot.
Sorry for the confusing implementation. But the fact expression contexts 
are not passed to the action providers does not mean they are 
manufactured again and again. getExprContext() calls createExprContext() 
only once and caches the result.

BTW: Just in case you want to work on ActionInformation.ActionInfo: The 
CMF HEAD version of ActionInfo is quite different, using a new Action 
interface. Maybe those changes should be backported to CMF 1.5 before 
you try to optimize the 1.5 code.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: Products/CMFCore - CMFCatalogAware.py:1.21.2.9

[yuppie]

Hi Florent!
Florent Guillaume wrote:
Update of /cvs-repository/Products/CMFCore
In directory cvs.zope.org:/tmp/cvs-serv9874/CMFCore
[...]
-ob = self.unrestrictedTraverse(brain_path, None)
+# Get the object
+if hasattr(aq_base(brain), '_unrestrictedGetObject'):
+ob = brain._unrestrictedGetObject()
+else:
+# BBB older Zope
Using 'BBB' should become part of the CMF checkin rules. But why didn't 
you add the Zope version? 'Older Zope' is not very useful if you grep 
for backwards compatibility cruft that can be removed.

Cheers, Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: Products/CMFCore - PortalContent.py:1.47.2.1

[yuppie]

Hi Jens!
Jens Vagelpohl wrote:
Update of /cvs-repository/Products/CMFCore
In directory cvs.zope.org:/tmp/cvs-serv23261/CMFCore
Modified Files:
  Tag: CMF-1_5-branch
	PortalContent.py 
Log Message:
- CMFTopic.Topic/CMFCore.PortalContent: Both these classes were using
  the now-deprecated CMFCore.utils._getViewFor method, and strangely
  enough the deprecation warning didn't show. Replaced with the
  new method of getting the view.
Maybe the deprecation warning didn't show up because the method was 
never called?

The first implementation of Method Aliases did never call objects 
directly. __call__ was only used for backwards compatibility if no alias 
was specified.

Before the release of CMF 1.5.0 I changed the Method Aliases machinery 
and now in some situations the object is called directly, but forgot to 
update __call__ on the 1.5 branch. So this needs to be fixed, but in a 
different way.

=== Products/CMFCore/PortalContent.py 1.47 => 1.47.2.1 ===
--- Products/CMFCore/PortalContent.py:1.47	Thu Aug 12 11:07:39 2004
+++ Products/CMFCore/PortalContent.py	Thu May  5 16:53:32 2005
@@ -95,22 +94,22 @@
 return "%s %s" % (self.Title(), self.Description())
 
 def __call__(self):
-'''
-Invokes the default view.
-'''
-view = _getViewFor(self)
-if getattr(aq_base(view), 'isDocTemp', 0):
-return view(self, self.REQUEST)
+""" Invokes the default view.
+"""
+view_id = self.getTypeInfo().queryMethodID('view')
+view_obj = self.unrestrictedTraverse(view_id)
+
+if getattr(aq_base(view_obj), 'isDocTemp', 0):
+return view_obj(self, self.REQUEST)
 else:
-return view()
+return view_obj()
 
There are two issues with this checkin:
1.) It implements different behavior than CMF HEAD
2.) It breaks backwards compatibility
I propose to use the code from HEAD and the _getViewFor code as fallback 
in case no '(Default)' alias is defined.

Cheers,
Yuppie
___
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [CMF-checkins] CVS: Products/CMFCore - DirectoryView.py:1.47.2.7

[yuppie]

Chris Withers wrote:

Florent Guillaume wrote:


+warn('DirectoryView %s refers to a non-existing path %s'
+ % (self.id, dirpath), UserWarning)



Urg. I hate the warn module, anyone object if I change that to a normal 
logging call?


Can you please tell us *why* you hate it? warnings.warn is used in many 
places, so if there is a good reason not to use it other code should be 
changed as well.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] basic Five support - a small proposal

[yuppie]

Hi!


There is already the CMFonFive project, but now that Zope 2.8 ships with 
Five I'd like to see basic Five support in CMF itself:



1.) Zope3 style interfaces (similar to what exists in CMFonFive)

2.) a five_template that bridges Five slots to those available in the 
main_template (similar to that in CMFonFive)


3.) a base class for Five content:
The PortalContent class does not implement everything required in 
CMFDefault. AFAICS at least some DublinCore methods are missing. We 
could either add a subset as in PortalFolder or use the complete 
DefaultDublinCoreImpl.



These first steps can be done without breaking Zope 2.7 compatibility. 
I'd like to start with this on the HEAD and backport it to the 1.5 
branch as soon as it is mature enough.


Any comments?


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] basic Five support - a small proposal

[yuppie]

Hi!


Lennart Regebro wrote:

On 5/24/05, yuppie <[EMAIL PROTECTED]> wrote:


There is already the CMFonFive project, but now that Zope 2.8 ships with
Five I'd like to see basic Five support in CMF itself:



Well you have a point. I see some options:

1. Moving CMFonFive to Zope corps CVS and simply shipping it with the
next version of CMF.

2. Moving the things that are in CMFonFive into CMFCore.


Moving CMFonFive to the CMF repository might make sense. But I don't 
think it is mature enough to be shipped with the CMF distribution or to 
be integrated into CMFCore.


And while CMF interface definitions really don't belong into an add-on 
product, there is nothing wrong with shipping additional tools and 
TypeInfo classes in separate products.



3. Moving just some parts, and thereby still requireing CMFonFive for
any reasonably CMF integration, and hence gaining very little. ;)


Maybe we first have to discuss what we want to gain with Five support.

My goal is to use Five technology for features CMF doesn't provide or 
that could be significantly improved by using Five. I'm sure there are 
other areas where CMF could benefit from Five, but these are the things 
I've currently on my list:


- schema based content and forms:

There are still some issues that have to be resolved in Five, but the 
CMF changes I proposed are all I need in CMF.


- object specific behavior based on marker interfaces:

Flon does it in a Plone specific way. I think this could become a 
generic Five feature, but I still have to figure out why Zope 3.1 has 
lost the UI for marker interfaces.


- events:

Didn't work on this so far, but it would be really nice if we could use 
Five events in CMF.



3.) a base class for Five content:
The PortalContent class does not implement everything required in
CMFDefault. AFAICS at least some DublinCore methods are missing. We
could either add a subset as in PortalFolder or use the complete
DefaultDublinCoreImpl.


Well, that's still not a Five issue. But it could be a reasonably
thing to have in CMFDefault anyway.


I agree that the class as proposed would be useful for non-Five content 
as well. But there might be reasons to make that base class Five 
specific at a later point, so I thought it would be a good idea to 
announce it as five specific from the beginning.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: custom WebDAV upload handling

[yuppie]

Hi Raphael!


Raphael Ritz wrote:

First, one needs to understand the processing chain:


[Zope]

1. FTP/DAV uploads call 'PUT' from 'webdav.NullResource'


[CMF]

2. This gets the 'PUT_factory' from the parent in spe
   (the target) folder.
   For CMF this is usually the one from 'PortalFolder'.


[CMF]

3. The 'PUT_factory' contacts the 'content_type_registry' to
   figure out what content type should be created for this
   particular upload.


[CMF]

4. If a valid type is found, an _empty_ instance thereof is
   created using 'parent.invokeFactory'.


[CMF]

5. Then this object is removed from the parent where it just has
   been created. This now "kind of homeless" object is returned to
   the calling 'PUT' from  'webdav.NullResource'


[Zope]

6. Calling 'parent._verifyObjectPaste' it is now checked whether
   it is actually allowed to put the "homeless" object into the
   parent and if so ...


[Zope]

7. ... it is placed in there.

(Why is this back-and-forth handling needed at all?)


CMF builds on top of Zope, so CMF's PortalFolder has to return a bare 
and empty object as required by Zope's webdav machinery.


Hence the question is: Why does PortalFolder's PUT_factory use 
invokeFactory, a method that obviously does more than we want?


AFAICS this was the easiest way to implement PUT_factory. TypesTool or 
TypeInfos don't provide a better method.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup types import/export

[yuppie]

Hi Florent!


Florent Guillaume wrote:

I have to modify CMFSetup's type information import/export  (typeinfo.py).

Currently, to discriminate on ti types on export, it does:

if isinstance( ti, FactoryTypeInformation ):
...
elif isinstance( ti, ScriptableTypeInformation ):
...

Because I have other TypeInformation classes, with different  
properties, I'll have to use some kind of registry. Anyone has  special 
needs here, before I commit an implementation? I think I'll  do a 
registry that discriminates on ti.meta_type.


Note that my ti class is a subclass of FactoryTypeInformation, so the  
isinstance test above is not enough in any case.


In the long run we might need a registry for meta_type or interface 
specific import/export handlers.



But if you just need support for different PropertyManager properties, 
I'd propose an other solution:


utils.ConfiguratorBase has some methods for generic property support. 
The typeinfo handlers could use that code in a similar way as the site 
properties handlers or the handlers for the newstyle Actions on HEAD.


The property support works with any set of properties, so there would be 
no need to write new handlers for customized typeinfo classes.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup types import/export

[yuppie]

Florent Guillaume wrote:


On 10 Jun 2005, at 17:02, yuppie wrote:

utils.ConfiguratorBase has some methods for generic property  support. 
The typeinfo handlers could use that code in a similar way  as the 
site properties handlers or the handlers for the newstyle  Actions on 
HEAD.


The property support works with any set of properties, so there  would 
be no need to write new handlers for customized typeinfo  classes.



Ok that's another option that suits me too.


Fine.

But it will change a bit the XML format. I don't have a problem with  
that, but I hope people are OK with a backport to the 1.5 branch of  
such changes.


Well. It should not be too hard to leave the old import code in place 
for backwards compatibility. I can't see a need to export the old XML 
format.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Problem in TypesTool with CMF1.5.1 and Zope2.8

[yuppie]

Stefan H. Holek wrote:
I get a whole bunch of Unauthorized errors when running CMF-1_5- branch 
tests with Zope 2.8. Interestingly, CMF HEAD does not appear  to suffer 
from the same...


Stefan


==
ERROR: test_CopyPasteSetsOwnership  
(CMFCore.tests.test_PortalContent.TestContentCopyPaste)

--
Traceback (most recent call last):
  File "/Users/zope/cmf15/Products/CMFCore/tests/ 
test_PortalContent.py", line 90, in test_CopyPasteSetsOwnership

member_area.invokeFactory('File', id='test_file')
  File "/Users/zope/cmf15/Products/CMFCore/PortalFolder.py", line  418, 
in invokeFactory

return pt.constructContent(type_name, self, id, RESPONSE, *args,  **kw)
  File "/Users/zope/cmf15/Products/CMFCore/TypesTool.py", line 929,  in 
constructContent

ob = info.constructInstance(container, id, *args, **kw)
  File "/Users/zope/cmf15/Products/CMFCore/TypesTool.py", line 338,  in 
constructInstance

raise AccessControl_Unauthorized('Cannot create %s' % self.getId())
Unauthorized: Cannot create File


FYI: I can't reproduce this error. All tests pass for me using latest 
CMF-1_5-branch and Zope 2.8.0 final.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMF 1.5.2

[yuppie]

Hi!


Jens Vagelpohl wrote:
Question to the group: Any problem with starting the CMF 1.5.2 beta  
cycle this week or next week?


Looks like some people are currently trying to use Zope 2.8.0 in 
production. I stumbled over an issue with the catalog migration:

http://www.zope.org/Collectors/Zope/1808
We might need to ship CMF 1.5.2 with its own manage_convertIndexes method.

And there was this TypesTool problem reported:
http://mail.zope.org/pipermail/zope-cmf/2005-June/022408.html
AFAICS only the unit tests problem is resolved, not the original problem.

I guess people will find other issues with Zope 2.8.0 within the next 
one or two weeks. Fixes for those issues should go into CMF 1.5.2.



Besides that there are Florent's CMFSetup changes and I'm working on 
porting some stuff from CMFonFive to CMF core 
(http://mail.zope.org/pipermail/zope-cmf/2005-May/022347.html).



So I'd propose to wait one or two weeks with the beta.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Adding context to FactoryTypeInformation.queryMethodID

[yuppie]

Hi Christian!


Christian Heimes wrote:
I'd like to change the queryMethodID method of FactoryTypeInformation in 
CMF 1.5 and HEAD. I want to reimplement Archetype's template mixin 
feature for CMF. (*)


For the new feature I need the caller context in queryMethodID for a 
dynamic view template. I propose to alter the method from 
queryMethodID(self, alias, default=None) to queryMethodID(self, alias, 
default=None, context=None) and add context=self to all calls of 
queryMethodID.


I'm not sure I understand what you propose:

- Just changing queryMethodID signature and calls?

- Or also adding the TemplateMixin stuff to CMFCore?

- Or also adding an UI for that to CMFDefault?


(*)
TemplateMixin allows to register different view templates per portal 
type. The owner of a content object can select a template that should be 
used as the default template for his object. For example he can choose 
that a folder should be viewed as photo album instead of folder listing 
by default.


Zope 2.8/Five has a different machinery that allows to do something 
similar: Adding marker interfaces to objects and specifying views for them.


This product implements the feature for Plone: 
http://codespeak.net/svn/z3/Flon/trunk/


Is there a need to have TemplateMixin *and* marker interfaces? What are 
the pros and cons of the two approaches?


I would be happy to contribute it to CMF 1.5 under ZPL 2.1. Is CMF 1.5 
still open for new features?


CMF 1.5 is open for small features that are 100% backwards compatible.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Adding context to FactoryTypeInformation.queryMethodID

[yuppie]

Christian Heimes wrote:

yuppie wrote:


I'm not sure I understand what you propose:

- Just changing queryMethodID signature and calls?

- Or also adding the TemplateMixin stuff to CMFCore?

- Or also adding an UI for that to CMFDefault?



I'm proposing at least the first point in your list, changing the 
signature and calls. I'm going to implement the template mixin in a 
different way for Plone but I would be happy to contribute the feature 
to CMF.



[...]


The con against the marker interface is easy to explain: We need the 
feature in Plone 2.1 but we won't depend on ZopeX3 and Five. :)


I'm fine with the additional queryMethodID argument in CMF if Plone 2.1 
ships with CMF 1.5 and this change makes the migration easier.


But AFAICS it doesn't make much sense for the CMF to duplicate a feature 
that Zope 2.8/Five provides already.



Just my 2 cents. Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: Products/DCWorkflow - Scripts.py:1.3.20.3

[yuppie]

Sidnei da Silva wrote:

Update of /cvs-repository/Products/DCWorkflow
In directory cvs.zope.org:/tmp/cvs-serv25820

Modified Files:
  Tag: CMF-1_4-branch
	Scripts.py 
Log Message:


- Need to wrap w/ aq wrapper on Zope 2.8


=== Products/DCWorkflow/Scripts.py 1.3.20.2 => 1.3.20.3 ===
--- Products/DCWorkflow/Scripts.py:1.3.20.2 Wed Mar 16 12:57:54 2005
+++ Products/DCWorkflow/Scripts.py  Mon Jun 13 22:05:12 2005
@@ -35,6 +35,7 @@
 '''
 '''
 kw['management_view'] = 'Scripts'
-return Folder.manage_main(self, client, REQUEST, **kw)
+m = Folder.manage_main.__of__(self)
+return m(self, client, REQUEST, **kw)
 
 Globals.InitializeClass(Scripts)


Why is this fix just in the CMF-1_4-branch?

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: CMF/CMFSetup - typeinfo.py:1.26

[yuppie]

Florent Guillaume wrote:

Update of /cvs-repository/CMF/CMFSetup
In directory cvs.zope.org:/tmp/cvs-serv6342/CMFSetup

Modified Files:
	typeinfo.py 
Log Message:

Use a new XML format for import/export of types, where the properties
are generic. Now arbitrary TypeInformation objects can be used, as long
as they are configured using properties.


[...]
 
-class TypeInfoImportConfigurator(ImportConfiguratorBase):

+# BBB: will be removed in CMF 1.6
+class OldTypeInfoImportConfigurator(ImportConfiguratorBase):


"will be removed in CMF 1.6" doesn't make much sense on HEAD. The HEAD 
*is* (a pre-release version of) CMF 1.6.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: Products/DCWorkflow - Scripts.py:1.3.20.3

[yuppie]

Sidnei da Silva wrote:

On Tue, Jun 14, 2005 at 05:26:16PM +0200, yuppie wrote:
| Why is this fix just in the CMF-1_4-branch?

Haven't looked at 1.5, I would expect it to be fixed there already, as
it's the 'current' version no?



Not all CMF 1.4 bugs are fixed in CMF 1.5. Scripts.manage_main is still 
broken in 1.5 and on HEAD.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup profile changing

[yuppie]

Hi Florent!


Florent Guillaume wrote:
In the Properties tab of CMFSetup, you can choose an active site  
configuration, among the snapshots and the registered profiles.
This sets the current context_id for the tool, and loads the import  
steps, export steps and toolset for that configuration.


When you switch to a new base configuration, the import/export steps  
are loaded on top of the current ones without purging. So for  instance 
if you:

- select CMFDefault Site. The import steps now comprise 8 steps.
- select CMFCalendar. The import steps now have an additional  "Various 
Calendar Settings" step.
- select CMFDefault Site again (or a third-party base (non-extension)  
profile). The Calendar step is retained.


Is this intended ? If yes, why ? My reasoning would be that when you  
import a base profile, you want just that, not what was previously  there.


I'll fix that if we agree it's a bug.


Well. This is still a mess. Loading import/export steps from the profile 
did make more sense before I added extension profile support. Now I 
would prefer to register *all* handlers on Zope startup.


The handlers are supposed to do nothing if there are no related 
XML-files in the selected profile. But this rule doesn't work with the 
provisional handlers in CMFDefault and CMFCalendar because they don't 
depend on an XML-file.


The problem with the fix you proposed is that we currently need a 
complete set of import/export handlers for snapshots/exports. Switching 
back to the base profile would reset all handlers and make snapshots 
incomplete.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMF-head and Zope 2.8

[yuppie]

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I would like to update the head of CMF to reflect a dependency on Zope
2.8+.  In particular, I want to reset any 'import Zope' to 'import
Zope2', and begin looking at using Five more directly, without worrying
about testing for its absence.  The CMF 1.5 branch will thus be the EOL
for sites which chose to continue running Zope 2.7.x.


+1

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CVS: Products/CMFCore/tests - test_CMFCatalogAware.py:1.4.2.2

[yuppie]

Tres Seaver wrote:

Update of /cvs-repository/Products/CMFCore/tests
In directory cvs.zope.org:/tmp/cvs-serv12473/CMFCore/tests

Modified Files:
  Tag: tseaver-z28_only-branch
	test_CMFCatalogAware.py 
Log Message:

 - Remove two tests of no-longer-present BBB behavior.


=== Products/CMFCore/tests/test_CMFCatalogAware.py 1.4.2.1 => 1.4.2.2 ===
--- Products/CMFCore/tests/test_CMFCatalogAware.py:1.4.2.1  Tue Jun 14 
21:20:26 2005
+++ Products/CMFCore/tests/test_CMFCatalogAware.py  Tue Jun 14 21:23:53 2005
@@ -151,7 +151,7 @@
 self.failIf(bar.notified)
 self.failIf(hop.notified)
 
-def test_reindexObjectSecurity_oldbrain(self):

+def BBB_test_reindexObjectSecurity_oldbrain(self):
 self.site.portal_catalog.brain_class = DummyOldBrain
 foo = self.site.foo
 self.site.foo.bar = TheClass('bar')
@@ -194,7 +194,7 @@
 self.failIf(foo.notified)
 self.failIf(missing.notified)
 
-def test_reindexObjectSecurity_missing_oldbrain(self):

+def BBB_test_reindexObjectSecurity_missing_oldbrain(self):
 # Missing object is swallowed by old Zope brains
 self.site.portal_catalog.brain_class = DummyOldBrain
 foo = self.site.foo


Why are they just disabled, not removed?

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFDefault: getHomeFolder robustnes

[yuppie]

Hi Raphael!


Raphael Ritz wrote:

If you change your 'Members' folder to be a BTree folder
CMFDefault's 'getHomeFolder' throws a 'KeyError' if looking
for a non-existing id (e.g., if your account is defined in
Zope root).

Per default, 'Members' is a regular PortalFolder instance
which gives an 'AttributeError' on such look-ups which
is caught in the method but the 'KeyError' isn't.


Thanks for reporting this. Should now be fixed in cvs.


PS: You might have guessed it: I'm starting to look at
getting Plone running on CMF-1.5


Great! It might help to test your changes against CMF HEAD. The HEAD is 
still very similar to CMF 1.5, but raises errors if you use deprecated code.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup profile changing

[yuppie]

Hi Florent!


Florent Guillaume wrote:

By the way will you (or others) be at EuroPython ? It would be nice to
discuss plans for CMFSetup face to face.


I'll not make it to Göteborg and I'm not sure who the 'others' 
interested in CMFSetup development are.


But I have many plans for CMFSetup and would love to hear your plans and 
to discuss them. Unfortunately I can't make this work part of one of my 
customer projects, so I can't spend as much time on CMFSetup development 
as I would like to.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Adding context to FactoryTypeInformation.queryMethodID

[yuppie]

Christian Heimes wrote:

yuppie wrote:

But AFAICS it doesn't make much sense for the CMF to duplicate a 
feature that Zope 2.8/Five provides already.



You are right but we can't use new Zope 2.8 features at the moment. It 
would delay Plone 2.1 and introduce new dependencies.


I was just talking about *CMF* and your offer to contribute the template 
mixin feature to CMF, not about Plone.



Regarding your queryMethodID checkin:

A sentence in the interface that explains why the new argument exists 
would be nice. And please port the change to HEAD and update CHANGES.txt 
(only on the branch).



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Another small plone related change

[yuppie]

Hi Christian!


Christian Heimes wrote:
I'm asking for another small change in CMF 1.5. For Plone's portal 
factory and temporary folder we have to bend the 
ActionInformation.getOAI method a little bit.


The current code in CMF calls the function getOAI(context=self, 
object=object) from the ActionInformation module.


I would like to alter the call a little bit to make it easier for us to 
customize the call:



[patch]


Same in workflow and discussion tool.

Any objections?


Please make yourself familiar with these changes:

http://mail.zope.org/pipermail/zope-cmf/2003-November/019801.html

_listActionInfos() is just a fallback and never called for action 
providers that implement 'interfaces.portal_actions.ActionProvider'. All 
tools subclassing CMF tools or ActionProviderBase implement this interface.


ActionProviderBase depends on getExprContext, not on getOAI. AFAIK 'OAI' 
means 'old ActionInformation' and is deprecated since CMF 1.3. But 
DCWorkflow still depends on it, so there are no deprecation warnings.



I guess you have to modify getExprContext *and* getOAI for Plone.

Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Another small plone related change

[yuppie]

Hi Christian!


I'm fine with the proposed change, but I would prefer to have _getOAI 
and _getExprContext in *one* place: ActionProviderBase.



Cheers,

    Yuppie



[I quote the complete mail because it didn't make it to the list:]

Christian Heimes wrote:

yuppie wrote:


Please make yourself familiar with these changes:

http://mail.zope.org/pipermail/zope-cmf/2003-November/019801.html

_listActionInfos() is just a fallback and never called for action 
providers that implement 'interfaces.portal_actions.ActionProvider'. 
All tools subclassing CMF tools or ActionProviderBase implement this 
interface.


ActionProviderBase depends on getExprContext, not on getOAI. AFAIK 
'OAI' means 'old ActionInformation' and is deprecated since CMF 1.3. 
But DCWorkflow still depends on it, so there are no deprecation warnings.



Thank you very much for your explanation. I'm trying to get into the 
changes in CMF 1.5 in the last days.



I guess you have to modify getExprContext *and* getOAI for Plone.



You are right. Of couse you are *g*
I would like to apply my patch that allows us to overwrite both 
functions w/o monkey patching CMF.


Christian




? patch.txt
Index: CMFCore/ActionProviderBase.py
===
RCS file: /cvs-repository/Products/CMFCore/ActionProviderBase.py,v
retrieving revision 1.30.2.2
diff -u -r1.30.2.2 ActionProviderBase.py
--- CMFCore/ActionProviderBase.py   16 Mar 2005 11:33:52 -  1.30.2.2
+++ CMFCore/ActionProviderBase.py   18 Jun 2005 12:29:19 -
@@ -81,7 +81,7 @@
 # List ActionInfo objects.
 # (method is without docstring to disable publishing)
 #
-ec = getExprContext(self, object)
+ec = self._getExprContext(self, object)
 actions = self.listActions(object=object)
 actions = [ ActionInfo(action, ec) for action in actions ]
 
@@ -109,6 +109,9 @@

 if max + 1 and len(action_infos) >= max:
 break
 return action_infos
+
+def _getExprContext(self, context, object):

+return getExprContext(context, object)
 
 security.declarePublic('getActionInfo')

 def getActionInfo(self, action_chain, object=None, check_visibility=0,
Index: CMFCore/ActionsTool.py
===
RCS file: /cvs-repository/Products/CMFCore/ActionsTool.py,v
retrieving revision 1.51.2.1
diff -u -r1.51.2.1 ActionsTool.py
--- CMFCore/ActionsTool.py  11 Apr 2005 10:43:11 -  1.51.2.1
+++ CMFCore/ActionsTool.py  18 Jun 2005 12:29:19 -
@@ -197,12 +197,12 @@
  'portal_actions will ignore listActions() of \'%s\'.'
  % provider.getId(),
  DeprecationWarning)
-info = getOAI(self, object)
+info = self._getOAI(self, object)
 actions = provider.listActions(info)
 
 action_infos = []

 if actions and not isinstance(actions[0], dict):
-ec = getExprContext(self, object)
+ec = self._getExprContext(self, object)
 for ai in actions:
 if not ai.getVisibility():
 continue
@@ -252,5 +252,11 @@
 continue
 action_infos.append(i)
 return action_infos
+
+def _getOAI(self, context, object):

+return getOAI(context, object)
+
+def _getExprContext(self, context, object):

+return getExprContext(context, object)
 
 InitializeClass(ActionsTool)

Index: CMFCore/DiscussionTool.py
===
RCS file: /cvs-repository/Products/CMFCore/DiscussionTool.py,v
retrieving revision 1.17.2.2
diff -u -r1.17.2.2 DiscussionTool.py
--- CMFCore/DiscussionTool.py   16 Mar 2005 11:33:52 -  1.17.2.2
+++ CMFCore/DiscussionTool.py   18 Jun 2005 12:29:20 -
@@ -160,7 +160,7 @@
 def listActions(self, info=None, object=None):
 # Return actions for reply and show replies
 if object is not None or info is None:
-info = getOAI(self, object)
+info = self._getOAI(self, object)
 content = info.object
 if content is None or not self.isDiscussionAllowedFor(content):
 return ()
@@ -180,5 +180,8 @@
 )
 
 return actions
+
+def _getOAI(self, context, object):

+return getOAI(context, object)
 
 InitializeClass(DiscussionTool)

Index: CMFCore/WorkflowTool.py
===
RCS file: /cvs-repository/Products/CMFCore/WorkflowTool.py,v
retrieving revision 1.46.2.5
diff -u -r1.46.2.5 WorkflowTool.py
--- CMFCore/WorkflowTool.py 26 Apr 2005 16:03:36 -  1.46.2.5
+++ CMFCore/WorkflowTool.py 18 Jun 2005 12

[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[yuppie]

Hi Christian!


Christian Heimes wrote:

CMF 1.5's implementation of PortalFolder conflicts with CMFBTreeFolder.

CMF 1.4:
class PortalFolder(DynamicType, CMFCatalogAware, Folder)

CMF 1.5:
class PortalFolder(DynamicType, CMFCatalogAware, OrderedFolder)

BTreeFolder2:
class CMFBTreeFolder(BTreeFolder2Base, PortalFolder)

traceback:
  File 
"/opt/zope/instances/plone21z28cmf15/Products/ATContentTypes/content/base.py", 
line 312, in processForm

self.setId(new_id)
  File "/opt/zope/instances/plone21/Products/Archetypes/BaseObject.py", 
line 231, in setId

parent.manage_renameObject(
  File 
"/opt/zope/releases/Zope-2_8-branch/lib/python/OFS/OrderSupport.py", 
line 255, in manage_renameObject

old_position = self.getObjectPosition(id)
  File 
"/opt/zope/releases/Zope-2_8-branch/lib/python/OFS/OrderSupport.py", 
line 222, in getObjectPosition

return ids.index(id)
AttributeError: 'OOBTreeItems' object has no attribute 'index'


As you can see CMFBTreeFolder doesn't work any more because PortalFolder 
is now subclassed from OrderedFolder. The changes to PortalFolder are 
*not* backward compatible. IMO they should be reverted and an 
OrderedPortalFolder class should be created for people how like to have 
ordered folders in CMF.


First of all CMF 1.5.2 has to be backwards compatible to CMF 1.5.0 and 
1.5.1, so reverting that change is no option.


I propose to override manage_renameObject in PortalFolder with code that 
works for OrderedFolder *and* CMFBTreeFolder.



Cheers,
Yuppie



BTW: I'm not at all happy with the fact that Zope 2.8 ships with 
CMFBTreeFolder. That circular dependency is a pain to maintain. Maybe we 
should move CMFBTreeFolder to a CMF product.


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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[yuppie]

Hi Christian!


Christian Heimes wrote:

yuppie wrote:
 > First of all CMF 1.5.2 has to be backwards compatible to CMF 1.5.0 and
 > 1.5.1, so reverting that change is no option.

That is understandable from your point of view but I don't agree with 
the desicion.


This is not a decision, I'm not the project owner. This is my opinion.

The new ordered PortalFolder has deep impacts on software 
that exists for years and depend on PortalFolder to be a subclass of 
Folder w/o order support. This includes BTreeFolder2, Archetypes and all 
Archetypes based products. Archetypes distinguishes explictly between 
BaseFolder and OrderedBaseFolder.


I'm proposing to change PortalFolder in the following way:

 * Revert PortalFolder to be subclassed from Folder

 * Create an OrederedPortalFolder as subclass from OrderedFolder

 * Subclass all classes in CMF from OrderedPortalFolder instead of 
PortalFolder


All third party software that was working with CMF 1.4 and older would 
work as expected and all CMF core software would still use the ordered 
folder.


PortalFolder is not just a base class, it's *the* folder class used in 
CMFDefault. Subclasses can mix in OrderSupport, but that has no effect 
on PortalFolder instances.


The downside is that software written for CMF 1.5 has to be 
altered. But it is much easier to alter a few lines in some products 
than trying to get rid of the ordered stuff in PortalFolder.


That's not fair. You are free to ignore CMF development for years, but 
you can't make other people pay for that. Upgrading from 1.5.x to the 
latest 1.5 version has to work without *any* trouble.



 > I propose to override manage_renameObject in PortalFolder with code
 > that works for OrderedFolder *and* CMFBTreeFolder.

That's not enough. Existing software like Archetypes depends on 
PortalFolder to be an ordinary folder, too.
Second you have to make sure that CMFBTreeFolder doesn't implemement to 
ordered interface. As you probably know BTreeFolders aren't orderable 
per se. The patching of PortalFolder won't solve these issues.


manage_renameObject is the only method that overrides Folder behavior. 
Defunct IOrderedContainer methods should not be a big problem. After all 
we are still in Zope 2 land with tons of inherited useless methods.



I'm open for any proposal that adds a *new* base class for CMF folders.

Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Another small plone related change

[yuppie]

Hi Christian!



Christian Heimes wrote:

+
+def _getOAI(self, context, object):
+return getOAI(context, object)
+   
+def _getExprContext(self, context, object):

+return getExprContext(context, object)


I didn't see it this morning, but after reviewing your checkins I 
believe 'context' is redundant and this should also work:


def _getOAI(self, object):
return getOAI(self, object)

def _getExprContext(self, object):
return getExprContext(self, object)


Would you mind if I change it that way?

Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Conflict between PortalFolder and CMFBTreeFolder

[yuppie]

Hi Christian!


Christian Heimes wrote:

yuppie wrote:

That's not fair. You are free to ignore CMF development for years, but 
you can't make other people pay for that. Upgrading from 1.5.x to the 
latest 1.5 version has to work without *any* trouble.



I'm sorry but I'm a little bit nervous. I have to get Plone 2.1 up and 
running on CMF 1.5 until saturday or Plone 2.1 will stay on CMF 1.4.


Accepted.

I have another idea. The patch is attached to this mail. In short terms 
I have renamed PortalFolder to PortalFolderBase subclassed of Folder and 
created a new PortalFolder class subclassed from OrderedFolder. 
PortalFolderBase contains nearly all code from PortalFolder. This way it 
is easy to subclass from PortalFolderBase w/o ordered support.


class PortalFolderBase(DynamicType, CMFCatalogAware, Folder):

class PortalFolder(PortalFolderBase, OrderedFolder):
manage_renameObject = OrderedFolder.manage_renameObject.im_func
tpValues = OrderedFolder.tpValues.im_func


That sounds *much* better :)

But please use OrderSupport instead of OrderedFolder. That makes the 
inheritance tree much simpler and you don't have to override the methods 
again:


  class PortalFolder(OrderSupport, PortalFolderBase):


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: PortalObject, PortalFolder, SkinnedFolder and __call__

[yuppie]

Hi Christian!


Christian Heimes wrote:
While I was working on the CMF 1.5 integration into AT and 
ATContentTypes for Plone 2.1 I had some issues with the view on folders. 
After some digging I found these interesting results:


CMFCore.PortalObject defines __call__ to use method aliases and 
_getViewFor() as fallback, view = __call__ and index_html = None.


CMFDefault.SkinnedFolder defines __call__ to use _getViewFor(), view = 
__call__ and index_html = None


CMFCore.PortalFolder doesn't hook into index_html/__call__ publishing at 
all.



What's the reason PortalFolder doesn't define __call__ at all? Shouldn't 
it use __call__ to get the view from method aliases or _getViewFor() as 
fallback?


1.) PortalFolder did never have a __call__ method and apparently nobody 
missed it so far.


2.) I know only one situation where we need to call an object directly: 
If a content object is used as a view method. That is e.g. the case for 
'index_html' documents, but doesn't make much sense with folders.


Why does SkinnedFolder still uses the old and deprecated way as default 
way to get the view and why does it ignore method aliases completly? IMO 
SkinnedFolder.__call__ is buggy and wasn't fixed when method aliases 
were introduced.


Like other folders a skinned folder should never be used as method, so 
__call__ should never be invoked. That code exists just for backwards 
compatibility and is completely removed on HEAD.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Lazy Keys in ActionInfo unresolved

[yuppie]

Christian Heimes wrote:

I have a strange issue with ActionInfo under CMF 1.5

Debugging output:

 > 
/opt/zope/instances/plone21z28cmf15/Products/CMFCore/ActionInformation.py(98)__getitem__() 


-> return value
(Pdb) value
True, 'title': 'My Folder', 'url': {...}>, 'name': 'My Folder', 'visible': True, 'allowed': True, 'id': 
'mystuff', 'permissions': ('View',)}>

(Pdb) self._lazy_keys
[]


self._lazy_keys should not be empty here.

I was able to reproduce this problem with copied ActionInfo objects. A 
fix for the copy method is on the CMF-1_5-branch. Hope that fixes your 
issue as well.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [DCWorkflow] condition on transition action

[yuppie]

Hi!


Encolpe Degoute wrote:

Now that CMF 1.5 is out, and 1.5.1 too, can I start to work on this patch:
http://www.zope.org/Collectors/CMF/207

Have you any recommandations ?


Well. I'm not against a condition field for workflow Actions. But I 
still can't see other than historical reasons to use a different Actions 
machinery for workflows than for the rest of the CMF.


DCWorkflow Actions still use the OAI, which is marked as deprecated 
since CMF 1.3. This means a lot of extra code to maintain and extra 
rules to learn and remember.


Your proposal adds a condition field that works different than the other 
OAI based Action fields and different than the condition fields in 
CMFCore Actions. It uses DCWorkflow Expressions and doesn't reuse any 
code from CMFCore Actions.



I think it's worth the effort to migrate DCWorkflow Actions to the 
CMFCore Actions machinery for CMF 1.6. And in that context your proposal 
is a move in the wrong direction.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: index_html no longer working for CMF folders with Plone 2.1 + CMF 1.5

[yuppie]

Hi Martin!


Martin Aspeli wrote:
On 2.1-cmf1.5 branch of Plone, creating a "CMF Folder" with an 
index_html  document does not work - the index_html is not set as the 
default page. At  the moment, this also breaks for ATCT "Folder" items, 
but I know why this  is and Tiran and I should be able to fix this 
tomorrow. For CMF Folders,  however, I'm quite confused.


As detailed in my investigations a few weeks ago, Plone uses the  
__browser_default__ hook and delegates to PloneTool.browserDefault() to  
implement the logic to determine what to display as a default page 
(note  that this includes support for things like 
ITranslatable/LinguaPlone,  selectable layouts etc.). It seems this no 
longer gets called. I am having  a hard time finding out how this is 
meant to work in CMF 1.5. Can someone  shed some light on how the 
default_page/index_html mechanism is meant to  work with CMF 1.5 folders 
and documents?


1.) By 'CMF Folder' you mean PloneFolder objects, not CMFCore Folders. 
Right? PloneFolder inherits from CMFCore Folder, but might not work with 
Method Aliases out of the box.


2.) _guessMethodAliases tries to set useful Method Aliases, but the 
result is not always satisfying. The guessing mode is disabled if the 
FTI data has an 'aliases' key or existing FTIs have an '_aliases' attribute.


3.) If you remove all method values on the aliases tab of the type info, 
the Method Aliases machinery is disabled and the traversal should work 
exactly as in CMF 1.4.


4.) If you set the '(Default)' alias to index_html, index_html is 
called. If you don't set it or set it to '(Default)', 
__browser_default__, index_html or __call__ is called depending on the 
class.



HTH,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [DCWorkflow] condition on transition action

[yuppie]

Encolpe Degoute wrote:


yuppie a écrit :

| I think it's worth the effort to migrate DCWorkflow Actions to the
| CMFCore Actions machinery for CMF 1.6. And in that context your
| proposal is a move in the wrong direction.


Now that actions machinery has been refactored in CMF 1.5, I would use
these new implementation instead to the old code.
There's to class using actions: transitions and worklists. Does
anybody have specific request on these migrations ?


Please be aware of the fact that some Action code has been further 
refactored on HEAD. If you plan to land your changes on the 1.5 branch, 
it might make sense to backport some stuff from HEAD. (I can do that if 
necessary.)


BTW: I'm not at all happy with the worklist Actions. They are very 
expensive and specialized. And they are in the wrong place because they 
are often not workflow specific if you have more than one workflow. 
Maybe they should be marked as deprecated instead of improved?



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Moving to CMF 1.5.2

[yuppie]

Hi!


Jens Vagelpohl wrote:
As you have noticed, I have just released 1.5.2beta. Tres tagged it a  
couple days ago and I just published it from that tag. Since he is at  
Europython right now I'm assuming he had enough of the cats that need  
herding for a release on hand to get a consensus that the time is  ripe 
for this beta.


Thanks! I'm sure Tres did have good reasons.

As always, the beta implies that you should hold off with anything  but 
bugfixes on the CMF-1_5-branch in CVS until CMF 1.5.2 final is  
released. If nothing comes up, I would actually like to do that in  
1-1.5 weeks without a second beta, but if fixes creep in a second  beta 
will be released instead. The latest point at which CMF 1.5.2  will come 
out is the middle of July, a little over 2 weeks from now.


Please test this beta and report any severe bugs that must be fixed  
before 1.5.2 final.


Well. I don't consider this a release candidate. There are still issues 
with Zope 2.8.0 compatibility. Some of them are resolved on the 
Zope-2_8-branch, but I think we should try to make CMF 1.5.2 work with 
Zope 2.8.0:



1.) catalog migration is broken

http://www.zope.org/Collectors/CMF/357
http://www.zope.org/Collectors/Zope/1823
A copy 'n' paste of the latest manage_convertIndexes code to CatalogTool 
should fix this.


2.) CMFBTreeFolder is broken and should be moved to the CMF

http://www.zope.org/Collectors/Zope/1813


3.) undoable_transactions behavior changed

http://www.zope.org/Collectors/Zope/1822
If the old behavior is not restored in Zope 2.8.1 we have to adjust CMF.


Besides that, I'm a bit confused by the fact that Florent didn't 
backport his latest CMFSetup changes to the CMF-1_5-branch.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Moving to CMF 1.5.2

[yuppie]

Hi Tres!


Tres Seaver wrote:


yuppie wrote:


1.) catalog migration is broken

http://www.zope.org/Collectors/CMF/357
http://www.zope.org/Collectors/Zope/1823
A copy 'n' paste of the latest manage_convertIndexes code to CatalogTool
should fix this.


Fine.


Looks like there are still unresolved issues with manage_convertIndexes:
http://www.zope.org/Collectors/Zope/1826

The risk of overriding the ZCatolog method is that Zope 2.8.1 will have 
more fixes than CMF 1.5.2.




2.) CMFBTreeFolder is broken and should be moved to the CMF

http://www.zope.org/Collectors/Zope/1813


That can't be fixed in the CMF for 2.8.0 compatibility.  Getting the
module aliases stuff to work right if the thing being aliased is really
there is painful.


Could you please elaborate on this? What are the problems with module 
aliases?




3.) undoable_transactions behavior changed

http://www.zope.org/Collectors/Zope/1822
If the old behavior is not restored in Zope 2.8.1 we have to adjust CMF.


We won't adjust CMF to work around this behavior unless Tim decress that
the new behavior is permanent.  I don't think we should hold up the CMF
release for this issue either way.


Tim restored the old behavior for Zope 2.8.1, so this one is resolved.



Besides that, I'm a bit confused by the fact that Florent didn't
backport his latest CMFSetup changes to the CMF-1_5-branch.


I think he thought he had dones so already.


Florent is working on this:
http://mail.zope.org/pipermail/zope-cmf/2005-June/022521.html


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup: non-ascii text

[yuppie]

Hi Florent!


Florent Guillaume wrote:
In many places, CMFSetup exports and imports things like titles and  
descriptions. For instance, for the workflow states and transitions.
These fields can often, outside the USA, contain non-ascii strings.  How 
do we export and reimport them ?


It would be nice if CMFSetup would work with non-ascii strings, but for 
me this has a low priority. I use English for all settings and the i18n 
machinery to translate them.


1. We can export by converting them to unicode, and the ZPT will  render 
that as UTF-8. Which charset do we assume ? Anything better  than 
"locale.getlocale()[1] or 'latin1'" ?


CMF 1.5 has a default_charset property, but not before the site 
properties are set up. I think the charset used by CMFSetup should be 
configurable.


2. When importing, do we set the values (attributes) as unicode, or  do 
we try to re-convert to the above charset...


CMF needs a lot of testing / refactoring to make it work with unicode 
settings. At the moment this is no option.



A related thread is here:
http://mail.zope.org/pipermail/zope-cmf/2004-October/021345.html

And here is the collector issue:
http://www.zope.org/Collectors/CMF/292


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Moving CMF into SVN

[yuppie]

Jens Vagelpohl wrote:

I have created a cvs2svn migration test sandbox for CMF on svn.zope.org:

http://svn.zope.org/Sandbox/jens/CMF/

This represents an import from the current state of the CVS  repository. 
It is looking pretty good, except for one niggle: The  
"branch/tag/trunk"-folders don't represent the direct root for the  
project files - they all contain a CMF directory which is the root  for 
the project files.


Well. I might well be missing something. But if I read the comment for 
_make_path() correctly, you just have to run cvs2svn from within the CMF 
directory. Did you try that already?


HTH, Yuppie



Here is the comment I refer to:

# For a while, we treated each top-level subdir of the CVS
# repository as a "project root" and interpolated the appropriate
# genealogy (trunk|tag|branch) in according to the official
# recommended layout.  For example, the path '/foo/bar/baz.c' on
# branch 'Rel2' would become
#
#   /foo/branches/Rel2/bar/baz.c
#
# and on trunk it would become
#
#   /foo/trunk/bar/baz.c
#
# However, we went back to the older and simpler method of just
# prepending the genealogy to the front, instead of interpolating.
# So now we produce:
#
#   /branches/Rel2/foo/bar/baz.c
#   /trunk/foo/bar/baz.c
#
# Why?  Well, Jack Repenning pointed out that this way is much
# friendlier to "anonymously rooted subtrees" (that's a tree where
# the name of the top level dir doesn't matter, the point is that if
# you cd into it and, say, run 'make', something good will happen).
# By interpolating, we made it impossible to point cvs2svn at some
# subdir in the CVS repository and convert it as a project, because
# we'd treat every subdir underneath it as an independent project
# root, which is probably not what the user wanted.
#
# Also, see Blair Zajac's post
#
#http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=38965
#
# and the surrounding thread, for why what people really want is a
# way of specifying an in-repository prefix path, not interpolation.

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup and workflows

[yuppie]

Hi Anahide!


Anahide Tchertchian wrote:

I'd like to make 3 main changes to the way CMFSetup handles workflow
export/import:


Please note that all other tool handlers use utils.*ConfiguratorBase. I 
didn't convert workflow.py because it is the biggest handler and it 
works for me as it is. But it uses deprecated patterns, so if you plan 
to improve it it might be worth to refactor it using *ConfiguratorBase.



- turn import methods in CMFSetup/workflow.py into configurator class
methods so that they're easier to override when subclassing
(_extract*Nodes and _initDCWorkflow* methods)


Sounds fine if you don't want to do the big refactoring.


- get rid of DCWorkflow specifics, and use the workflow factory and
API methods to import a workflow (no need to import
DCWorkflowDefinition, State, Transition classes anymore, for instance)


I didn't have a look at the details. But I'm afraid we would loose some 
flexibility. Other import handlers allow fine-grained changes to 
existing setups.



- do not list workflows that are not supported when exporting (not
supported workflows are listed but not exported at the moment)


You mean workflows without CMFSetup supported? i.e. CMFDefault 
DefaultWorkflow? Why shouldn't they be listed?



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup and workflows

[yuppie]

Encolpe Degoute wrote:

That's seems a good idea, but I don"t where worklists will be import
in few weeks.


That sounds like you're working on a big worklists refactoring. If 
that's the case, sending a small proposal to the list would be nice.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup and workflows

[yuppie]

Hi!


Anahide Tchertchian wrote:

yuppie wrote:


- turn import methods in CMFSetup/workflow.py into configurator class
methods so that they're easier to override when subclassing
(_extract*Nodes and _initDCWorkflow* methods)


Sounds fine if you don't want to do the big refactoring.


Yes I'd like to, but as I am new to this code I thought these methods 
were necessary (is it?) and I just wanted to make them class methods. 
Maybe it's not the case with ConfiguratorBase, I just have to have a 
closer look at it.


Great. The _extract*Nodes methods should become obsolete, the 
_initDCWorkflow* methods (or similar methods) are still necessary. I 
guess the best example to look at is typeinfo.py.



- get rid of DCWorkflow specifics, and use the workflow factory and
API methods to import a workflow (no need to import
DCWorkflowDefinition, State, Transition classes anymore, for instance)


I didn't have a look at the details. But I'm afraid we would loose 
some flexibility. Other import handlers allow fine-grained changes to 
existing setups.


I'm not sure I understand why we could lose some flexibility.
For instance, instead of doing:

from Products.DCWorkflow.States import StateDefinition
s = StateDefinition(id)
workflow.states._setObject(id, s)

I'd like to do:
workflow.states.addState(id)

Since workflows handled are supposed to be quite similar to DCWorkflow 
workflows, I thought that if it's too different, a new configurator will 
have to be coded anyway. This is just to handle DCWorkflow subclasses, 
like CPSWorkflow classes.


Ok. Looking at your example, I guess this is fine.


- do not list workflows that are not supported when exporting (not
supported workflows are listed but not exported at the moment)


You mean workflows without CMFSetup supported? i.e. CMFDefault 
DefaultWorkflow? Why shouldn't they be listed?


Currently, on export, if a workflow is not a DCWorkflowDefinition 
instance, its name is listed in workflows.xml but there is no other file 
containing the worklow definition, so I'm not sure there is a point to 
list it.


It's not useful for an automated re-import. But people can read the XML 
and get informed about unsupported objects in their site.


On the other hand I don't care much about this.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: RFC: CMF 2.0 Roadmap

[yuppie]

Hi!


Seb Bacon wrote:

As to your notes on the wiki:

* Zope3 style interfaces: this is fairly uncontroversial and not too painful

* Movement of presentation logic into Views gives us potentially great wins


Five provides a smooth migration path for both migration tasks: CMF 
1.5.2 already ships with many Zope3 style interfaces and mixing skins 
and views seems to work fine.



* However, are you / we confident that we've found the best patterns
for utilities / adapters yet?  I'm not!


Maybe we should first see what people want to contribute and decide 
later if we call it CMF 1.6 or 2.0.



In addition, I have a number of more ambitious thoughts about the CMF,
which don't necessarily relate to Zope3 - relating, for example, to
schema-driven development,


You can use schema-based Five content with CMF 1.5.2.


or XML in the presentation layerl.


Not sure what you mean exactly by that.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] Site factory - a small proposal

[yuppie]

Hi!


CMF 1.5 registers 2 Site factories:

- CMFDefault the old and deprecated factory for meta type 'CMF Site'

- CMFSetup the new factory for meta type 'Configured CMF Site'


On CMF HEAD the old factory should no longer be used TTW, but 
manage_addCMFSite should still be available for backwards compatibility.


See also this issue: http://www.zope.org/Collectors/CMF/364

My first attempt was to make the old factory invisible, but that doesn't 
work because the ObjectManager machinery requires a visible 'CMF Site' 
factory to handle CMFSite objects correctly. And we can't override that 
behavior because the parent of CMFSite objects is no CMF specific 
ObjectManager.



So I propose a different approach:

- move the 'Configured CMF Site' factory to CMFDefault (it is anyway 
CMFDefault specific because it uses a hardcoded CMFDefault CMFSite)


- make 'CMF Site' behave like CMF 1.5's 'Configured CMF Site'


If there are no objections, I'll change this on HEAD.

Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] CMFSetup backwards compatibility policy

[yuppie]

Hi!


CMFSetup is fast changing code and maintaining full backwards 
compatibility is a pain, slowing down development.


I don't think we should try to maintain code compatibility on HEAD. All 
we should promise is that imports of old profiles work and that we don't 
break the persistent SetupTool.


I believe we have already a policy like that, just want to make this 
more explicit and give people a chance to correct me.



Right now this means (on HEAD):

- I'll move factory.py around and don't plan backwards compatibility for 
addConfiguredSiteForm/addConfiguredSite imports.


- I'd like to remove the BBB code in typeinfo.py.


Any comments?


Cheers,

Yuppie


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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: New CMFDefault type profiles altering ATCT types

[yuppie]

Hi Alec!


Alec Mitchell wrote:
I recently noticed that the recent addition of default type profiles to 
CMFDefault (e.g. CMFDefault/profiles/default/types/Topic.xml), has the very 
unwelcome side-effect of adding extra unwanted actions to the ATCT types in 
plone 2.1.  Perhaps these customizations should check the meta_type of the 
FTI they are altering before making potentially undesirable changes?


Could you please describe what you are exactly doing? When and why does 
Plone import the CMFDefault profile?



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: New CMFDefault type profiles altering ATCT types

[yuppie]

Alec Mitchell wrote:

On Thursday 14 July 2005 11:27 am, yuppie wrote:

Alec Mitchell wrote:


I recently noticed that the recent addition of default type profiles to
CMFDefault (e.g. CMFDefault/profiles/default/types/Topic.xml), has the
very unwelcome side-effect of adding extra unwanted actions to the ATCT
types in plone 2.1.  Perhaps these customizations should check the
meta_type of the FTI they are altering before making potentially
undesirable changes?


Could you please describe what you are exactly doing? When and why does
Plone import the CMFDefault profile?



Actually, the problem was in ATCT, though it appears to have only become 
visible because of the new profiles.  The profiles are imported in 
PloneGenerator, which inherits CMFDefault.Portal.PortalGenerator and calls 
setup.  Sorry for the false alarm. :)


CMFDefault.Portal.PortalGenerator is deprecated code and doesn't use 
CMFSetup and profiles in any way.


CMF 1.5 has some new / modified Actions, but that has nothing to do with 
CMFSetup.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Bippity, Boppity, Boo!

[yuppie]

Hi Tres!


Some feedback regarding your notes and checkins:

Tres Seaver wrote on 
http://palladion.com/home/tseaver/obzervationz/cmf_z3_interfaces_20050715:


I also cleaned up a lot of docstrings in the original interfaces. In many cases, the "style 
guide" for docstrings has changed over time. My preference has always been for docstrings 
which specify the contract in the "imperative mode": e.g, rather than:

def foo(bar, baz):
""" This method frobs 'baz' into the 'qux' method of 'bar'.  'baz'
will implement IBaz, unless it is None.  The method raises SpamError
if 'qux' returns an error string.
"""

I prefer:

def foo(bar, baz):
""" Frob 'baz' into 'bar.qux'.

o 'baz' implements IBaz, or is None.

o Raise SpamError if 'qux' returns non-None (an error string).
"""

as less chatty, and more clearly "contract".


What about using reStructuredText with Epydoc fields?
See http://epydoc.sourceforge.net/fields.html

The docstring for 'foo' would look like this:

def foo(bar, baz):
""" Frob 'baz' into 'bar.qux'.

:param bar: The bar that will be modified.
:type bar: an IQuxBar type
:param baz: The baz that should be frobbed.
:type baz: an IBaz type or NoneType

:return: Success indicator.
:rtype: bool

:raise SpamError: If 'qux' returns non-None (an error string).
"""


Remaining Cleanup

* Address the XXX comments I scattered through the docstrings, in 
particular.
* Figure out whether we need to leave webdav.WriteLockInterface as a Zope2 
interface BBB wart.


There are at least two other dependencies on Zope 2 interfaces:

1.) Code using OFS.ObjectManager.IFAwareObjectManager:

ActionsTool, ActionCategory and TypesTool use IFAwareObjectManager. I 
can have a look at making IFAwareObjectManager aware of z3 interfaces.


2.) Help system:

'interfaces' directories are registered as help directories. If we 
bridge the z3 interfaces back, this should still work.



* Decide what to do with the z2interfaces modules / packages to which I 
moved the discards:
  o "Bring outcher dead!"? (Just scrag them, that is)?
  o "None shall pass!" (Reverse bridge them using the new Five 
directive in Zope 2.8.1)?


I would vote for this option, but the reverse bridge is no Five 
directive (it's just a python function) and so far there are no plans to 
add the reverse bridge to Zope 2.8.1.


Current plans are that the reverse bridge is shipped with Five 1.1 and 
Zope 2.9. There might be other reasons to require Five 1.1 for CMF 1.6: 
I'm currently looking at using its i18n features for the CMF.


On the other hand it would be easy to backport the reverse bridge to 
Zope 2.8.1 if we need it there.



  o "Bring us ... a shrubbery!" (never mind, I forgot what that was 
going to be)?


Other issues:

1.) I don't understand why you renamed IActionInfo to 
IActionInformation: ActionInformation doesn't implement this interface, 
ActionInfo does.


Sorry for using similar class names that might have confused you. I try 
to use 'Info' for dicts containing information about an object and I 
hope ActionInformation can be deprecated soon.


2.) Looks like something went wrong with CMFCore.(Old)Discussable: It 
has the wrong Discussable interface and verifyClass got lost.


3.) Why did you add implements() statements like this one:


-__implements__ = ( PortalContent.__implements__
- , DefaultDublinCoreImpl.__implements__
- )
+implements(implementedBy(PortalContent),
+   implementedBy(DefaultDublinCoreImpl),
+  )


AFAICS this is redundant because z3 interfaces are inherited from all 
base classes.


4.) There are still many flags like _isPortalRoot, _isAWorkflow, 
_isPortalContent, _isDiscussable or _isTypeInformation. This could be 
done in an other cleanup, but I think we should use interfaces instead.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [ATTN]: CMF and related packages moved to svn.zope.org

[yuppie]

Jens Vagelpohl wrote:
I just finished migrating the CMF and related projects from  
cvs.zope.org to svn.zope.org, from CVS to Subversion. All tags and  
branches have moved, unlike Zope itself there won't be some  development 
using CVS and some using Subversion. These are the packages:


- CMF
- CMF_Hotfixes
- CMF_Extras

They packages became new toplevel projects at svn.zope.org, as can be  
seen here:


  http://svn.zope.org/

Pending final agreement on the CMF list (or an overriding word from  the 
CMF Pope himself) svn.zope.org will now be the canonical location  for 
CMF sources.


+1 for using the new repository, looks great so far.

Two minor issues (almost non-issues):

1.) AFAIK we don't use these keywords: 'Author', 'Date' and 'Revision'. 
Maybe they should not even be set.


2.) The virtually empty products like CMFCollector, CMFStaging and 
CMFTracker don't make much sense in a new repository. I guess they 
should be removed from CMF trunk. (The real products are in CMF_Extras)


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: SVN: CMF/branches/CMF-1_5-branch/C Fix DefaultWorkflowDefinition bug on isActionSupported() for the

[yuppie]

Hi Julien!


Julien Anguenot wrote:

Log message for revision 37237:
  Fix DefaultWorkflowDefinition bug on isActionSupported() for the
  keywargs support to reflect DCWorkflowDefinition changes.  Add test
  case for this definition as well.

Changed:
  U   CMF/branches/CMF-1_5-branch/CHANGES.txt
  U   CMF/branches/CMF-1_5-branch/CMFDefault/DefaultWorkflow.py
  A   CMF/branches/CMF-1_5-branch/CMFDefault/tests/test_default_workflow.py


Why did you add a new test file instead of using test_DefaultWorkflow.py?



+import Zope2
+Zope2.startup()


Importing 'Zope2' fails with Zope 2.7. Please use on the 1.5 branch the 
pattern used in other tests.




Property changes on: 
CMF/branches/CMF-1_5-branch/CMFDefault/tests/test_default_workflow.py
___
Name: svn:keywords
   + Id


Please don't forget to set always svn:eol-style native.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Plone participation in the CMF list

[yuppie]

Hi!


Geoff Davis wrote:

On Mon, 01 Aug 2005 17:30:20 +0100, Jens Vagelpohl wrote:


It would help everyone if the CMF side opened up a little  
more to ideas coming down from Plone, and if the Plone side stopped  
reinventing wheels that would be much better off (and benefit  
everyone) in the CMF or other non-Plone core products.



Perhaps some specifics would help.

* What wheels do you think Plone has reinvented?

* Are there any particular things in Plone that you think should be pushed
down into CMF?


If you ask me most of the install/setup/migration stuff of Plone is 
implemented in the wrong layer. The way Plone uses the CMFDefault 
PortalGenerator and customizes CMFDefault settings looks quite strange.


AFAICS Plone could benefit from CMFSetup and CMFSetup could benefit from 
the experience Plone people have with install/setup/migration tasks. 
CMFSetup still needs a lot of work, but it could became a generic 
framework that replaces (at least big parts of) CMFQuickInstallerTool 
and the Plone migrations machinery. CPS people already contribute to 
CMFSetup.



In general I'm skeptic if people want to contribute new products. CMF 
still needs a lot of consolidation work. And CMF has to be modernized to 
benefit from Five features.



I guess the first thing we need is a unit test framework that is more 
similar to Zope 3 and Plone tests. Most people not familiar with CMF 
unit tests have problems writing new ones. I don't like the idea to 
depend on an external product, but maybe CMFTestCase could become part 
of CMF?



Just my 2 cents.

Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] i18n improvements - a proposal

[yuppie]

Hi!


Zope 2.8.1 with Five 1.1 and Zope 2.9 will come with integrated i18n 
support. Localizer / PTS are no longer needed.


CMF currently has limited i18n support and describes in INSTALL.txt how 
to use it with Localizer and TranslationService.



I propose the following changes on CMF trunk:


1.) Using zope.i18nmessageid.MessageIDFactory in Python code:

This allows to extract message strings with pygettext / zope3 tools and 
to set domain, mapping and default in Python code.


Each product will have a factory in utils.py that is used by Python code 
like this::


  from Products.CMFDefault.utils import CMFDefaultMessageID as _
  message = _('foo')


2.) Using different domains for different products:

While 'cmf_default' should be used by the core products (CMFCore, 
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for 
CMFCalendar.


This might cause some problems in the first place, but resolving these 
issues is necessary for third party add-ons.



3.) Adding a utility script for extracting i18n messages:

i18nextract.py is quite zope3 specific, but with some modifications it 
seems to work quite well for CMF. I'd like to add a modified 
i18nextract.py to the root of the CMF repository.


We could use that script to provide *.pot files in a CMFDefault/locale 
and CMFCalendar/locale.



4.) Adding i18n support for settings loaded from profiles:

This is the most difficult part and so far I just have some ideas.

One issue is extracting message strings. I hope to find a way to use the 
i18n namespace in profile XML files. This would allow to use the 
standard tools.


The other issue is handling some settings like 'Title' and 'Description' 
fields as MessageIDs. AFAICS a first step would be adding a 'domain' 
field to Actions and TypeInfos. Don't know if we can just use the old 
attributes and return MessageIDs instead of strings or if we need new 
attributes. This depends on possible backwards compatibility issues.



5.) Adding translations:

If someone wants to maintain one or more translations we could ship CMF 
with translations and enable the i18n machinery by default.



I'd like to work at least on the first 3 items for CMF 1.6. AFAICS this 
should not break anything on Zope 2.8.0. But maybe we should anyway make 
Zope 2.8.1 the required platform for CMF 1.6.


Any comments?


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Jens Vagelpohl wrote:
I'd like to work at least on the first 3 items for CMF 1.6. AFAICS  
this should not break anything on Zope 2.8.0. But maybe we should  
anyway make Zope 2.8.1 the required platform for CMF 1.6.



Making Zope 2.8.1 the required platform for CMF 1.6 is fine IMHO, I  
believe we have plenty of freedom right now. Any time estimate for  
those first tasks?


The first tasks should be finished within a week. I hope to catch most 
of the message strings in the Python scripts and at least some in the 
tools, but the rest has to be done step by step if people stumble over 
untranslated messages.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Raphael Ritz wrote:

yuppie wrote:

Just one minor question out of curiosity:

i18nextract.py is quite zope3 specific, but with some modifications it 
seems to work quite well for CMF. I'd like to add a modified 
i18nextract.py to the root of the CMF repository.



How about making the original i18nextract.py more generic from the
onset instead of having the CMF provide its own?


I did consider that. But

a) we need something that works with ZopeX3-3.0.1.

b) this is still work in progress, I'm not sure about all the necessary 
modifications.


c) I wanted to focus on the other tasks right now.

I agree that in the long run zope3's utilities/i18nextract.py and 
app/locales/extract.py should be modified based on our experiences.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Hi Florent!


Florent Guillaume wrote:


yuppie wrote:


4.) Adding i18n support for settings loaded from profiles:

This is the most difficult part and so far I just have some ideas.

One issue is extracting message strings. I hope to find a way to use 
the i18n namespace in profile XML files. This would allow to use the 
standard tools.


You still would have to store this somewhere in the ZODB after the 
loading, to allow the user to change the domains.


Sure. Talking about 'extracting' I just had creating *.pot files in mind.

For importing/exporting domain settings we have to extend CMFSetup and 
need new properties in the ZODB. Thinking a bit more about this we might 
have some trouble to write XML files containing i18n attributes. Is 
there an easy way to tell PageTemplateFile *not* to interpret i18n 
attributes?


The other issue is handling some settings like 'Title' and 
'Description' fields as MessageIDs. AFAICS a first step would be 
adding a 'domain' field to Actions and TypeInfos. Don't know if we can 
just use the old attributes and return MessageIDs instead of strings 
or if we need new attributes. This depends on possible backwards 
compatibility issues.


Here we're talking about content or meta-content, right? So the i18n 
problem is different than for the code -- you have to decide if a Title 
field (for instance) is a msgid or not. Maybe an empty i18n_domain could 
mean "don't translate", and a non-empty one would mean "translate using 
this domain". Another option would be a checkbox is_i18n that would 
change the interpretation of title/description from text to msgids. Or 
you could have i18n_msgid and i18n_domain, that would be used if 
i18n_msgid is not empty, otherwise the normal title field is used. They 
are many choices. But you can't say by fiat that all Title and 
Decription fields will become mandatorily i18ned, some people will want 
to go in the ZMI and directly change action titles or description in 
their own single language.


The only problem I see with making these fields i18ned are encoding 
issues. Besides of that your use case should work with msgids as well: 
If there are no translations the default string is used.


Nevertheless I like your idea to use an empty i18n domain for the 
backwards compatible "don't translate" mode.


If there are no important use cases for more fine grained settings I'd 
like to add *one* i18n_domain property per TypeInfo / Action and 
hardcode the set of properties that are delivered as msgids if 
i18n_domain is not empty.



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Hi Dieter!


Dieter Maurer wrote:

yuppie wrote at 2005-8-9 19:11 +0200:


...
2.) Using different domains for different products:

While 'cmf_default' should be used by the core products (CMFCore, 
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for 
CMFCalendar.



Can we give "CMFCore" its own domain?

We would like to use "CMFCore" without any reference to
"CMFDefault".



Are you concerned about imports from CMFDefault or do you see a need to 
ship CMFCore with its own translations?


My plan was to define this in CMFCore.utils::

  CMFCoreMessageID = MessageIDFactory('cmf_default')

That way there is no need to import something from CMFDefault but 
CMFCore translations will have the 'cmf_default' domain.



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Florent Guillaume wrote:

Dieter Maurer wrote:


yuppie wrote at 2005-8-9 19:11 +0200:


...
2.) Using different domains for different products:

While 'cmf_default' should be used by the core products (CMFCore, 
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for 
CMFCalendar.




Can we give "CMFCore" its own domain?

We would like to use "CMFCore" without any reference to
"CMFDefault".



Frankly I hate domains. The less domains there are, the better. Myself, 
I'd much rather have a single "cmf" domain for everything in CMF. Let 
addon frameworks like Plone or CPS add their own for their own use, but 
I think it's folly to have several domains for pure CMF packages.


Does that mean you are voting against using 'cmf_calendar' in CMFCalendar?

The reason why I'd like to use a different domain for CMFCalendar is 
that CMFCalendar is our example add-on product. This way we *use* 
different domains for Actions and TypeInfos within the CMF, showing how 
to do that and making sure it works.



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Jens Vagelpohl wrote:
Does that mean you are voting against using 'cmf_calendar' in  
CMFCalendar?


The reason why I'd like to use a different domain for CMFCalendar  is 
that CMFCalendar is our example add-on product. This way we  *use* 
different domains for Actions and TypeInfos within the CMF,  showing 
how to do that and making sure it works.



Is it our example add-on product? It's not been all that well- 
maintained to be deserving of that status... ~8-0


I didn't say it is a good and well-maintained example.

But the first sentence of CMFCalendar/README.txt says:
"The CMFCalendar product is an example of creating a CMF Product."

In history it showed how to use an External Method to install an add-on 
product and CMF 1.5 shows how to use an extension profile for that task.



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: [dev] i18n improvements - a proposal

[yuppie]

Hi Dieter!


Dieter Maurer wrote:

If would be nice if the message catalog translating
CMFCore term were independent from the (probably much larger)
CMFDefault catalog. Especially, we would like to continue to deploy
our application without a need to include the CMFDefault product.

If this does not interfere with giving CMFCore the domain
"cmf_default", then I do not have objections to use this
domain for "CMFCore" as well.


AFAICT a separate 'cmf_core' domain would be the best solution to 
support your use case, but


a) at the moment there is only *one* MessageID in CMFCore. If more 
messages are converted to MessageIDs depends on contributed patches / 
bug reports.


b) it is easy to split the domain at a later point.

c) we are currently cheating with portal_status_messages sent through a 
redirect. CMFDefault always translates them in the cmf_default domain.


d) Florent voted against it.


Can you nevertheless have a small message catalog for CMFCore
terms and another one for CMFDefault?


I'm afraid not. At least not now. But with a small script you should be 
able to extract a CMFCore message catalog yourself.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: GenericSetup split off from CMFSetup

[yuppie]

Tres Seaver wrote:

[...]
I think that this split ("framework" in GenericSetup, CMF-specific
policy in CMFSetup) might make the overall approach used in CMFSetup
more widely useful.  I can see that making CMF dependent on a non-core
package would be tricky;  can anyone point out other issues, or suggest
workarounds?


There are other CMF features that are also distributed as standalone 
products. FileSystemSite and CookieCrumbler come to my mind. Maybe all 
these products should live in the CMF repository and CMF should depend 
on them instead of duplicating code?


Recently, I also thought about splitting of a generic part from 
CMFSetup. Trying to write handlers for portal_catalog I found that at 
least 90% of the work has nothing to do with the CMF and handlers for 
generic Zope objects like ZCatalog and indexes would be better located 
in the Zope core.



BTW, I did add a new feature (import from tarballs) to GenericSetup;  if
the CMF community can't see a way to use GenericSetup, I will look at
porting that feature back to CMFSetup (it shouldn't be too hard).


Great. How ever the dependencies are resolved - this should become part 
of the CMF.



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup

[yuppie]

Hi Pete!


computing project wrote:
I was looking at CMFSetup, and was thinking of writing a handler for one 
of the tools that isn't covered at the moment, to familiarise myself 
with how it all works in a useful way.


Great! But please be aware of the fact that CMFSetup is still fast 
changing code. Some things might work different in CMF 1.6.


Is anyone working on the 
import/exports that aren't marked as done?


I have some portal_catalog handler fragments in my sandbox. So maybe you 
better choose an other tool. Picking something from importVarious (as 
Florent proposed) is a good idea.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: RFC: Flon functionality ported to CMF?

[yuppie]

Hi!


whit wrote:

Yes.  The current roadmap[1] calls for updating the CMF itself to
exploit Z3-via-Five in a number of ways;  such a UI would be very useful
in that effort.  It might even be useful *without* the catalog stuff
(but I haven't looked at what the exact dependencies are).



A primary reason for the plip was the exposure of apidoc within Plone.

Also, iirc, yuppie was talking about creating a more general framework 
for using stub interfaces, and it would be nice to roll all of these 
efforts into one at the lowest possible level.


Right. I have a working prototype that adds an 'interfaces' tab to most 
Zope objects in the ZMI. But finishing this has low priority for me and 
there are still some unresolved issues:



1.) It depends on zope.app.introspector, but the introspector is 
deprecated in Zope 3.1.


http://mail.zope.org/pipermail/zope3-dev/2005-March/013763.html says 
marker interfaces are YAGNI. Looks like this should be discussed with 
Zope 3 people.



2.) All empty interfaces are addable as marker interfaces, but there are 
many empty interfaces that aren't useful as marker interfaces.


I guess we need a more explicit way to specify marker interfaces.


AFAIR (didn't look at Flon for a while) Flon has the same issues.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements

[yuppie]

Florent Guillaume wrote:

Geoff Davis wrote:


I'm sure I won't do Stefan's work full justice (feel free to chime in,
Stefan!).  The most important thing in my mind that ZopeTestCase does is
to make it simpler to set up your test fixture.  ZopeTestCase creates a
new folder to work in, adds a user folder, and creates a user.  It
provides methods to log in and out, to set permissions assigned to a 
role,

and to set roles assigned to users.

We ship a subclass of ZopeTestCase with Plone called PloneTestCase.  An
instance of PloneTestCase creates a Plone site for you, installs a base
set of associated products, creates two members of the site, one with
Manager role and one with Member role, and creates folders owned by 
each. It provides convenience methods for importing and installing
additional products, for logging in as given member, and so on.  



However this kind of default fixture actually is quite heavy, and makes 
you write tests that are hardly "unit" anymore. They are still good 
integration tests, but I've found that using PortalTestCase or something 
like that is often extremely costly in terms of time spent running the 
tests.


Agreed. Nevertheless we should focus on lowering the barrier of entry 
for new CMF contributors. People used to write tests for Zope or Plone 
will have less trouble if they can use ZopeTestCase. And ZopeTestCase 
tests are definitely better than no tests at all.


On the other hand I'm not sure if it is a good idea to use 
PortalTestCase (shipped with ZopeTestCase):


PortalTestCase is in the wrong layer. It makes assumptions about the way 
CMF works. Changes to the CMF might break PortalTestCase and create a 
dependency on a new Zope release. (We saw that problem already with the 
_refreshSkinData changes in CMF 1.5)


Cheers, Yuppie


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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup

[yuppie]

Hi!


computing project wrote:
I've written handlers for the cookie crumbler and for the mailhost - not 
exactly rocket science but actually very informative as they are pretty 
simple (well, the simplest!) tools.  I started off looking at all the 
code, and found that I didn't need to look at most of it to get things 
working.  I also feel like I've also come up with a bit of a methodology 
that's useful to follow when trying to write handlers, so I will write 
up a brief HowTo at some point - grateful for some feedback on this.  No 
unit tests yet though...


Great! Copy'n'paste and search'n'replace are your friends if you want to 
create unit tests ;) The handler tests are all very similar...



Some vague questions though:

- in what way is the setup tool code 'likely to change'.  i'm interested 
to find out more about what's planned, and also how to make the setup 
scripts less brittle?


Looks like the setup handlers registered via export_steps.xml and 
import_steps.xml will be replaced by adapters. Tres is working on a 
proposal for that and the portal_catalog code in my sandbox also uses 
adapters. This means that handlers will have to provide a new interface.


Besides of that I'm experimenting with reading / writing settings 
directly from / to a DOM fragment. The result is less code that is 
hopefully easier to write and maintain.


Other handler related issues that come to my mind:

- We need a reporting/logging machinery (seems to be covered by Tres' 
proposal if I interpret his example correctly). Handlers have to be more 
verbose.


- We might need more import modes, currently just 2 modes are supported: 
"purge" and "don't purge". The behavior for these modes has to be 
implemented within the handlers.


All these things still have to be discussed.

- i found it tricky that i couldn't look at some sort of schema for the 
inout/output of an import/export step: there is some information which 
is only captured in zpt templates.  is this something useful to think 
about more?  i also wondered if attaching types into the schema would 
make the import configuration simpler (e.g. i could specify in the 
schema that a property should be interpreted as an integer, and not in 
the import configurator: which would make it easier to read).


The dicts returned by _getImportMapping() have a proprietary format but 
they are similar to schemas. We can't use those dicts for exporting 
because zpts don't allow to use dynamic element names.


Given the variety of object factories and mutators in the CMF/Zope2 
world I tend to get rid of any framework for importing/exporting XML and 
to manipulate/read the DOM directly.


- in cmf core + default, the mailhost is just referenced by 
self.MailHost.  Should this be a getToolByName?  and/or should the 
MailHost be a unique object so the id doesn't change?  and should we 
always assume it's a child of the portal object?  i wasn't sure what the 
'correct' way to reference it was, to ensure it was available to import.


MailHost is a Zope "tool", not a CMF tool. If we don't want to subclass 
MailHost we can't use UniqueObject. But using getToolByName() sounds 
like a good idea.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements

[yuppie]

Dieter Maurer wrote:

yuppie wrote at 2005-9-5 14:06 +0200:


...
PortalTestCase is in the wrong layer. It makes assumptions about the way 
CMF works. Changes to the CMF might break PortalTestCase and create a 
dependency on a new Zope release. (We saw that problem already with the 
_refreshSkinData changes in CMF 1.5)



It is not better to fix such problems at a single place ("PortalTestCase")
rather than in lots of individual tests (that happen to make similar
assumptions)?


Seems I didn't make my point clear:

I wasn't arguing against PortalTestCase. The problem is that 
PortalTestCase is shipped with Zope, not with the CMF. But the correct 
implementation of PortalTestCase depends on the CMF version. Using 
PortalTestCase creates a circular dependency between Zope and CMF.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] [dev] CMF trunk dependencies

[yuppie]

Hi!


If there are no objections I'll make Zope 2.8.1 the required platform 
for CMF trunk/1.6 and remove the Zope 2.8.0 backwards compatibility code.


Reasons:

- I hope some day CMF-tseaver-z3_interfaces-branch will be finished and 
merged. To do that right we need the new Interfaces.bridge.


- PluginIndexes, ZCTextIndex and ZCatalog have some new interfaces that 
are useful to write portal_catalog setup adapters.


- The recently added i18n MessageIDs are ignored in Zope 2.8.0.


Cheers,

    Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Hi Geoff!


Geoff Davis wrote:

I have checked my CachingPolicyManager improvements into the
geoffd-cachingpolicymanager-branch.  Enjoy!


Great!

Some feedback regard formal aspects:

- Please make sure your checkins show up on the CMF-checkins list. Don't 
know if Tres can fix that for you or if you've got to register for that 
list.


- Please don't forget to set svn:eol-style and svn:keywords Id for new 
files.


- Tests are easier to find and maintain if they are located in 
test_.py. Most CMF tests follow that pattern.



PS  Those of you who raised concerns about ZopeTestCase causing test
problems in Zope 2.7 might want to take a look at why test_z3interfaces is
broken when you run the tests with zopectl test.


1.) Why "those of you who raised concerns about ZopeTestCase"?

2.) Please note that I raised concerns about using PortalTestCase.

3.) Please be more specific. I can't reproduce any problems with 
test_z3interfaces.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Jens Vagelpohl wrote:


On 8 Sep 2005, at 11:08, yuppie wrote:


PS  Those of you who raised concerns about ZopeTestCase causing test
problems in Zope 2.7 might want to take a look at why  
test_z3interfaces is

broken when you run the tests with zopectl test.


1.) Why "those of you who raised concerns about ZopeTestCase"?


I raised a concern that Zope 2.7 does not come with ZopeTestCase, so  
the test that uses it should not raise an error or failure condition.  
There should not be any failures when you download a vanilla Zope  2.7.x 
and CMF 1.5.x and run the unit tests, unless there is a real  software bug.


I know. My question wasn't *who* those people are but *why* it is more 
likely that those people might want to take a look at the 
test_z3interfaces issue.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Hi Geoff!


Geoff Davis wrote:

On Thu, 08 Sep 2005 12:08:23 +0200, yuppie wrote:

- Tests are easier to find and maintain if they are located in 
test_.py. Most CMF tests follow that pattern.



Yes, I put the tests relating to new CachingPolicyManager functionality
into test_CachingPolicyManager.py.  The other tests I added were
integration tests that check how CachingPolicyManager interacts with
FSPageTemplate.py.  I didn't really think those tests were appropriate for
either test_CachingPolicyManager.py or test_FSPageTemplate.py.  Instead I
put them in test_Template304Handling.py, and I tried to convey the
functionality being tested in the file name.  I'm open to other naming
suggestions, though.


Ok. I see your point.

In the first place those tests seem to test CachingPolicyManager 
features, so I would have added them to test_CachingPolicyManager.py. 
But maybe that's just me.



PS  Those of you who raised concerns about ZopeTestCase causing test
problems in Zope 2.7 might want to take a look at why test_z3interfaces is
broken when you run the tests with zopectl test.


2.) Please note that I raised concerns about using PortalTestCase.


Knock! Knock! Anybody there?

I told you twice that I'm concerned about using PortalTestCase:
http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html

Would be nice to get some feedback. Obviously you don't share those 
concerns. What do you propose to do if changes in CMF make a new version 
of PortalTestCase necessary?


Florent also raised (different) concerns about using PortalTestCase:
http://mail.zope.org/pipermail/zope-cmf/2005-September/022917.html

3.) Please be more specific. I can't reproduce any problems with 
test_z3interfaces.



Yeah, sorry to sound cranky here -- I'm in the middle of a nasty
deployment.


Accepted.


I put in some effort getting my tests to degrade quietly for
Zope 2.7 only to find some other Zope 2.7 problems with the tests.  It
could be it's my setup, though -- I'm not sure.  When running the tests
with a fresh checkout of the 1.5 branch on Zope 2.7.7 using

bin/zopectl test --dir Products/CMFCore/tests

I get a bunch of errors like the following:

==
ERROR: test_z3interfaces (CMFCore.tests.test_ActionInformation.ActionInfoTests)
--
Traceback (most recent call last):
  File "/home/zope/plonedev/Products/CMFCore/tests/test_ActionInformation.py", 
line 60, in test_z3interfaces
from Products.CMFCore.interfaces import IActionInfo
ImportError: cannot import name IActionInfo

I don't see IActionInfo defined anywhere in interfaces, so I don't think
it's just me.


The z3interfaces tests are based on the assumption that Five is 
available if zope.interface is available. Five creates IActionInfo 
dynamically on startup.


That's obviously not true in your setup. Looking again at these tests it 
would be more robust to include the interface imports in the try/except 
ImportError statement.



One other frustration: I was able to run my new tests in isolation, but
when I ran the whole test suite, they failed.  The problem appears to be
that somehow some things that happen in test_ActionProviderBase.py are not
being cleaned up before test_Template304Handling.py.  Some items placed in
the CMFSetup profile registry in test_ActionProviderBase.py are still
present when test_Template304Handling.py runs.  I added a workaround that
clears out profile_registry, but that shouldn't be necessary.  I don't
know if the problem is with the test runner or with
test_ActionProviderBase.py, but it's definitely bad that state from one
test is affecting another.  This problem appeared in both Zope 2.7.7 and
Zope 2.8.1.


I guess ZopeTestCase installs again products that are already installed. 
The registry raises errors if the same product is registered twice.


Not sure how to resolve this.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Sidnei da Silva wrote:
| The z3interfaces tests are based on the assumption that Five is 
| available if zope.interface is available. Five creates IActionInfo 
| dynamically on startup.
| 
| That's obviously not true in your setup. Looking again at these tests it 
| would be more robust to include the interface imports in the try/except 
| ImportError statement.


For the records, I had other tests failing for the same reason in
PAS. It's common to have zope.interface but not five if you install
twisted in Ubuntu it has a dependency on the python-zope-interface
package or something.


Ok. I'll change those tests.

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Hi Geoff!


Geoff Davis wrote:

On Thu, 08 Sep 2005 19:24:51 +0200, yuppie wrote:


Knock! Knock! Anybody there?

I told you twice that I'm concerned about using PortalTestCase:
http://mail.zope.org/pipermail/zope-cmf/2005-September/022891.html

Would be nice to get some feedback. Obviously you don't share those 
concerns. What do you propose to do if changes in CMF make a new version 
of PortalTestCase necessary?

[...]


Perhaps I wasn't clear earlier when I said that I thought we should ship
our own CMFDefaultTestCase with the CMF?  If I am understanding you
correctly, shipping a CMF-specific CMFDefaultTestCase should address your
dependency concerns.


???

Are you aware of the fact that test_Template304Handling.py depends on 
PortalTestCase? Do you plan to change that before merging your branch?



One other frustration: I was able to run my new tests in isolation, but
when I ran the whole test suite, they failed.  The problem appears to be
that somehow some things that happen in test_ActionProviderBase.py are not
being cleaned up before test_Template304Handling.py.  Some items placed in
the CMFSetup profile registry in test_ActionProviderBase.py are still
present when test_Template304Handling.py runs.  I added a workaround that
clears out profile_registry, but that shouldn't be necessary.  I don't
know if the problem is with the test runner or with
test_ActionProviderBase.py, but it's definitely bad that state from one
test is affecting another.  This problem appeared in both Zope 2.7.7 and
Zope 2.8.1.


I guess ZopeTestCase installs again products that are already installed. 
The registry raises errors if the same product is registered twice.


Not sure how to resolve this.



I believe that ZopeTestCase has some way of avoiding double imports since
we have big test suites in Plone that all do their own imports.  I don't
know the details, but perhaps Stefan Holek would?  I am not so sure it is
a ZopeTestCase specific problem -- perhaps things have been running fine
to date only because test_ActionProviderBase.py is the only test that does
these kinds of imports.


Two observations:

- The traceback in 
http://mail.zope.org/pipermail/zope-cmf/2005-September/022933.html shows 
that products *are* installed twice. This has nothing to do with a 
specific test like test_ActionProviderBase.py. This seems to be a 
general problem with running ZopeTestCase tests and other tests side by 
side.


- Even with your workaround the tests are failing if run together with 
CMFCalendar tests. Looks like the skin changes in 
CalendarRequestTests.setUp are not cleaned up correctly.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements

[yuppie]

Hi Stefan!


Stefan H. Holek wrote:
PortalTestCase is actually only intended as a base class for  
CMFTestCase/PloneTestCase/CPSTestCase/whatever, not for direct use.  It 
provides some default behavior, because, for example, the  requirement 
to refresh the skin cache is pretty hard to figure out.  The 
ZopeTestCase philosophy is about convenience and "plumbing  included".


I am committed to keeping things up-to-date. Please make me aware of  
breakage, I am going to address everything that might come up.


That's great, but that doesn't resolve the problem:

If changes like the _refreshSkinData change in CMF 1.5 are made in CMF, 
tests are broken until there is a new Zope version with a new 
PortalTestCase that reflects these changes. CMF would depend on that new 
Zope version.



On 5. Sep 2005, at 14:06, yuppie wrote:

PortalTestCase is in the wrong layer. It makes assumptions about  the 
way CMF works. Changes to the CMF might break PortalTestCase  and 
create a dependency on a new Zope release. (We saw that problem  
already with the _refreshSkinData changes in CMF 1.5)



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements

[yuppie]

Hi Stefan!


Stefan H. Holek wrote:
Well, you are supposed to use a subclass anyway, and in that subclass  
you can fix everything, even _refreshSkinData.


Sure there are ways to work around the problems. But nevertheless Zope 
should not contain code that requires knowledge about the CMF.


Maybe I should make  
PortalTestCase truly abstract to emphasize the point.  
NotImplementedError anyone? :-)


What ever helps to convince Sidnei and Geoff not to check in tests that 
use PortalTestCase directly ;)



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

yuppie wrote:
- Even with your workaround the tests are failing if run together with 
CMFCalendar tests. Looks like the skin changes in 
CalendarRequestTests.setUp are not cleaned up correctly.


Just checked in a fix for this. (1.5 branch and trunk)

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Geoff Davis wrote:

On Fri, 09 Sep 2005 11:33:53 +0200, yuppie wrote:


Are you aware of the fact that test_Template304Handling.py depends on 
PortalTestCase? Do you plan to change that before merging your branch?



Yes, I am aware of that fact.  No, I am not planning to change it -- it
works just fine.  I am sure that if the CMF changes as substantially as
you are worried about, there will be numerous things that will need to
change. I'm not sure that it is time well spent trying to fix things that
may or may not happen at some unspecified point in the future.  However,
if you feel sufficiently strongly about it, the code is in SVN and you are
more than welcome to work on it.


I'm still -1 on merging the branch as it is and Stefan confirmed that 
PortalTestCase should not be used directly: 
http://mail.zope.org/pipermail/zope-cmf/2005-September/022932.html


But I don't have to decide about that so I'll shut up now.

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CachingPolicyManager improvements checked in to svn

[yuppie]

Tres Seaver wrote:

Jens Vagelpohl wrote:


I'm still -1 on merging the branch as it is and Stefan confirmed  that
PortalTestCase should not be used directly: http://
mail.zope.org/pipermail/zope-cmf/2005-September/022932.html



Lets work on replacing the PortalTestCase in Testing.ZopeTestCase with a
abstract 'SiteTestCase' in CMFCore.tests.base.testcase, and a concrete
'DefaultSiteTestCase' someplace like CMFDefault.tests.common.  We can
then have Stefan follow through with deprecating PTC in Zope 2.8, and
removing it in 2.9.  In the meanwhile, for backward compatibility, we
might need to be willing to monkey patch
Testing.ZopeTestCase.PortalTestCase, if it is present, to use our new
version.


How about a compromise: I'll spend a little time tomorrow rewriting 
that test module so it does not use ZopeTestCase at all.



Excellent.  Another option would be to move the test into CMFDefault,
where it might be appropriate to use 'DefaultSiteTestCase'.



The changes on this branch are good and valuable, and a final  decision
and implementation of the extended testing fixtures problem  will
probably take a while...



I'd really like to second Jens here.  Geoff's contribution here is a
real win, and only incidentally provoked this rather extended wrangle
about how to do the testing properly.  At least in part, this wrangle
has been useful, as it is forcing us to think hard about how we manage
our dependencies;  we've been doing that informally, (but have messed
up, too) but don't have any writeup of the "Right Way" to write and run
tests within the various pieces of the CMF.

If we are going to expand participation (e.g., to welcome contributions
from Plone folks), we need to be careful that we set and keep the tone
with which we receive those contributions appropriate. Writing up the
"developer's crib sheet" would help, so that we had something objective
describing how we do development;  focusing on encouraging / fostering
new CMF developers will help, too.  Keeping the discussion positive is
something we can all do to make the community more welcoming.


+1 for everything

And a big applause for Geoff and Jens! Their joined effort made 
CachingPolicyManager and the CMF a better piece of software.


Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Schedule query: CMF 2.0 Roadmap chat

[yuppie]

Tres Seaver wrote:

I'd like to have some public chat about the "CMF 2.0" roadmap, in
particular resolving issues which impact the "downstream" applications /
frameworks (CPS and Plone, particulary).  Will Monday at 15:00 Zulu work
for everyone?

Where: irc://irc.freenode.net/#zope-cmf
When:   Monday, 9/12, 15:00-16:00 UTC

I'll send out an announcement later today with details, assuming nobody
has a serious objections.


No objections here. I'll be there.

Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup vs. factory_type_information

[yuppie]

Hi Jens!


Jens Vagelpohl wrote:

Here's some food for thought about a possible code simplification:

I was looking at the (annoying) duplication of configuration data  
between CMFSetup type information XML files and  
factory_type_information structures stored inside python modules. It  
would be cool if the XML files could completely remove the need to  have 
a factory_type_information, and that seems to be the case (mostly).


That would be a big win and we are coming closer to the point where we 
can do that. Not only for FTI data, but also for other settings like 
Actions and workflows.


I noticed that when I pass an empty tuple as the "fti" argument to  
ContentInit everything seems to work as expected. The only  shortcoming 
I found was the fact that inside the TypesTool, when you  select 
"Factory Type Information" from the ZMI add list, my type is  not 
showing up anymore, which makes sense. If you want to get the  type, you 
can use the portal_setup tool.


Using the setup tool for tasks like that is not easy. You can't select 
settings for a specific portal type and use them for your new type info 
object.


I hope the pending CMFSetup refactorings will make it easier to extract 
specific settings from profiles and to make them selectable in the add 
forms for tools, FTIs and workflows. (Just like complete profiles are 
selectable in the site add form.)


Would it make sense to remove all those factory_type_information  
structures for those types in CMF that have been converted to  CMFSetup? 
Would there be any bad consequences that I'm not seeing?


1.) I like the feature that allows to create pre-configured FTIs/STIs 
and I don't think CMFSetup makes that feature obsolete.


2.) manage_addCMFSite and PortalGenerator are deprecated, but they still 
depend on the oldstyle FTI data.


3.) It might be easier to discuss this in the context of Tres' CMFSetup 
and roadmap proposals.



Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: CMFSetup vs. factory_type_information

[yuppie]

Hi Jens!


Jens Vagelpohl wrote:


On 11 Sep 2005, at 17:22, yuppie wrote:

The Actions thing is another issue that I noticed today. On the  trunk, 
we seem to have "old style" actions on some tools (I  specifically 
looked at the Membership and Memberdata tools because  I'm re-doing 
CMFLDAP) that are not being used at all because they are  now new-style 
actions in the Actions tool, and indeed those tools are  not even 
registered as action providers anymore. Any objections to  removing 
those old-style actions from tools that are no longer set up  as action 
providers?


+1

I hope the pending CMFSetup refactorings will make it easier to  
extract specific settings from profiles and to make them selectable  
in the add forms for tools, FTIs and workflows. (Just like complete  
profiles are selectable in the site add form.)



I'm assuming the "settings" you mean here would be the equivalent of  
being able to instantiate CMFSetup-controlled types manually in the  
Types tool without going to the Setup tool? Yes, that functionality  is 
missing. What's the ETA on those refactorings? Sounds interesting.


I have some ideas, but I don't know exactly what Tres is working on and 
what the discussions of the next 2 weeks (CMF 2.0 roadmap, CMF/Five 
sprint) will bring. So I just could speculate at the moment.


I didn't mean that the refactorings will bring such a functionality out 
of the box. I just said I'm hopeful that implementing it becomes easier.


So in the end it looks like while we're retaining FTIs in CMF for  
backwards compatibility (thus already providing the answer to one  
question) it is perfectly safe for me in my products to do away with  
them. That was the implied question ;)


Yes. That should be perfectly safe.


Cheers,

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Small CMFCatalogAware refactoring

[yuppie]

Sidnei da Silva wrote:

On Mon, Sep 12, 2005 at 01:46:00PM +0200, Jean-Marc Orliaguet wrote:
| Julien fixed a bug. Only poorly designed software implements hardcoded
| references to paths ('portal_catalog'). And he needed it to implement a
| separate catalog for portlets. So let's move on

Sorry, but I totally disagree with that. CMFCatalogAware is not the
only place that has references to portal_catalog. There are a couple
other references spread around CMF. Either you come up with a CMF-wide
fix and a proposal, or you make that change somewhere else.

I, for once, would instead make 'getToolByName' hookable so that it
can return a different 'portal_catalog' based on whatever constraints
you need to distinguish which catalog to use, and then ensure
'getToolByName' is used all around where a catalog is needed.


+1

Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests

[Zope-CMF] Re: Small CMFCatalogAware refactoring

[yuppie]

Tres Seaver wrote:

Julien's refactoring is not a bugfix, but a refactoring, intended to
allow the possibility of using more than one catalog.


Julien Anguenot wrote:

It's speculation at this
stage. Note, we do *not* support multiple catalogs yet. This is
something we *could* support if eventually some people here are
interested to discuss it.



I'm a bit confused:

Was this change made to support multiple catalogs or not? And how does 
that explain the new _getWorkflowTool() method?



Cheers, Yuppie

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

See http://collector.zope.org/CMF for bug reports and feature requests