[Zope-CMF] CMF Collector: Open Issues

2005-12-15 Thread tseaver
The following supporters have open issues assigned to them in this collector
(http://www.zope.org/Collectors/CMF).

Assigned and Open


  efge

- CMFSetup: provide non-ascii im- and exports,
  [Accepted] http://www.zope.org/Collectors/CMF/292


  jens

- Discussion replies removal,
  [Accepted] http://www.zope.org/Collectors/CMF/391


  mhammond

- Windows DevelopmentMode penalty in CMFCore.DirectoryView,
  [Accepted] http://www.zope.org/Collectors/CMF/366


  regebro

- fiveactionstool broken (Zope 2.9/3.2),
  [Accepted] http://www.zope.org/Collectors/CMF/392


Pending / Deferred Issues

- CMFCalendar weekday locale issue,
  [Pending] http://www.zope.org/Collectors/CMF/237

- Wrong cache association for FSObject,
  [Pending] http://www.zope.org/Collectors/CMF/255

- CMFSetup: Windows exports contain CR/LF, LF and even CR newlines,
  [Pending] http://www.zope.org/Collectors/CMF/266

- FSPropertiesObject.py cannot handle multiline input for lines, text 
attributes,
  [Pending] http://www.zope.org/Collectors/CMF/271

- PortalCatalog.ZopeFindAndApply should probably also search in 
opaqueItems,
  [Pending] http://www.zope.org/Collectors/CMF/296

- Can't invalidate skin items in a RAMCacheManager,
  [Pending] http://www.zope.org/Collectors/CMF/343

- CMFSetup: Workflow Tool export fails with workflows which have scripts,
  [Pending] http://www.zope.org/Collectors/CMF/373

- CMFCore.Skinnable.SkinnableObjectManager can merge skin data,
  [Pending] http://www.zope.org/Collectors/CMF/375

- Proxy Roles does't work for a Script using portal_catalog.searchResults,
  [Pending] http://www.zope.org/Collectors/CMF/380

- WorkflowAction deprecated warning should not printed for WorkflowMethod,
  [Pending] http://www.zope.org/Collectors/CMF/388

- workflow notify success should be after reindex,
  [Pending] http://www.zope.org/Collectors/CMF/389

- came_from and VIRTUAL_URL problem,
  [Pending] http://www.zope.org/Collectors/CMF/393

- DCWorkflow - Transition Guards - Documentation Bug,
  [Pending] http://www.zope.org/Collectors/CMF/394


Pending / Deferred Features

- Favorite.py: queries and anchors in remote_url,
  [Pending] http://www.zope.org/Collectors/CMF/26

- Allow flexible date editing in Event.py (CMFCalendar),
  [Pending] http://www.zope.org/Collectors/CMF/40

- DefaultDublinCore should have Creator property,
  [Pending] http://www.zope.org/Collectors/CMF/61

- Make changeFromProperties accept sequences too,
  [Pending] http://www.zope.org/Collectors/CMF/99

- path criteria on Topic should honor VHM,
  [Pending] http://www.zope.org/Collectors/CMF/111

- Document.py: universal newlines,
  [Pending] http://www.zope.org/Collectors/CMF/174

- Permissions in PortalFolder: invokeFactory(),
  [Pending] http://www.zope.org/Collectors/CMF/175

- Add condition for transition's action like other action,
  [Pending] http://www.zope.org/Collectors/CMF/207

- Major action enhancement,
  [Pending] http://www.zope.org/Collectors/CMF/232

- portal_type is undefined in initialization code,
  [Pending] http://www.zope.org/Collectors/CMF/248

- Action._listsActions() should be more safe,
  [Pending] http://www.zope.org/Collectors/CMF/253

- Expose Document text_format metadata,
  [Pending] http://www.zope.org/Collectors/CMF/285

- customization of type of homefolder on creation,
  [Pending] http://www.zope.org/Collectors/CMF/288

- Allow contentFilter to use review_state,
  [Pending] http://www.zope.org/Collectors/CMF/294

- CMFTopic Does Not Cache,
  [Pending] http://www.zope.org/Collectors/CMF/295

- Wishlist: a flag that tags the selected action.,
  [Pending] http://www.zope.org/Collectors/CMF/301

- CMFDefault should make use of allowCreate(),
  [Pending] http://www.zope.org/Collectors/CMF/340

- Nested Skins,
  [Pending] http://www.zope.org/Collectors/CMF/377

- CatalogVariableProvider code + tests,
  [Pending] http://www.zope.org/Collectors/CMF/378

- manage_doCustomize() : minor additions,
  [Pending] http://www.zope.org/Collectors/CMF/382



___
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: CMF GenericSetup log levels

2005-12-15 Thread Chris Withers

yuppie wrote:
1.) It would be nice to have a policy for Zope. If the Zope core 
officially supports the BLATHER level (not just in the deprecated zLOG 
module) I'm fine with using it in GenericSetup as well.


It doesn't, ZODB has a mapping for it but it's a stupid name left over 
from before the same timeframe as STUPID_LOGGER and some of the wacky 
error messages that ZServer used to spit out. I really want it to die :-(


Python has .info and .debug.

If this stuff is useful and normal people will want to know it, it 
should be at info.


If it's not really that interesting and is only useful when there's a 
problem, it should be at .debug


2.) So far IWriteLogger just defines methods that are also used by the 
python logging Logger. If we add a blather method we can no longer use 
the python logger as a replacement.


Hmmm, this sounds odd. Why does IWriteLogger even exist if it just 
mirrors the python logging interface?


3.) I don't think all messages should have the same logging level. E.g. 
if there are problems that will cause broken setups WARNING might be 
appropriate.


No, .error is what you want here.

.warning is for things that are problems but which don't result in 
broken setups.


Messages that report the success of export steps are a 
candidate for DEBUG.


Agreed, although a summary logged at info at the end would be nice...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
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 pretty XML

2005-12-15 Thread yuppie

Hi Florent!


Florent Guillaume wrote:

On 14 Dec 2005, at 10:51, yuppie wrote:

Florent Guillaume wrote:
Can I fix the pretty xml exporter to use standard identing? (2 
spaces for tags, 4 for attributes)


AFAICS nothing is broken and we don't have a policy for that. So I 
would not call it a 'fix'.


After having a closer look at this I agree that PrettyDocument is broken 
because it doesn't respect the 'indent' argument of toprettyxml() in all 
places. I have a fix for this in my sandbox, but svn.zope.org is down.


2 spaces make it easier to read XML files with 2 or 3 levels of 
indentation, but if the whitespace eats up a significant part of the 
complete width and triggers additional line wrapping, I don't think 
it's a win.


I doubt we'll have more than 2 or 3 levels of indentation in profiles.


I tried to keep the indenting in sync with the HTML templates which have 
much deeper levels. But I forgot about the ZCML files. That means that 
we already have different patterns in use.


I don't know where the indenting standard you mention is defined and 
you didn't provide any other arguments for that change.


It's the standard chosen by Zope (used in all .zcml files for instance, 
or in component.xml files), and based on standard indenting observed in 
the XML world, and default indenting levels in most editors.


It's a pain to edit the profiles in an editor and have them not indent 
properly.


I change my vote to -0 if

- this is no decision about the HTML templates in CMF

- all profile XML on the 1.6 branch and trunk is updated, including the 
XML examples in unit 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


Re: [Zope-CMF] Re: GenericSetup pretty XML

2005-12-15 Thread Jens Vagelpohl


On 15 Dec 2005, at 10:39, yuppie wrote:
After having a closer look at this I agree that PrettyDocument is  
broken because it doesn't respect the 'indent' argument of  
toprettyxml() in all places. I have a fix for this in my sandbox,  
but svn.zope.org is down.


I just fixed svn.zope.org.

jens

___
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 GenericSetup log levels

2005-12-15 Thread Florent Guillaume

Chris Withers wrote:

yuppie wrote:
1.) It would be nice to have a policy for Zope. If the Zope core 
officially supports the BLATHER level (not just in the deprecated zLOG 
module) I'm fine with using it in GenericSetup as well.



It doesn't, ZODB has a mapping for it but it's a stupid name left over 
from before the same timeframe as STUPID_LOGGER and some of the wacky 
error messages that ZServer used to spit out. I really want it to die :-(


Stupid is in the eye of the beholder. You don't like something that's useful 
for others so you want it to die. Congratulations for your openmindedness. 
And you apparently can't grasp the idea that there can be different levels 
of informativeness.



Python has .info and .debug.

If this stuff is useful and normal people will want to know it, it 
should be at info.


There's no such thing has normal people. There are many profiles. And at 
different times the same person may want to read information at a more 
detailed level than usual. Just INFO and DEBUG is not enough.


Florent

--
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of RD
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
___
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 GenericSetup log levels

2005-12-15 Thread yuppie

Hi Chris!


Chris Withers wrote:

yuppie wrote:
1.) It would be nice to have a policy for Zope. If the Zope core 
officially supports the BLATHER level (not just in the deprecated zLOG 
module) I'm fine with using it in GenericSetup as well.


It doesn't, ZODB has a mapping for it but it's a stupid name left over 
from before the same timeframe as STUPID_LOGGER and some of the wacky 
error messages that ZServer used to spit out. I really want it to die :-(


It doesn't right now, but AFAIR the discussion on zope-dev ended without 
a clear result. The question if BLATHER should die isn't CMF specific in 
any way, so I don't want to discuss it on this list.


2.) So far IWriteLogger just defines methods that are also used by the 
python logging Logger. If we add a blather method we can no longer use 
the python logger as a replacement.


Hmmm, this sounds odd. Why does IWriteLogger even exist if it just 
mirrors the python logging interface?


Feel free to contribute a patch if you think this could be implemented 
in a cleaner way. I don't have the time to figure out how to use the 
Python logger for the reports created by the setup tool. The current 
implementation is a wrapper around the Python logger which adds a copy 
of all messages to the _messages list of the setup context.


3.) I don't think all messages should have the same logging level. 
E.g. if there are problems that will cause broken setups WARNING might 
be appropriate.


No, .error is what you want here.


No, WARNING is what I want here.

.warning is for things that are problems but which don't result in 
broken setups.


By 'broken setups' I meant e.g. if you loose some catalog indexes on 
export/import because no handler exists for those index classes. This is 
a problem you should know about, but maybe you don't care or you fix 
that by hand.



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 GenericSetup log levels

2005-12-15 Thread Chris Withers

yuppie wrote:
By 'broken setups' I meant e.g. if you loose some catalog indexes on 
export/import because no handler exists for those index classes. This is 
a problem you should know about, but maybe you don't care or you fix 
that by hand.


Ah, okay, I kinda agree here, and don't feel strongly enough about it to 
argue :-)


Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
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 GenericSetup log levels

2005-12-15 Thread Chris Withers

Hi Tres,

Tres Seaver wrote:


No, it isn't, at least in Zope.  BLATHER is intended to be summary
information, useful for developers but not important enough to show by
default.  DEBUG is for more detailed information, and TRACE is for
completely overwhelming detail.


Show me the docs in zope and I'll believe that's not just your 
interpretation ;-)



Sure it is ;-) You seem to be confusign .info with .warning. If your
funny customers get scared by stuff at .info, then change their log
level in zope.conf to warning, then they won't bug you so much and in
turn get you bugging the rest of us to log at the wrong levels ;-)


Your misunderstanding of Zope's levels is clearly present in that
sentence, Chris.


Oh? Please explain...

Chris

--
Simplistix - Content Management, Zope  Python Consulting
   - http://www.simplistix.co.uk
___
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 GenericSetup log levels

2005-12-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Withers wrote:
 Florent Guillaume wrote:
 
 Stupid is in the eye of the beholder. You don't like something that's
 useful for others so you want it to die. Congratulations for your
 openmindedness. And you apparently can't grasp the idea that there can
 be different levels of informativeness.
 
 
 Are you honestly telling me that warning, info, debug, error and
 critical aren't enough?
 
 debug is the same as blather, just with a more meaningful name...

No, it isn't, at least in Zope.  BLATHER is intended to be summary
information, useful for developers but not important enough to show by
default.  DEBUG is for more detailed information, and TRACE is for
completely overwhelming detail.

 Python has .info and .debug.

 If this stuff is useful and normal people will want to know it, it
 should be at info.


 There's no such thing has normal people. There are many profiles. 
 
 
 Yeah, that's why we have configurable log levels in zope.conf ;-)
 
 And at different times the same person may want to read information at
 a more detailed level than usual. Just INFO and DEBUG is not enough.
 
 
 Sure it is ;-) You seem to be confusign .info with .warning. If your
 funny customers get scared by stuff at .info, then change their log
 level in zope.conf to warning, then they won't bug you so much and in
 turn get you bugging the rest of us to log at the wrong levels ;-)

Your misunderstanding of Zope's levels is clearly present in that
sentence, Chris.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDoaCB+gerLs4ltQ4RAuJmAJsFmyaDr30bpVyMzHlviX3hOjgp/wCgxBwU
raBfALEsvV/RoQHKNsXYEDM=
=Hq2n
-END PGP SIGNATURE-

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

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