Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-03-01 Thread Christian Zagrodnick
On 2011-02-28 07:43:55 +0100, Christian Zagrodnick said:

 On 2011-02-25 21:56:49 +0100, David Glick said:
 
 On 2/20/11 1:32 AM, Christian Zagrodnick wrote:
 On 2011-02-19 17:17:44 +0100, Hanno Schlichting said:
 
 On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnickc...@gocept.com  
 wrote:
 On 2011-02-16 22:22:53 +0100, Hanno Schlichting said:
 svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called
Sure.
I'll 
 
 review, merge and release. Should be sometime this week,
 cannot promise a day.
 Branch reviewed, merged and released in Acquisition 2.13.6.
 
 Could you remove the merged branch once you updated your buildout config?
 Done.
 
 Thanks for releasing!
 This change introduces a regression when calling unicode on wrapped
 objects that implement __str__ but not __unicode__. Essentially it is
 now doing the equivalent of str(aq_base(obj)) ... __str__ used to get a
 wrapped object as 'self', but now it is unwrapped.
 
 Here's a failing test that can be added to Acquisition's TestUnicode
 test case to demonstrate the issue:
 
 def test_str_fallback_is_still_wrapped(self):
 class A(Acquisition.Implicit):
 def __str__(self):
 return str(len(Acquisition.aq_chain(self)))
 wrapped = A().__of__(A())
 self.assertEqual(u'2', unicode(wrapped))
 
 This is currently causing some regressions in Plone tests.
 
 I'll have a look at it. Thanks for spotting that.

Fixed in r120651 (trunk)

- Fixed bug: When an object did not implement ``__unicode__``, calling
  ``unicode(wrapped)`` was calling ``__str__`` with an unwrapped ``self``.

Is the situation with Plone better now?


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-02-27 Thread Christian Zagrodnick
On 2011-02-25 21:56:49 +0100, David Glick said:

 On 2/20/11 1:32 AM, Christian Zagrodnick wrote:
 On 2011-02-19 17:17:44 +0100, Hanno Schlichting said:
 
 On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnickc...@gocept.com  
 wrote:
 On 2011-02-16 22:22:53 +0100, Hanno Schlichting said:
 svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called
Sure.
I'll 
 
 review, merge and release. Should be sometime this week,
 cannot promise a day.
 Branch reviewed, merged and released in Acquisition 2.13.6.
 
 Could you remove the merged branch once you updated your buildout config?
 Done.
 
 Thanks for releasing!
 This change introduces a regression when calling unicode on wrapped
 objects that implement __str__ but not __unicode__. Essentially it is
 now doing the equivalent of str(aq_base(obj)) ... __str__ used to get a
 wrapped object as 'self', but now it is unwrapped.
 
 Here's a failing test that can be added to Acquisition's TestUnicode
 test case to demonstrate the issue:
 
  def test_str_fallback_is_still_wrapped(self):
  class A(Acquisition.Implicit):
  def __str__(self):
  return str(len(Acquisition.aq_chain(self)))
  wrapped = A().__of__(A())
  self.assertEqual(u'2', unicode(wrapped))
 
 This is currently causing some regressions in Plone tests.

I'll have a look at it. Thanks for spotting that.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-02-20 Thread Christian Zagrodnick
On 2011-02-19 17:17:44 +0100, Hanno Schlichting said:

 On Thu, Feb 17, 2011 at 8:27 AM, Christian Zagrodnick c...@gocept.com wrote:
 On 2011-02-16 22:22:53 +0100, Hanno Schlichting said:
 svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called

Sure. 
 
 I'll review, merge and release. Should be sometime this week,
 cannot promise a day.
 
 Branch reviewed, merged and released in Acquisition 2.13.6.
 
 Could you remove the merged branch once you updated your buildout config?

Done.

Thanks for releasing!


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-02-16 Thread Christian Zagrodnick
On 2011-02-16 10:10:05 +0100, Hanno Schlichting said:

 On Wed, Feb 16, 2011 at 9:18 AM, Michael Howitz m...@gocept.com wrote:
 Zope 2.12.8 on Python 2.6 breaks the same way as 2.13.
 But Zope 2.11.7 on Python 2.5 works correctly.
 
 So either Python or Acquisition must have changed since than.
 
 Acquisition changed a lot from 2.11 to 2.12 - it got support for
 parent pointers for example. The full changelog is quite long, but
 should be unrelated
 (http://pypi.python.org/pypi/Acquisition#changelog).
 
 The full diff is at:
 
 svn di 
 svn+ssh://svn.zope.org/repos/main/Acquisition/branches/2.11/src/Acquisition/_Acquisition.c
svn+ssh://svn.zope.org/repos/main/Acquisition/trunk/src/Acquisition/_Acquisition.c

There's 
 
 nothing obvious I can see here.

I suspect a change in python (which I did not follow up after getting 
strange feelings when looking at PyObject_Unicode).

Nevertheless I've fixed that on a branch:

svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called

Hanno: 

Would you review that change please?

Thanks.
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-02-16 Thread Christian Zagrodnick
On 2011-02-16 22:22:53 +0100, Hanno Schlichting said:

 On Wed, Feb 16, 2011 at 10:19 PM, Christian Zagrodnick c...@gocept.com 
 wrote:
 I suspect a change in python (which I did not follow up after getting
 strange feelings when looking at PyObject_Unicode).
 
 Nevertheless I've fixed that on a branch:
 
 svn+ssh://svn.zope.org/repos/main/Acquisition/branches/zagy-unicode-should-be-called

Hanno:

Would 
 
 you review that change please?
 
 Sure. I'll review, merge and release. Should be sometime this week,
 cannot promise a day.

Thanks. There is no pressure. mr.developer FTW :)

Anyway, I've added another test to make myself more comfortable.

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Acquisition wrapped objects do not behave well on unicode call

2011-02-15 Thread Christian Zagrodnick
On 2011-02-15 15:26:28 +0100, Hanno Schlichting said:

 On Tue, Feb 15, 2011 at 2:35 PM, Michael Howitz m...@gocept.com wrote:
 When I have an acquisition wrapped object, e. g. my_object and call:
 
 unicode(my_object)
 
 The method __str__ of my_object is called even when it has an 
 __unicode__ method.
 
 Acquisition wrappers only fill the tp_repr and tp_str slot and as far
 as I can tell there's no tp_unicode slot in PyObject_HEAD_INIT.
 
 So I'm not sure how to add the C equivalent of a __unicode__ to the
 Wrappertype and XaqWrappertype PyExtensionClasses. It would probably
 have to do a lookup for a __unicode__ method on the wrapped instance,
 call it if it exists and otherwise call its own __str__ - essentially
 duplicating the logic of the string type.

Jup.

 
 My C-fu is too weak to attempt this.

Heh. My C-fu is also rather weak but I might try it if there are no 
objections.  (or there is somebody hacking it in 5 minutes …)

 The workaround is to call
 unicode(aq_base(my_object)).

Yes, but that's not really an option.

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Can ZTK 1.0 support Python 2.7?

2010-07-13 Thread Christian Zagrodnick
On 2010-07-13 14:12:01 +0200, Hanno Schlichting said:

 Hi.
 
 We have Python 2.7 final now and some work has begun on making ZTK
 packages compatible with it. Currently we still see various test
 failures in the zopeapp set though and nobody who steps up to fix
 them.
 
 Apart from that, we have made a promise to support Python 2.4 up to
 2.6 for the ZTK 1.0 release. The ZODB 3.10 releases do no longer
 support Python 2.4 but require 2.5. The ZODB 3.9.x releases are in
 maintenance mode for a while and currently don't support Python 2.7. I
 doubt that we can get official 2.7 support for the 3.9.x release line.
 
 Given all of these, I'm leaning towards not supporting Python 2.7 for
 a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
 support 2.7 in addition.

Yes, ZTK 1.0 should become stable/released soon. Adding a new Python 
version or removing one, doesn't help.

But I really want to see Python 2.7 support rather soon. So how do we 
actually proceed there? Even after ZTK 1.0 is out, how is the 
transition made to 1.1? I suppose there could be a 1.0.1 at the same 
time as a 1.1.0.

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Can ZTK 1.0 support Python 2.7?

2010-07-13 Thread Christian Zagrodnick
On 2010-07-13 20:37:42 +0200, Tres Seaver said:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Christian Zagrodnick wrote:
 On 2010-07-13 14:12:01 +0200, Hanno Schlichting said:
 
 Hi.
 
 We have Python 2.7 final now and some work has begun on making ZTK
 packages compatible with it. Currently we still see various test
 failures in the zopeapp set though and nobody who steps up to fix
 them.
 
 Apart from that, we have made a promise to support Python 2.4 up to
 2.6 for the ZTK 1.0 release. The ZODB 3.10 releases do no longer
 support Python 2.4 but require 2.5. The ZODB 3.9.x releases are in
 maintenance mode for a while and currently don't support Python 2.7. I
 doubt that we can get official 2.7 support for the 3.9.x release line.
 
 Given all of these, I'm leaning towards not supporting Python 2.7 for
 a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
 support 2.7 in addition.
 
 Yes, ZTK 1.0 should become stable/released soon. Adding a new Python
 version or removing one, doesn't help.
 
 But I really want to see Python 2.7 support rather soon. So how do we
 actually proceed there? Even after ZTK 1.0 is out, how is the
 transition made to 1.1? I suppose there could be a 1.0.1 at the same
 time as a 1.1.0.
 
 As soon as we get to 1.0b1, the release team will make a 'branches/1.0'
 branch for stabilization, and the trunk can then be updated to drop 2.4
 support and add 2.7 support.

Actually I was thinking about the individual packages. I assume 
dropping Python 2.4 should bump the respective package version at least 
from 1.x.y to 1.x+1.0, right?

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] zope.server: Exception during task logging

2010-06-11 Thread Christian Zagrodnick
On 2010-05-27 16:44:58 +0200, Tres Seaver tsea...@palladion.com said:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Christian Zagrodnick wrote:
 On 2010-04-14 14:58:47 +0200, Christian Zagrodnick c...@gocept.com said:
 
 Hi,
 
 zope.server logs the Exception during task message to the root
 
 logger. So there is no (easy/useful) way to filter that.
 
 I'd like to change this logging to a zope.server logger. (i.e. using
 
 logging.getLogger(...))
 
 Objections?
 
 Since there where none thats implemented in r112771.
 
 Would somebody make a release or give me (zagy) the pypi permissions?
 
 I just added you.

Thanks. I just released it. (3.6.2)

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] zope.server: Exception during task logging

2010-05-27 Thread Christian Zagrodnick
On 2010-04-14 14:58:47 +0200, Christian Zagrodnick c...@gocept.com said:

 Hi,
 
 zope.server logs the Exception during task message to the root
 
 logger. So there is no (easy/useful) way to filter that.
 
 I'd like to change this logging to a zope.server logger. (i.e. using
 
 logging.getLogger(...))
 
 Objections?

Since there where none thats implemented in r112771.

Would somebody make a release or give me (zagy) the pypi permissions?

Thanks,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] zope.server: Exception during task logging

2010-04-14 Thread Christian Zagrodnick
Hi,

zope.server logs the Exception during task message to the root 
logger. So there is no (easy/useful) way to filter that.

I'd like to change this logging to a zope.server logger. (i.e. using 
logging.getLogger(...))

Objections?
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] ZConfig + SMTP Auth email logger

2010-04-10 Thread Christian Zagrodnick
Hi,

I just added SMTP authentication to the email notification logger in ZConfig.

Would somebody make a release please or give me (zagy) the proper PyPI rights?

Thanks,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] IAbsoluteURL for browser view should contain @@?

2010-04-01 Thread Christian Zagrodnick
Hi,

the explicit way to address a view is using the /@@viewname namespace 
traversal.

An IAbsoluteURL for a browser view returns an URL without the @@ (i.e. 
/foo/bar/view instead of /foo/bar/@@view). I think this should be 
changed so that the URL contains the @@.

If you agree with this, where should I place this adapter?

The two relevant interfaces are
zope.browser.interfaces.IBrowserView
zope.traversing.browser.interfaces.IAbsoluteURL

But neither package depends on the other, so a different package might 
be more suiteable?

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] IAbsoluteURL for browser view should contain @@?

2010-04-01 Thread Christian Zagrodnick
On 2010-04-01 12:31:10 +0200, Jacob Holm j...@improva.dk said:

 Marius Gedminas wrote:
 
 Are you sure that most views provide IBrowserView these days?  URL
 traversal looks them up as multi-adapters providing just Interface.
 
 
 True and you will almost never see a view class using
 implements(IBrowserView) directly.  Still, if you use the browser:view
 or browser:page zcml directives from zope.browserpage (used to live in
 zope.app.publisher.browser) to register your views, then the magic class
 that they create for you and that is *actually* registered is a
 descendant of zope.publisher.browser.BrowserView which *does* implement
 IBrowserView.

Yes indeed.

One problem I found already is, that the FileResource is more an 
IBrowserView than an IResources currently. That is currently 
registering an IAbsoluteURL adapter for IBrowserView will break the URL 
for file resources. But that's solvable.
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] Update ZTK: zc.resourcelibrary 1.3.1

2010-03-24 Thread Christian Zagrodnick
Hi,

I just released zc.resourcelibrary 1.3.1. IMO the ZTK should be updated 
accordingly.

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Update ZTK: zc.resourcelibrary 1.3.1

2010-03-24 Thread Christian Zagrodnick
On 2010-03-24 12:12:07 +0100, Baiju M mba...@zeomega.com said:

 On Wed, Mar 24, 2010 at 3:06 PM, Christian Zagrodnick c...@gocept.com wrote:
 Hi,
 
 I just released zc.resourcelibrary 1.3.1.
 
 Great !
 
 IMO the ZTK should be updated accordingly.
 
 +1

done (r110171)

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] Generations in Zope 2

2009-12-15 Thread Christian Zagrodnick
Hi,

to get generations working in Zope 2 the following subscriber is needed:

@zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
def evolve_minimum(event):
zope.app.generations.generations.evolve(
Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM)


I think should become part of Zope 2 / Five. Objections?

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] Generations in Zope 2

2009-12-15 Thread Christian Zagrodnick
On 2009-12-15 11:20:19 +0100, Wichert Akkerman wich...@wiggy.net said:

 On 12/15/09 11:02 , Christian Zagrodnick wrote:
 Hi,
 
 to get generations working in Zope 2 the following subscriber is needed:
 
 @zope.component.adapter(zope.app.appsetup.IProcessStartingEvent)
 def evolve_minimum(event):
 zope.app.generations.generations.evolve(
 Zope2.DB, zope.app.generations.generations.EVOLVEMINIMUM)
 
 
 I think should become part of Zope 2 / Five. Objections?
 
 -1, this would add a needless dependency on zope.app.generations to Zope
 2 as far as I can see. Why not move include this in zope.app.generations
 itself in a [zope2] extra ? Or create a tiny five.generations package to
 do this.

five.generations is part of five enough for me ;)

I don't like an zope2 extra for zope.app.generations.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] zope.testing: Define __add__ for RENormalizing

2009-12-06 Thread Christian Zagrodnick
On 2009-06-18 10:00:01 +0200, Christian Zagrodnick c...@gocept.com said:

 Hi,
 
 I suggest defining __add__ for zope.testing.renormalizing.RENormalizing
 
 which would return a new Checker with the transformers combined.
 
 This allow better reuse of those checkers without having to define the
 
 patterns separately. Like
 
 checker = checker_a + checker_b.

Finally got that in: r106221.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] z3c.recipe.i18n tests fail

2009-12-01 Thread Christian Zagrodnick
Hi,

the tests fail with the following error:

Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
Traceback (most recent call last):
  File /Users/zagy/development/python/lib/python2.6/unittest.py, line 
270, in run
self.setUp()
  File 
/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
 
line 2289, in setUp
self._dt_setUp(test)
  File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
zc.buildout.testing.install('zope.app.publisher', test)
  File 
/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
 
line 464, in install
if dist.location.endswith('.egg'):
AttributeError: 'NoneType' object has no attribute 'location'

I actually have no idea why this is happening. Anybody got a clue?

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] z3c.recipe.i18n tests fail

2009-12-01 Thread Christian Zagrodnick
On 2009-12-01 16:36:50 +0100, yuppie y.2...@wcm-solutions.de said:

 Christian Zagrodnick wrote:
 Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt
 Traceback (most recent call last):
 File /Users/zagy/development/python/lib/python2.6/unittest.py, line
 270, in run
 self.setUp()
 File
 /Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py,
line 
 
 2289, in setUp
 self._dt_setUp(test)
 File /private/tmp/trunk/src/z3c/recipe/i18n/tests.py, line 43, in setUp
 zc.buildout.testing.install('zope.app.publisher', test)
 File
 /Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py,
line 
 
 464, in install
 if dist.location.endswith('.egg'):
 AttributeError: 'NoneType' object has no attribute 'location'
 
 Should be fixed now. Yuppie

Thanks! And it was such an easy fix! :)

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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 )


Re: [Zope-dev] zc.zope3recipes:instance: zdaemon/eventlog rotatation

2009-09-17 Thread Christian Zagrodnick
On 2009-09-16 13:03:44 +0200, Jim Fulton j...@zope.com said:

 On Wed, Sep 16, 2009 at 5:28 AM, Christian Zagrodnick c...@gocept.com wrote:
 The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes
 the transcript_log and zdaemon's eventlog to the same file. That's
 actually fine.
 
 ZDaemon's reopen_transcript does exactly that: it reopens *only* the
 transcript. So when rotating the logfile (as zc.zope3recipes does it
 via logrotate) ZDaemon messages still go to the old logfile.
 
 I see two obvious ways to fix that:
 
 a) Write ZDaemon's eventlog to stdout
 
 That won't help.  The messages are coming from the controller.

Well, I think it helps in the way, that the messages are not written to 
a logfile. Thus nothing needs to be reopend or rotated. They won't be 
stored anyware obviously.

 
 b) Add a sane way to reopen the logfile.  There is a logreopen command
 in ZDaemon but that actually restarts the daemon process.
 
 Comments? Suggestsions?
 
 The controller needs to be more careful about how it manages it's log
 file.  It needs to keep track of the handler used and, when the
 transacript file is reopened, it needs to remove the old handler it
 was using and create a new one.
 This is probably complicated by ZConfig which is managing the logging
 configuration.  This is easy to deal with if you're willing to rely on
 the logging systems internal details. :)

Eeek :)

Oh I'm not sure if it is complicated. But I'll have a look into it when 
I've got some time.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] zc.zope3recipes:instance: zdaemon/eventlog rotatation

2009-09-16 Thread Christian Zagrodnick
Hi,

The zc.zope3recipes:instance recipe creates a zdaemon.conf which writes 
the transcript_log and zdaemon's eventlog to the same file. That's 
actually fine.

ZDaemon's reopen_transcript does exactly that: it reopens *only* the 
transcript. So when rotating the logfile (as zc.zope3recipes does it 
via logrotate) ZDaemon messages still go to the old logfile.

I see two obvious ways to fix that:

a) Write ZDaemon's eventlog to stdout
b) Add a sane way to reopen the logfile.  There is a logreopen command 
in ZDaemon but that actually restarts the daemon process.

Comments? Suggestsions?
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone 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] zope.testing: Define __add__ for RENormalizing

2009-06-18 Thread Christian Zagrodnick
Hi,

I suggest defining __add__ for zope.testing.renormalizing.RENormalizing 
which would return a new Checker with the transformers combined.

This allow better reuse of those checkers without having to define the 
patterns separately. Like

checker = checker_a + checker_b.

Comments?


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] [Checkins] SVN: zope.app.publisher/trunk/ To make browsers update their caches of resources immediately when the

2009-06-10 Thread Christian Zagrodnick
Hoi,

On 2009-06-09 15:51:03 +0200, Stephan Richter 
srich...@cosmos.phy.tufts.edu said:

 On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
   To make browsers update their caches of resources immediately when the
   resource changes, the absolute URLs of resources can now be made to
 contain a hash of the resource's contents, so it will look like
   /++noop++12345/@@/myresource instead of /@@/myresource.
  
   - Implemented an AbsoluteURL adapter that computes a hash of the
 resource's contents and inserts that into the URL. - Content hashes will
 be
 cached in memory, except when in developer mode - Introduced a ++noop++
 traverser that simply throws away the path segment - Wrote a bit of
 documentation about resources
 
 Mmmh, this looks like a lot of extra code to get behavior that is served
 
 better with different tools. Have you looked at z3c.versionedresource and
 
 z3c.traverser? Both of those should solve these type of use cases well.

The checkin actually is two in one (which aruably is not such a good thing):

1. Make resources compute urls with an IAbsoluteURL adapter so they 
behave like every other object.

2. Provide an optional hashing adapter (and the ++noop++ namespace).

I don't think we have to argue about 1.

The ++noop++ and hashing could easily be moved to a different package. 
The idea behind the hasing is that one should not have to think about 
new versions or cache invalidations. That's also why in development 
mode the hash is computed every time and not just once: It aids 
development a lot. But it helps in deployment as well of course.

So, why in a zope package? Because I really think this is a core issue 
of a web framework. Do we really want to not change any zope.* package 
any more in regard to new features?

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] z3c.recipe.i18n tests break on unix

2009-05-15 Thread Christian Zagrodnick
Hi,

the tests of z3c.reipce.i18n break on unix systems, for instance with:

Failed example:
ls('bin')
Expected:
-  buildout-script.py
-  buildout.exe
-  i18ncompile-script.py
-  i18ncompile.exe
-  i18nextract-script.py
-  i18nextract.exe
-  i18nmergeall-script.py
-  i18nmergeall.exe
-  i18nstats-script.py
-  i18nstats.exe
Got:
-  buildout
-  i18ncompile
-  i18nextract
-  i18nmergeall
-  i18nstats


What's the general way of testing those things in both environments? I 
don't have a windows box to test this. I also see most recipes are 
tested only for unix (which would be fine for me).

How should we proceed in this special case? Actually there is a bug 
which I'm going to fix w/o having passing tests now.

Regards,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] z3c.recipe.i18n tests break on unix

2009-05-15 Thread Christian Zagrodnick
On 2009-05-15 12:16:30 +0200, Roger Ineichen d...@projekt01.ch said:

 Hi Christian
 
 What's the general way of testing those things in both
 
 environments? I don't have a windows box to test this. I also
 
 see most recipes are tested only for unix (which would be
 
 fine for me).
 
 
 How should we proceed in this special case? Actually there is
 
 a bug which I'm going to fix w/o having passing tests now.
 
 I'm fine if you switch the tests that they pass on linux and
 will break on windows. I can catchup the tests later and try
 to make them running again on windows and linux.

Okay, would you give me the pypi access (user zagy)?


 
 Thanks a lot for help improve missing parts or fix issues!

np, after all I want to use it :)



-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] release of lovely.remotetask?

2009-02-11 Thread Christian Zagrodnick
Hi,

I'd like to create a new release of lovely.remotetask. Could somebody 
give me (zagy) the pypi rights?

Thanks,
-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Release zc.selenium on pypi

2009-01-19 Thread Christian Zagrodnick
On 2009-01-07 14:32:07 +0100, Benji York be...@zope.com said:

 On Wed, Jan 7, 2009 at 7:29 AM, Christian Zagrodnick c...@gocept.com wrote:
 there is zc.selenium on svn.zope.org which is not on pypi. Could this
 be released?
 
 Yes.
 
 Also it speaks of the ZVLS in some files which doesn't
 seem to be correct.
 
 It's not correct.  They should all be ZPL.

Just released 1.1.0 and added you as owner.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Deprecate ITerms in zope.app.form? [Re:zope.browser?]

2009-01-07 Thread Christian Zagrodnick
On 2008-12-22 18:48:47 +0100, Martijn Faassen faas...@startifact.com said:

 Hi there,
 
 All right, I was getting a bit confused when it appeared you were
 arguing against moving things at all, but you're basically in favor of
 leaving the old APIs intact without explicitly breaking them.
 
 I think we need to think of some way to signal that the preferred
 import location of something has changed that doesn't result in
 deprecation warnings. It's clear from this discussion that this should
 be done upon request, not during runtime. The old import location can
 then stay around indefinitely.

Right. May I remove the deprecation warning then?

 
 I'd like a tool that I can point at a package and it'll sort through
 whatever it imports and tell me which ones are not importing from the
 right public location. Each package should have some way to indicate
 to that tool whether certain imports are better made from somewhere
 else if one is in the business of reducing dependencies. Perhaps a #
 BBB comment is enough, though what it looks like exactly depends a bit
 on how the tool will work in the end.

A correctly crafted BBB together with some simple grep-like tool would 
be sufficient, would it not?

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Release zc.selenium on pypi

2009-01-07 Thread Christian Zagrodnick
Hi,

there is zc.selenium on svn.zope.org which is not on pypi. Could this 
be released? Also it speaks of the ZVLS in some files which doesn't 
seem to be correct.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]

2008-12-15 Thread Christian Zagrodnick
On 2008-12-12 16:04:09 +0100, Robert Niederreiter r...@squarewave.at said:

 Hi,
 
 Am Freitag, den 12.12.2008, 15:51 +0100 schrieb Christian Zagrodnick:
 On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said:
 
 Hey,
 
 Christian Zagrodnick wrote:
 [snip]
 That's good. One thing which is not good is that you deprecated the use
 of ITerms from zope.app.form. I'd just leave the reference/import there
 like we did with ISite in zope.app.component.
 
 Why is such a deprecation warning bad? Wouldn't this encourage people to
 update their code?
 
 
 A deprecation warning isn't bad. But I think we should not deprecate
 the use of ITerms from zope.app.form. I don't see a gain in this API
 change.
 Imo it's a bad idea to keep exactly the same interface in 2 places. At
 least i don't see an improvement or convenience in keeping it.
 
 the only real reason to keep it is for legacy reasons, but import
 adoption should not be that hard ;)

No it is not. I just question why we force everybody to use the new 
location when we did not do so with ISite. It is exactly the same issue 
with two different outcomes.

The canonical location for ISite is zope.location now. It used to 
reside in zope.app.component but was moved to zope.location w/o 
deprecating the use from zope.app.location to keep the API backward 
compatible. I really do not see a differrence to ITerms here.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Deprecate ITerms in zope.app.form? [Re: zope.browser?]

2008-12-15 Thread Christian Zagrodnick
On 2008-12-15 13:44:43 +0100, Roger Ineichen d...@projekt01.ch said:

 Hi Christian
 
 Betreff: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:
 zope.browser?]
 
 [...]
 
 A deprecation warning isn't bad. But I think we should not
 deprecate
 the use of ITerms from zope.app.form. I don't see a gain
 in this API
 change.
 Imo it's a bad idea to keep exactly the same interface in 2
 places. At
 least i don't see an improvement or convenience in keeping it.
 
 the only real reason to keep it is for legacy reasons, but import
 adoption should not be that hard ;)
 
 No it is not. I just question why we force everybody to use
 the new location when we did not do so with ISite. It is
 exactly the same issue with two different outcomes.
 
 The canonical location for ISite is zope.location now. It
 used to reside in zope.app.component but was moved to
 zope.location w/o deprecating the use from zope.app.location
 to keep the API backward compatible. I really do not see a
 differrence to ITerms here.
 
 This doesn't have to do with bachward compatibility. Deprecated
 imports are backward compatible too. I think someone just missed
 to deprecate that interface.

Nope. http://mail.zope.org/pipermail/zope3-dev/2007-August/023223.html

 
 
 The reason why we should deprecate interfaces is: If a package
 still points to the old interface location, this package whould
 bring in the old dependency we tried to remove.

Depends. See below.

 
 I guess, since you are asking for support the old location,
 this doesn't hurt you because you are using both packages.
 Others don't. Any other packages which doesn't adjust the
 import to the new location will hurt others which do not use
 both packages.

If there is a packe which uses ITerms but  not zope.app.form this must 
be updated then. For packages which use zope.app.form this is not so 
important. I think they will be updated sooner or later when code is 
touched anyway because the new import is much shorter. But the 
deprecation *forces* everybody to update now. And this interface is 
used in *many* places.

 
 I see that this makes it more a good thing for others then
 for yourself. But I think that's fine. Isn't it?



 
 In my point of view, deprecation messages are a great concept
 to announce changes/improvments without to break compatibility.
 Without such announcements our code can get very quick out
 of date and we have no change to know about that.

Yes, for necessary API changes which do not need to be shipped 
immeadiately I can see that.


 
 btw,
 we also should deprecate the ISite interface at the old location.

Same question: what would you gain here? Packages are slowly migrated 
to using the new ISite import but nobody is forced to change all the 
code right now to get rid of all the deprecation warnings.



-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] zope.browser?

2008-12-12 Thread Christian Zagrodnick
On 2008-12-11 17:13:06 +0100, Roger Ineichen d...@projekt01.ch said:

 Hi Martijn
 
 
 Betreff: Re: [Zope-dev] zope.browser?
 
 Martijn Faassen wrote:
 Hi there,
 
 I saw that Roger Ineichen created and released a package called
 zope.browser.
 
 I assume that this package is intended to reduce
 dependencies, which
 is a project I applaud. So far I don't see any effect of this - in
 fact several packages now have an added dependency to zope.browser
 that wasn't there before. I'm sure there's a bit of the
 plan I don't
 understand yet - please enlighten me?
 
 Looking more, I've noticed that zc.sourcefactory replaces the
 dependency on zope.app.form with this package. That seems to
 be an improvement.
 
 Since I'm quite interested in this project, I'd like to hear
 much more about how we will determine which kind of
 dependency surgery we'll do next.
 
 I just moved the zope.app.form.interfaces.ITerms interface
 to this package. Which makes it possible to implement ISource
 and their widgets in z3c.form wihtout to depend on zope.app.browser.
 (zagy branch in z3c.form)

That's good. One thing which is not good is that you deprecated the use 
of ITerms from zope.app.form. I'd just leave the reference/import there 
like we did with ISite in zope.app.component.


-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] zope.browser?

2008-12-12 Thread Christian Zagrodnick
On 2008-12-12 14:24:09 +0100, Martijn Faassen faas...@startifact.com said:

 Hey,
 
 Christian Zagrodnick wrote:
 [snip]
 That's good. One thing which is not good is that you deprecated the use
 of ITerms from zope.app.form. I'd just leave the reference/import there
 like we did with ISite in zope.app.component.
 
 Why is such a deprecation warning bad? Wouldn't this encourage people to
 update their code?


A deprecation warning isn't bad. But I think we should not deprecate 
the use of ITerms from zope.app.form. I don't see a gain in this API 
change.

-- 
Christian Zagrodnick · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.

2008-12-09 Thread Christian Zagrodnick
On 2008-12-08 18:23:33 +0100, Tres Seaver [EMAIL PROTECTED] said:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Benji York wrote:
 On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster [EMAIL PROTECTED] wrote:
 On Dec 8, 2008, at 9:02 AM, Benji York wrote:
 
 On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick [EMAIL PROTECTED]
 wrote:
 Log message for revision 93722:
 - Switched to Zope 3.4 KGS.
 
 - New lines are no longer stripped in XML and HTML code contained in a
 textarea; requires ClientForm = 0.2.10 (LP #268139).
 This revision make the buildout fail with
 
 Error: Couldn't find a distribution for 'ClientForm=0.2.10'.
 
 I suspect you had that version of ClientForm in your cache and didn't
 realize that it is not available in the KGS index.
 
 Even if we fixed that, I don't want to require a particular version of
 ClientForm in testbrowser.  There's no need to impose a newer version on
 people who don't need it.  Anyone who does need the bug fix can specify
 the newer version in their project.
 FWIW, I disagree.  The specification that you removed is exactly the sort of
 thing that I think is appropriate in setup.py.  The tests will now fail (I
 assume, since I believe Christian Z added testbrowser tests for the failure
 caused by the ClientForm bug) with a lower version of ClientForm, so it is
 appropriate to set the value in setup.py.
 
 Nope, the tests will pass in the zope.testbrowser buildout.
 
 Having tests which pass only in that buildout is an attractive
 nuisance:  I'm seeing test failures in the version of zope.testbrowser
 linked into the Zope2 trunk, for instance.
 
 If the behavior of zope.testbrowser is broken in the absence of a
 sufficiently-recent version of ClientForm, then that behavior should be
 spelled out in setup.py's dependencies:  that is what they are for.

That's the way I think of it, too. Also the bug introduced by an older 
ClientForm is so subtle that it is not immediately obvious that it is 
the testbrowser which is broken. It may if you just got an upgrade, but 
not if you setup your things and it just behaves strange.


 
 However, if a testbrowser user for some reason run the testbrowser tests
 outside of its buildout, then you're right, they may see a failure if
 their versions aren't new enough.  At that point I would hope they would
 read the CHANGES.txt and see that a new version is required.
 
 The trade off is in requiring people to upgrade a dependency in order to
 get a bug fix that they may not care about.
 
 In the large, this is the problem with specifying versions in setup.py.
 Doing so assumes too much about how people are using all the
 dependencies involved.
 
 Here's a scenario:  I fix a bug in some package, it depends on a newer
 version of say, zope.publisher.  I put that requirement in my package's
 setup.py.  A user of my package upgrades to get an unrelated bug fix and
 is forced to use the newer zope.publisher.  It so happens that that the
 new version of zope.publisher has a different bug that bites them.  They
 now are in a bad spot.
 
 A user of your package cannot rely on automatic dependency resolution in
 this case:  your package is broken without the new version of its own
 dependency, so they can't upgrade to it.
 
 Stripping all versions from the dependencies in setup.py only works if
 users are willing to run their own package indexes, and figure out edge
 cases such as the ones you describe by themselves:  at that point,
 forking the egg to drop the manually-resolved extra dependency is a
 minor nuisance.

Agreed.



-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] deprecate http://download.zope.org/distribution

2008-11-14 Thread Christian Zagrodnick
On 2008-11-12 23:41:55 +0100, Jim Fulton [EMAIL PROTECTED] said:

 
 http://download.zope.org/distribution was set up as a place to publish
 distributions while we were learning about setuptools, eggs, and
 pypi.  I think now, we're all using PyPI (or local repositories).  I'd
 like to deprecate this site, making it read-only for now, but
 eventually removing it.

Yeah, make it read only. But I'd just leave it there. We have the 
policy of not removing eggs which are out there, so I suggest leaving 
the eggs there.

-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] z3c.autoinclude doesn't include extra_requires

2008-11-11 Thread Christian Zagrodnick
Hi,

when I include an egg with extras (like gocept.foo[server]) the 
dependencies from the extra are not automatically included with 
autoinclude.

I'm posting this here, because there is no other obvious place (no 
project for this on lauchpad).

Regards,
-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] ForbiddenAttribute: why subclass AttributeError?

2008-10-17 Thread Christian Zagrodnick
On 2008-10-15 17:49:30 +0200, Christian Theune [EMAIL PROTECTED] said:

 
 Why is a ForbiddenAttribute also an AttributeError? Is this intended to
 avoid 'information leaks'?
 
 We found a nasty side-effect together with getattr and annotations: a
 user that didn't have read-access to __annotations__ would end up trying
 to create the annotations container again and again because getattr(obj
 '__annotations__', None) would return None instead of propagating the
 ForbiddenAttribute exception.

On a proxied object you'd never get an AttributeError but only 
ForbidenAttribute, wouldn't you? So I think an ForbiddenAttribute as 
subclass of AttributeError is the right thing.


-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] zope.testbrowser: Newlines in textarea not always preserved

2008-10-17 Thread Christian Zagrodnick
Hi,

a few weeks ago I posted a bug regarding zope.testbrowser: 
https://bugs.launchpad.net/zope3/+bug/268139

»When there is XML or HTML-Code in the Textarea the newlines are removed.«
Could anybody give me a hint how to fix it? I'd really apprechiate it 
because it prevents me from using Python 2.5 :)

Regards,
-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Make simple ISource usable

2008-09-01 Thread Christian Zagrodnick
On 2008-09-01 06:58:16 +0200, Christian Theune [EMAIL PROTECTED] said:

 
 
 
 
 Hi,
 
 sorry for removing all the quotes, but I need to clarify your baseline
 question a bit.
 
 On Sun, 2008-08-31 at 23:23 +0200, Roger Ineichen wrote:
 Yes exactly, it's up to the developer how they implement something
 useful for handle ISource objects.
 =20
 If it comes to implement a widget framework is looks a little bit
 different. A widget framework can define an API which othter can use.
 ITerms in zope.app.form does that already. You can do what ever
 you need to do in such an ITerms adapter for access the ISource and
 return standard ITerm objects which the widget can handle.
 =20
 The ITrems is a standard API for handle ISource, doesn't nmatter
 how you will query or get our data form an ISource.
 
 This sounds like you want to implement something different than ITerms
 but that you see a structural similarity between what you want and what
 ITerms already do.
 
 I think this causes some confusion (and resistance by my side) right
 now.
 
 Can you try to phrase what you want to achieve and maybe not use the
 word 'ITerms' (for now)?

Right. What's the difference from the ITerms we have now? Why do I need it?

-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Make simple ISource usable

2008-09-01 Thread Christian Zagrodnick
On 2008-08-31 22:51:38 +0200, Marius Gedminas [EMAIL PROTECTED] said:

 
 
 
 
 On Sun, Aug 31, 2008 at 10:23:00PM +0200, Christian Zagrodnick wrote:
 Wait. zope.schema really shouldn't know about terms. Terms are about=20
 the user interface, hence title/token. That has really *nothing* to do=20
 with zope.schema. For searching you don't need titles or tokens. For a=20
 search *UI* you do, but that doesn't belong to zope.schema either.
 
 Are you arguing that zope.schema.Field should not have a title
 attribute?

No no no, sorry :)

I only don't see why I need titles for a source all the time. If you 
need both tied toogether (which frankly quite often is the case) 
zc.sourcefactory does the right thing (for me). If you just need to 
define a set of values you can just define the source (i.e. 
__contains__).


-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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] Make simple ISource usable

2008-08-31 Thread Christian Zagrodnick
On 2008-08-30 16:54:57 +0200, Roger Ineichen [EMAIL PROTECTED] said:

 Hi Chritian
 
 Betreff: Re: [Zope-dev] Make simple ISource usable
 
 
 On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote:
 [...]
 
 The only query API defined for ISource in zope.schema is the
 
 ISourceQueriables API. That's defently to less and makes it
 
 required
 
 to implement custom query APIs in UI frameworks if we need to work
 
 with terms.
 
 
 I no one objects, I'll start a zope.schema branch and let you know
 
 about the progress and a hopfully a simple solution. Additional to
 
 them I started allready a z3c.form branch for adjust the ITerms
 
 implementation.
 As far as I can see right now this refactoring will only provides
 
 additional features.
 
 
 What do you think? Any objections or hints about that?
 
 
 Terms require access to a request. Any application's model
 
 code should be happy to only deal with the values of sources.
 
 I agree, ITerm lookup from an ISource should work without the request.
 
 Terms are used to map values to the UI parts of an
 
 application (by providing identification tokens and user
 
 readable titles).
 
 
 IMHO zope.schema doesn't need to know about terms.
 
 I agree if you think about the ITerms adapter pattern
 like defined in zope.app.form using (source, request)
 as discriminators.

Which would be good. The term could very well be different in different 
skins, could it not? At least the title is language dependent (hm, 
okay, translation comes later...)

 
 But zope.schema does already know about term. ITerm is a
 
 part of zope.schema. ISource uses ITerm as items. But

No, ISource contains just values, i.e. ISource can contain any python 
object. It doesn't even say that there must be a way to create a Term 
vor a value.


 
 the only query API is ISourceQueriables. There is no
 
 simple query API for work with terms.

You'd probably convert a term to a value and then look it up in the 
source. This of course works (inefficiently) for IIteralbeSources. But 
you cannot search a plain ISource (besides plain containment) so that's 
not a problem. Also it is good that ISource is not iterable, because it 
is of couse possible to define non-iterable sources.

 
 I do agree that the whole issue of searching/querying sources
 
 is currently underdesigned.
 
 What do you think about an ITerm interface next to the
 ISourceQueriables interface. This interface could offer
 getTerm and getValue and offer a base for access none
 
 queriable ISource implementations.
 
 Of corse such a ITerms adapter for ISource doesn't adapt
 the request. The PrincipalSource ITerms implementation
 from zope.app.security doesn't even use the implemented
 request.
 
 Probably we should named the new interface in zope.schema
 ISourceTerms instead of ITerms?

Wait. zope.schema really shouldn't know about terms. Terms are about 
the user interface, hence title/token. That has really *nothing* to do 
with zope.schema. For searching you don't need titles or tokens. For a 
search *UI* you do, but that doesn't belong to zope.schema either.


Regards,
-- 
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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: zc.testbrowser.real support for mozlab 0.1.9

2008-07-04 Thread Christian Zagrodnick

On 2008-07-04 01:19:47 +0200, Graham Stratton [EMAIL PROTECTED] said:


I've checked in a branch with changes to the testbrowser.real code to
make it work with mozlab 0.1.9 (and firefox 3).


Hi Sebastian,

This is great. I spent all day yesterday trying to make this happen  
and didn't get anywhere. Sometimes I wake up with a better idea as to  
how to solve things, but I don't often wake up to find all the work's  
been done!


I tried running the tests with Python 2.4. About half the time they  
pass fine, and the other half fail something like this:


   File doctest README.txt[40], line 1, in ?
 browser.open('navigate.html')
   File /Users/graham/development/patched_zc.testbrowser/src/zc/ 
testbrowser/real.py, line 201, in open

 self.wait()
   File /Users/graham/development/patched_zc.testbrowser/src/zc/ 
testbrowser/real.py, line 193, in wait

 assert self.execute('tb_page_loaded;') == 'false'
 AssertionError

though for varying pages with browser.open(). I don't understand what  
could be causing it; why would that value be changed in between those  
two lines? I guess the time.sleep() on line 191 implies that there's  
something we might want to wait for. I increased it by 10x and only  
got 1 failure out of 10, so I guess that helps.


I had this error, too and checked in a maybe-fix in r87964. Have you 
tried with this revision or the one before? If it's thisone I'll add 
another loop there.


--
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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: Deciphering Zope Comments

2008-06-05 Thread Christian Zagrodnick

On 2008-06-04 20:28:07 +0200, Dieter Maurer [EMAIL PROTECTED] said:


Shane Hathaway wrote at 2008-6-4 00:01 -0600:


That led me to the zope.thread module, which is apparently deprecated
already, yet zope.app.component still depends on it.  Is that an
hysterical accident?


As I have read, thread local variables have been invented and
implemented in Zope 3 land and donated to Python.

Now, that it is in Python, the original Zope implementation
can go away. Maybe, that is the purpose of the zope.thread module?


Actually zope.thread does nothing but importhing the python 
implementation. The module is there for backward compatibility.


--
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept

2008-05-20 Thread Christian Zagrodnick

On 2008-05-10 19:38:15 +0200, Martijn Pieters [EMAIL PROTECTED] said:


On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman [EMAIL PROTECTED] wrote:

zcml is a pretty simple format though: xml with only human readable text
in title and description attributes (and perhaps a few others) and the
translation domain specified in a i18n_domain attribute. It should be
quite trivial to extract that data without having to pull all of zope
in.


If you determine beforehand which strings are translatable (end up as
msgid objects) it should be trivial to extract these. You will have to
update i18ndude to add new zcml tags though.


What's translatable and what not is defined by the schema of the 
configuration which can be extended by any package. So adding this 
information to the extractor would duplicate it. Not good.


--
Christian Zagrodnick · [EMAIL PROTECTED]
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development


___
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: New i18n locale extraction concept

2008-05-01 Thread Christian Zagrodnick

On 2008-05-01 02:06:17 +0200, Roger Ineichen [EMAIL PROTECTED] said:



What does this mean?
The locale extraction is now a part of a recipe
and not a part of a package itself.

My goal is to remove the dependencies in the
z3c.recipe.i18n, because right now it uses the
base implementation in zope.app.locales which makes
it depend on the hole zope namepsace. Because of
the overall zope.* dependenc in zope.app.locale.


Actually, there is lovely.receipe:i18n which provides i18n extraction. 
Does z3c.recipe.i18n something else or why is there yet another i18n 
recipe?




The best option whould be to split zope.app.locales
into usefull packages. The not so good optipon whould
be to copy over the relevant classes and scripts to
the recipe and skip the dependency to zope.app.locale.

I also started to use the recipe in z3c.locales
and zam.locales. Take a look at this package for
a real usecase.

What do you think? Should we switch the locale extraction
to that concept for the zope.* packages too or not?


Exctaction should be in a recipe, of course. But I'm also advocating 
for having the translations in the package and having one domain per 
package. `


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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.app.locales i18nmergeall.py not used anymore?

2008-04-30 Thread Christian Zagrodnick

On 2008-04-26 10:25:16 +0200, Christophe Combelles [EMAIL PROTECTED] said:


Maurits van Rees a écrit :

Hi,

zope/app/locales/TRANSLATE.txt says:

  ...
  After that, you need to merge those changes to all existing
  translations.  You can do that by executing the ``i18nmergeall.py``
  script from the ``utilities`` directory of your Zope 3 checkout:

$ python utilities/i18nmergeall.py -l src/zope/app/locales

So I tried that and found that in the 13 po files that are present,
over 80 thousand lines were changed (counting all lines in an svn
diff).  Since the files combined have about 100 thousand lines, this
could be called a fairly big change. :)

So: is there a reason this merging is not regularly done anymore?  Or
can I just go ahead and submit those 80 thousand lines?


It seems too big, that's weird.
I think merging is not really done, and there are several changes to do 
f or i18n:


- split the zope gettext domain into all the separate namespaces. 
Maybe  only zope.app.* packages can be kept under the zope.app domain.


I think each and every package should have its own domain. Should we 
just start with that for 3.5 packages? Would this break anything?




- find a way to generate the .pot and .mo files at build. They should 
not  be stored in the svn. We should only have the translated .po 
files, and the  merging and compiling should be done during build. 
Maybe the .pot file could be a lso stored but this is not really 
necessary.


Yeah, the .mo files don't need to be stored indeed. But that's not 
really high priority I think.




- add an automatic test in each package to check whether the .po files 
ha ve been merged by the developer. If a po file is not in sync with 
the code, the t est fails. This would allow all the .po files to be 
always up to date.



Actually I don't really use the merge script. I prefere using somethink 
like poedit and its update from pot file feature. This also tells me 
what I have to translate and what is gone.





--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Splitting up zope.app.container

2008-04-17 Thread Christian Zagrodnick

On 2008-04-16 18:34:44 +0200, Malthe Borch [EMAIL PROTECTED] said:

The ``constraints`` module in zope.app.container seem to be usable 
outside a ZODB-application---ditto most of the interfaces.


If we want to support a nozodb-environment, it would be nice to not 
have to pull in ZODB just to get these frameworky definitions.


Is it package overkill to move these out to, say, zope.container?


+1

Also the container interfaces could be moved there.

--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: AW: Field for blobs?

2008-04-16 Thread Christian Zagrodnick

On 2008-04-16 10:01:30 +0200, Nikolay Kim [EMAIL PROTECTED] said:


On Tue, 2008-04-15 at 17:37 +0200, Roger Ineichen wrote:


The other option whould be to split every widget into it's own
package and use z3c.widget as namespace package.

What do you think?


i think we should split z3c.schema and z3c.widget to separate packages,
so we can have one namespace for all third party fields and widgets


actually, when the __init__.py of z3c.schema would be a namespace 
__init__.py one could just add new packages w/o the need to split the 
z3c.schema up. Even though this might be a bit confusing.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] Field for blobs?

2008-04-15 Thread Christian Zagrodnick

Hi,

I'd need a zope.schema field for blobs. Should this go directly to 
zope.schema or some third party package?


Something like

  bla = zope.schema.Blob(title=...)

would be nice to have.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Setting the size of a zope.formlib's schema html input

2008-04-07 Thread Christian Zagrodnick
On 2008-04-07 03:41:34 +0200, Marcelo de Moraes Serpa 
[EMAIL PROTECTED] said:





Hello,

This might sound lik a stupid question, but I couldn't find any simple
solution or answer for this anywhere else, so hopefully someone in this list
knows the answer.

I'm using zope.formlib to generate a simple contact form. It is simple and
effective. But the framework complicates for simple things such as setting
the size of a textfield. I don't want all the textfields to be of the same
size - I want that, depending on the field, the size of the html input will
vary. And that's exactly what I couldn't do as of yet. Does anyone know how
could I set the size of a textfield?

Take this as example:

Telefone = schema.TextLine(title=_(uTelefone para Contato),
  required=True)

Is there an attribute like size or something?


No, use CSS for layout. :)

You could also use a custom widget which has a different size, but CSS 
might be the more correct separation.


Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: testing a meta-egg

2008-04-07 Thread Christian Zagrodnick

On 2008-04-04 14:22:06 +0200, Jim Fulton [EMAIL PROTECTED] said:



On Apr 4, 2008, at 7:14 AM, Adam GROSZER wrote:

Hello,

Is there a sane way (or recipe) out there that makes testing a
meta-eggs easier?
As I see now, I'll need to enter all dependent eggs as:

[test]
recipe = zc.recipe.testrunner
eggs = my-meta-egg [test]
  dep-egg-1 [test]
  dep-egg-2 [test]
  ...
  zope.interface [??test??]

Seems like buildout knows which eggs should be there.
This would be needed for a pre-installation test on the target system.
We need to make sure that all tests pass before going into production.

Any help is appreciated.



IMO, testing the dependent eggs isn't desirable, however, I don't  
object to providing an option to do it.


It might be better to just provide a variable containing all the 
dependent eggs like ${test:dependent-eggs}. You could do what ever you 
want then.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Setting the size of a zope.formlib's schema html input

2008-04-07 Thread Christian Zagrodnick

On 2008-04-07 09:25:28 +0200, Wichert Akkerman [EMAIL PROTECTED] said:


Previously Christian Zagrodnick wrote:

On 2008-04-07 03:41:34 +0200, Marcelo de Moraes Serpa
[EMAIL PROTECTED] said:

Hello,

This might sound lik a stupid question, but I couldn't find any simple
solution or answer for this anywhere else, so hopefully someone in this
list
knows the answer.

I'm using zope.formlib to generate a simple contact form. It is simple and
effective. But the framework complicates for simple things such as setting
the size of a textfield. I don't want all the textfields to be of the same
size - I want that, depending on the field, the size of the html input will
vary. And that's exactly what I couldn't do as of yet. Does anyone know how
could I set the size of a textfield?

Take this as example:

Telefone = schema.TextLine(title=_(uTelefone para Contato),
required=True)

Is there an attribute like size or something?


No, use CSS for layout. :)


That depends on the type of input you want to influence. For text
input elements the size attribute indicates the maximum number of
characters a user can input in the field, and you can not control
that using CSS.


Well, okay. But still this information must not be put into the 
schema/interface but in the form.




Often you also want to put a different CSS class or id on the different
type of input fields. You do not want your checkboxes to be just
as wide as your text input fields!


a) input[type=text]
b) You should have the widget id/name as id on the input field or some 
containing div.


Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: testing a meta-egg

2008-04-07 Thread Christian Zagrodnick

On 2008-04-07 13:12:15 +0200, Jim Fulton [EMAIL PROTECTED] said:


It might be better to just provide a variable containing all the  
dependent eggs like ${test:dependent-eggs}. You could do what ever  you 
want then.


How would that help?


Oh, when writing that mail I thought one could do

[test]
eggs = foo
 ${test:dependent-eggs}

But unfortunatly to understand recursion you have to undertand 
recursion.  So this would only work to test the dependent eggs of 
another section. But forget about that.


Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] zope.component.zcml _protectedFactory not protecting?

2008-03-27 Thread Christian Zagrodnick

Hi,

I'm a little confused by the permission attribute on the adapter statement.

First of all, a principal not having the set permission still gets the 
adapter. That wouldn't be much of a problem if the adapter was 
securiy-proxied.


The adapter is created with the _protectedFactory:

def _protectedFactory(original_factory, checker):
   # This has to be named 'factory', aparently, so as not to confuse
   # apidoc :(
   def factory(*args):
   ob = original_factory(*args)
   try:
   ob.__Security_checker__ = checker
   except AttributeError:
   ob = Proxy(ob, checker)

   return ob
   factory.factory = original_factory
   return factory


I wonder why the factory only creates a security proxy when it cannot 
assign __Security_checker__ to the adapter. I suppose this is 
intentional?


Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] Test isolation problems starting with zope.app.publisher 3.5.0a3

2008-03-13 Thread Christian Zagrodnick

Hi,

starting with zope.app.publisher 3.5.0a3 I geht isolation problems with 
tests. When the second functional test layer is reached the menus are 
empty. I don't know why this is but I'm pretty sure ist has todo with 
the checkin below.





On 2007-11-27 20:59:01 +0100, Juergen Kartnaller 
[EMAIL PROTECTED] said:



Log message for revision 81993:
  make it possible to override menus: this was not possible because new
  interfaces where created any time a menu with the same name was created.


Changed:
  U   zope.app.publisher/trunk/CHANGES.txt
  U   zope.app.publisher/trunk/src/zope/app/publisher/browser/menumeta.py
  U   zope.app.publisher/trunk/src/zope/app/publisher/browser/tests/support.py
  U   
zope.app.publisher/trunk/src/zope/app/publisher/browser/tests/test_directives.py


-=-
Modified: 


zope.app.publisher/trunk/CHANGES.txt
===
--- zope.app.publisher/trunk/CHANGES.txt2007-11-27 19:57:29 UTC (rev 
81992)
+++ zope.app.publisher/trunk/CHANGES.txt2007-11-27 19:59:00 UTC (rev 
81993)
@@ -5,6 +5,12 @@
 3.5.0 (???)
 ===

+3.5.0a3 (2007-11-27)
+
+
+- make it possible to override menus: this was not possible because new
+  interfaces where created any time a menu with the same name was created.
+
 - Resolve ``ZopeSecurityPolicy`` deprecation warning.


[]


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: SVN: zc.recipe.filestorage/trunk/ Removed 'shared-blob-dir' from blobstorage section

2008-02-28 Thread Christian Zagrodnick

Hi


On 2008-02-27 21:00:39 +0100, Nikolay Kim 
[EMAIL PROTECTED] said:



Log message for revision 84351:
  Removed 'shared-blob-dir' from blobstorage section


could you tell me why you've removed the shared-blob-dir option?

One could argue to remove the whole blob support from the recipe, but 
just removing the shared option is not useful IMHO.





Changed:
  U   zc.recipe.filestorage/trunk/CHANGES.txt
  U   zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py

-=-
Modified: zc.recipe.filestorage/trunk/CHANGES.txt
===
--- zc.recipe.filestorage/trunk/CHANGES.txt 2008-02-27 19:49:55 UTC (rev 
84350)
+++ zc.recipe.filestorage/trunk/CHANGES.txt 2008-02-27 20:00:37 UTC (rev 
84351)
@@ -2,6 +2,12 @@
 CHANGES
 ===

+1.1.0 (2008-??-??)
+--
+
+- Removed 'shared-blob-dir' from blobstorage section.
+
+
 1.0.0 (2007-11-03)
 --


Modified: zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py
===
--- 
zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py	2008-02-27 
19:49:55 UTC (rev 84350)
+++ 
zc.recipe.filestorage/trunk/zc/recipe/filestorage/__init__.py	2008-02-27 
20:00:37 UTC (rev 84351)

@@ -41,12 +41,10 @@
 blob_dir = os.path.join(buildout['buildout']['directory'],
 blob_dir)
 options['blob-dir'] = blob_dir
-shared = options.get('shared-blob-dir', 'no')

 options['zconfig'] = template % dict(
 path=path,
-blob_dir=blob_dir,
-shared=shared)
+blob_dir=blob_dir)

 def install(self):
 if self.make_part:
@@ -70,7 +68,6 @@
 zodb
   blobstorage
 blob-dir %(blob_dir)s
-shared-blob-dir %(shared)s
 filestorage
   path %(path)s
 /filestorage



--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Mailinglists on Launchpad

2008-02-18 Thread Christian Zagrodnick

On 2008-02-18 11:20:05 +0100, Christian Theune [EMAIL PROTECTED] said:

Launchpad started the beta tests for their mailing list offers. A while 
ago we discussed this option for future hosting of the mailing lists.


The current implementation has the restriction that the mailing lists 
can not be hosted using custom domains (@zope.org).


IMHO when migrating mailing lists the addresses should not change.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: SVN: zc.resourcelibrary/branches/resources-bundles-branch/src/zc/resourcelibrary/ Implemented resource manager capable of bundling resources based on library intersection and resource c

2008-02-15 Thread Christian Zagrodnick

On 2008-02-13 13:07:47 +0100, Malthe Borch [EMAIL PROTECTED] said:


Christian Zagrodnick wrote:

when will this be merged to the trunk and released? Any plans for that?


I still need to hook up the resource bundle with the publisher. The 
implementation hasn't been tested in a browser yet. There might be 
caveats.


I'll try and bring the branch into a fully working state.


Cool. Sounds really useful :)

--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: SVN: zc.resourcelibrary/branches/resources-bundles-branch/src/zc/resourcelibrary/ Implemented resource manager capable of bundling resources based on library intersection and resource c

2008-02-13 Thread Christian Zagrodnick

Hi,

when will this be merged to the trunk and released? Any plans for that?


On 2008-02-05 20:37:28 +0100, Malthe Borch 
[EMAIL PROTECTED] said:



Log message for revision 83553:
  Implemented resource manager capable of bundling resources based on 
library intersection and resource content digests. This is explained in 
detail in README.txt under the section Resource bundles.



--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] zope.viewlet 3.4.1 release broken

2008-01-24 Thread Christian Zagrodnick

Hi,

the release of zope.viewlet 3.4.1 on pypi is missing the data files 
(like .txt and .zcml), hence it is unusable. Also the date in the 
CHANGES is wrong (2007 should be 2008)


Roger, it is good that you do releases, but could to please take take 
of making them proper?


Unfortunately I cannot fix it since I don't have access to 
zope.viewlet, so somebody else please fix it (or give me access).


BTW Roger, z3c.menu.simple has the same problem of missing data files.

Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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.viewlet 3.4.1 release broken

2008-01-24 Thread Christian Zagrodnick

On 2008-01-24 14:21:44 +0100, Christian Theune [EMAIL PROTECTED] said:




Christian Zagrodnick schrieb:

Hi,

the release of zope.viewlet 3.4.1 on pypi is missing the data files 
(like .txt and .zcml), hence it is unusable. Also the date in the 
CHANGES is wrong (2007 should be 2008)


Roger, it is good that you do releases, but could to please take take 
of making them proper?


Unfortunately I cannot fix it since I don't have access to 
zope.viewlet, so somebody else please fix it (or give me access).


You have now.


Thanks, I just uploaded zope.viewlet 3.4.2.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: AW: zope.viewlet 3.4.1 release broken

2008-01-24 Thread Christian Zagrodnick

On 2008-01-24 17:11:32 +0100, Roger Ineichen [EMAIL PROTECTED] said:


Hi Christian


Betreff: [Zope-dev] zope.viewlet 3.4.1 release broken

Hi,

the release of zope.viewlet 3.4.1 on pypi is missing the data
files (like .txt and .zcml), hence it is unusable. Also the
date in the CHANGES is wrong (2007 should be 2008)


No it doesn't miss the data. Your linux is just not able to
extract them. It works on windows box.


Interesting. So still the package would be broken for most users. I'm 
using Mac OS btw.






Roger, it is good that you do releases, but could to please
take take of making them proper?


Probably you know already. That's a (linux) bug in the python
tar library. I did nothing wrong. It's just broken if you extract
the files from the egg. on linux. Everything is build correct.


Could you clearify why the package I built works then? That's the great 
mystery I suppose ;)


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: AW: zope.viewlet 3.4.1 release broken

2008-01-24 Thread Christian Zagrodnick

On 2008-01-24 22:28:19 +0100, Marius Gedminas [EMAIL PROTECTED] said:






On Thu, Jan 24, 2008 at 12:06:16PM -0500, Stephan Richter wrote:

On Thursday 24 January 2008, Christian Zagrodnick wrote:

Probably you know already. That's a (linux) bug in the python
tar library. I did nothing wrong. It's just broken if you extract
the files from the egg. on linux. Everything is build correct.


Could you clearify why the package I built works then? That's the great
mystery I suppose ;)

=20
Because UNIX built packages work on UNIX and Windows. But Windows built=

=20

packages only work on Windows.


This email contains the explanation -- it's a bug in distutils/setuptools:
http://mail.python.org/pipermail/distutils-sig/2007-September/008296.html

Note that the latest setuptools release (setuptools 0.6c7) does NOT
contain the fix.


So let's hope there will be a release which fixes this soon. This is 
very disturbing. And meanwhile  we should not make releases on windows, 
should we.


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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.viewlet 3.4.1 release broken

2008-01-24 Thread Christian Zagrodnick
On 2008-01-24 18:04:44 +0100, Stephan Richter 
[EMAIL PROTECTED] said:



On Thursday 24 January 2008, Christian Zagrodnick wrote:

the release of zope.viewlet 3.4.1 on pypi is missing the data files
(like .txt and .zcml), hence it is unusable. Also the date in the
CHANGES is wrong (2007 should be 2008)


The fact that you noticed this problem this quickly tells me you are not using
the KGS. I tend to reply to this tough luck. I will update the KGS as soon
as I have re-released the packages. Jim has also given me already a
new zope-dev directory already, so we can evolve a new, experimental KGS
there.

BTW, if you want to use a newer package than the KGS provides, you can always
use the find-links option and point to the package in PyPI or PPIX directly.


Most component packages do not use the KGS in their buildout, so I 
wasn't either.  For production use we pin exact versions actually.





Roger, it is good that you do releases, but could to please take take
of making them proper?


He did take the care. The problem is a Python bug as Martijn pointed out
later.


Yeah, actually I wondered how it would be possible to do it wrong ;)




BTW Roger, z3c.menu.simple has the same problem of missing data files.


Yes, there are a bunch of packages that have this problem. I am going to
re-release them all. (In fact, I have already started.)


Good. Thanks!


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] Should zope.annotation.factory send ObjectAddedEvent?

2007-12-21 Thread Christian Zagrodnick

Hi,

zope.annotation.factory is a very handy tool.

I wonder if it should not send an ObjectAddedEvent when the annotation 
object is created. After all an object is added. But there is no (easy) 
way catalog those objects or do anything.


If there are no objections I'll add this.

Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Should zope.annotation.factory send ObjectAddedEvent?

2007-12-21 Thread Christian Zagrodnick

On 2007-12-21 09:52:34 +0100, Christian Zagrodnick [EMAIL PROTECTED] said:


Hi,

zope.annotation.factory is a very handy tool.

I wonder if it should not send an ObjectAddedEvent when the annotation 
object is created. After all an object is added. But there is no (easy) 
way catalog those objects or do anything.


I have to correcty myself:

ObjectAddedEvent is the wrong event I suppose since it is from 
zope.app.container and the annotation factory doesn't add it into a 
container.


zope.lifecycleevent.ObjectCreatedEvent might be okay though. There 
should be at least some event when this object was created, shouldn't 
there?


--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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] Request typing (to get the xmlrpc layer discussion finished)

2007-12-17 Thread Christian Zagrodnick

Hi,

a couple of weeks ago there was some discussion about the skin/layer 
support for XML-RPC which I implemented without asking (shame on me). 
As some time has passed now everybody could have some fresh thoughts 
about it.



Let me first summarise:

* Skin and layers should be seen as typing the request.

* There are no general objections against having layers for XML-RPC.

* There are objections against using ++skin++ for XML-RPC, ++api++ 
would be fine.



Discussing the issue here at gocept again we've come to the following:

There are different kinds of request (BrowserRequest, XMLRPCRequest, 
FTPRequest, …) which depend on the “channel” or server zope is accessed 
through.


Then, depending on the kind of request, it often is desirable to 
further type the request:


* a skin for browser requests
* an API for xmlrpc requests
* maybe different listings or content views for webdav

We’d like to codify this understanding (the general concept of marking 
a request with a type) using a general IRequestType which all specific 
type implementations (skins, APIs, ...) are derived from. In our view 
this allows for understandably named implementations for each channel 
but still provide a common base.


Therefore we propose to:

* Create in zope.publisher.interfaces:

class IRequestType(zope.interface.interfaces.IInterface):
 pass

* Rename IXMLRPCSkinType to IXMLRPCAPIType(IRequestType) and create a 
traverser ++api++ for IXMLRPCApiType.


* Use IRequestType as new base of IBrowserSkinType (instead of IInterface).

* Do *not* provide any traverser for IRequestType since the traversers 
should be close to the “channel” so it is easy to understand what is 
happening. If the traverser name is too far fetched we end in confusion 
like with skin for xmlrpc.



Regards,
--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: Bug in AbsoluteURL Adapter

2007-12-02 Thread Christian Zagrodnick
On 2007-11-28 19:52:49 +0100, Philipp von Weitershausen 
[EMAIL PROTECTED] said:



On 28 Nov 2007, at 12:54 , Daniel Havlik wrote:

Am 28.11.2007 um 12:01 schrieb Philipp von Weitershausen:
The problem we tried to solve was: We have a structure of Plone  
content objects. We wanted to access a particular one in a view  which 
can be called anywhere. Therefore we registered this content  object as 
an utility. It turned out, that this utility does not  have a request 
after fetching it in our view with getUtility().  The request is needed 
to get an absolute URL of our content object.


This is what I don't understand: why should content objects have  
access to the request? I understand that the request is needed in  
order to compute the absolute URL, but the IAbsoluteURL adapter is  a 
*multi*-adapter for (context, request). So it will always receive  the 
request explicitly in its constructor. This pattern is the  foundation 
of separating content from presentation: the content  object is 
request-unaware, the adapters and views around it are  request-aware.


Exactly, thats why we thought this may be a bug. The __str__ method  of 
Five's AbsoluteURL adapter does not make use of the request the  
adapter gets in its constructor, it just calls the zope2-ish  
absolute_url() method on the context. (Which itself relies on the  
REQUEST attribute of the object to convert the path to an URL)


I see what you mean now. In that case I agree that it would be  
cleaner to use the adapter's request, *IF*  
request.physicalPathToURL(obj.getPhysicalPath()) will always yield the  
same as obj.absolute_url(), especially regarding virtual hosting, etc  
(if we don't have tests for that yet, creating some would be extremely  
good).


If the improved version of the adapter will also fix a few problems  
when used with Plone, it would still be good to have tests that  
provoke such circumstances and verify that the new implementation is  
indeed better.


I think the real problem here is that when you register a content 
object as utility that it is either acquition wrapped or not. If it is 
not wrapped I don't really see how to get the physical path in Z2. If 
it is wrapped you'll probably have fun with pickling acquisition 
wrappers.




--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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: New Contributor References

2007-09-16 Thread Christian Zagrodnick

On 2007-09-12 15:32:42 +0200, Jim Fulton [EMAIL PROTECTED] said:



Lately, I've started being a bit more careful about accepting new  
contributors.  In particular, I'm requesting that new contributors  
provide the name of an existing contributor who is familiar with them  
and their work.  I (or someone) really need to add this to the  
contributor agreement, but I'm not sure when I'll have time.  Now,  
It's taking a fair bit of time writing new contributors to ask for  
references. I encourage folks to request committer access, I just ask  
that people provide the names of one or more existing committers who  
can vouch for them.


I think that is good. It's just like noting references on a job 
application. Sobody you (as employer) can call/mail and ask about the 
applicant.



--
Christian Zagrodnick

gocept gmbh  co. kg  ·  forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891



___
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 )