Re: [Zope-dev] (optional) CSRF protection in zope.formlib

2013-09-18 Thread Leonardo Rochael Almeida
Hi Jan-Wij,

+1 for implementing convenient CSRF.

I wonder if you could make your implementation more orthogonal by
implementing a CSRF field/widget, and make your `protected` attribute
simply trigger the inclusion of this field implicitly.

This way you wouldn't need to change the `*pageform.pt` templates like you
do now, and `setupToken()`/`checkToken()` would move to the widget code.

Cheers,

Leo


On Wed, Sep 18, 2013 at 11:41 AM, Jan-Wijbrand Kolman janwijbr...@gmail.com
 wrote:

 Hi,

 I've been working on CSRF protection for zope.formlib.

 I have a csrfprotection branch in my zope.formlib fork on github. The
 changes against the current zope.formlib mainline can be found here:

 https://github.com/**janwijbrand/zope.formlib/**compare/csrfprotectionhttps://github.com/janwijbrand/zope.formlib/compare/csrfprotection

 When creating form components based on zope.formlib.form.FormBase, one can
 enable this protection just by setting the attribute ``protected`` to True
 on the component.

 This implementation is based on the following assumptions:

 * We do not want to keep server-side state(!)

 * An attacker that attempts CSRF cannot get to information stored in
 cookies that are meant for the domain of the (forged) request.

 * The token stored in the cookie is sufficiently random and long, to be
 practically unguessable by the attacker.

 * The form submit is deemed valid as long as the token in the cookie is
 identical to a hidden input value that is part of the form submit.

 My questions:

 * Do you find this feature useful enough to be, in principle, included in
 zope.formlib?

 * I'd like to kindly request someone to review my branch and provide
 feedback.

 The included test cases describe a few more questions and concerns about
 this implementation.

 Thank you in advance!

 kind regards, jw

 __**_
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/**listinfo/zope-devhttps://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
 https://mail.zope.org/mailman/**listinfo/zope-announcehttps://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/**listinfo/zopehttps://mail.zope.org/mailman/listinfo/zope)

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] five.grok - svn

2013-04-11 Thread Leonardo Rochael Almeida
Thanks!

On Thu, Apr 11, 2013 at 10:37 PM, Stephan Richter
stephan.rich...@gmail.com wrote:
 On Wednesday, April 10, 2013 04:43:17 PM Leonardo Rochael Almeida wrote:
 Can anyone please migrate five.grok to GitHub?

 Done.

 Regards,
 Stephan
 --
 Entrepreneur and Software Geek
 Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] five.grok - svn

2013-04-10 Thread Leonardo Rochael Almeida
Hi repository specialists,

Can anyone please migrate five.grok to GitHub?

Some people have fixes for it, but don't want to touch SVN ever again,
like its some sort of plague...

Thanks in advance!

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Python 3 support status page

2013-01-28 Thread Leonardo Rochael Almeida
Cool, looks nice!

On Mon, Jan 28, 2013 at 3:27 PM, Marius Gedminas mar...@gedmin.as wrote:
 I wanted to have an up-to-date status page for the status of the Python
 3 porting efforts of various zope-ish packages, so I made one:
 http://zope3.pov.lt/py3/

 Source for the data extraction bits: https://github.com/mgedmin/ztk-py3-status
 Source for the presentation bits: use View Source in your browser.

 Marius Gedminas
 --
 http://pov.lt/ -- Zope 3/BlueBream consulting and development

 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Status of github migration

2013-01-10 Thread Leonardo Rochael Almeida
Hi Jens,

On Thu, Jan 10, 2013 at 11:47 AM, Jens Vagelpohl j...@dataflake.org wrote:


 [...] All other repositories (Zope, Products.*) were test migrations where I 
 asked for feedback and never got any. They are throw-away and not final. The 
 only finished migrations are yours and Tres'.

I've been overly busy with these last couple of monks with job
change/country relocation/new year, so I couldn't review those
migrations before.

I took a quick look at the Zope migration now and I think it's
excellent. The only thing I'd add is that I'd also migrate branches
2.12 and 2.13 branches since they're all active, even if just for
bug/security fixes.

Having those branches means that back/forward-porting fixes is easier.
Although we could always recreate the branches based on the tags,
which were also nicely migrated.

I think you mentioned this before, but I couldn't find it in a quick
archive search, but which script did you use for those migrations?

Thanks for all the work! And thanks also for the very nice mirror at:
git.zope.org

Cheers,

Leo


 jens




 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] DateTime issues with negative offsets

2012-12-09 Thread Leonardo Rochael Almeida
Here's Guido's official explanation for the divmod behaviour:

http://python-history.blogspot.com.br/2010/08/why-pythons-integer-division-floors.html

IMHO we should treat negative offsets specially, doing the divmod()
with -60 in that case.

Regards,

Leo

On Fri, Dec 7, 2012 at 5:22 PM, Juan A. Diaz nue...@ravvit.net wrote:

 secconds / 60
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] AccessControl C extension, ExtensionBase, Cylic memory and tp_traverse

2012-11-06 Thread Leonardo Rochael Almeida
Hi Silvain,

Thanks for the deep analysis. Did you put this code in a branch
somewhere for us to take a look?

Cheers,

Leo

On Tue, Nov 6, 2012 at 2:54 PM, Sylvain Viollon sylv...@infrae.com wrote:
 Hello,

 I recently find out I had a memory leak in Silva, with Python 2.7. After 
 playing a while with various tools (objgraph is nice), I found out I leaked 
 between two and three objects at every request:

- an AccessControl.SecurityManagement.SecurityContext instance,

- two bound methods to ZopeSecurityPolicy.validate and 
 ZopeSecurityPolicy.checkPermission.

 Of course, those leaks disappears as soon as I use the Python 
 implementation for the security instead of the one in C. And I have tested it 
 as well with various older versions of AccessControl, and have the same 
 behavior.

 Looking closely at the code, I see that those objects are used internally 
 by the SecurityManager. The SecurityManager is implemented in C, using the 
 facilities provided by ExtensionClass. The SecurityManager properly implement 
 the method dealloc, and it is correctly called. However, since it holds 
 objects managed by the Python garbage collector (namely one called context 
 that is an instance of  AccessControl.SecurityManagement.SecurityContext, one 
 called policy, that is an instance of ZopeSecurityPolicy, and a two last ones 
 that are the bound methods ZopeSecurityPolicy.validate and 
 ZopeSecurityPolicy.checkPermission), it should implements the tp_traverse 
 method, but it doesn't. This is not done because ExtensionClass uses the slot 
 for tp_traverse to store something else (namely what goes in tp_methods 
 later).

 In a local checkout of AccessControl, I converted the SecurityManager C 
 code not to rely on ExtensionClass anymore, but use the 'new object' C API, 
 that is mostly equivalent to ExtensionClass, and implemented the tp_traverse 
 method. This fixed my memory leak.

I propose you to commit my code in a branch, and after review to merge it 
 with the branch 2.13 and the trunk of AccessControl.

I don't see any argument against not using ExtensionClass anymore for 
 SecurityManager, and it might be possible to convert some other classes to 
 the 'new object' C API too. I can have a look at it.

Regards,

Sylvain,

 --
 Sylvain Viollon -- Infrae
 t +31 10 243 7051 -- http://infrae.com
 Hoevestraat 10 3033GC Rotterdam -- The Netherlands



 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] libmysqlclient_r.so.15: cannot open shared object file: No such file or directory

2012-10-29 Thread Leonardo Rochael Almeida
Hi,

This is the mailing list to discuss development of Zope itself. It's
not strictly a support mailing list. You should likely contact:
https://mail.zope.org/mailman/listinfo/zope

In any case, by googling [libmysqlclient_r.so.15 centos 6]

I found this page:

http://forum.teamspeak.com/showthread.php/63894-libmysqlclient-so-15-not-found

Which explains how to install the MySQL-shared-compat package which
likely contains the library you need.

In any case, you don't describe what you actually did to migrate zope
from CentOS 5 to 6, but it looks like you simply copied a number of
files from one machine to another.

You should recompile your MySQL-Python bindings for a newer version of MySQL.

Regards,

Leo

On Mon, Oct 29, 2012 at 9:40 AM, Babylakshmi Muthusamy
babylaks...@ibioinformatics.org wrote:
 Hi,

 I have migrated zope from Cent OS 5 to 6. Now I am getting the following
 error when I try to save or run external method using mysql:

 Error Type: ImportError
 Error Value: libmysqlclient_r.so.15: cannot open shared object file: No such
 file or directory

 Any help to fix this is highly appreciated.

 Thanks,
 Babylakshmi

 --

 Babylakshmi Muthusamy
 Ph.D. student
 Institute of Bioinformatics
 7th Floor, Discoverer Building
 International Technology Park
 Bangalore - 560 066
 India
 Ph: +91-80-28416140



 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: Zope/branches/2.12/ LP #1047318: Tighten import restrictions for restricted code.

2012-09-10 Thread Leonardo Rochael Almeida
On Mon, Sep 10, 2012 at 8:09 AM, Hanno Schlichting ha...@hannosch.eu wrote:
 On Mon, Sep 10, 2012 at 10:31 AM, yuppie y.2...@wcm-solutions.de wrote:
 CMF uses some ZTUtils in restricted code: Batch, LazyFilter, make_query and
 SimpleTreeMaker. The new Zope 2 releases (2.12.24 and 2.13.17) are not
 compatible with existing CMF releases. Is this intended?

 This wasn't intended.

I agree these should have not been restricted.

 CMF could declare the ZTUtils it uses as public. But that would require new
 CMF releases for the new maintenance releases of Zope. And other packages
 might have the same problem.

 ZTUtils is part of Zope2 and clearly intended for use inside templates
 / restricted code. So it should be fixed there.

 Were the restrictions tightened too much in Zope?

 I'm not sure. There isn't really any clear documentation on what APIs
 you are supposed to use. It seems ZTUtils.__init__ sets
 __allow_access_to_unprotected_subobjects__ = 1 on the module scope
 level. But it doesn't use the allow_module or ModuleSecurityInfo APIs.
 I'm guessing this is all historical baggage and the proper APIs were
 only created much later.

 Maybe some other long term developers can chime in with their perspective?

Without digging much in the history, I'm inclined to agree with this
analysis. I think the new APIs should be used, and tests added, to
make sure these ZTUtils utilities are available from restricted code.

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] (no subject)

2012-09-10 Thread Leonardo Rochael Almeida
Zope4 Lille Sprint 2012 Report

The first thing we did was discuss the state of contributions to the
Zope codebase, specially in light of many vocal members of the
community that would like to use GitHub (and other members, less
numerous but equally vocal, who would not like to use GitHub at all,
but still want to use Git).

Jens started investigating the options and will report to the Foundation board.

Then we started reviewing the current state of various existing
branches that try to advance the state of Zope trunk. Laurence rebased
some previously existing parent pointers work onto the current Zope
trunk, and Leonardo worked on restoring a minimal Welcome page on a
just installed Zope instance that would not involve adding more
persistent objects.

We then took stock of what work is already done or is sufficiently
advanced that we could reasonably expect to be ready soon:

 - WSGI as the only publisher, moving transaction handling back into
it (i.e. a pure Zope4 wsgi app without any other middleware should be
complete). This will likely be folded back into Zope 2.13.

 - Parent pointers - need to specify a minimum migration strategy,
which should not require modifying all objects in your instance
(mostly for objects looked up by C.A.: local site manager,
utilities...)

 - Lots of stuff removed already

 - Decide on egg name (Zope2 currently, ideally it should be Zope)

 - ZMI tidy up (not removal, for this release).

 - WebOb based request

 - Remove Session and TemporaryFolder.

Nice to have (i.e. if we have manpower to develop):

 - Use Chameleon and drop old ZPT implementation, but only if Plone
has shipped with it by then (to be sure incompatibilities are fixed.)

 - Don't use docstrings to control publishing.


The expectation is to be able to release a Zope4 alpha by the end of the year.

Next sprint will be at the Plone Conference in Arnhem, focussing on
WSGI and merging branches.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope 4 Sprint Report [was: (no subject)]

2012-09-10 Thread Leonardo Rochael Almeida
Sorry for the missing subject. Hit Send too fast.

On Mon, Sep 10, 2012 at 4:51 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 Zope4 Lille Sprint 2012 Report

 The first thing we did was discuss the state of contributions to the
 Zope codebase, specially in light of many vocal members of the
 community that would like to use GitHub (and other members, less
 numerous but equally vocal, who would not like to use GitHub at all,
 but still want to use Git).

 Jens started investigating the options and will report to the Foundation 
 board.

 Then we started reviewing the current state of various existing
 branches that try to advance the state of Zope trunk. Laurence rebased
 some previously existing parent pointers work onto the current Zope
 trunk, and Leonardo worked on restoring a minimal Welcome page on a
 just installed Zope instance that would not involve adding more
 persistent objects.

 We then took stock of what work is already done or is sufficiently
 advanced that we could reasonably expect to be ready soon:

  - WSGI as the only publisher, moving transaction handling back into
 it (i.e. a pure Zope4 wsgi app without any other middleware should be
 complete). This will likely be folded back into Zope 2.13.

  - Parent pointers - need to specify a minimum migration strategy,
 which should not require modifying all objects in your instance
 (mostly for objects looked up by C.A.: local site manager,
 utilities...)

  - Lots of stuff removed already

  - Decide on egg name (Zope2 currently, ideally it should be Zope)

  - ZMI tidy up (not removal, for this release).

  - WebOb based request

  - Remove Session and TemporaryFolder.

 Nice to have (i.e. if we have manpower to develop):

  - Use Chameleon and drop old ZPT implementation, but only if Plone
 has shipped with it by then (to be sure incompatibilities are fixed.)

  - Don't use docstrings to control publishing.


 The expectation is to be able to release a Zope4 alpha by the end of the year.

 Next sprint will be at the Plone Conference in Arnhem, focussing on
 WSGI and merging branches.
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] We need to change how code ownership works.

2012-08-20 Thread Leonardo Rochael Almeida
Hi,

On Mon, Aug 20, 2012 at 11:09 AM, Lennart Regebro rege...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 10:28 AM,  j...@nexedi.com wrote:
 This approach protects from:
 - legal risks posed by github

 Such as?

I'll let Jean-Paul elaborate, but I suppose it could be something
along the lines of GitHub suddenly disappearing with (some of) your
content (code, forum posts, metadata like group associations) or
making some other unwanted use of it, and you having no legal recourse
because of some small print in some EULA somewhere that someone didn't
bother to fully read.

 - instabilities due to ever changing fashion in code hosting (sourceforce 
 then google code then bitbucket then github then etc.)

 Sure. At the cost of a lot of extra complexity, that is.

 - destruction, traceability or security issues posed by cloud infrastructure 
 not controlled by ZF (logs, bugs,  forums, not only code)

 What would these be.

c.f.: 
https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation

The point is not that these can't happen to ZF repos, but that ZF
would have no recourse to fix the issue except to wait on GitHub to
act on it.

 This approach enforces:
 - freedom for fashion victims to follow latest fashions

 Making it easy to contribute is not a fashion but a fundamental part
 of how good open source works.

Yes, and both you and I are around long enough to remember when
SourceForge w/ SVN was the easiest way to get others to contribute,
which is why Plone originally selected it. Now it's GitHub and git.

By fashion JP doesn't meant to say that the selection was frivolous,
but that the same criteria can lead to selection of different
tools/services at different points in time.

In any case, this discussion seems to be converging, which is
excellent. It is also one of those discussions that could be solved in
less than an hour by folks talking over beverage, but takes a ton of
attention bandwidth and time when discussed over e-mail.

So I'd like to reinforce Vincent Pelletier's invitation to the Zope4
sprint that is going to be hosted in Lille next week[1] for which both
Jens Vagelpohl and Laurence Rowe have confirmed their presence.

[1] http://www.erp5.org/Zope4Sprint2012

I'm sure we can hash out a solution that works for everybody in a very
short amount of time.

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: drop interactive feature of zdaemon

2012-06-11 Thread Leonardo Rochael Almeida
Speaking of handling command line options and eventually having (or
not) an interactive interpreter, I'd like to point out Michele
Simionato's plac.

http://plac.googlecode.com/hg/doc/plac.html

Just to throught it out there...

On Tue, Jun 5, 2012 at 4:06 PM, Fred Drake f...@fdrake.net wrote:
 On Tue, Jun 5, 2012 at 10:00 AM, Jim Fulton j...@zope.com wrote:
 I (and many people I know) find the interactive feature of
 zdaemon annoying.  I'd like to drop it, both to reduce annoyance
 and to reduce the amount of code to maintain.

 I've never found this a useful feature.

 +1


 --
 Fred L. Drake, Jr.    fred at fdrake.net
 A storm broke loose in my mind.  --Albert Einstein
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zope.file/branches/ulif-fix-menus/ Do menu-related configuration only if z.a.zcmlfiles is available.

2012-06-03 Thread Leonardo Rochael Almeida
+1 for merging

On Mon, May 28, 2012 at 11:16 AM, Uli Fouquet u...@gnufix.de wrote:
 On Sun, 27 May 2012 21:09:44 -0400 Tres Seaver wrote:

 On 05/27/2012 07:36 PM, Ulrich Fouquet wrote:
 Log message for revision 126504: Do menu-related configuration only if
 z.a.zcmlfiles is available.

 Changed: U   zope.file/branches/ulif-fix-menus/CHANGES.txt U
 zope.file/branches/ulif-fix-menus/src/zope/file/browser.zcml

 Hmmm, looks like you forgot to 'svn add src/zope/file/menu.zcml'.

 I was convinced I did, but apparently I didn't. It's in now.

 Thanks for the hint!

 The branch (ulif-fix-menus) could be reviewed now, although there is not
 much to review.

 I didn't manage to create a reasonable regression test for the use case,
 as it seems to be very difficult and complex to remove some installed
 package and make it temporarily unimportable.

 If someone has an idea how to do this with not too much effort, I'd be
 glad to add it. Simply changing sys.modules and sys.path seems not to be
 enough.

 If this test would be not crucial, I'd leave it this way and prepare a
 minor release, maybe with some additional changes (the buildout.cfg is a
 bit outdated and test coverage could be improved otherwise).

 Best regards,

 --
 Uli


 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Remove zmi_views menus from zope.file?

2012-05-27 Thread Leonardo Rochael Almeida
Hi Uli,

Thanks for taking care of this.

IMHO:

Move to a conditional include of a menu.zcml that (or include a
menu.zcml file that conditionally) registers the browser menus for
zmi_views and release a new minor version, declaring an extra
dependency on the packages that provides zmi_views. With this, release
a new minor version that will be backward compatible, due to the
conditional.

Then release a new major version that removes the include and the
conditional. Add to README the instructions for manually including
menu.zcml if this functionality is needed.

If you get tired, do just one of the above :-)

Regards,

Leo

On Sun, May 27, 2012 at 3:52 PM, Uli Fouquet u...@gnufix.de wrote:
 Hi there,

 zope.file still registers browser menus for `zmi_views` in its
 browser.zcml. This is a problem if you don't have/want the ZMI but want
 to use zope.file otherwise (IMHO it also means an undeclared dependency,
 as none of the packages zope.file declares to depend on really provides
 this browser menu AFAICS).

 I see that it is easy to register such a menu yourself but it annoys and
 confuses people new to Grok/Zope.

 I'd therefore like to remove these registrations from zope.file, make it
 at least conditional, or move it to some `menu.zcml` or similar, not
 included automatically by z3c.autoinclude and friends.

 Is there a reason why that shouldn't happen? If not: what way would be
 the best in your opinion (removal/conditional/menu.zcml)?

 Best regards,

 --
 Uli


 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Remove zmi_views menus from zope.file?

2012-05-27 Thread Leonardo Rochael Almeida
Hi Uli,

Not sure if you wanted to remove zope-dev from copy on purpose, but
what we talk about below is probably of general interest...

On Sun, May 27, 2012 at 4:38 PM, Uli Fouquet u...@gnufix.de wrote:
 Hi Leo,

 nice to hear from you, I hope you are well :-)

I'm fine, thanks for asking! :-) Hope you're doing fine as well...

 On Sun, 27 May 2012 16:16:43 +0200 Leonardo Rochael Almeida wrote:

 IMHO:

 Move to a conditional include of a menu.zcml that (or include a
 menu.zcml file that conditionally) registers the browser menus for
 zmi_views and release a new minor version, declaring an extra
 dependency on the packages that provides zmi_views. With this, release
 a new minor version that will be backward compatible, due to the
 conditional.

 Then release a new major version that removes the include and the
 conditional. Add to README the instructions for manually including
 menu.zcml if this functionality is needed.

 If you get tired, do just one of the above :-)

 Yep, I planned in the same direction. The problem, however, is the
 condition. The 'condition:zcml' directive, AFAICS, only asks for
 existence of packages or features. But in the zope.file (or zmi_views)
 case I'd have to ask for zope.app.menus.zmi_views (which wouldn't be a
 package nor a feature).

 Furthermore if one asks for a package as condition, that could be wrong
 as people could define a zmi_views menu elsewhere and then the
 registrations should be included (okay, on the other hand one could tell
 them to include the menus.zcml manually then).


I guess we could argue that whoever provides the zmi_views menu should
provide a respective feature.

 Oh, and I haven't found out yet, which package exactly normally provides
 the zmi_views menu. Do you know it by any chance?

I tried to locate it as well, but failed. What I could discover is
that whichever distribution provides this will likely include a menu
id=zmi_views ... directive somewhere.

Since you mentioned on the grok list that previous versions of grok
could work with zope.file, then perhaps you can search the eggs/
directory for this directive.

Good hunting, and please keep us informed.

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Adding broken/missing support to zope.interface? (was: experimental.broken - Graceful handling of broken interfaces and components in the ZODB)

2012-04-08 Thread Leonardo Rochael Almeida
Not ZCA/ZODB maintainer, but a big +1 from me.

I've also experienced the negative effects of missing code for
(marker) interfaces in persistent data.

Cheers,
Leo

On Sun, Apr 8, 2012 at 22:04, Ross Patterson m...@rpatterson.net wrote:
 experimental.broken is working well for me.  It greatly aided me in
 getting through a particularly nasty upgrade allowing me to cleanup the
 ZCA cruft left by poorly behaved add-ons.  I'd like to proceed with
 adding the core of this to zope.interface and I need the
 developers/maintainers to weigh in.

 The first and most fundamental matter is changing interface pickles such
 that they can be unpickled into something that can fulfill the minimum
 interface contract and don't break the ZCA.  To that end, I'd like to
 add the following to zope.interface.interface:

    ...
    try:
        from ZODB.broken import find_global
        from ZODB.broken import IBroken
        def find_interface(modulename, globalname,
                           Broken=IBroken, type=InterfaceClass):
            
            Find a global interface, returning a broken interface if it can't 
 be found.
            
            return find_global(modulename, globalname,
                               Broken=IBroken, type=InterfaceClass)
    except ImportError:
        IBroken = Interface
        def find_interface(modulename, globalname,
                           Broken=IBroken, type=InterfaceClass):
            
            Find a global interface, raising ImportError if it can't be found.
            
            # From pickle.Unpickler.find_class
            __import__(module)
            mod = sys.modules[module]
            klass = getattr(mod, name)
            return klass
    ...
    class InterfaceClass(Element, InterfaceBase, Specification):
    ...
        def __reduce__(self):
            if self is IBroken:
                return self.__name__
            return (find_interface, (modulename, globalname))
    ...

 With this change, previously existing interface pickles will be
 different from newly committed ones but both pickles would unpickle to
 the same object.  Also, running zodbupdate would convert all pickles to
 the new format.

 Is this the correct approach?  If not, how should it be changed or what
 might be the correct way?  Is there a better way to put the broken
 object support in ZODB and still have the same interface pickles when
 using ZODB?

 This still leaves the problem of instance provides declarations and
 component registrations which contain previously existing interface
 pickles for missing interfaces.  Without addressing these, previously
 existing instance pickles cannot be unpickled and all component registry
 operations fail.  experimental.broken addresses these by adding handling
 for broken interfaces when provides declaration are unpickled (in the
 ProvidesClass.__init__ method) and when component registries are
 unpickled (in the __setstate__ method of
 persistentregistry.PersistentAdapterRegistry and
 persistentregistry.PersistentComponents).  Again, with these patches,
 missing interfaces don't break instances or registries and allow running
 zodbupdate to fix all existing pickles.  Where should this support live?
 Should I keep it in a separate package, maybe just rename
 experimental.broken to z3c.broken or somesuch?  Should it be merged into
 zope.interface and zope.component?

 Will the developers/maintainers of zope.interface, zope.component and/or
 ZODB please weigh in on this and give me feedback towards getting this
 finished?

 Thanks!
 Ross

 Ross Patterson m...@rpatterson.net writes:

 I've done some more work on this and I've gotten the component
 registrations fully working now with one exception that I'm having real
 trouble with.  I'd like some help with that, more below.  I'm also a bit
 more clear on what might be appropriate to bring back into
 zope.interface and I'd like feedback on that.

 Currently interfaces are pickled as globals.  Given their centrality in
 any ZCA application, I think they should be pickled using a function:

     def __reduce__(self):
         return (find_interface, (modulename, globalname))

 where find_interface, if ZODB.broken.find_global can be imported, in
 turn calls:

     ZODB.broken.find_global(modulename, globalname,
                             Broken=IBroken, type=InterfaceClass)

 since find_global already has nicely abstracted graceful missing global
 handling.

 If this were added to zope.interface, and changed ZODB objects with
 marker interfaces or persistent registries where all the code for the
 interfaces is still available will then be updated with pickles that
 will gracefully handle missing interfaces in the future.  Thus you could
 use zodbupdate to make sure that the interfaces in your ZODB will fail
 gracefully in the future.  Do you agree/disagree that this belongs in
 zope.interface?

 What this will not address are existing interfaces-as-globals pickles
 where the original 

[Zope-dev] PyConUS sprint on Zope 4

2012-01-29 Thread Leonardo Rochael Almeida
Hi,

Anyone going to this PyConUS who would like to sprint on Zope4?

Topics of particular interest to me include security (as I explained
in a previous e-mail) and the new ZMI.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope 4 publisher/traversal, sprint topic

2011-10-27 Thread Leonardo Rochael Almeida
Hi,

Sorry for the cross-post, but I'd like to talk about a possible sprint
topic for the next DZUG sprint[1], and invite myself to it :-)

After the last two rather serious security issues that were recently
patched in the Zope2 code base, it is increasingly clear to me that,
differently than what Hanno reported some time ago, it's not so much
the ZMI that represents a huge security liability in the Zope
codebase, but it's actually the way the current publisher happily
traverses any attribute and publishes any method with docstring by
default.

The ZMI, of course, has its problems (ugly in appearance and even
uglier in code), and I agree with Hanno on most everything he has to
say about it, but I'd like to propose we start, for Zope 4, by
tackling the potential security liability that is the Zope publisher
itself, and the fact that it makes it easy to open up large security
holes if you're not paying attention.

I'd like to propose that publishing traversal in Zope 4 would, by
default only traverse based on __getitem__ (not attribute lookup). For
a minimum of backward compatibility, it could perhaps do a single
traversal on getattr, and only after it has exhausted __getitem__
traversal.

After this, if the traversal found something, it would only be
published if there is an explicit indication of intention that the
object in question is supposed to be published. Otherwise, raise a
NotFound, as if the traversal had failed.

One example of an explicit demonstration of intent is, for example, if
it provides an IPublishable interface (I just made that up, other
names can be considered).

Taking a suggestion from Shane, we could have convenient decorators
for people who wants to explicitly publish class methods. They could
dynamically create ZTK views with the same name as the function that
they wrap and allow (or perhaps enable by default) some form of CSRF
protection.

To ease code migration, we could consider that the InitializeClass
call provides the same effect as the above decorator. This would allow
large amounts of previously existing code to work without recoding,
while at the same time avoiding the security trap of forgetting to
call InitializeClass and thus exposing unintented methods. It could
even remove the need for the single getattr traversal compatibility
above.

On top of that, if InitializeClass register these views to a specific
ZTK skin, it would make it possible to disable them by default,
unless that specific skin is in effect, which would alleviate what
Hanno described as running phpMyAdmin accessible to the world with
the same credentials and on the same domain as the rest of your
application.

Anyway, I think the above is on-topic for the next DZUG sprint and I'd
like to work on it there.

So, even if the sprint is supposed to be in German, and I don't speak
a word of it, can I attend?

[1] http://www.zope.de/community/veranstaltungen/3.-dzug-sprint-2011-zmi
, translation at:
http://translate.google.com/translate?hl=ensl=autotl=enu=http%3A%2F%2Fwww.zope.de%2Fcommunity%2Fveranstaltungen%2F3.-dzug-sprint-2011-zmi

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Conversion old.zope.org to static site

2011-10-14 Thread Leonardo Rochael Almeida
Hi,

Congratulations on this move, must have been a nice technical challenge.

And although I wholeheartedly agree with it, there is a part of me
that is sad to know that the old zope.org Zope insance has been shut
down for good.

Leo

On Fri, Oct 14, 2011 at 11:35, Jens Vagelpohl j...@dataflake.org wrote:
 Hi all,

 Just as a heads-up: Jim Fulton and I have converted old.zope.org to a static 
 website. This allows ZC to decommission the hardware and reduces the 
 maintenance burden for everyone involved.

 We have tried to keep all URLs intact and the site navigation working at the 
 same time, which required a little creative thinking.

 Some of you rely on resources from the old.zope.org site, such as release 
 tarballs of older Zope versions and other products. Please test and ensure 
 the files you need are still where you expect them. If you have problems, 
 just contact me off-list and I'll take a look.

 jens


 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] disabling zope.schema constraint check in edit form

2011-08-18 Thread Leonardo Rochael Almeida
Hi Joshua,

On Thu, Aug 18, 2011 at 09:59, Joshua Immanuel j...@hipro.co.in wrote:
 [...] Worse case scenario is where I have a cancel
 action button which just redirects to another page, that too screams for
 the NameAlreadyExists error.

For the 'cancel button' case, you need to have a form action with a
validator that always validates, no matter what. You can find an
example of one such null_validator here:

https://svn.plone.org/svn/plone/plone.app.form/tags/2.0.3/plone/app/form/validators.py

To use it, you do something like

class MyForm(...):

  @form.action(..., validator=null_validator):
  def handle_cancel(self, ...)
[... do the redirect ...]

Cheers,

Leo

 [...]
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Pluggable template engine

2011-07-21 Thread Leonardo Rochael Almeida
Hi Malthe,

How often is the adaptation called?

For example, suppose a Page Template had a tal:repeat that rendered a
macro inside of it. If that tal:repeat looped 5 times, do we get 5
more adaptation calls, besides the call of the outermost Page
Template?

Just asking out of curiosity, I haven't looked at the code, other than
the interface link you posted.

Cheers,

Leo

On Wed, Jul 20, 2011 at 17:24, Malthe Borch mbo...@gmail.com wrote:
 I've refactored the ``pagetemplate`` module to realistically support
 plugging in an alternative implementation of the parser and
 interpreter.

  http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/

 Two new interfaces are added which serve as the plugging point see
 ``IPageTemplateEngine`` and ``IPageTemplateProgram`` in this module:

  http://svn.zope.org/zope.pagetemplate/branches/engine-as-component/src/zope/pagetemplate/interfaces.py?rev=122300view=markup

 I'd like to propose merging this into trunk.

 \malthe
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-05 Thread Leonardo Rochael Almeida
Hi Hanno,

On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote:
 On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 I would've thought it would also be possible for those who rely on this to
 maintain the relevant eggs as optional installations against Zope 2.x, no?

 The ZMI is not a package - we don't have a split into zope and
 zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates
 stops using RestrictedPython and the OFS base classes don't inherit
 from Acquisition.Implicit anymore, it'll be really hard to keep the
 legacy development approach working.

I guess this is the biggest point of contention. Why does the ZMI have
to go? Although both Plone and ERP5 strive to gradually replace ZMI
based configuration with native interfaces (native to Plone/ERP5),
isn't there value in having a minimal OFS browser with the ability to
Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to
conflict with your stated goal:

I think what's going to stay is AccessControl, OFS (a bit lighter),
ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
Zope Toolkit libraries like components, events, browser pages and so
on.

That's the kind of scope that should be possible to port to Python 3
and actually modernize enough to be understandable.(...)

Or to put it differently, in which way does having a minimalistic OFS
browser for a ZMI conflicts or hinders Plone's objectives for the
Zope2 code base?

If we still have that minimalistic ZMI, all players in our community
can decide how much effort they want to spend maintaining which legacy
pieces technology, depending on what makes economic sense to them,
without causing extra maintenance burden on the other players.

 [...]

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-04 Thread Leonardo Rochael Almeida
Hi Hanno,

From the point of view of the ERP5 codebase, this direction for Zope2
should be mostly ok, save for a few comments below:

On Sun, Jul 3, 2011 at 03:41, Hanno Schlichting ha...@hannosch.eu wrote:
 On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida
 leoroch...@gmail.com wrote:
 [...]

 I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
 or other large existing codebases, as you get support for current
 versions of the ZODB, Zope Toolkit packages and support for Python 2.7
 with Zope 2.13. Since Python 2.7 is a long-term maintenance release
 for Python itself, this should provide a stable and good basis for the
 next years - the statements from the Python community aren't
 completely clear - but I'd expect to see ongoing maintenance until
 2013 or maybe even 2015.

Yes, these were the reasons we ported to Zope 2.12 to begin with.

 Going forward I can see two paths for Zope 2. Either we don't touch it
 at all anymore and let it bitrot or we try to move it forward and
 adept it to current best practices of development. Since complete
 rewrites almost always fail, like we have seen with Zope 3 - I prefer
 changing Zope 2.

Agreed.

 If you are interested in stability I think sticking with an older
 version of Zope 2 is a completely sane and good approach. What me and
 others from the Plone community are trying to do with the Zope 2
 codebase is to actually move it forward. We can either do that as part
 of the official Zope 2 release series or fork the codebase. Since so
 far there isn't really anyone else interested in working on the Zope 2
 codebase, we keep changing Zope 2 without forking it.

With the direction the Zope2 codebase has taken so far, I don't see
any reason to fork it even if all current players keep depending on
it.

 But can you explain to us a little of how you expect Zope2 to behave
 with the changes you're doing?

 There's a number of things I want to do. Not sure when I'll or others
 will have the time, but these are things I expect to happen in the
 next months or releases:

 - Continue to remove functionality tailored for TTW development, like
 SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
 - Document and use the WSGI publisher and remove obsoleted
 functionality like the virtual host monster, error_log,
 ZServer/medusa, zopectl/zdaemon

In ERP5, we've made TTW development sane and safe, and integrated with
VCSs (both SVN and Git), so the above paragraph sounds  a little bit
scary, though in reality it doesn't have to be.

SiteRoot, AccessRules, HelpSys, of course, are really unused, so I
don't fear their disappearance.

As for the rest, most of the things that have been removed from core
were done in such a way that they can still be used with Zope2, so
ERP5 can happily keep using them. If things can keep evolving with
this care we should be ok.

As others have pointed out, the core url rewriting functionality of
VHM is useful even in a WSGI context, and I'd argue that it should
actually be made part of the root Application, so that we don't need a
persistent object just for this.

On the other hand, if we could get the ZTK version of this working
(the one that used /++vh-host and /++vh-root url segments) I think it
should be ok, and we could get rid of VHM completely.

 - Make the browser id manager, session data manager, temporary storage
 optional and remove it and request.SESSION from the core, instead we
 can use something based on Products.BeakerSessionDataManager /
 collective.beaker if someone has a need for sessions
 - Start using and storing parent pointers and remove
 Acquisition.Implicit from the most common base classes (a branch for
 this already exists with almost all core tests passing)

ERP5 will probably get rid of all its uses of acquisition too at some
point. We've recently taken a large step in this direction, but again,
it can still be used as an add-on, so this is not a problem.

 - Merge five.pt (Chameleon) into the core and use it instead of the
 zope.tal/zope.tales implementation (which means no more
 RestrictedPython for templates).

A few months ago, I and Malthe did some work to make sure that TTW
ZPTs worked with five.pt. Malthe even surprised me with something that
I thought couldn't possibly work and managed to get the
RestrictedPython evaluator to translate python expressions in TTW
ZPTs. So, getting rid of RestrictedPython is not strictly necessary
for using five.pt in Zope2 core.

Then again, we might decide to get rid of it for other reasons...

Anyway, as long as there are still TTW addable ZPTs, PythonScripts and
ZSQLMethods, ERP5 can still work.

 - Once most of the ZMI is gone, it should be feasible to drop DTML or
 rewrite what little is left as page templates

If DTML is still available as an optional product/package, this should
not be a problem for us, but we'll likely depend on ZSQLMethods
(hence, on DTML) for a long time, since our ZSQLCatalog functionality
is built heavily around

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ Removed the last remaining code to support `SOFTWARE_HOME` and `ZOPE_HOME`.

2011-07-03 Thread Leonardo Rochael Almeida
Hi Hanno,

I haven't checked deeply, but the change below seems to break
Products.ZSQLMethods. At least there is an import in
Products.ZSQLMethod from this location. And we depend heavily on it...

Since you're already around that piece of code, would you mind moving
it over there and releasing a new version of Products.ZSQLMetods? I
would be most thankful.

Cheers,

Leo

On Sun, Jul 3, 2011 at 17:19, Hanno Schlichting hanno...@hannosch.eu wrote:
 Log message for revision 122084:
  Removed the last remaining code to support `SOFTWARE_HOME` and `ZOPE_HOME`.


 Changed:
  [...]
  U   Zope/trunk/src/App/Extensions.py
  [...]
 -
 -class NoBrains:
 -    pass
 -
 -
 -def getBrain(module, class_name, reload=0, modules=None):
 -     Check/load a class from an extension.
 -    
 -    if not module and not class_name:
 -        return NoBrains
 -
 -    if modules is None:
 -        c=getObject(module, class_name, reload)
 -    else:
 -        c=getObject(module, class_name, reload, modules=modules)
 -
 -    if getattr(c, '__bases__', None) is None:
 -        raise ValueError('%s, is not a class' % class_name)
 -
 -    return c
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Getting translation of python code string to work

2011-06-05 Thread Leonardo Rochael Almeida
Hi Morten,

 OK.  Well I have this function now:

 def _(msgid, request):
language = request['LANGUAGE']
return translate(msgid, domain='SimpleChat', target_language=language)

 Which sends all the relevant bits to the translate function.  But, this
 doesn't work either, and I can see it is because the interpolate function
 call is used in translate.

It seems you misunderstood my explanation (or I misunderstood yours),
but are you trying to use your custom _() function instead of using a
MessageFactory?

the translation() function should be used WITH the results of calling
MessageFactory() objects, not INSTEAD of them.

First you create MessageFactory() objects in your code when creating
messages, preferably as early and as little as possible. THEN, you
call translate() on them, as late as possible, and as close as
possible to the time where the translation is to be transmitted to the
user.

 So do I need to setup some utility?

In theory, IMessageDomain utilities need to be registered, but if
translations are working inside Page Templates, then this is already
the case.

These utilities need to be configured before the translate() call
happens (for example, when it is called implicitly during ZPT
rendering), but don't need to be configured yet when calling _(some
message) (assuming the _ object is a MessageFactory instance).

I hope I'm not making this even more of a mess for you to understand...

Cheers,

Leo

On Wed, Jun 1, 2011 at 09:02,  li...@nidelven-it.no wrote:
 [...]
 On Tue, May 31, 2011 at 13:19,  li...@nidelven-it.no wrote:
 Hi,

 I have a oldschool style Zope 2 product, which has an i18n
 directory containing translations.

 Using i18n:domain=SimpleChat in this product works fine in
 the page templates,

 Well, ZPTs generate message objects automatically from translated
 content, but they also explicitly translate all the message objects
 they get during interpolation between the literal parts of the
 template and the dynamically generated ones.

 but when I start translating text in
 a Python module using _(Translate me) I just get English
 text (instead of Norwegian, which is what I want).

 When you say I just get English text, what does exactly get mean
 in terms of code?

 Mind you, if you simple call unicode(message) you'll most likely only
 get the English version back. Same thing if you do:

   usome other string: %s % message

 To get an actual translation, you need to call
 zope.i18n.translate(message), eventually passing the
 target_languate=... parameter.

 Take a look at the zope.i18n module for details, specifically the
 translate() and negotiate() functions.

 OK.  Well I have this function now:

 def _(msgid, request):
    language = request['LANGUAGE']
    return translate(msgid, domain='SimpleChat', target_language=language)

 Which sends all the relevant bits to the translate function.  But, this
 doesn't work either, and I can see it is because the interpolate function
 call is used in translate.

 So do I need to setup some utility?

 -Morten


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)

2011-05-10 Thread Leonardo Rochael Almeida
Hi Andreas,

On Tue, May 10, 2011 at 06:55, Andreas Jung li...@zopyx.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi there,

 I am happy to announce that we have made progress
 with the zope.org relaunch project. The first public
 version of the new site is now available under

 http://beta.zope.org

Very nice work.

I would just like to give a small suggestion, which is to have 301
HTTP redirects from some non conflicting URL spaces on www.zope.org to
old.zope.org, so that we don't lose search engine indexing and ranking
of the old pages. Ex: the members area:

www.zope.org/Members/itamar/CorruptedZODB -
old.zope.org/Members/itamar/CorruptedZODB

This should be very easy to achieve with a small number of Redirect
Apache directives specifying permanent redirections.

Cheers,

Leo

 The basic idea behind the project is:

  - a minimalistic www.zope.org site giving a short
   overview about what Zope is - including all
   related app servers, CMSes, frameworks etc.
   which links to the related project sites (micro-site
   approach)

  - no more member contents on www.zope.org

  - the current www.zope.org will be stripped down
   to the current member contents and stuff that
   has to be preserved. www.zope.org will be
   renamed to old.zope.org later

 Constructive criticism and feedback is welcome _now_.

 I hope that we can fix the outstanding issues and integrate
 further feedback over the next few week in order to roll
 out the new site in the first half of June (2011 of course).

 Many thanks to my team (doing the real work):

 - - Michael Haubenwaller
 - - Kai Mertens
 - - Johannes Raggam

 Andreas Jung
 Zope Foundation

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.11 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQGUBAEBAgAGBQJNyMVOAAoJEADcfz7u4AZjTgoLvigFQqPKlnn9J97+wrQRJkdr
 8ErOiV6LCmpQeNLGDVodq0Y4JGnfQELu0ByzRz+xdig3NDAY9WyKTcxjJqu7DJ4H
 NnZ49dK47uvZaYbfq0kKjzIw9/FX092t5+lyVdiYst1d3JGEphz1iDsl+rySu4m1
 xf3Zq5/+HH0xl2NPQ391dqPuoka+93ydygBfqR7TbBxr4t1GcbFs6vMhN5/13I7c
 g/Q6CWCKlBOfdSnof+p1M/EHtLelst7LPHXluB5tLSQcbpbhd3vtV2x19+InNBWs
 3vbaWz9EFPQVdgrAc8f3Npw6+t1tn2JMBlLEJtwLmaErqjgDA4MMEmOmJPqNDqYo
 7fyVWy0+OFeJdrGtO6MOZvmkgTxp+DBYjCOqzhzBijoHGaBQz1RsfH8IrWqhI+Av
 PRihsjM6ZBEhVcHyW/FIQfSvsYJCsim+xxcfkmUhUjXSD6j2h4BBjNnnyI2JRHkq
 iu0A27ANzqZrHx8rRipFcU9gJqLtBfA=
 =8/ed
 -END PGP SIGNATURE-

 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)

2011-05-10 Thread Leonardo Rochael Almeida
Hi,

On Tue, May 10, 2011 at 11:52, Martijn Faassen faas...@startifact.com wrote:
 Hi there,

 On 05/10/2011 06:55 AM, Andreas Jung wrote:

 Constructive criticism and feedback is welcome _now_.

 Application servers has Zope  BlueBream.
 [...]

Speaking of

http://beta.zope.org/the-world-of-zope

We at Nexedi would appreciate if ERP5 was mentioned on that page as
well. Possibly in a Zope Based Applications section (where Zenoss
could also fit nicely). Something like:

ERP5 is a full featured Open Source Enterprise Resource Planning (ERP)
solution including customer relationship management (CRM), production
management (MRP), supply chain management (SCM), product design
management (PDM), accounting, human resources, e-commerce and many
others.

Link: http://www.erp5.com/

Thanks,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] plone 4.1: can not access plone 3.5 site after startup

2011-03-02 Thread Leonardo Rochael Almeida
I usually saw this error when some of the objects persisted in the
ZODB have references  to (i.e. they directly provide) interfaces that
are not there in the code anymore anymore, such as when an interface
class is removed or moved to another module or package.

It can be solved by providing the old interface in the same place in
the 'module/package' namespace. Or by removing the interface reference
from the object in the old environment before starting the code in the
new environment.

Incidentally, I'm of the opinion that these kinds of errors should be
captured by either zope.interface or by ZODB, logged as 'ERROR', and
the object returned without the faulty interface, but that seems to
require either adding knowledge about zope.interface to ZODB or
vice-versa.

Cheers,

On Wed, Mar 2, 2011 at 12:07, robert rottermann rob...@redcor.ch wrote:
 Hi there,
 I created a 4.1a3 buildout and added all needed products, of which I had to
 adapt some to be able to start at all.
 Then I copied the data.fs of a 3.5x site.

 Now in the ZMI, when I want to navigate to the plone 3.5 folder I get the
 following error:

 What can I do to fix that?
 Do I have to prepare the Data.fs somehow?

 thanks
 robert

 2011-03-02 11:57:55 ERROR Zope.SiteErrorLog 1299063475.730.425785426825
 http://localhost:8481/focus/focus
 Traceback (innermost last):
   Module ZPublisher.Publish, line 115, in publish
   Module ZPublisher.BaseRequest, line 437, in traverse
   Module ZPublisher.BeforeTraverse, line 97, in __call__
   Module Products.CMFCore.PortalObject, line 78, in 
 __before_publishing_traverse__
   Module zope.event, line 23, in notify
   Module zope.component.event, line 24, in dispatch
   Module zope.component._api, line 136, in subscribers
   Module zope.component.registry, line 321, in subscribers
   Module zope.interface.adapter, line 585, in subscribers
   Module zope.component.event, line 32, in objectEventNotify
   Module zope.component._api, line 136, in subscribers
   Module zope.component.registry, line 321, in subscribers
   Module zope.interface.adapter, line 585, in subscribers
   Module plone.browserlayer.layer, line 14, in mark_layer
   Module zope.component._api, line 179, in getAllUtilitiesRegisteredFor
   Module zope.component.registry, line 176, in getAllUtilitiesRegisteredFor
   Module ZODB.Connection, line 859, in setstate
   Module ZODB.Connection, line 913, in _setstate
   Module ZODB.serialize, line 613, in setGhostState
   Module zope.component.persistentregistry, line 40, in __setstate__
   Module zope.interface.adapter, line 91, in _createLookup
   Module zope.interface.adapter, line 439, in __init__
   Module zope.interface.adapter, line 476, in init_extendors
   Module zope.interface.adapter, line 480, in add_extendor
 AttributeError: type object 'IDatabaseSettings' has no attribute '__iro__'
 2011-03-02 11:57:55 WARNING OFS.Uninstalled Could not import class
 'IThemeSpecific' from module 'focus.theme.browser.interfaces'
 2011-03-02 11:57:55 WARNING OFS.Uninstalled Could not import class
 'IFocViewletManager' from module 'focus.theme.browser.interfaces'
 2011-03-02 11:57:55 ERROR ZODB.Connection Couldn't load state for 0x19746b
 Traceback (most recent call last):
   File
 /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/Connection.py,
 line 859, in setstate
     self._setstate(obj)
   File
 /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/Connection.py,
 line 913, in _setstate
     self._reader.setGhostState(obj, p)
   File
 /home/zope/focus4/eggs/ZODB3-3.10.1-py2.6-linux-i686.egg/ZODB/serialize.py,
 line 613, in setGhostState
     obj.__setstate__(state)
   File
 /home/zope/focus4/eggs/zope.component-3.10.0-py2.6.egg/zope/component/persistentregistry.py,
 line 40, in __setstate__
     self._createLookup()
   File
 /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py,
 line 91, in _createLookup
     self._v_lookup = self.LookupClass(self)
   File
 /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py,
 line 439, in __init__
     self.init_extendors()
   File
 /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py,
 line 476, in init_extendors
     self.add_extendor(p)
   File
 /home/zope/focus4/eggs/zope.interface-3.6.1-py2.6-linux-i686.egg/zope/interface/adapter.py,
 line 480, in add_extendor
     for i in provided.__iro__:
 AttributeError: type object 'IDatabaseSettings' has no attribute '__iro__'
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Bug day and developer meeting today at 15:00 UTC

2010-10-28 Thread Leonardo Rochael Almeida
This being PloneConf week, it's not surprising the attendance was even
lower than usual.

On Wed, Oct 27, 2010 at 08:55, Christian Theune c...@gocept.com wrote:
 Hi,

 On 10/26/2010 09:14 AM, Christian Theune wrote:
 [...]

 This week my job of summarizing is suprisingly easy: nothing to
 summarize as I was the only attendee of the meeting.

 So, just in case: if you're not happy with the topics I propose, please
 feel free to suggest others or just walk in. I'm happy to provide the
 regular space (and time) and am open to any issues regarding zope-dev.

 ...
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZEO TempStorage: Odd behavior on ZEO restart

2010-07-14 Thread Leonardo Rochael Almeida
On Wed, Jul 14, 2010 at 19:22, Benji York be...@benjiyork.com wrote:
 [...]

 Let me make sure I understand your setup: you have a TemporaryStorage
 running on a central server that is exposed via ZEO to clients.  Right?

 So, when the ZEO server restarts the temp storage is reset (it's
 contents don't survive a restart by design), but the clients don't know
 all the objects they know about in the temp storage just disappeared.
 Therefore when they go to load one (because it wasn't in their object or
 ZEO caches), the load fails.

 Not surprising really.

What could be surprising is that, since the objects are not in the
object cache or the ZEO cache, how can the clients 'know' about them
to request them?

And the answer is probably that there are other objects which ARE in
the object cache, or the ZEO cache and that hold references (ghost
objects in the case of the object-cache) to the objects in the
zeo-distributed temporary storage.

So, perhaps, Sebastian can avoid a Zope restart if he finds a way to
flush all caches. Flushing the object caches is easy, it's in the
Control_Panel. Flushing the ZEO cache is something else. Perhaps he
can run with a 0-sized ZEO cache for the TempStorages?

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

2010-07-13 Thread Leonardo Rochael Almeida
Hi,

The latest Zope 2.12.9 release broke the last release of Products.ZMySQLDA.

To demonstrate, bootstrap and run the attached buildout, then run:

  $ bin/py -c import Shared.DC.ZRDB, Products.ZMySQLDA

You'll get the following traceback:

Traceback (most recent call last):
  File bin/py, line 107, in module
exec _val
  File string, line 1, in module
  File 
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py,
line 90, in module
import DA
  File 
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py,
line 243, in module
os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
  File 
/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py,
line 77, in __init__
stat_info = os.stat(path)
OSError: [Errno 2] No such file or directory:
'/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'

Edit buildout.cfg and switch the extends directive to the commented
out 2.12.8 tag and see that the above command shows no error, only a
deprecation warning that is unrelated to the breakage above.

Internal buildbots that tracked the 2.12 branch notified me of this
problem, but in between catching up with all the traffic for the
mailing lists and the Zope commit, and a day job, I didn't have enough
time to track down the issue before the 2.12.9 release was made: there
was less than 4 days between spinning off Products.ZSQLMethods and the
new 2.12 release.

The most trivial fix seems fairly obvious: ZMySQLDA should carry its
own icon, but in any case, Zope 2.12 should not break compatibility in
the middle of a stable series. I strongly suspect other Zope2 DB
adapters to suffer from the same problem.

I'm not sure what the proper fix should be. App.ImageFile.ImageFile
could grow support for icons outside of software_home, or perhaps the
spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
only, but in any case the 2.12 branch should be a safe upgrade for
third party code as much as reasonably possible.

suggestions?

Cheers,

Leo


buildout.cfg
Description: application/httpd-cgi
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

2010-07-13 Thread Leonardo Rochael Almeida
Hi

On Tue, Jul 13, 2010 at 12:44, Hanno Schlichting ha...@hannosch.eu wrote:
 [...]

 You'll get the following traceback:

 Traceback (most recent call last):
  File bin/py, line 107, in module
    exec _val
  File string, line 1, in module
  File 
 /home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py,
 line 90, in module
    import DA
  File 
 /home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py,
 line 243, in module
    os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
  File 
 /home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py,
 line 77, in __init__
    stat_info = os.stat(path)
 OSError: [Errno 2] No such file or directory:
 '/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'

 The most trivial fix seems fairly obvious: ZMySQLDA should carry its
 own icon, but in any case, Zope 2.12 should not break compatibility in
 the middle of a stable series. I strongly suspect other Zope2 DB
 adapters to suffer from the same problem.

 We documented it pretty clearly in the Zope 2.12.0 release notes, that
 you can no longer rely on software home or zope home. See for example
 http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#fully-eggified

 The code should have long been changed to import Shared.DC.ZRDB and
 then os.path.join(ZRDB.__file__, 'www', 'DBAdapterFolder_icon.gif') or
 better yet use its own icon. Both of these would have worked with all
 2.12.x releases.

the call that failed is this:

ImageFile(os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))

There is no explicit mention of software home anywhere, and there
was no warning that this API was being used in a deprecated way.

In fact, the use of software home happens inside ImageFile itself:

def __init__(self, path, _prefix=None):
import Globals  # for data
if _prefix is None:
_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
elif type(_prefix) is not type(''):
_prefix=package_home(_prefix)

Of course I and most people on this list can read the ImageFile() call
above and probably get a good hunch that sofware_home is being assumed
somewhere, but a cursory reading of the call could also imply that a
data file is simply being read relative to the Zope2 package location,
and that this is supported behaviour of the ImageFile class.

 I'm not sure what the proper fix should be. App.ImageFile.ImageFile
 could grow support for icons outside of software_home, or perhaps the
 spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
 only, but in any case the 2.12 branch should be a safe upgrade for
 third party code as much as reasonably possible.

 We don't make guarantees on internals. Zope 2 always had a policy of
 allowing minor changes and new features to occur in the stable release
 series. It's not just pure bugfix releases.

And I'm not disagreeing with the policy, but it can be argued that
depending on the location of *data* files inside the Zope2 package is
not necessarily relying on guarantees on internals.

 I think in this case the code in Products.ZMySQLDA should be changed
 to be compatible with Zope 2.12.

Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
that do rely on software_home) should give a clear warning when
software_home is assumed, since it is the one assuming it. The
exception raised by the ImageFile call now gives no clue on what
actually went wrong and what a developer should do about it.

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

2010-07-13 Thread Leonardo Rochael Almeida
On Tue, Jul 13, 2010 at 14:46, Hanno Schlichting ha...@hannosch.eu wrote:
 On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida
 leoroch...@gmail.com wrote:
 And I'm not disagreeing with the policy, but it can be argued that
 depending on the location of *data* files inside the Zope2 package is
 not necessarily relying on guarantees on internals.

 I'd call anything that relies on a specific file system layout to be
 internals. We only make guarantees on the semantics of the Python
 import system, not how packages and modules are stitched together in
 distributions and end up on the file system.

Considering that the Zope source code has a dozen examples of
App.ImageFile.ImageFile being used without a prefix (ex. OFS.misc_),
I think third party developers should be excused to think they could
follow the lead and expect their packages not to break during a stable
series.

I still think we should give them at least the 2.12 series to stop
using ImageFile incorrectly without breaking their code, but I won't
belabor the point any longer.

 Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
 that do rely on software_home) should give a clear warning when
 software_home is assumed, since it is the one assuming it. The
 exception raised by the ImageFile call now gives no clue on what
 actually went wrong and what a developer should do about it.

 I agree with that. I thought the call to software home was being made
 inside ZMySQLDA and not in Zope 2 code.

The attached patch adds such a warning, and also reveals where Zope2
commits the same sins. If there are no objections I'll commit it to
2.12 and trunk.

Finally, I'd like to ask that, when major changes land in a stable
series (like the spinning off of a whole package), that we allow at
least a week or two to pass before making a release, so people who
have test runners for their apps running against a stable repository
branch have time to adapt to the changes

Cheers,

Leo
Index: src/App/config.py
===
--- src/App/config.py	(revisão 114644)
+++ src/App/config.py	(cópia de trabalho)
@@ -36,7 +36,7 @@
 def setConfiguration(cfg):
 Set the global configuration object.
 
-Legacy sources of common configuraiton values are updated to
+Legacy sources of common configuration values are updated to
 reflect the new configuration; this may be removed in some future
 version.
 
Index: src/App/tests/testImageFile.py
===
--- src/App/tests/testImageFile.py	(revisão 0)
+++ src/App/tests/testImageFile.py	(revisão 0)
@@ -0,0 +1,28 @@
+import unittest
+import App
+from Testing.ZopeTestCase.warnhook import WarningsHook
+
+
+class TestImageFile(unittest.TestCase):
+
+def setUp(self):
+# ugly: need to save the old App.config configuration value since
+# ImageFile might read it and trigger setting it to the default value 
+self.oldcfg = App.config._config
+self.warningshook = WarningsHook()
+self.warningshook.install()
+
+def tearDown(self):
+self.warningshook.uninstall()
+# ugly: need to restore configuration, or lack thereof
+App.config._config = self.oldcfg
+
+def test_warn_on_software_home_default(self):
+App.ImageFile.ImageFile('App/www/zopelogo.jpg')
+self.assertEquals(self.warningshook.warnings.pop()[0],
+  App.ImageFile.NON_PREFIX_WARNING)
+
+def test_suite():
+return unittest.TestSuite((
+unittest.makeSuite(TestImageFile),
+))
Index: src/App/ImageFile.py
===
--- src/App/ImageFile.py	(revisão 114644)
+++ src/App/ImageFile.py	(cópia de trabalho)
@@ -18,6 +18,7 @@
 import os.path
 import stat
 import time
+import warnings
 
 from AccessControl.SecurityInfo import ClassSecurityInfo
 from Acquisition import Explicit
@@ -34,6 +35,13 @@
 os.path.join(os.path.dirname(Zope2.__file__), os.path.pardir)
 )
 
+NON_PREFIX_WARNING = ('Assuming image location to be present in the Zope2 '
+  'distribution. This is deprecated and might lead to ' 
+  'broken code if the directory in question is moved ' 
+  'to another distribution. Please provide either an '
+  'absolute file system path or a prefix. Support for ' 
+  'relative filenames without a prefix might be '
+  'dropped in a future Zope2 release.')
 
 class ImageFile(Explicit):
 Image objects stored in external files.
@@ -43,9 +51,12 @@
 def __init__(self, path, _prefix=None):
 import Globals  # for data
 if _prefix is None:
-_prefix=getattr(getConfiguration(), 'softwarehome', PREFIX)
+_prefix=getattr(getConfiguration(), 'softwarehome', None) or PREFIX
+if not os.path.isabs(path

Re: [Zope-dev] SVN: Zope/branches/2.12/ ReST changes, and it's a new year already

2010-06-20 Thread Leonardo Rochael Almeida
This should've gone to zope-dev too.

On Sun, Jun 20, 2010 at 23:14, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 Hi Tres,

 That file was brand new from this year. I just copied a copyright
 boilerplate that contained 2009 and pasted into the file before adding
 it to the repository.

 On Sat, Jun 19, 2010 at 10:31, Tres Seaver tsea...@palladion.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Leonardo Rochael Almeida wrote:
 Log message for revision 113624:
   ReST changes, and it's a new year already

 Changed:
   U   Zope/branches/2.12/doc/CHANGES.rst
   U   Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py

 -=-
 Modified: Zope/branches/2.12/doc/CHANGES.rst
 ===
 --- Zope/branches/2.12/doc/CHANGES.rst        2010-06-18 19:33:34 UTC (rev 
 113623)
 +++ Zope/branches/2.12/doc/CHANGES.rst        2010-06-18 19:38:08 UTC (rev 
 113624)
 @@ -38,9 +38,9 @@
    - Missing = 2.13.1
    - Persistence = 2.13.2

 -- Added setSortKey() method to the Shared.DC.ZRDB.TM.TM class
 +- Added ``setSortKey()`` method to the ``Shared.DC.ZRDB.TM.TM`` class
    to allow database connections to specify the commit order without
 -  needing to override the sortKey() method.
 +  needing to override the ``sortKey()`` method.

  2.12.7 (2010-06-13)
  ---

 Modified: Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py
 ===
 --- Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py     2010-06-18 
 19:33:34 UTC (rev 113623)
 +++ Zope/branches/2.12/src/Shared/DC/ZRDB/tests/testTM.py     2010-06-18 
 19:38:08 UTC (rev 113624)
 @@ -1,6 +1,6 @@
  ##
  #
 -# Copyright (c) 2009 Zope Foundation and Contributors.
 +# Copyright (c) 2010 Zope Foundation and Contributors.
  #
  # This software is subject to the provisions of the Zope Public License,
  # Version 2.1 (ZPL).  A copy of the ZPL should accompany this distribution.

 We don't replace the original copyright date ever, but add new dates for
 changes which introduce copyrightable material (i.e., non-trival new
 code).  If such changes apply in this case, then the header should be:

  # Copyright (c) 2009, 2010 Zope Foundation and Contributors.



 Tres.
 - --
 ===
 Tres Seaver          +1 540-429-0999          tsea...@palladion.com
 Palladion Software   Excellence by Design    http://palladion.com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

 iEYEARECAAYFAkwcxp4ACgkQ+gerLs4ltQ78BwCfZLPDoWvWZchqo27IB34pOFH2
 R+cAn3kqAgE2Fg6TWT6/MkqjCSyjq3xb
 =/uib
 -END PGP SIGNATURE-

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] connection commit ordering

2010-06-18 Thread Leonardo Rochael Almeida
Hi Laurence

On Fri, Jun 18, 2010 at 08:06, Laurence Rowe l...@lrowe.co.uk wrote:
 On 18 June 2010 01:24, Leonardo Rochael Almeida leoroch...@gmail.com wrote:
 By the way, this issue is completely separate from the
 two-phase-commit discussion that we had recently, since all the
 connectors involved here are fully transactional.

 As you can see here:

 http://zope3.pov.lt/trac/browser/Zope/trunk/src/Shared/DC/ZRDB/TM.py

    def tpc_vote(self, *ignored):
        self._finalize = 1

    def tpc_finish(self, *ignored):

        if self._finalize:
            try: self._finish()
            finally: self._registered=0

 The transaction manager is only doing one phase commit. It sorts first
 as it commits in the second phase. If you change the sort order, you
 lose the guarantee of transactional integrity.

For me this means that TM subclasses need to override tpc_vote and
implement a proper commit preparation [1] [2] to assure they are
correctly participating in the TPC dance.

And if that is not the case, but you have, for example, more than one
MySQL connector, you are already in a situation where you can't
guarantee transactional integrity, so this discussion is actually
orthogonal to the sortOrder one.

 Perhaps a better way to solve this would be to include the zope
 transaction id in the table, then in the background thread only
 reindex the queued items with a tid = the current tid of the
 connection.

Possibly, but is there a way to know the id of a transaction that
hasn't been committed yet, to store it on MySQL? Besides, when working
with multiple mount points, you might have to store multiple TIDs, for
all storages involved, or else there should be a global transaction ID
that should be recorded everywhere, and I don't see the 'transaction'
package providing one.

In any case, does anyone oppose the existence of a .setSortKey() on
the TM class?

Cheers,

Leo

[1] http://www.postgresql.org/docs/current/static/sql-prepare-transaction.html
[2] http://dev.mysql.com/doc/refman/5.0/en/xa.html
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] connection commit ordering

2010-06-18 Thread Leonardo Rochael Almeida
On Fri, Jun 18, 2010 at 10:55, Hanno Schlichting ha...@hannosch.eu wrote:
 On Fri, Jun 18, 2010 at 3:32 PM, Leonardo Rochael Almeida
 leoroch...@gmail.com wrote:
 In any case, does anyone oppose the existence of a .setSortKey() on
 the TM class?

 Your branch looks simple enough. Feel free to merge it to Zope trunk
 but don't forget to add a change entry in doc/CHANGES.rst

Thanks. Can I commit it to Zope 2.12 as well? It is backward
compatible and helps us address a bug we see on production.

Cheers,
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] connection commit ordering

2010-06-17 Thread Leonardo Rochael Almeida
Hi,

In ERP5[1], which is CMF based, we have a number of strategies for
high performance and scalability. One of these is that we have
ZSQLCatalog extensively. The other is that we delay execution of
potentially expensive operations (like indexing) for background
execution. For the latter, we store the information about background
tasks to be executed (path to affected object, method to call,
serialization and ordering tags) in an SQL table. Background requests
(clock-server) then look up the activity table to either distribute
the tasks between the nodes of a ZEO cluster or to execute a
previously distributed task.

In one specific client with a very high volume of transactions, we
were experiencing failures in these background executions. We traced
it, among other things, to the ordering of connections during commit.
Here is what happened.

 1. An object in the ZODB
 2. the .reindexObject() method of this object schedules a task for
the real indexation to the background processes, using a ZMySQLDA
connector.
 3. The transaction machinery performs the commit, ordering the
connections according to the .sortKey() method of each connection:
3.1. All ZMySQLDA connectors involved, since their .sortKey()
returns the integer 1 (see Shared.ZRDB.TM.TM.sortKey() )
3.2. all mounted ClientStorages or FileStorages involved, whose
.sortKey()s are strings which sort after integers.

If in between 3.1 and 3.2 a background process tries to execute the
scheduled activity commited on 3.1, then it will see the new
information on the 'background-tasks' table but the object to be
indexed will not yet be in the ZODB causing the activity to fail.

The solution we found involves changing the result of .sortKey() for
the transaction manager of the database connection, but we can't do
this globally for all connectors, otherwise we could have the
connector for the SQL based catalog being committed after the
connector for the background tasks, and we would end up with a similar
error situation. The adapter for the background tasks must necessarily
commit after all data needed by the background tasks was already
committed.

By the way, this issue is completely separate from the
two-phase-commit discussion that we had recently, since all the
connectors involved here are fully transactional.

At Nexedi, we concluded that we might need to be able to customize the
sortKey() per database-adapter instance in Zope, since different
adapters might need to be committed in different order. Unfortunately
it looks like the connection sorting machinery was intended only to
obtain a consistent ordering to avoid deadlocks from competing
clients, instead of establishing dependency relationships between the
connectors, since there seems to be no standard on what the sorting
keys should be (they're integers for Shared.ZRDB.TM.TM and strings for
ZODB storages).

To make this easier without requiring reimplementation of the
.sortKey() method in all database connectors, I took the liberty of
creating a branch of Zope 2.12 [2] that adds a .setSortKey() method to
Shared.ZRDB.TM.TM and I'd welcome opinions.

In any case, we were left wondering if others have faced similar
issues with the commit order and if others have any opinions on this
problem.

Cheers,

Leo

[1] http://erp5.com/

[2] http://svn.zope.org/repos/main/Zope/branches/rochael-TM_sortKey/
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Launchpad gardening

2010-04-15 Thread Leonardo Rochael Almeida
Thanks Tres and Sidnei,

My questions were intended to go to the list anyway.

Can we take a branch from the launchpad mirror and bind it back
directly at svn+ssh://svn.zope.org/ to commit?

For instance, say I'm reviewing a bugfix proposed by someone that
doesn't currently have access to svn.zope.org but added a
merge-proposal to lp, can I branch it, bind it to
svn+ssh://svn.zope.org and then commit?

Wouldn't it be nice if it was possible?

Cheers,

Leo

On Thu, Apr 15, 2010 at 12:34, Sidnei da Silva
sidnei.da.si...@gmail.com wrote:
 On Thu, Apr 15, 2010 at 12:17 PM, Tres Seaver tsea...@palladion.com wrote:
 snip
 Finally, I push my branch up to Launchpad::

  $ bzr push lp:~tseaver/zope.interface/lp_12345

 Once the branch is submitted to Launchpad, it is also possible to
 create a Merge Proposal, which is a step up from a patch. Reviewers
 can see a live diff on the Merge Proposal that gets updated every time
 you do a new 'push'. Merge Proposals also have their own state.

 There's a dashboard for keeping track of pending and approved Merge
 Proposals, eg:

  https://launchpad.net/zopetoolkit/+activereviews

 (the same exists for users: https://launchpad.net/~sidnei/+activereviews)

 If you have bzrtools installed, you can use the 'bzr lp-submit'
 command to create a Merge Proposal from the command line, IIRC.

 It might seem like extra work at first, but once you get used to using
 Merge Proposals to track work that's pending a merge it pays off very
 quickly.

 snip

 A branch made using 'bzr checkout' is bound to the SVN repository:
 commits are automatically pushed back to the master. When working in
 bzr, I really like the ability to batch up local commits, so I often
 create a local branch of the bound one, hack on it with multiple
 commits, and then push back to the bound branch.

 That's how I work too, even with branches stored in bzr, by having a
 'trunk' branch that is bound it saves you a few steps when merging
 work back into the main tree. For people that prefer to be really
 explicit, you can use 'bzr branch svn+ssh://...' instead of 'bzr
 checkout' to create an unbound branch by default. You can also use
 'bzr bind' and 'bzr unbind' to switch between bound and unbound.

 -- Sidnei

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New Zope 3 name: BlueBream

2010-01-07 Thread Leonardo Rochael Almeida
On Thu, Jan 7, 2010 at 07:18, Lennart Regebro rege...@gmail.com wrote:
 On Thu, Jan 7, 2010 at 04:56, Baiju M mba...@zeomega.com wrote:
 http://www.youtube.com/watch?v=HyG5Qee5wbs

 Heh, nice! :-)

Except that the song in this clip is what weddings in Brazil
traditionally play in the part where the bride walks down the aisle
with her father.

I kept expecting to see either a bride in white gown or another
wedding reference to appear somewhere on the video :-)

Cheers, Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] A summary of Interfaces vs ZCA concepts

2009-12-17 Thread Leonardo Rochael Almeida
We've been through this option recently already. It has been quickly
shot down by those who want interfaces to get the new behaviour
immediately available in existing interfaces, instead of having to
rewrite already existing interfaces to support the new API.

Painful memories of a time when we had 2 interface implementations
come to mind. Though in this case, with z.c.Interface extending
z.i.Interface, we probably wouldn't have so much backward
compatibility issues as we had before: the new API would just not be
available in non migrated code, and old code could treat
z.c.Interfaces just like z.i.Interfaces.

On Thu, Dec 17, 2009 at 15:07, Gary Poster gary.pos...@gmail.com wrote:
 Yeah, I was thinking that too, as a I don't have time to think hard about 
 this little daydream.

 Actually I believe you would want to subclass InterfaceClass and make your 
 new zope.component.Interface an instance of the new InterfaceClass and 
 specify zope.interface's Interface as something it extends.

 Then packages in the Zope world would start to use that Interface, I'd guess.

 I don't know how I feel about it.

 Gary


 On Dec 17, 2009, at 11:51 AM, Chris McDonough wrote:

 I'll throw out the obvious...

 Why not subclass Interface in zope.component and make the required API
 additions there?  If it were anybody but us thinking about doing this, they'd
 probably just subclass.

 - C

 Martijn Faassen wrote:
 Wichert Akkerman wrote:
 [knip]
 Perhapse LookupError should be a subclass of TypeError.

 It's a Python built-in. :)

 Regards,

 Martijn

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Interfaces vs ZCA concepts

2009-12-15 Thread Leonardo Rochael Almeida
Funny you should mention this, I've got this idea bugging for a few
weeks now, after the last thread:

Have the zope.interface package expose a single overridable hook:

def getInterfaceAttribute(iface, name, default):

This method would be called by any attempt to look up an interface
attribute that isn't provided by zope.interface itself. For example:

  IFoo.adapter(bar, default=baz)

  Would be the almost the same as:

  getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz)

That is unless getInterfaceAttribute(IFoo, 'adapter') returned the
passed-in marker which would instruct zope.interface to raise an
AttributeError instead.

In turn, zope.component could then provide a getInterfaceAttribute()
implementation that called:

  getAdapter(IFoo, interface=IInterfaceMethod, name='adapter')

Yes, the first parameter above is the original interface. The
IInterfaceMethod is an interface defining __call__(*args, **kw)

This idea would also allow one to define named adapters for
IInterfaceMethod to, for instance, __call__ or __add__, such that
the semantics of IFoo(...) or IFoo + IBar could also be changed.

Perhaps entry points could be used to provide getInterfaceAttribute
implementations, and if multiple entry points are present, each would
be called in turn to attempt to provide the attributes of an
interface, but maybe this is too much flexibility...

Just an idea...

Cheers, Leo

On Tue, Dec 15, 2009 at 14:16, Thomas Lotze t...@gocept.com wrote:
 So we've decided to let interfaces grow `adapt` and `utility` methods. I've
 written a simple and straight-forward implementation of them (see the
 tlotze-component-API branches of zope.interface and zope.component) that is
 closely modelled on the exisiting `__call__`. In particular, the new methods
 use component hooks which are like adapter hooks but with a richer set of call
 parameters. There are a few tests for the new methods as well, so everything
 should be fine.

 Except that I don't like the implications now that I have actually written
 down the code. I'll describe the problem I see and then suggest an idea that I
 don't think we've been considering in the discussion two weeks ago:

 We're intentionally leaking the concept of utilities to zope.interface.
 Assuming we're entirely fine with this, we still need to decide how much of
 the particulars of the ZCA we want to bring along: named components, lookup
 contexts, the ComponentLookupError. My current implementation tries to
 introduce enough generic behaviour into the `adapt` and `utility` methods so
 that they don't cause too obvious (conceptual) dependencies of zope.interface
 on zope.component:

 * `adapt` and `utility` don't define particular optional arguments but pass
  all keyword parameters except for `default` to the component hook which,
  being implemented by zope.component, keeps the knowledge about named
  adapters and lookup contexts within the latter package.

 * The hook invokes the `query*` functions to play nice with any other
  component hooks and the interface methods raise a TypeError if all of them
  fail to find a component.

 However, the generic behaviour gets in our way: the method signatures become
 useless and hooks lose the possibility of raising useful exceptions.

 I've tried some variations but as long as the `adapt` and `utility` methods
 are actually implemented by zope.interface, it will always come down to a
 compromise that either renders the new methods unusable with anything that's
 not very much like zope.component, or makes for a half-hearted copy of the
 functionality we currently have in the zope.component API.

 I discussed this a bit with Wolfgang as we both don't like this kind of
 compromise in such core functionality. We came up with the idea that a clean
 solution would be to keep any implementation of the two methods out of
 zope.interface and rather inject them into the interface API by code kept
 entirely within zope.component. We do realise how close to the concept of
 monkey-patching this comes, but maybe it wouldn't be so bad if we could do it
 in a more structured way (being intentionally vague here yet).

 In particular, keeping the concrete `adapt` and `utility` methods out of the
 core implementation of interfaces would address the concern raised by somebody
 on this list that we were going to tailor zope.interface too much to the needs
 of the Zope ecosystem. Uses of interfaces other than adaptation and component
 lookup could get convenience methods registered by the same mechanism
 zope.component would end up employing, which is a big conceptual advantage
 from my point of view.

 What do people think of this?

 --
 Thomas



 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  

Re: [Zope-dev] ZCA proposal

2009-12-03 Thread Leonardo Rochael Almeida
For my 2 cents (not that I think anyone should care):

+1 for IFoo.adapt[er](*args, **kw) and IFoo.utility(*kw)

-1 for tuple adaptation on 1st arg. Besides losing genericity on tuple
adaptation, we risk situations where a class could trigger
multi-adaptation by inheriting from tuple.

+1 for deprecating unamed default argument. Yes, this is separate
from the 1st item above but if in the future we want to expand/fix the
IFoo() semantics, we should start deprecating things as early as
possible. Besides defalt=something is way more readable and
explicitly, especially when you consider the typecasting mindset.

Cheers, Leo

On Thu, Dec 3, 2009 at 10:00, Martijn Faassen faas...@startifact.com wrote:
 Gary Poster wrote:
 I think I could get fully behind the following proposal that others
 have made (Shane I think was one of several?).

 IFoo.adapt(...)

 IFoo.utility(...)

 I was thinking people would get behind the following proposal:

 IFoo()

 for adaptation and multi adaptation (with tuple arguments)

 and

 IFoo.utility()

 for utility lookups.

 One argument in favor of using plain calls for multi adaptation (using
 tuples) is that people have already discussed various alternative names
 to 'adapt' in just this little thread... The other argument is that we
 would avoid too many ways to do it.

 Even though I thought we had good consensus on it originally, since then
 I've seen an argument against a deprecation warning of implicit default
 on IFoo(). It is a separate discussion. I'd be in favor of it as I think
 the implicit default argument on IFoo() is not that common (and actually
 quite hard to read!), but we could easily separate that from this
 discussion.

 It would break the backwards compatibility of adapting a tuple using the
 adapter hook. I think that's a risk we could take.

 Regards,

 Martijn

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] implementing zope.component 4.0

2009-11-30 Thread Leonardo Rochael Almeida
I find it rather odd that we're wasting so much time worrying about
backward incompatibility when we have a perfect mechanism to introduce
backward incompatible changes in a way that allows both flavours to be
used by packages in the same application (on a module by module basis
just like Martijn would like):

 * Use a different package name!

Yes, I know, zope.component and zope.interface are such clear and nice
names, and it'd be a shame to let them go for the sake of a new and
better API. But why should we even go down the route of backward
incompatibility? We can keep the backward compatibility forever while
having zero code duplication by implementing the old API on top of the
newer one. It's what we've been doing all these years on zope.app
namespace and even on the Zope 2 codebase. It's a tried and true
method. It's not like we're changing the core Python language in a way
as to correct previous uncorrectable mistakes. It's just a couple of
pakages!

And to have a little bit more of bike sheds to paint, I'll even
suggest the new names:

zc.component and zc.interface. We'll even save a couple of bytes on
every import.

Cheers, Leo

On Mon, Nov 30, 2009 at 10:43, Hanno Schlichting ha...@hannosch.eu wrote:
 On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli optilude+li...@gmail.com 
 wrote:
 Martijn Faassen wrote:
 This implies we don't want to release zope.component 4.0 for a long time
 yet.

 I think the answer should be never. :)

 I think never is a rather long time. I'd suggest we think about these
 changes more in the timeline of years.

 Looking at Python itself or Zope's own former deprecation policies, it
 seems that policies where we deprecate / warn about API changes in one
 release and change behavior it one or two releases after that seem to
 work. They do rely on their being something like a coherent release of
 some language / framework / toolkit though. And they rely on these
 releases being made at an interval of at minimum a year or preferably
 18 months (as in Python's case).

 I think that once we get a ZTK 1.0 release out that promises to be
 maintained for at least three years, we can start working on a ZTK 2.0
 which introduces deprecation warnings about the changed behavior and a
 3.0 that will change the default. If released at an interval of 18
 months like Python, that puts these changes about 3 years into the
 future with a lot of time in between to adjust.

 Given such an approach I think we can indeed change core API's in
 backwards incompatible ways. Python itself does this all the time,
 look at Exceptions as new-style classes, new language keywords like
 with or the massive amount of changes in Python 3.

 But if we treat zope.component / zope.interface just as two packages
 of their own, I'd agree that we don't have any way to provide
 reasonable backwards compatibility and ensure that some packages won't
 use these straight away. The whole point of the toolkit is to ensure
 we have a large number of packages that are compatible and tested with
 each other.

 Hanno
 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] improving the utility and adapter lookup APIs

2009-11-26 Thread Leonardo Rochael Almeida
On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote:
 On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
 matt...@matthewwilkes.co.uk wrote:

 On 2009-11-25, at 1601, Benji York wrote:

 I'm not sure I like the following suggestion better than the above, but
 throwing it out there anyway:

 Multiadapter:

 IFoo((x,y))

 I know it's probably a spurious use case, but what if I want to adapt a
 tuple?

 There could be an optional keyword argument to be explicit.

 This would be a single-adapter lookup:

 IFoo(from=my_tuple)

You probably already realized it by now, but this is a syntax error
(remember: from module import name).


 While this would be a multi-adapter lookup:

 IFoo(my_tuple)

To take my stab at this bikeshed painting, and since it doesn't seem
likely we'd want to break backward compatibility, I think I'd prefer
the other way around:

IFoo(multi=my_tuple)

and leave the first parameter for single adaptation, although what I'd
really prefer is multi-adaptation on multiple positional parameter.

Cheers, Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.12 - one more ZPublisher event

2009-11-12 Thread Leonardo Rochael Almeida
Wouldn't it be better to just move IPubFailure before the abort? Is
there a reason for subscribing to such an event which would required
the transaction to be aborted already? I can see the usefulness of the
transaction being already doom()ed before this event, but not aborted.

On Wed, Nov 11, 2009 at 08:53, Martin Aspeli optilude+li...@gmail.com wrote:
 Hi,

 In Zope 2.12 ZPublisher we have a good set of events now, which provide
 useful hooks for modifying the response before or after publication.
 However, I'd like to add one more. ;-)

 Basically, we have IPubFailure, but this is sent *after*
 transaction.abort() and endInteraction(). This means that it's
 impossible to read from the ZODB when trying to deal with a failure.

 I'd like to add an event before that, IPubBeforeAbort, which mirrors
 IPubBeforeCommit in being sent before the transaction is aborted.

 I can do this on Zope trunk + 2.12 branch if no-one objects.

 Martin

 --
 Author of `Professional Plone Development`, a book for developers who
 want to work with Plone. See http://martinaspeli.net/plone-book

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope 2.12 - one more ZPublisher event

2009-11-12 Thread Leonardo Rochael Almeida
On Thu, Nov 12, 2009 at 12:29, Martin Aspeli optilude+li...@gmail.com wrote:
 Leonardo Rochael Almeida wrote:
 Wouldn't it be better to just move IPubFailure before the abort? [...]
 I can see the usefulness of the
 transaction being already doom()ed before this event, but not aborted.

 There is an IPubSuccess which runs after the transaction is closed.
 Doing post-processing after closure may be useful to keep transactions
 shorter and thus reduce the risk of conflict errors. I don't think an
 extra event will cost us much, so being consistent and granular is
 probably best.

Fair enough. I still suggest doom()ing the transaction before this event.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope closes connection if the client closes the write-end of connection

2009-10-17 Thread Leonardo Rochael Almeida
On Sat, Oct 17, 2009 at 10:30, Lennart Regebro rege...@gmail.com wrote:
 2009/10/16 Lennart Regebro rege...@gmail.com:
 So HTTP seems to contradict itself, typically But from looking at
 other peoples responses, most interpret the specification that the
 connection should immediately be closed, so the Zope does the right
 thing there, and Varnish should be changed. This is apparently the
 generally accepted interpretation.

 Of course, it would make even more sense if Zope the immediately
 stopped the transaction, but i have no idea how THAT would work...

- sys.maxint

I definitively don't want zope to cancel a long running transaction
just because my browser got tired of waiting. At the very least this
should be configurable, though I can see a lot of value of being able
to toggle this cancel-transaction behaviour per-request. But the
default should be off (i.e. the transaction keeps going).

Cheers,

Leo
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope closes connection if the client closes the write-end of connection

2009-10-16 Thread Leonardo Rochael Almeida
On Fri, Oct 16, 2009 at 16:36, Tres Seaver tsea...@palladion.com wrote:
 [...]
 You might also look at fixing varnish:  I don't know of any valid
 reason for it to be using the half-open connection model to test that
 an HTTP-based backend is up

Going out on a limb here, but I think Varnish might be trying to save
on file-descriptors. It could be a while before a backend-server
answers and Varnish could have a large number of fds open on any given
time while talking to both clients and servers.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ fix #2235 for real now

2006-11-17 Thread Leonardo Rochael Almeida
Em Sex, 2006-11-17 às 07:48 +, Chris Withers escreveu:
 Leonardo Rochael Almeida wrote:
 []
 
  This is the full method before my changes:
  
  def getobject(self, rid, REQUEST=None):
  Return a cataloged object given a 'data_record_id_'
  
  obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
  if not obj:
  if REQUEST is None:
  REQUEST=self.REQUEST
  obj = self.resolve_url(self.getpath(rid), REQUEST)
  return obj
 
 [...]
 
  A) Keep my changes, but use a marker object() instead of None for the
  default parameter of the .unrestrictedTraverse() call.
  
  B) Reverse my changes, but also remove the if not obj block, which is
  buggy whichever way you look at it with the old unrestrictedTraverse
  call.
  
  Which one should it be?
 
 I'd go for B.

If no one else chimes in today, I'll implement B.
ZCatalog .getobject(rid) call will simply call unrestrictedTraverse,
ignoring the REQUEST. parameter. I'll add a deprecation warning on the
trunk if the REQUEST parameter is passed in.

Cheers, Leo

-- 
Leonardo Rochael Almeida
Enfold Systems
http://www.enfoldsystems.com
phone. +1.713.942.2377 Ext 215
fax. +1.832.201.8856

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Upcoming releases: 2.10.1, 2.9.6

2006-11-17 Thread Leonardo Rochael Almeida
Em Sex, 2006-11-17 às 14:20 -0200, Dorneles Treméa escreveu:
 Hey folks,
 
  I am planning  to release 2.10.1 and 2.9.6 early next week (likely on TUE).
 
 anyone with 5 minutes available to bless my fix for #2191? :-)
 
 http://www.zope.org/Collectors/Zope/2191

Looks good enough for me.
-- 
Leonardo Rochael Almeida
Enfold Systems
http://www.enfoldsystems.com
phone. +1.713.942.2377 Ext 215
fax. +1.832.201.8856

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Re: [Zope-Checkins] SVN: Zope/branches/Zope-2_8-branch/ fix #2235 for real now

2006-11-16 Thread Leonardo Rochael Almeida
Hi Chris,

Em Qui, 2006-11-16 às 07:33 +, Chris Withers escreveu:
 Leonardo Rochael Almeida wrote:
  @@ -615,8 +615,8 @@
   def getobject(self, rid, REQUEST=None):
   Return a cataloged object given a 'data_record_id_'
   
  -obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
  -if not obj:
  +obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
  +if obj is None:
 
 Please revert this change. You've changed the semantics of this 
 statement and it will now mask errors in traversing to the path.
 
 This is bad...

I agree with you the semantics have changed, but I argue that they've
changed to what they were intended to be in the first place :-)

This is the full method before my changes:

def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'

obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid))
if not obj:
if REQUEST is None:
REQUEST=self.REQUEST
obj = self.resolve_url(self.getpath(rid), REQUEST)
return obj


Here it is, after my changes

def getobject(self, rid, REQUEST=None):
Return a cataloged object given a 'data_record_id_'

obj = self.aq_parent.unrestrictedTraverse(self.getpath(rid), None)
if obj is None:
if REQUEST is None:
REQUEST=self.REQUEST
obj = self.resolve_url(self.getpath(rid), REQUEST)
return obj

Traversing with a default argument will only mask traversal errors, not
any other errors that might happen during traversing.

If the intent was not to mask any errors at all, even the ones normal to
traversal, then the if not obj that was there before would only be
triggered in situations where there it was a bug: an object was found
but it's got a .__len__ or .__nonzero__ method.

In the version with my changes, but with the old unrestrictedTraverse
call, the if obj is None would only ever be reached in the
pathological situation where the attribute at the end of the path is
None. Which means the .resolve_url(self.getpath(rid), REQUEST) would
hardly ever be called at all.

I'm open to reversing the unrestrictedTraverse call to the old
semantics, as soon as we agree what those where, so I propose 2 options
and I'll implement whatever this list decides:

A) Keep my changes, but use a marker object() instead of None for the
default parameter of the .unrestrictedTraverse() call.

B) Reverse my changes, but also remove the if not obj block, which is
buggy whichever way you look at it with the old unrestrictedTraverse
call.

Which one should it be?

Cheers, Leo

-- 
Leonardo Rochael Almeida
Enfold Systems
http://www.enfoldsystems.com
phone. +1.713.942.2377 Ext 215
fax. +1.832.201.8856

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Branches finished for merging.

2006-04-26 Thread Leonardo Rochael Almeida
Em Qua, 2006-04-26 às 19:14 +0200, Lennart Regebro escreveu:
 I have (at least) two branches that will be merged before The Big
 Freeze on monday, if all goes well, and unless somebody has any very
 serious objections.
 
 1. easter-sprint_traversal-refactor
 [...]
 2. regebro-wsgi_refactor

+1 to merging both branches

 I also recommend that we deprecate both __bobo_traverse__ and
 __browser_default__, but perhaps with a longer derecation period that
 usual, since this are very basic techniques used in many products.
 Please discuss. :)

+1 to deprecation and to longer period for this case.

-- 
Leonardo Rochael Almeida
Enfold Systems
http://www.enfoldsystems.com
phone. +1.713.942.2377 Ext 215
fax. +1.832.201.8856

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Strange traceback or Error in the traceback ?

2006-01-16 Thread Leonardo Rochael Almeida
Hi,

Em Seg, 2006-01-16 às 16:20 +0100, Godefroid Chapelle escreveu:
 Hi,
 
 While seaching for objects of all types containing some text through the 
 ZMI find tab, I got the traceback hereunder. (Zope 2.7.8-final on
 windows)
 
 Traceback (innermost last):
[...]
Module OFS.Image, line 425, in PrincipiaSearchSource
 AttributeError: content_typestartswith
 
 I went to the code and found the following :
 
 [...]
  if self.content_type.startswith('text/'):
 [...]
 
 IOW, the traceback is really strange.
 
 Anybody with a clue ?

I've seen this happen a few times before. In your case, content_type is
probably a standard python function (or method). When an unknown
attribute is looked up in a std python function like that, somehow you
get an AttributeError with the name of the function and the looked up
attribute concatenated, instead of separated by a dot (or more commonly,
instead of the attribute name alone).

Don't know if this is a bad interaction between
ExtensionClass/AttributeError and python, or a python bug.

Cheers, Leo


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] What use cases are driving make install from a checkout?

2005-12-21 Thread Leonardo Rochael Almeida
Just as a data point.

A lot of autoconf projects (the ones that made ./configure; make; make
install famous) don't just run like that from a checkout, but they are
never more than 2 steps away from that.

The process for a checkout is usually more like
./autoconf; ./automake; ./configure; make; make install

My point is: I don't think there's anything wrong in the install
procedure being different between the checkout and the tarball, but it
should never take more than a couple of fixed (and documented) steps to
convert a checkout to a tarball-equivalent environment, where
./configure; make; make install would work.

Cheers, Leo.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: PermissionGeddon

2005-11-29 Thread Leonardo Rochael Almeida
Hi all,

Em Dom, 2005-11-27 às 21:26 +0100, Florent Guillaume escreveu:
 Dieter Maurer wrote:
 The first change is in the manage_pasteObjects method of CopyContainer. 
 There are some _setObject and _delObject calls which grew a new 
 suppress_events parameter. [...]
  
  
  Several Folder like classes are likely to overwrite
  _setObject and _delObject.
  Maybe, the code that calls these methods with an additional parameter
  should be prepared to meet implementations that do not support
  the extra parameter.
 
 Maybe. But on the other hand I'd rather not have object manager code 
 slowed down and uglified to suit the negligibly small number of classes 
 that are in this case, and that can be trivialy upgraded in a 
 forward-compatible manner.

Not gathering crust is a nice an laudable goal, but so is keep
backward compatibility.

I humbly suggest that the workaround code on ObjectManager be created
with a deprecation warning whenever it's triggered, declaring that the
backward compatibility will go away in, say, version 2.11, when it won't
be uglified and slowed down anymore.

You are, in essence, changing the API. IMHO this should take the same
deprecation treatment as everything else.

Cheers, Leo.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: PermissionGeddon

2005-11-29 Thread Leonardo Rochael Almeida
Hi Florent

Em Ter, 2005-11-29 às 15:32 +0100, Florent Guillaume escreveu:
 [...]
 I'm a bit peeved though at the lack of willingness from the few people that 
 have reimplemented their version of _setObject/_delObject (which could be 
 considered private APIs, seeing that they're prefixed with an underscore) 
 to just modify their code for forward compatibility and be done with it, but 
 instead have us embark in a year-long deprecation strategy.
 
 This is supposed to be open source, can't we be reactive to change in such 
 situation? Are folks really going to ship their framework code with 
 _setObject unmodified from the current version when they ship it for Five 
 1.2 or Zope 2.9?

They probably will change it, people don't like their code to generate
deprecation warnings. But the greatest beneficiaries of the deprecation
strategy are not the framework builders, but the users.

Suppose a Zope change breaks, say, Plone (to pick two arbitrary
examples :-). This means, that in order to upgrade to the next Zope
version, I need to upgrade Plone first. If Plone, on the other hand,
depends on Zope features that are only available in the newer Zope
version, I'm forced to upgrade both layers of my running site
simultaneously, making it much more expensive to calculate the migration
overhead and procedures.

I don't want to start a discussion about whose responsability is to keep
compatibility with what software, but I, for one, prefer to upgrade the
lower layers of my solutions before the upper layers if possible: Python
before Zope, Zope before Plone, Linux kernel before glibc. This is not
always possible, and there are loads of counter-examples, but if we can
avoid forcing the poor user to upgrade more than one piece of software
at a time, I think this is something we should try to achieve.

Cheers, Leo

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Username/userid separation

2005-08-04 Thread Leonardo Rochael Almeida
Em Qui, 2005-08-04 às 08:39 +0100, Jens Vagelpohl escreveu:
 On 4 Aug 2005, at 01:01, Leonardo Rochael Almeida wrote:
 
  Hi,
 
  I've started the lra-userid_username_separation-branch (from
  Zope-2_8-branch to start from a stable point) in order to implement
  proper userid/username separation in Zope.
 
 Chris McDonough did most of that for Zope 2.7 already a long long  
 time ago. There might be cleanups needed here and there, but for all  
 practical purposes the separation exists and works. The standard user  
 folder implementation doesn't support it AFAIK. Where specifically do  
 you see it not work?

AFAICS, in AccessControl/dtml/owner.dtml, the owner string that is
rendered to the browser comes from Owned.owner_info() in
AccessControl/Owned.py, which comes, untranslated, from
Owned.getOwnerTuple(), which retrieves that value that is set from
Owned.changeOwnership(), which calls ownerInfo() which gets the path to
the user folder and user.getId(), as it should since we are assuming
that .getId() is the immutable and potentially not-displayable
identifier for the user that comes from the user source.

What I'm proposing is to change owner.dtml (with the eventual help of
owner_info()) to get the username equivalent to that userid and display
that instead.

Also, in AccessControl/listLocalRoles.dtml and editLocalRoles.dtml, the
usernames that are rendered from users that already have local roles are
the keys from the RoleManager.__ac_local_roles__ attribute from
AccessControl/Role.py.

These keys eventually come from RoleManager.get_valid_userids(), which
calls acl_users.user_names() for all acl_users in it's acquisition path.

In the default Zope user folder implementation, .user_names() call
getUserNames() which is supposed to list usernames, not userids, which
means we've been storing usernames in __ac_local_roles__ all this time.
This could break if the username for a certain acl_users implementation
changes, specially since User.getRolesInContext() looks up
__ac_local_roles__ with self.getId() and not self.getUserName() in
AccesControl/User.py.

(Actually, isn't it odd that the local roles management is not using the
same approach of owner tuples like Owned.py does?)

I propose that we look up the userid for the username in
RoleManager.manage_{add,set,del}LocalRoles() and change the signature of
these methods to mention username instead of userid.

This might leave us with a slight window for mismatches if the username
for a userid changes between selecting the user in the listLocalRoles
screen and actually setting it after the editLocalRoles screen, but at
least we avoid having to make sure binary userids are correctly quoted
thru all the HTML and URL roundtrips.

What do you guys think?

 I've been using it for the LDAPUserFolder for ages where you can  
 specify different attributes for the ID and the login, and change the  
 login value at will. And, like Tino mentioned, PAS uses it as well.

Yes, Enfold is aware of PAS, we've been doing the Plone integration for
it and we intend to use it for this particular project for which I need
the changes I mentioned above.

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfoldsystems.com/
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Username/userid separation

2005-08-04 Thread Leonardo Rochael Almeida
Em Qui, 2005-08-04 às 16:20 -0300, Leonardo Rochael Almeida escreveu:
 I propose that we look up the userid for the username in
 RoleManager.manage_{add,set,del}LocalRoles() and change the signature of
 these methods to mention username instead of userid.

And we also need to change RoleManager.get_local_roles() to lookup
usernames for the stored userids.

But this leaves us with another interesting problem: in what user folder
should we be looking up these ids? Theoretically, in all of them,
like .list_valid_usernames() does, but this might bring some different
interactions between local roles set for a username that exists in 2 or
more user folders in the current acquisition path.

The definitive fix for this would involve storing the (userid, acl_users
path) tuple in the local roles information after all, and changing
User.localRolesInContext() accordingly, but this brings a host of
backward compatibility issues which my suggestions above make some
effort to avoid, I believe.

Cheers,

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfoldsystems.com/
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Username/userid separation

2005-08-03 Thread Leonardo Rochael Almeida
Hi,

I've started the lra-userid_username_separation-branch (from
Zope-2_8-branch to start from a stable point) in order to implement
proper userid/username separation in Zope.

I don't intend to change the default user folder implementation, just
the ZMI interface for owner and local roles so that they keep using
userid for storage like they currently do but use usernames for display
(specifically acl_users.getUserById(id).getUserName()). The intent is to
never leak the userid to the ZMI (except for url query strings and
such), and to never store the username persistently.

The motivating usecase is an LDAP (eDirectory) authenticated system
where the username for a user can change, but not the internal ID (a
string).

This will also help ActiveDirectory integration, which also has an
internal ID to reference users.

I remember there being a discussion about this in the list archives, but
a Google search didn't help much.

Are there any other projects in this area that I should colaborate with
instead of duplicating efforts?

Are there any considerations I should be aware of?

Is the Proposals wiki pages still used for this kind of change?

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RAMcache and container vs. context

2005-04-25 Thread Leonardo Rochael Almeida
Sorry for comming late into the fray :-)

Em Qui, 2005-04-21 às 19:46 -0400, Paul Winkler escreveu:
 On Fri, Apr 22, 2005 at 12:27:18AM +0200, Stefan H. Holek wrote:
  Note that aq_parent() gives you the URL parent, not the container. I 
  see no way around that as the return value of a script may well depend 
  on its context.
 
 Yes, it may, agreed. Thanks much for pointing out the relevant
 code, at least now I understand what's happening.
 
 But I still would like to argue against this behavior:
 There *is* an easy alternative, and that's to put one or more
 of the many location-related request variables into the
 cache manager's configuration.

This alternative won't help you when:

  * the pythonscript is sensitive to the context AND

  * it is called w/ 2 or more different contexts on the same request

An artificial example I can come up w/ from the top of my head: 
Suppose you have a folder w/ an index_html that displays information
about it's subfolders that is calculated by an expensive script and you
want to cache the results of this script, you'd go:

ul
 li tal:repeat=subfolder python: here.objectValues('Folder')
  Folder span tal:content=subfolder/title_or_id contains
  span tal:content=subfolder/expensively_calculate_shruberries
  shruberries.
 /li
/ul

Then you'd go and RAMCache expensively_calculate_shruberries

But if we implement the change you're suggesting, then this page would
list the same number of shruberries of the first subfolder for all of
them.

-1 from me

 For a related annoyance, see:
 http://www.zope.org/Collectors/CMF/343

This annoyance is indeed related, but the proper fix is for
FSPythonScript to have a ZCacheable_manage page that takes into account
the fact that it's usually part of a portal_skins setup and deal with
it. Alternativelly, portal_skins should provide the functionality of
expiring RAMCached subitems.

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Zope-Coders] Re: Question about procedures

2005-03-29 Thread Leonardo Rochael Almeida
Em Ter, 2005-03-29 às 17:21 +0200, Florent Guillaume escreveu:
 martin f krafft  [EMAIL PROTECTED] wrote:
  also sprach Florent Guillaume [EMAIL PROTECTED] [2005.03.24.1814 +0100]:
-if RESPONSE is not None:
+if RESPONSE is not None and ob:
   
   You should check 'and ob is not None' too.
  
  ... but ob is false when it is None, no?
 
 Yes but comparing to None is faster, and in some cases (REQUEST for
 instance), much much faster, than checking the boolean value.

And not every False object is None. A custom object could implement
__len__() and be considered false if it's empty, or it could implement
__nonzero__() and be considered false even when you want to return it.

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] ZConfig issue: products and container-class

2005-02-14 Thread Leonardo Rochael Almeida
Hi,

I found a problematic corner case in the interaction between two zconfig
directives:

If I set the products directive to a value other than the standard
ones (SOFTWARE_HOME/Products or INSTANCE_HOME/Products) AND set the
container-class directive of the zodb_db section to a class that is
only available inside the alternate products directory specified
above, then Zope completely fails to start-up with a configuration
error.

Reproducing this error is simple. Just set the products directive to,
say, $INSTANCE/../Products; put, say, CMF or Plone in there; add another
zodb_db section, for instance:

zodb_db mounttest
filestorage
  path $INSTANCE/var/mounttest.fs
/filestorage
mount-point /mounttest
container-class Products.CMFPlone.PloneFolder.PloneFolder
/zodb_db

Change the container-class directive to a class that only exists in
../Products (like Products.CMFPlone.PloneFolder.PloneFolder or
Products.CMFCore.PortalFolder.PortalFolder). Finally, try to startup
Zope. It will fail with something like:

Error: The object named by Products.CMFPlone.PloneFolder.PloneFolder
could not be imported
(line 862 in file:///home/leo/opt/enfold/etc/zope.conf)
For help, use /opt/zopes/Zope-2.7.2/lib/python/Zope/Startup/run.py -h

If you comment out the new zodb_db section, Zope starts up fine, and
CMF and Plone work ok, proving that the produtcts directive work on
it's own.

If instead of commenting out the new zodb_db section, you just move
your products back to the standard $INSTANCE_HOME/Products location,
Zope also starts up ok, proving that the container-class directive
works (or at least doesn't keep Zope from starting up).

I'm just mentioning this here before filing a collector entry to see if
I'm not forgetting something obvious or if others have found the same
behaviour.

This behaviour is problematic for Windows users with, say,
multiprocessor machines, who want to maintain a consistent setup between
various ZEO clients, as this forces them to copy products between
instances instead of keeping them in a shared location.

It's obvious that the container-class directive is being evaluated
much earlier than the products directive. Without delving further into
the code, it looks like the container-class directive has an error
checking built right into the directive type that tries to import the
assigned class, while the products direcive will only be made
effective AFTER all ZConfig configuration has been processed...

Any pointers? Should this go right into the collector?

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfolsystems.com/

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZConfig issue: products and container-class

2005-02-14 Thread Leonardo Rochael Almeida
Em Seg, 2005-02-14 às 13:36 -0500, Fred Drake escreveu:
 On Mon, 14 Feb 2005 15:22:38 -0200, Leonardo Rochael Almeida
 [EMAIL PROTECTED] wrote:
  It's obvious that the container-class directive is being evaluated
  much earlier than the products directive. Without delving further into
  the code, it looks like the container-class directive has an error
  checking built right into the directive type that tries to import the
  assigned class, while the products direcive will only be made
  effective AFTER all ZConfig configuration has been processed...
 
 This is a known limitation.

Should I bother with the collector entry or is it a known limitation no
one is going to bother with? :-)

 You can avoid it by using the PYTHONPATH
 environment variable instead.

And it must really be done in the environment, instead of with the
path directive, as that is also evaluated too late in the process...

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
Enfold Systems - http://www.enfolsystems.com/

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: inconsistent mimetype assignment for uploaded files

2004-10-14 Thread Leonardo Rochael Almeida
Em Ter, 2004-10-12 às 00:23, Kapil Thangavelu escreveu:
 i believe you were referring to
 http://freedesktop.org/Software/shared-mime-info
 
 spec 
 http://freedesktop.org/Standards/shared-mime-info-spec
 
 its a system wide shared mime database for use by applications (ie. both
 gnome and kde). apparently no python bindings.

Actually, the last url above lists a certain ROX-Lib:
http://rox.sourceforge.net/phpwiki/index.php/ROX-Lib

It's pure Python and suports a lot of stuff besides mime, but seems to
require gtk, which could be a problem for people wanting to maintain
slim servers free of any X Window System client dependencies. It's
certainly too heavy a dependency for Zope :-)

Cheers, Leo


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] using VirtualHostMonster in a ZPublisher python module?

2004-09-21 Thread Leonardo Rochael Almeida
Em Ter, 2004-09-21 às 12:17, Royce escreveu:
 Was hoping to hear of a way to insert a VHM into my zpublisher app
 object tree or something. Could just hack in hardwired cleanup for URL
 and BASE but that seems ugly.

The code in VHM is really not that complicated. I recommend you read it
so that you understand how to change your application to emulate or
integrate it.

Basically it hooks itself up into __bobo_traverse__ so that it gets
called when the request comes in, before all objects in the path (after
the root) are looked up. When called, VHM alters the request information
(server and path, and as a consequence BASE* and URL*) which has the
consequence of changing what objects are looked up to handle the request
(i.e. no need for objects called VirtualHostBase or VirtualHostRoot).

This is done thru Request methods that where created exactly for this
purpose: .setServerURL() and .setVirtualRoot()

Documentation for those can be found in the Zope Online Help and other
places.

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Patch: let non-seekable streams be input for ZPublisher (updated)

2004-08-18 Thread Leonardo Rochael Almeida


Em Qua, 2004-08-18 às 12:22, Ames Andreas (MPA/DF) escreveu:
 [...]
 Questions:
 
 - Is this the right forum/place to send patches to?

This is the right forum to discuss the patches, and to send them for
evaluation if it's a small one, like yours. The best place to actually
send patches to is as attachment in a bug report in the Zope bug
collector.

 - Is there any chance that this could be applied to Zope's mainline?
   (If not I will proceed with a local disk buffering scheme in the
   long term.)

Yes, if you file a feature request on the bug collector, which can be
found at:

http://collector.zope.org/Zope

Cheers, Leo
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-dev] Possible Windows Service improvements.

2004-08-09 Thread Leonardo Rochael Almeida

Can't we just parse the log files, or maybe even have a special logger
for Window Service, and wait for this?

  2004-08-03T15:37:55 INFO(0) Zope Ready to handle requests

If the process dies after this, restart.

Em Seg, 2004-08-09 às 10:56, Chris McDonough escreveu:
 Would a lockfile work ok to signify running state?  IOW, Zope would
 lock a file as one of the last steps during startup (which it actually
 does now, but might do it a bit too early).  The Windows service manager
 would attempt to lock the same file after timeout seconds (although
 I'm not sure where to get timeout from) on initial startup.  If the
 file doesn't exist or the lock succeeds, the process is nonrestartable. 
 If it exists and cannot be locked (Zope has locked it, signifying
 successful startup), the process is restartable.
 
 On Sun, 2004-08-08 at 21:10, Mark Hammond wrote:
  [Me]
By adding a layer around run.py, I believe we could arrange
for these fatal errors to be handled with a special return code.
  
  [Jim]
   I assume by fatal, you mean errors that we should not try to restart
   from.
  
  Correct.
  
   Let me see if I understand the use cases here:
  
   - Normal shutdown.  (Should it be possible to shut down Zope
  through the web on Windows?)
  
  I see no reason it makes less sense for Windows than it does for anywhere
  else wink.
  
  
   - Start-up error. We want to log relevent information somewhere.
  We don't want to restart.
  
   - Run-time (after startup) error.  We also want to log a problem,
  but we do want to restart Zope.
  
  Yep, I think that covers it.
  
   Note that we also need to consider uncontrolled exits, like segfaults.
  
  Yes - if the segfault is at startup, it should be considered
  non-restartable.  Once normal operations have started, a segfault should
  cause a restart.
  
   Perhaps there should be a framework that with calls that a program can
   make to indicate normal exit, fatal (non-restartable) exit,
   and non-fatal (restartable) exit.
  
  That could done with process exit codes if all the child needs to is report
  *exit* status - but that really doesn't cover enough bases.  Given the
  number of ways programs can fail, it may be hard to guarantee, and doesn't
  handle uncontrolled exits or children going zombie.
  
  What we need is something a more authoritative - where the child process
  actively signals its state to the parent - ie starting, running or
  stopping.  pausing and paused may also make sense.  If the child never
  reported 'running', it is non-restartable.  If the child terminates without
  reporting graceful shutdown, it is restartable.
  
  This still does not provide any way of handling the case when the child
  process is running, but failing to transition between states.  We still need
  a timeout, but can make it more robust by having the child process report
  the status *and* the timeout the parent should use.
  
  Which, coincidently, sounds exactly like the Windows Services API wink.
  Is that sounding reasonable, or moving into too-complicated/YAGNI territory?
  
  Thanks,
  
  Mark.
  
  ___
  Zope-Dev maillist  -  [EMAIL PROTECTED]
  http://mail.zope.org/mailman/listinfo/zope-dev
  **  No cross posts or HTML encoding!  **
  (Related lists - 
   http://mail.zope.org/mailman/listinfo/zope-announce
   http://mail.zope.org/mailman/listinfo/zope )
  
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Fwd: Re: [Zope-dev] Referencial Integrity in ZCatalogs]

2004-08-02 Thread Leonardo Rochael Almeida
Forgot to Cc: zope-dev

-Mensagem encaminhada-
From: Leonardo Rochael Almeida [EMAIL PROTECTED]
To: Santi Camps [EMAIL PROTECTED]
Subject: Re: [Zope-dev] Referencial Integrity in ZCatalogs
Date: Mon, 02 Aug 2004 17:05:53 -0300

I would suggest you take a look at mxmRelations, however Zope.org
workflow is keeping it out of reach, and I couldn't find it on MaxM's
own site.

The URL for it would be:

http://www.zope.org/Members/maxm/products/mxmRelations

but right now it requires a login.

If any kind soul from the Zope web team could release it, or if MaxM
could post it somewhere else, that would be very nice.

Cheers, Leo

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope-dev list policies

2004-06-24 Thread Leonardo Rochael Almeida
+1 for member-only posting

On Wed, 2004-06-16 at 22:24, Tim Peters wrote:
 Over on the zope and zope-dev lists, there's currently agitation to make
 them members-only mailing lists.  The point is that spam could not get thru
 then (unless posted by a member).
 
 What would zodb-dev members like?
 [...]
-- 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] bug day?

2004-06-24 Thread Leonardo Rochael Almeida
This next Friday (25th) is the last friday of the month. Are we going to
have a bugday?

Cheers, Leo


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: zope-dev list policies

2004-06-24 Thread Leonardo Rochael Almeida

On Mon, 2004-06-21 at 11:59, Casey Duncan wrote:
 -1 on changing the list policy. I read and post to all of the public
 lists through Gmane, which won't work if the policy is changed.


 
 I rarely see spam get through list either (unless Gmane is filtering it
 all out for me), so I fail to see the problem from that point of view.
 
 -Casey
 
 On Wed, 16 Jun 2004 21:24:07 -0400
 Tim Peters [EMAIL PROTECTED] wrote:
 
  Over on the zope and zope-dev lists, there's currently agitation to
  make them members-only mailing lists.  The point is that spam could
  not get thru then (unless posted by a member).
  
  What would zodb-dev members like?
  
  Posting by a list member would not be affected, unless you attempted
  to send a message from an email account other than one you subscribed
  with.  In the latter case, your message would be bounced back to you.
  
  You could worm around that by subscribing to zodb-dev with that
  address too, then going to your list membership page on the web and
  checking the box to suspend email delivery on that account.  Then you
  could post using that account too, but wouldn't also get zodb-dev
  email on that account.
  
  I'm the list admin for zodb-dev, and don't have a preference.  If you
  do, and it's strong enough to scream it, shout.  The loudest screamer
  will winwink.  By default, I won't change the current policy (anyone
  can post here, member or not).
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
-- 

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-23 Thread Leonardo Rochael Almeida
On Wed, 16 Jun 2004 11:16:55 +0200
 Eric Brun [EMAIL PROTECTED] wrote:
 
  
  
  Hi,
  
  I have a problem with 'getObject' method of CatalogBrains class on
  Zope271b1 : it's return None. But with a Zope2.7.0 my object is
  correctly find and returned. The permissions are right.
 

Em Qua, 2004-06-16 às 11:28, Casey Duncan escreveu:
 getObject was refactored recently and its security was increased. It
 uses restrictedTraverse() now, which means that you need access to all
 of the enclosing folders as well as the object. Before, no security
 checking was performed by getObject.
 
 I suspect you do not have access to one of the containing folders.

I certainly hope he'd get a permission error instead of silent 'None'
for '.getObject()' in this case or I'd consider it a bug :-)

Cheers, Leo

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: [Collector] Strange reject policy

2004-05-06 Thread Leonardo Rochael Almeida
On Thu, 2004-05-06 at 11:56, Lennart Regebro wrote:
 From: Ken Manheimer [EMAIL PROTECTED]
  All the actions are verbs, won't fix is not a verb.  Can you suggest a
  verb the more clearly indicates the result is won't fix? 
 
 Tough one...
 
 Live with 
 Ignore
 Keep this bug as is
 Zenify
 Featurize (as in This is not a bug, it's a feature)
 Shove under carpet
 Forget
 Procrastinate
 Pretend to be deaf

How about Refuse to fix?

Cheers, leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Proposal: cvs to subversion transition May 11 (?)

2004-05-05 Thread Leonardo Rochael Almeida
On Wed, 2004-05-05 at 02:59, Jim Fulton wrote:
 Jim Fulton wrote:
 [...] 
 I'm thinking of trying again to do the cvs to svn conversion of the main-line
 development branches (cvs heads) on Tusday May 11. This would entail moving
 ZODB, Zope 2, and Zope 3 head development to subversion (along with ZConfig,
 zdaemon, and zLOG).
 
 Any objections?

Isn't that the day of the next ZC IRC session? How will that be affected
by the migration?

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] performance tuning of ZODB

2004-04-26 Thread Leonardo Rochael Almeida
Hi Syver,

Please add this issue to the Collector, including the test (prefereably
without the twisted bits)

On Thu, 2004-04-22 at 12:57, Syver Enstad wrote:
 [...]
 
 I have a strange case here with ReadConflictErrors. I don't know if
 this is covered already but anyway. I am using ZODB 3.2 so this might
 be fixed in 3.3 for all I know.
 
 Just replace the twisted stuff with the standard lib unittest module to
 have it work on a computer without twisted installed.

-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Proposal: Rename zope package

2004-04-20 Thread Leonardo Rochael Almeida
+1

I had thought about exactly this idea during the weekend but I thought
the z alternative had such traction that it wasn't worth mentioning.
The only difference is that I thought about renaming Zope to ZopeClassic
or ZopeLegacy instead of Zope2 (keeping version numbers out of packages
and all that...)

Cheers,

On Tue, 2004-04-20 at 13:08, Jim Fulton wrote:
 [...]
 I've gotten enough negative feedback to z, that I've added an alternative 4
 to the proposal:
 
4. Rename the Zope package to Zope2 and provide a legacy Zope
   package
 
   - Rename the Zope package to Zope2
 
   - Put the Zope 3 zope package into the same location as
 Zope2 in a combined installation.
 
   - Provide a legacy directory containing a Zope package.
 There will be an option to add this to the Python path. This
 option will be enabled by default in Zope 2.8 and disabled by
 default in Zope 2.9.
 
 Importing Zope will cause a deprecation warning.
 
 The legacy Zope package will have a README.txt file that
 explains what it is and refers people to the zope and Zope2
 packages.
 
 This would mainly impact Zope 2.
 
 What do people think about alternative 4?
 
 Jim
-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Use Z SQL methon in projects

2004-03-29 Thread Leonardo Rochael Almeida
Hi R33t,

On Sat, 2004-03-27 at 14:35, R33t wrote:
 [...] The problem I have now is that I don't know how to manage to
 export my Z SQL method getNewsletters to my product folder and register
 it to Zope from within python when my product gets installed, so that
 the template can call this method like before...I don't want the users
 of my product to manually create this Z SQL method when they install the
 newsletter system. Is it possible at all or do I have to start all over
 again?

I don't know about exporting your ZSQLMethods for the filesystem. As for
importing them, take a look at the SQL authentication and property
sources for exUserFolder. They populate folderlike objects with
ZSQLMethods upon initialization.

http://sf.net/projects/exuserfolder

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Making a custom class addable to another class in product, but not to Zope

2004-02-25 Thread Leonardo Rochael Almeida
Anoter option is to register a container_filter for the Thing class:

def initialize(context):
(...)
context.registerClass(thingmodule.Thing,
  permission=thingmodule.ADD_THING_PERMISSION,
  constructors=(...),
  container_filter=thingmodule.containerFilter,
  icon=www/thing.png)

where containerFilter is a module global function that could be:

def containerFilter(container):
isinstance(container, containermodule.Container)

This way Zope doesn't show it as addable to anything on the management
interface except Containers. I don't think Zope checks the
container_filter if the constructors are invoked directly, eg. by a
PythonScript, but if you want to be strict, you can invoke the
containerFilter again on the constructors and raise an exception...

Cheers, Leo.

On Wed, 2004-02-25 at 17:52, Dieter Maurer wrote:
 Ian Beatty wrote at 2004-2-24 17:33 -0500:
  ...
 I've got
 two classes in my product; let's call them Container and Thing. I want to
 have Container addable to any old folder in the ZMI; that's no problem, I
 just register it in my product's __init__.py file. I want Container to allow
 instances of Thing to be added to it, and nothing else; that's also no
 problem, using all_meta_types.
 
 However, I want Thing to be addable to Container, but not to any other
 ObjectManager-based object.
 
 You simply do not register Thing.
 You define constructors (they are factories indeed, but
 Zope uses the term constructors) for Thing on Container,
 among them the construtor for the action you used
 in all_meta_types.
 
 Your all_meta_types will return something like:
 
 (
   {
   'name' : 'Thing',
   'action': 'Thing_add',
   'permission': ManagePortal,
   },
   )
 
 Note, there is not manage_addProduct in the action...
-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Adapters in Zope 2

2004-02-10 Thread Leonardo Rochael Almeida
Hi Santi.

The Zope2 official way of extending objects at runtime is acquisition.

The easiest way to make use of it is to put the methods/scripts you need
in the acquisition path (e.g. closer to the root). There are more
sofisticated methods, such as SkinnedFolders  and TransparentFolders
that allow you to shape acquisition to avoid cluttering parent folders
with methods and/or a more precise control of the selection of objects
to be aquired.

All of the methods of shapping acquisition rely on creative
interpretation/manipulation of the __of__() method of acquisition-aware
objects.

Acquisition is very powerful, and very magic at the same time.
Adapters is Zope3 way of implementing Acquisition in a less
surprising way.

On Mon, 2004-02-09 at 18:48, Santi Camps wrote:
 Hi all,
 
 I know that adaptors are introduced in zope3 but, anybody knows if this
 technique can be used in zope2 ?
 
 I've been trying to add some extra functionallity to a Folder object
 without inheriting, but I'm not able to make it work.  To maintain the
 adapted object publishable I've rewrited __getattr__, but then some
 extra problems appears.  
 
 Anybody knows if there is a way to use adapters in zope2 ?  Or, if not,
 there is some other way to add functionallity on-the-fly, without
 inheriting ?
 
 Thanks in advance
-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope2.7.0rc2 AttributeError: 'NoneType' object has no attribute 'setHeader'

2004-02-07 Thread Leonardo Rochael Almeida
On Fri, 2004-02-06 at 20:01, Christian Heimes wrote:
 Christian Heimes wrote:
 [...]
 
 And the next one:
 
 Python2.3.3/Zope2.70rc2/Plone2rc5.
 
 Exception Type
 AttributeError
 Exception Value
 'str' object has no attribute 'RESPONSE'
 
 [...]
 Module Products.CMFPhoto.Photo, line 510, in clearCache
 AttributeError: 'str' object has no attribute 'RESPONSE'

METOO!

I just got this error. I commented out line 510 and the code worked.

I was about to uncomment the code again to try and debug it. It happened
when I tried to upload a .jpg thru webdav (konqueror webdav support) to
a CMFPhotoAlbum (0.4final) inside a plone2rc5 instance (Zope 2.6.4rc2,
Python 2.3.3).

I'm curious to at least know what kind of string 'self.REQUEST' is :-)

Want to coordinate? I'm happy to be the guinnea pig for this bug.


-- 
Leonardo Rochael Almeida [EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope2.7.0rc2 AttributeError: 'NoneType' object has no attribute 'setHeader'

2004-02-07 Thread Leonardo Rochael Almeida
On Sat, 2004-02-07 at 22:47, Christian Heimes wrote:
 Chris McDonough wrote:
   FWIW, this often happens when self isn't ultimately wrapped in a
   RequestContainer (as it always should be when dealing with TTW code or
   code that depends on REQUEST).  The string is likely something like
   Special Object Used To Force Acqusition, which is the string that
   represents something when it is declared as Acquisition.Acquired in a
   class definition.
  
   The trick is finding out where the thing loses its context.  No clue in
   this case.
 
 If it's Special Object Used To Force Acqusition then it's (maybe) 
 partly my fault.

That's it alright,

 type(self.REQUEST) is Special Object Used To Force 
 Acqusition when the object hasn't a real acquisition context. That's 
 for example when we are still in the __init__() part of object creation.

That's it alright :-)

 I was pretty shure that upload_data is called in an acquisition context. 
 It seems that it isn't called in a context under *every* circumstances.

In this case it's being callet by Photo.__init__ - OFS.Image.__init__ - 
Photo.update_data

Here's the traceback:

Traceback (innermost last):
  File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/Publish.py, line 98, in publish
  File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/mapply.py, line 88, in mapply
(Object: PUT)
  File /opt/zope/sw/Zope-264rc2/lib/python/ZPublisher/Publish.py, line 39, in 
call_object
(Object: PUT)
  File /opt/zope/sw/Zope-264rc2/lib/python/webdav/NullResource.py, line 108, in PUT
(Object: dcp_0996.jpg)
  File /home/leo/zopes/lra.com.br/Products/CMFPhotoAlbum/PhotoAlbum.py, line 69, in 
PUT_factory
(Object: unisa-congresso-brooklin)
  File /home/leo/zopes/lra.com.br/Products/CMFCore/PortalFolder.py, line 361, in 
invokeFactory
(Object: unisa-congresso-brooklin)
  File /home/leo/zopes/lra.com.br/Products/CMFCore/TypesTool.py, line 709, in 
constructContent
(Object: portal_types)
  File /home/leo/zopes/lra.com.br/Products/CMFCore/TypesTool.py, line 398, in 
constructInstance
(Object: Photo)
  File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 110, in addPhoto
(Object: unisa-congresso-brooklin)
  File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 174, in __init__
(Object: dcp_0996.jpg)
  File /home/leo/zopes/lra.com.br/Products/CMFDefault/Image.py, line 147, in __init__
(Object: dcp_0996.jpg)
  File /opt/zope/sw/Zope-264rc2/lib/python/OFS/Image.py, line 124, in __init__
(Object: dcp_0996.jpg)
  File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 400, in update_data
(Object: dcp_0996.jpg)
  File /home/leo/zopes/lra.com.br/Products/CMFPhoto/Photo.py, line 510, in clearCache
(Object: dcp_0996.jpg)
AttributeError: 'str' object has no attribute 'RESPONSE'


Cheers, Leo


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches

2004-01-27 Thread Leonardo Rochael Almeida
Hi,

There's a recent entry in the 2.6 branch from fred stating:

types don't have a guaranteed truth value, so check that it
isn't None

the diff is here:
http://cvs.zope.org/Zope/lib/python/ZTUtils/Zope.py.diff?r1=1.10.6.3r2=1.10.6.4only_with_tag=Zope-2_6-branch

This same fix needs to be applied to at least the 2.7 branch and HEAD,
probaly other branches too, but I haven't checked.

Should I file a bug for this?

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: fdrake's fix for brian's fix for bug 1203 needs to be applied in other branches

2004-01-27 Thread Leonardo Rochael Almeida
On Tue, 2004-01-27 at 12:42, Tres Seaver wrote:
 [...]
 The 2.7 branch and the head are the only two other active branches;  I 
 just checked in a fix which removes the pre-2.3 compatibility code.

Funny, with all the talk about 2.8 including only the ZODB work and
fixes, I thought we'd have a 2.8 branch by now... :-)

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New-style classes and ClassSecurityInfo, fixed already?

2004-01-04 Thread Leonardo Rochael Almeida

On Mon, 2004-01-05 at 00:06, Mike C. Fletcher wrote:
 http://zope.org/Collectors/Zope/1055
 
 Is a bug report I filed a while ago for a fairly trivial breakage of the 
 ClassSecurityInfo class due to the use of assignment to the class 
 dictionary during the apply method. [...]
 
 The InitializeClass function also needs to have the same transformation 
 applied to it.
 
 If desired I can pull the CVS tree and produce a diff if the problem 
 isn't already solved.

If you do that, and attach the patch to the bug report, people with CVS
access will have even less excuses not to fix it :-)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Preview of a Stackless Zope Application

2003-12-11 Thread Leonardo Rochael Almeida
On Thu, 2003-12-11 at 01:50, Christian Tismer wrote:
 Howdy,
 
 I made a little demo of Stackless Zope.
 It is just a quick hack to see how things
 can work. The example is a long-running
 Python method which prints lines to the
 browser.
 The key to this surprizing solution is
 tasklets, channels, and thread pickling.
 
 Let me know your thoughts...
 
 http://www.centera.de/tismer/stackless/zope_demo

This is very impressive. Can we get the rest of the source code? like,
what is the definition of channel_send()?

[]'s Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


RE: [Zope-dev] To the brave folks trying Zope HEAD...

2003-12-11 Thread Leonardo Rochael Almeida
On Thu, 2003-12-11 at 15:28, Tim Peters wrote:
 Anyone?  Since Sidnei's efforts to use the head are exposing problems, it
 would be great if we could keep him obsessed wink with it a bit longer.

Just point Sidnei torwards (sp?) some pretty API docs about old and new
BTrees and he'll be happy as an otter. He'll come up with a conversion
script in no time :-)

[]'s

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SMPT Authorization support

2003-12-11 Thread Leonardo Rochael Almeida
On Thu, 2003-12-11 at 18:26, Lennart Regebro wrote:
 I just checked in (on regebro-esmpt_support-branch) support for setting a
 username and password on the mailhost. Very nice and easy fix, and lot's of
 people want it.
 
 But I realized that what you actually might want is to have different login
 and password for each user, that is a possibility to pass username +
 password to send(). And maybe you want a setting to allow this or not.
 
 Or is this overkill? What do you think?

IMHO, YAGNI. Besides, a lot of userfolders have encrypted passwords,
including Zope's default.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Post-mortem [Was: Zope 2.7.0 b3 regressions]

2003-12-09 Thread Leonardo Rochael Almeida
I'd like to suggest that any new methods created to handle paths or urls
do not require parameters for different behaviours (which should be
implemented as different methods), so that they can be more easily used
from plain ZPT path expressions.

Cheers, Leo

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: Zope 2.7.0 b3 regressions

2003-12-08 Thread Leonardo Rochael Almeida
On Mon, 2003-12-08 at 09:35, Stefan H. Holek wrote:
 [...]
 So by my definition, the URL (relative or not) should *always* include  
 eventual _vh_xyz parts. If what one really needs is related to the  
 physical layout of the ZODB, there is always getPhysicalPath().

+1

 URLs are in fact just some whack attributes of objects, and objects can  
 have more than one URL at any time, depending on Vhost configs *only*.  
 URLs are a function of the current REQUEST (traversal) and do represent  
 little information with regard to an object's location in the ZODB.

+1

 I see the main issue here in that the concepts of URL and physical  
 location are not well separated (CMF's getIcon() attempting to use URLs  
 to locate objects for example).

IMHO, this is broken behaviour. If you try to use an URL to locate an
object, the only sane behaviour is to feed this URL to an URL api
(probably in the REQUEST object) to get it mapped to a physical path.

 Should this be your last word on this I am with Lennart in that we have  
 to think about a whole new class of API methods for URL information.

I think this should be done anyway, because of backward compatibility
problems. Really, I think it's ok if at some point we simply say hey,
now we'll use this new API because that old API was broken and people
relied on the broken behaviour. This is certainly better than pulling
people's rug under their feet. We could then start deprecating the old
API and eventually pull it away, if the arrival of Zope3 doesn't obviate
it anyway :-)


 P.S.: I have written a bunch of regression tests for absolute_url  
 behavior over the weekend and if nobody tells me otherwise am going to  
 check them into Products/SiteAccess/tests.

+5 Yes, please!

As the author of ASP404, I'd really like to be able to rely on Zope's
virtual hosting behaviour.

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Double products in management interface pulldown menu after database copy to new zope version.

2003-11-05 Thread Leonardo Rochael Almeida
On Wed, 2003-11-05 at 09:07, Martin Koekenberg wrote:
 Hello,
  
 I've made the step from 2.6.2b5 to 2.6.2. Everything is working well,
 but something went wrong.
 In the management interface are some option in the pulldown menu
 listed twice:

I have no idea whether this will work (make backups, yadda, yadda...)
but you can try going to the Control_Panel/Products folder in the ZMI,
deleting every product there and restarting Zope.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Bare except and ConflictError in manage_beforeDelete

2003-10-31 Thread Leonardo Rochael Almeida
On Fri, 2003-10-31 at 09:28, Florent Guillaume wrote:
 [...] manage_beforeDelete has this code:
  try:
  if hasattr(aq_base(object), 'manage_beforeDelete'):
  object.manage_beforeDelete(item, container)
  except BeforeDeleteException, ob:
  raise
  except:
  LOG('Zope',ERROR,'manage_beforeDelete() threw',
  error=sys.exc_info())
  pass
 Which means that ConflictErrors in my invariant code get swallowed [...]
 
 I want to add an additionnal:
  except ConflictError:
  raise

+1

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] We need a user search API (was Better MemberData search for CMF)

2003-10-31 Thread Leonardo Rochael Almeida
There is another function in Zope that would be an excelent client of
this search API: the local-roles screen of default Zope objects.

As it is now, it tries to list all existing userids to allow the user to
pickup a userid to associate with a role.

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope doesn't know enough mime types.

2003-10-24 Thread Leonardo Rochael Almeida
On Fri, 2003-10-24 at 11:48, Romain Slootmaekers wrote:

 [...]
 
 (Monkey)patching zope(s) to workaround (bugs | missing features) is 
 indeed sometimes needed but if the fix is as simple as adding some 
 name-value pairs I see no reason why not to do this before the next release.

Put it in the collector.

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] WebDAV and UTF-8 filenames

2003-10-15 Thread Leonardo Rochael Almeida
If you set the management_page_charset property to utf-8 in a folder
(even the root folder) then Zope will inform the browser that the
charset of the management pages of this folder and all subobjects is
utf-8 and the IDs in the folder listing page will look right.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] WebDAV and UTF-8 filenames

2003-10-15 Thread Leonardo Rochael Almeida
On Wed, 2003-10-15 at 12:50, Lennart Regebro wrote:
 Leonardo Rochael Almeida wrote:
  If you set the management_page_charset property to utf-8 in a folder
  (even the root folder) then Zope will inform the browser that the
  charset of the management pages of this folder and all subobjects is
  utf-8 and the IDs in the folder listing page will look right.
 
 This does seem to solve the problem (at least with OpenOffice. Cadaver 
 does not like it, but that is probably a Cadaver bug).

If the does not seem to like it is just a charset display issue, and
not an explicit error condition, then this is probably because Cadaver
is a command line client, which usually (but not always) means that it's
totally obvlivious to charset issues. It'll just spew whatever it
receives from the server to your terminal and vice-versa. In this case,
it's your terminal's job to interpret utf-8 chars correctly in this
case, and to pass accented chars to Cadaver as two byte utf-8 sequences
when you type them on the terminal.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-CMF] Re: [Zope-dev] _p_deactivate() and _v_ variables?

2003-10-10 Thread Leonardo Rochael Almeida
On Fri, 2003-10-10 at 14:34, Dieter Maurer wrote:
 If such a _v_ attribute is flushed, the next access to the DA
 (in the same request) reopens the database. As this is a new
 connection, it does not see the changes made by the previous
 connection (in the same request).
 
 This can lead to very nasty non-deterministic and almost ununderstandable
 errors.

Such as prematurely triggered integrity contraints that would be
satisfied by another operation before the end of the transaction.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] relations in objects

2003-10-09 Thread Leonardo Rochael Almeida
On Fri, 2003-10-10 at 00:46, Jason Corbett wrote:
 Thanks for your reply.  I've actually been thinking in
 an object oriented form for a while.  I've looked at
 implimenting this project in Java using either
 prevailance or a object persistence model that mapped
 to a RDBMS.  I like the idea of zope, so maybe I
 should clarify my question:
 
 How does an object in zope know where it sits in the
 hirearchy, and how does it reach other objects. 
 That's what I'm really looking for, I can probably
 code the rest of the parts.

In my experience, you should put an object inside another if and only if
they have an explicit containment relationship, e.g. a car has 4 tires
and a steering wheel. The steering wheel can belong to (at most) one car
at any moment in time, so it would make sense to put the steering wheel
object inside the car object. The same is not true of, for instance,
students and school classes. In this case you either store a reference
to the student in the school class (eg a student id in a lines or
tokens property) or you create an object to represent the
class-student relationship (for example an enrollment) and store it
somewhere.

Tip: always use methods that return the objects you need, for instance
aSchoolClass.students() this way you can more easily change the storage
of the relationship information when you change your mind. And you will
change your mind a lot of times.

Tip2: a lot of times you'll implement the above mentioned methods as
catalog queries, like: what objects in the other side of the
relationship reference me?

Tip3: look mxmRelations

Cheers, Leo

PS: just because this is a pet peeve of mine, I'll explain that a
relation and a relationship are two very different things.
Relation is the mathematical term for a table, a set of distinct
elements (rows) with the same kinds of attributes (columns). You can
think of a relation (table) of cars, or a relation (table) of students.
Relational databases get their names because they store relations and
allow you to do some relational algebra with (usually) SQL.

A relationship, on the other hand, is a link, or association, between
elements.

RDBs allow you to model relationships relatively easily thru either
relational operations:

SELECT * from cars, steering_wheels
WHERE steering_wheels.carId = car.carId AND
steering_wheels.wheelType = sport

or by storing relationship information in relations (sometimes known as
link relations or link tables):

SELECT * from enrollments, classes, students
WHERE classes.classId = enrollments.classId AND
enrollments.studentId = students.studentId AND
students.studentName = Jason Corbett

But RDBs themselves have absolutely no concept of relationships.

So, next time you read the word relation, think table :-)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Re: catalogObject changes (Zope-2_6-branch)

2003-10-08 Thread Leonardo Rochael Almeida
On Tue, 2003-10-07 at 21:37, Leonardo Rochael Almeida wrote:
 On Tue, 2003-10-07 at 16:57, Chris McDonough wrote: 
  OK, I checked in changes on the 2.6, 2.7, and HEAD branches that add an
  update_metadata keyword argument to Catalog's catalogObject and
  ZCatalog's catalog_object.  The argument defaults to true.  I also added
  some tests, and made sure that the reindexIndex method of ZCatalog took
  advantage of this feature.
 
 Cool! Can we get some form of 2.6.3 beta out to encourage people not to
 migrate to 2.6.2?

Or maybe a HotFix?

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Which ZODB to use for both Zope 2.5.1 and 2.6.1 onPython 2.1.3

2003-10-08 Thread Leonardo Rochael Almeida
On Wed, 2003-10-08 at 06:46, Dario Lopez-Kästen wrote:
 Also I forgot to mention: this is for a kluster we are setting up, so I need
 to know what ZEO is recommended for us with Zope 2.5.1 and 2.6.1 with Python
 2.1.3.

I'd say ZODB 3.1.4 from http://zope.org/Products/ZODB3.1/

You have to install the whole of ZODB into your Zope, though. Not just
ZEO. But I think that is easier than it sounds. The installation
instructions in the package mention a switch to install the full ZODB
into Zope for you.

Cheers, Leo

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


  1   2   3   >