Re: [Zope] [Off-Topic] KSS ugly?

[Philipp von Weitershausen]

Encolpe Degoute wrote:
> Dieter Maurer a écrit :
>> Garito wrote at 2008-10-8 14:22 +0200:
>>> I'm agree with you, Tino. Plone has a lot of ugly features (as KSS, for
>>> instance)
>> Why is KSS ugly?
>> Reading the documentation, I found it quite attractive
> 
> That is what KSS opponents atr thinking:
> http://svn.plone.org/svn/collective/collective.kss.fucker/trunk/README.txt

This document provides as little substance as much as it manages to 
insult the authors of KSS.

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

Re: [Zope] Zope 2.x for Py 2.6 as 64 bit Windows application?

[Philipp von Weitershausen]

[EMAIL PROTECTED] wrote:
> We're contemplating the move of our Zope 2.x application to 64-bit Windows.
> We rely on a few add-on packages, notably PyWin, which has 64-bit support for
> Py 2.6 only.
> 
> I'd be grateful for a rough idea on when there could be a Zope 2.x release
> working with Python 2.6 as a 64-bit Windows application.

We have no roadmap for this. Currently Zope doesn't run on Python 2.5 
yet as Chris pointed out. That said, the GSoC porting project has made 
progress on the "gsoc-python-2.5" branch and I think it runs Python 2.5 
without any problems (but I might be wrong). Furthermore, Sidnei got 
this branch running on Python 2.6 now, albeit in an experimental status.

If you have the need for this stuff to land, it would be a good idea to 
help out Sidnei and his crew. I have no idea what's holding up the 
Python 2.5 work to land, certainly it can't be that much more work to 
make it ready for trunk.

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

Re: [Zope] Script (Python) insecure ?

[Philipp von Weitershausen]

Thanks a lot for taking care of these issues, Andreas!



Andreas Jung wrote:
> 
> 
> --On 12. August 2008 16:05:47 +0200 Andreas Jung 
> <[EMAIL PROTECTED]> wrote:
> 
>>
>>
>> --On 12. August 2008 14:16:44 +0200 Andreas Jung 
>> <[EMAIL PROTECTED]> wrote:
>>
>>> *sigh*
>>>
>>> I wished that both exploits were reported to the Zope bugtracker in 
>>> order
>>> to work on solutions before making the exploits public.
>>>
>>>
>>> --On 12. August 2008 13:41:04 +0200 "M.-A. Lemburg" 
>>> <[EMAIL PROTECTED]>
>>> wrote:
>>>
 Hello,
>>>
>>>
>>>

 1. Attack:

 Put this into a "Script (Python)" object and run it:

 return 'kaboom'.encode('test.testall')

 This results in a denial-of-service, since Zope will hang
 running the Python test suite.

 The reason for this is a problem in the way the encoding search
 function works in Python 2.4. This was changed in 2.5 to no longer
 allow searching for codecs outside the encodings package.
>>>
>>> That's pretty obscure behavior of Python 2.4...anyway.
>>
>> The followup for this issue is also on Launchpad including a possible
>> solution:
>>
>> 
>>
>> The patches/monkey patches for both issues need review and testing.
>>
>> I am now working on a security advisory.
>>
>> For the hotfixes and testing I need definitely help since I am the road
>> for the rest of the week and pretty busy and limited network 
>> connectivity.
>>
>>
> 
> I created a preliminary hotfix
> 
> 
> 
> After rough test: it seems to work for Zope trunk, 2.10 and 2.11
> but has a failure for Zope 2.8.
> 
> That's all I can do for now - please test and improve the hotfix
> if needed.
> 
> Thanks,
> Andreas
> 
> 
> 
> 
> ___
> Zope maillist  -  Zope@zope.org
> http://mail.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope-dev )

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

Re: [Zope] Page Template help

[Philipp von Weitershausen]

Garito wrote:
> Finally it's possible to do what I need without the need to declare any 
> variable?

Not that I know of.

> If not my change will be 4-6 lines of code and it's ok for me to make 
> this change
> 
> I only need to understand were the code decides if the expression is 
> standard, string or python

I already pointed you to the code where the different expression types 
are registered. From there you should be able to deduce where these 
registrations are used. I don't know this by heart and would have to 
search for myself.

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

Re: [Zope] Page Template help

[Philipp von Weitershausen]

Garito wrote:
> Considere this case:
> 
> I have the sking value in the variable at args/Yanged/Skin
> 
> How can I do the equivalent to
> 
> args/Yanged/raiz/Skins/${args/Yanged/Skin}/arbolYanged.css/absolute_url
> 
> ?
> 
> In the python way it will be:
> 
> path(path('string:' + 
> 'args/Yanged/raiz/Skins/${args/Yanged/Skin}/arbolYanged.css/absolute_url'))
> 
> That's returns the expected value but I can't see how to do with your 
> propossed way




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

Re: [Zope] Page Template help

[Philipp von Weitershausen]

Garito wrote:
> Use: 
> /path/to/the/object/with/${some/magic/variables}/to/solve/some/paths/in/a/simplest/way

Path expressions already support this.

   tal:define="pathel some/magic/variables;
   objpath/to/the/object/with/?pathel/to/solve/some/..."

So basically in TALES path expressions you can say foo/?bar and the 
value of the 'bar' variable will be used to traverse the next step from 
'foo'.

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

[Zope] Re: Page Template help

[Philipp von Weitershausen]

Garito wrote:
Could someone point me where the page template code decide if an 
expression is a path expression or a string or python one, please?


I'm studying the zope page template classes and I would like to 
understand where this decision is taken


Products.PageTemplates.Expressions.createZopeEngine():

for pt in ZopePathExpr._default_type_names:
e.registerType(pt, ZopePathExpr)

ZopePathExpr._default_type_names contains, among others, the name 
'standard', which makes this expression type the default expression type.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Disable configuration of 3rd party packages with z3c.unconfigure

[Philipp von Weitershausen]

When relying on a third-party package with ZCML configuration, it is 
sometimes desirable to disable certain directives, for instance when the 
third-party package defines an event subscriber that you'd like to 
disable.  This is now possible with z3c.unconfigure.


While zope.configuration (the package that implements ZCML) itself 
supports overriding existing configuration and the zc.configuration 
package supports excluding whole ZCML files from being loaded, 
z3c.unconfigure allows you to disable specific directives.


More information is available at 
http://pypi.python.org/pypi/z3c.unconfigure.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Deployment Best Practices?

[Philipp von Weitershausen]

Paul Winkler wrote:

On Sun, Jul 13, 2008 at 01:20:53PM -0400, Philipp von Weitershausen wrote:

Jeff McNeil wrote:

I'd love to be able to just drop an egg on the file system and tell
Zope "Here, go load that one now" via configuration alone.
You could also write your own ZCML directive (+ a handler) that does that. 
Then you'd only ever have to change your application's site.zcml to load a 
new plugin.


There's also this:
http://pypi.python.org/pypi/z3c.autoinclude


Yep, that only saves you the

  

directive, though.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Deployment Best Practices?

[Philipp von Weitershausen]

Jeff McNeil wrote:

That's not all that obvious to someone new to the Zope system.  Most
of the documentation I've found is geared towards the 2.x branch.  As
Zope 3 and Zope 2 are different animals, I wouldn't think that the
deployment steps and recommendations would be all that similar.


With buildout, they can be similar, at least superficially.


I really like what I've seen thus far, it's just been difficult at
times as it feels like I'm fighting with documentation.

So I'm assuming I'll just need to build up a Zeo server instance with
zc.zodbrecipes and update my corresponding buildout.cfg for the Zope
instances?


Yep, you can do that.


If Buildout is the preferred deployment tool, then my
redistributable is a sandbox tarball or an RPM containing the skeleton
files needed to bootstrap a buildout run on the target hosts?


Yes.


Maybe I'll dump the whole process on a blog somewhere as I step through it.


That'd be cool!


I do have another question. The project we're working on is plug-in
based. Within the old system, eggs are loaded dynamically using
setuptools pkg_resources and we define certain entry points for
capability registration.  Eggs are added to a directory and a config
entry is made such that we can load the proper version of each
plug-in.  Is there an upfront way to reproduce that functionality
without needing to update setup.py and rerun buildout every time we
want to push a new plug-in or update an existing?


Well, you could just do the exact same thing that you did in your old 
application, I suppose.



I'd love to be able
to just drop an egg on the file system and tell Zope "Here, go load
that one now" via configuration alone.


You could also write your own ZCML directive (+ a handler) that does 
that. Then you'd only ever have to change your application's site.zcml 
to load a new plugin.



My apologies if some of this is obvious. As I said, I'm really just
tackling Zope for the first time.


Don't worry, your questions are valid. We haven't actually done a very 
good job of documenting things on the website.



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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: I wonder why class constructor is never in apidoc ?

[Philipp von Weitershausen]

KLEIN Stéphane wrote:

I wonder why class constructor is never in apidoc ?


Because nobody has bothered to implement this feature. Patches are 
welcome :)



Are there something in OOP concept I haven't understand ?


I don't know what you mean with this.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Python instance growing while ZTC

[Philipp von Weitershausen]

Marco Bizzarri wrote:

Hi all.

Apologies in advance if my question has a somewhat obvious answer.

I'm working on a Zope application, developed as a python product.

I've ZTC in place for this application. While I run all the ZTC, I can
see python process size growing. Can I use this as an indication of a
leak of resources in my application?


Probably not. I suggest running your tests multiple times in a loop 
using the -N switch of the test runner. If the memory consumption grows 
with each repetition of the tests, you may have a leak.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: PageTemplates len() of unsized object

[Philipp von Weitershausen]

On 2 Jun 2008, at 20:44 , Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2008-5-28 21:52 +0200:

Dieter Maurer wrote:

2008-05-24T09:31:32 ERROR Zope.SiteErrorLog http://myurl/error_log/manage_main
Traceback (innermost last):
 Module ZPublisher.Publish, line 119, in publish
 Module ZPublisher.mapply, line 88, in mapply
 Module ZPublisher.Publish, line 42, in call_object
 Module Shared.DC.Scripts.Bindings, line 313, in __call__
 Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
 Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
 Module Products.PageTemplates.PageTemplate, line 89, in pt_render
 Module zope.pagetemplate.pagetemplate, line 117, in pt_render
 Module zope.tal.talinterpreter, line 271, in __call__
 Module zope.tal.talinterpreter, line 346, in interpret
 Module zope.tal.talinterpreter, line 379, in do_startEndTag
 Module zope.tal.talinterpreter, line 412, in do_startTag
TypeError: len() of unsized object

...
As far as I can tell, the code in zope.pagetemplate and zope.tales  
still

has the same traceback information that Products.PageTemplate had.
zope.tal, which contains the TAL interpreter, doesn't have any  
traceback

supplements, but then again, Zope 2's TAL package doesn't either.

To conclude, I don't think there's a "step backward" at all.


The Zope 2.9 code had traceback support in "PageTemplate.pt_render"
which told us which template was affected.
As you can see in the traceback above, at least this traceback support
is lost in Zope 2.10.

To conclude: "no step backward at all" is incorrect.

Looking at Zope 2.11, the traceback support above seems to have
been resurrected.


Furthermore, I could not find the equivalent of the transback
support which formerly was in "Expressions.py" (I found the one
corresponding to "TALES" and "PythonExpr").


Thank you for that careful analysis. I was only comparing Zope 2.9  
with Zope 3 (which are AFAICT equivalent in their traceback info) but  
I didn't take 2.10 into consideration. I've now filed a bug report at https://bugs.launchpad.net/zope2/+bug/236938 
 to make sure the issue isn't lost. I will look into it a.s.a.p.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: PageTemplates len() of unsized object

[Philipp von Weitershausen]

Dieter Maurer wrote:

Giampiero Benvenuti wrote at 2008-5-24 11:47 +0200:

...
after the upgrade from zope2.9.7 to 2.10.6 i get this error in the  
event log:


2008-05-24T09:31:32 ERROR Zope.SiteErrorLog http://myurl/error_log/manage_main
Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Shared.DC.Scripts.Bindings, line 313, in __call__
  Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec
  Module Products.PageTemplates.PageTemplateFile, line 129, in _exec
  Module Products.PageTemplates.PageTemplate, line 89, in pt_render
  Module zope.pagetemplate.pagetemplate, line 117, in pt_render
  Module zope.tal.talinterpreter, line 271, in __call__
  Module zope.tal.talinterpreter, line 346, in interpret
  Module zope.tal.talinterpreter, line 379, in do_startEndTag
  Module zope.tal.talinterpreter, line 412, in do_startTag
TypeError: len() of unsized object


Looks as if the Zope 2.10 PageTemplate implementation made a big
step backward with respect to quality of traceback information :-((


As far as I can see, traceback information was never added within the 
TAL interpreter but always for TALES expression evalutation. The 
traceback above seems to be about something going wrong within the TAL 
interpreter which is probably why we don't see any further traceback info.



Shane had added lots of "__traceback_info__" and "__traceback_supplement__"
declarations to the older code such that the tracebacks were
very informative
... unlike the traceback above.


As far as I can tell, the code in zope.pagetemplate and zope.tales still 
has the same traceback information that Products.PageTemplate had. 
zope.tal, which contains the TAL interpreter, doesn't have any traceback 
supplements, but then again, Zope 2's TAL package doesn't either.


To conclude, I don't think there's a "step backward" at all.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: dtml-tree documentation

[Philipp von Weitershausen]

Andreas Jung wrote:

Is there a complete documentation of the dtml-tree tag anywhere?
The dtml reference of the Zope book has the following for some options:
"This attribute is for advanced usage only"
Where can I find out about this 'advanced usage'?


Using DTML and related DTML tags is like driving a SUV in the time
of climate change.

Better look a "ZopeTree" or something similar (I think there was 
something like "SimpleTree" - Google).


zope.app.tree has a bunch of adapters and helpers for creating complex 
folding trees with any sort of templating mechanism, including Page 
Templates.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Upgrade Five for Zope 2.9.7?

[Philipp von Weitershausen]

James Robertson wrote:

How do I upgrade Five (http://codespeak.net/z3/five/) from v1.3.8 to
v1.4.4 in Zope v2.9.7?

The Plone product I wish to install (Reflecto v1.2 -
http://plone.org/products/reflecto) apparentl. requires v1.4.1+.

Frustratingly, the installation page
(http://codespeak.net/z3/five/INSTALL.html) and INSTALL.txt file for
Five do not actually explain how to install it.


Just drop the 'Five' directory into your instance's 'Products' 
directory, just like you would install any other product (e.g. Reflecto).


Plone, btw, should already ship with Five 1.4.x.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Five 1.5.5 and menuItem - problem with 'filter' parameter

[Philipp von Weitershausen]

On 1 Dec 2007, at 23:49 , Pawel Lewicki wrote:

Pawel Lewicki pisze:

Philipp von Weitershausen pisze:

Pawel Lewicki wrote:

Hi,
Am I doing anything wrong or filter parameter of browser:menuItem  
is just ignored?
I have that problem in Plone but I suspect CMF ActionsTool if not  
Five itself.


 

I tried "whatever" Python Script, registered page view, etc. No  
success.


You're using it wrong. The "string: object/whatever" expression  
yields a string containing "object/whatever", instead of calling  
object.whatever(). To achieve that,  you should simply say "object/ 
whatever" in the filter argument.


Hi,
I get KeyError: 'object'
that way.

Pawel


Full traceback:

http://paste.plone.org/18260




Use 'context' instead of 'object'.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Five 1.5.5 and menuItem - problem with 'filter' parameter

[Philipp von Weitershausen]

Pawel Lewicki wrote:

Hi,
Am I doing anything wrong or filter parameter of browser:menuItem is 
just ignored?
I have that problem in Plone but I suspect CMF ActionsTool if not Five 
itself.


  

I tried "whatever" Python Script, registered page view, etc. No success.


You're using it wrong. The "string: object/whatever" expression yields a 
string containing "object/whatever", instead of calling 
object.whatever(). To achieve that,  you should simply say 
"object/whatever" in the filter argument.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Frustrated with Python and Frameworks. Zope, Grok, , Django, CherryPy

[Philipp von Weitershausen]

Tres Seaver wrote:

Martijn Faassen wrote:

Hey,

On Nov 28, 2007 12:16 AM, Martijn Jacobs <[EMAIL PROTECTED]> wrote:

We could also consider putting them in some kind
 of collective-like SVN repository so that people can
make changes when they need to.

I think this is a great idea as it works with the Plone collective this
way as well.

Just to make it utterly clear: this stuff won't happen by itself. We
need a bunch of self-driven volunteers to do this work: look up
the relevant codebases, contact their authors, check them into a SVN
if they look orphaned (if they aren't of course don't fork them!) and
make an index page describing what is going on. This can be done
independently from zope.org, and should later become part of the
zope.org website.

You will need a SVN repository somewhere. svn.zope.org could be used
if you have committer access, but it would
be somewhat restricted as GPL-ed products can't be placed in there.
Anyway, all these questions I'm thinking of now someone else should
take the lead on, as it won't be me. :)


For clarity, nobody but a ZC employee (at present) is supposed to be
checking in any code with any license other than the ZPL;  in the
future, such a checkin will need to be approved by some agent / organ of
the Zope Foundation.


It's actually even more restrictive than that: If I read paragraph 5 of
the contributor agreement [1] right, then whoever checks things in must
have the intellectual property over the code, otherwise s/he would not
be able to donate half of it to ZC. So effectively you can't check in
somebody else's code, even if it's covered by the ZPL.


[1] http://www.zope.org/DevHome/CVS/Contributor.pdf

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Zope is in trouble

[Philipp von Weitershausen]

Gregory Dudek wrote:
A key factor is that from the zope.org web site it is not clear if the 
community is healthy or not, and the general impression is that the 
project is stalled since so many links are dead and defunct (and in fact 
I am not so sure of the zope community health myself any longer, despite 
the ongoing zope postings here).   In my opinion, making zope.org look 
healthy and be usable is the MOST important obstacle for the Zope 
community.  I believe this is both a symptom and a cause of disarray in 
the Zope user/developer community.


Zope was always a bit hairy to get into, without saying anything about 
Plone development or Zope 3, I just want to point out that without a 
clear simple up-to-date main web site, things are looking really bad.  I 
introduced some zope-based material in an introductory computer science 
course a few years ago with moderate success, but am starting to doubt 
it would be appropriate any longer.


I am not criticizing the people on this list or the other Zope 
developers: I have enormous appreciation for what has been built, I just 
would hate to see is dwindle in vitality and use.


Gregory, thanks for bringing this up. Please be assured that we're aware 
of this problem just as well. With the Zope Foundation in place, we can 
now tackle tasks like zope.org much better. But it takes time to get 
settled and we need volunteers. We've made some progress already, but 
we're not there yet. There's a committee which is actively planning on 
improving zope.org in the near future.


As far as zope.org's focus is concerned, it has shifted, as many already 
pointed out. We're no longer trying to make it a site with member 
accounts. Software is best released through the Python CheeseShop (aka 
PyPI) these days and bug collectors can be found on Launchpad. 
Outsourcing high-maintenance factors like these will allow us to focus 
on zope.org's actual message: promoting Zope.



--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: z3c.offlinepack

[Philipp von Weitershausen]

Ross Patterson wrote:

Also, I can't seem to get the ReStructuredText in the long_description
on the pypi page to display as ReStructuredText instead of just
displaying as test.  Anyone got any pointers?


I assume you're generating long_description from a README.txt file or 
so. If you have docutils installed, you can render this file yourself 
using the rst2html script. It will show warnings and errors during the 
rendering. Fix those, and PyPI will happily render your reST as well.



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: asynchronous MailHost

[Philipp von Weitershausen]

Andreas Jung wrote:
--On 19. August 2007 11:37:30 -0600 Sean Fulmer 
<[EMAIL PROTECTED]> wrote:



I just read about the latest changes to MailHost:

http://blog.zopyx.com/blog_ajung/archive/2007/08/19/zopes-mailhost-overha
uled

I'm currently using MaildropHost to do async delivery and would like
to streamline that setup if possible.

Can the latest MailHost be dropped into Zope 2.9.8?



If you can get zope.sendmail running under Zope 3.2/Zope 2.9: yes.


In Zope 3.2, zope.sendmail is called zope.app.mail. You should only have 
to change the imports.



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: _p_resolveConflict not called on conflict

[Philipp von Weitershausen]

Martijn Pieters wrote:

On 8/7/07, Joachim Schmitz <[EMAIL PROTECTED]> wrote:

Yes ZEO is involved, but where do I specify a Products-directory in
etc/zeo.conf ?


You can't, AFAICT. ZEO servers only support one Products directory in
their INSTANCE_HOME, it appears.


'Products' is just like any other package, so adjusting your PYTHONPATH 
should be all that's necessary. Moreover, 'Products' is just like any 
other namespace package (IOW, a package spread over multiple directories 
using Python's __path__ feature). You can declare namespace packages 
with Python's own pkgutil or with pkg_resources from setuptools.


If we stop pretending Zope lived in its own little world, things are 
actually quite simple and solutions are quite obvious.



--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Fwd: Zope 3 training in Oslo with Philipp von Weitershausen

[Philipp von Weitershausen]

In case anybody who's interested is not subscribed to zope-announce...


 Original Message 
Subject: Zope 3 training in Oslo with Philipp von Weitershausen
Date: Tue, 31 Jul 2007 15:15:04 +0200
From: Andreas Johnsen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

Bouvet is happy to announce Zope 3 training in Oslo with Philipp von 
Weitershausen, author of the best selling book «Web Component 
Development with Zope 3». The training is targeted at Zope 2 and Plone 
developers who want to step into the world of modern Zope development.


- When: Monday 1. October - Thursday 4. October 2007

- Where: Oslo, Norway

For agenda and more information, please visit 
http://www.bouvet.no/BouvetWEB/KursSeksjon.aspx?PageID=e1.



--

Best regards,

Andreas Rübner Johnsen
www.bouvet.no



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: 2.10.3: "default" keyword with tal:replace problems?

[Philipp von Weitershausen]

Sascha Welter wrote:

Yesterday evening I installed 2.10.3 for some tests with Zwiki (haven't
tried any of the other 2.10s). I noticed that the wiki logo wasn't
displayed. I think I narrowed it down to the "default" keyword in
tal:replace being treated like "nothing".


 My testcase (in a blank ZPT):

[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; 
tal:replace="structure here/notexists|default" />]


[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; 
tal:replace="structure default" />]


[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; 
tal:replace="default" />]



 Expected behaviour:
In 2.9 these render to 3 little zpt.gif icons in []. Rendered source:
[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; />]

[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; />]

[http://127.0.0.1:8080/misc_/PageTemplates/zpt.gif"; />]

 What I got:
In 2.10.3 this renders to the html source:
[]

[]

[]


I tested on two machines, but both Mac OS X 10.4 (one PPC, one Intel),
so I'd be glad if someone could try and reproduce it, to see if it's
just on "my" OS / machine combination. If it is, I will of course submit
it to the Collector. Of course if the expected behaviour has changed,
then I must have missed that information.


This sounds like a BBB bug. Please file a bug collector entry.

If you want to be extra helpful, you could provide a unit test:

* Get a subversion checkout of Zope 2.10:

  svn co svn://svn.zope.org/repos/main/Zope/branches/2.10

* If you look in Products/PageTemplates/tests, there are two 
directories, 'input' and 'output'. Place a PageTemplate file into 
'input' and the expected output into 'output'.


* Add a test case in testHTMLTests.py

* Attach the output of 'svn diff' (after having executed 'svn add' for 
the newly created files) to the collector entry.


This will increase the speed with which this issue would be 
reproduceable and therefore fixed immensely :).



--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: smart development & debugging

[Philipp von Weitershausen]

Roberto Scelzo wrote:

to aj:

If you have the freedom to choose your Zope version:

 - start with Zope 2.10 + CMF 2.1

 - put your templates etc. into the filesystem using portal_skins

 - use Zope 3 technology together with CMF: Zope 3 schema + formlib
   for creating content-types, forms etc...

 - avoid Plone if you really don't need it. Don't start with Plone
  *just because it looks nice* and if you really need only a small

subset

  of the Plone functionality...

-aj


Yes, I do have the freedom to choose which Zope version to run on my
machines and I'm going to focus my attention on the setup you suggested.


If you've got freedom, then why not consider Zope 3, perhaps with the 
Grok library on top to make things easier: http://grok.zope.org.



--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: V iewlet in rotterdam?

[Philipp von Weitershausen]

Derek Richardson wrote:

Zope 3.3

I want to add a viewlet to the rotterdam skin. I don't want to create my 
own skin. is there an accepted way of doing this? I'm surprised that the 
left sidebar in rotterdam doesn't appear to have  a viewlet manager. I 
have been unable to find any declarations in zcml (grepped for 
viewletManager through the entire zope source, didn't see anything 
relevant).


It looks like rotterdam makes do with macros, instead of using viewlets. 
Is there a reason for this? Seems like the left sidebar is perfect for a 
manager, with a viewlet for navigation and another for the add menu.


I am writing a syndication (web feeds: Atom, RSS, etc) package for zope 
and want to plug my viewlet for accessing feed links directly into 
rotterdam. Perhaps this isn't the way to do it, but it seems to me that 
a package like mine that provides general functionality shouldn't define 
its own skin, but should be usable in other skins. Am I wrong?


Quite frankly yes :).

Like others mentioned, Rotterdam predates viewlets. But even then... who 
the @#$()&%*^ cares about Rotterdam. It's ugly, barely functional and 
quite confusing.


If you're writing a syndication package for Zope, the best thing this 
package can do is provide a nice and clear API to the syndication data. 
Then people can make use of this API in their own views, viewlets or 
whatever.



--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Get paid for spending your summer improving Zope!

[Philipp von Weitershausen]

The Zope Foundation has been accepted as a mentoring organization in 
this year's Google Summer of Code project. That means chosen students 
who want to hack on one of the Zope projects (Zope 2, Zope 3, ZODB, CMF, 
grok, ...) this coming summer will get paid USD 4,500 if they 
successfully complete a project.



What can you work on?
-
See project suggestions at http://wiki.zope.org/zope3/SummerOfCode2007. 
You may also come up with your own suggestions.



Who can apply?
--
Anybody eligible for the GSoC program. See 
http://code.google.com/support/bin/answer.py?answer=60279&topic=10730.



How do I apply?
---
You may apply until March 24th through the GSoC webapp. See 
http://code.google.com/support/bin/answer.py?answer=60306&topic=10727 
for more info.



If you have any questions, feel free to ask questions on the 
[EMAIL PROTECTED] (http://mail.zope.org/mailman/listinfo/gsoc) mailinglist.



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: zope.testbrowser, how to?

[Philipp von Weitershausen]

Basil Shubin wrote:

Basil Shubin wrote:

Hi friends,

I want use zope.testbrowser for testing my sites, but before write it 
as DocTest I want execute each statemnt interactively in python shell. 
I don't know any way to see where it's works, what value it returns, 
what error I can get and how this error should looks is python... It's 
why I want check it in python shell.


What the problem?

First, if execute following code in python shell:

 >>> from zope.testbrowser import Browser
 >>> browser = Browser()
 >>> browser.open('http://localhost/Plone')


but if I have use this instead above code:

  >>> from zope.testbrowser.browser import Browser
  >>> browser = Browser('http://localhost:8080/Plone')

everything works!


That's because zope.testbrowser.browser.Browser opens real HTTP 
connections. zope.testbrowser.Browser uses Zope 3's functional test 
framework.


If you want to use the test browser for functional tests in Zope 2, use 
Products.Five.testbrowser.Browser.


--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Running ./zopectl gives NameError: name 'set' is not defined

[Philipp von Weitershausen]

michael nt milne wrote:

Hi

On trying to make a new zopeinstance from a Plone 2.5 instance created 
using the unified installer I am getting the following error when I 
attempt to run ./zopectl and start the instance.


Traceback (most recent call last):

...

NameError: name 'set' is not defined


Sounds like you're using Python 2.3 while Python 2.4 is required.


--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Configure.zcml In Hello World Video On WorldCookery.Com Doesn't Work

[Philipp von Weitershausen]

Mark, Jonathan (Integic) wrote:

Here is my configure.zcml file, which is identical to the one Paul Everitt says 
to write:

http://namespaces.zope.org/browser";>

  
   for="zope.app.container.interfaces.Icontainer"

   permission="zope.Public" />




and here is the error message that I get when I reboot the Zope 3.3
server on Windows XP:

ConfigurationError: ('Invalid value for', 'for',
'ImportError: Module
zope.app.container.interfaces has no global
Icontainer')


It's IContainer (capital 'C'), not Icontainer. Paul's video is correct, 
you must've missed it when comparing



--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Zope 2 and Zope 3

[Philipp von Weitershausen]

Geoff Gerrietts wrote:
[some paragraphs about scaling which I can't really comment on]


As for source control, I figure all of your code (DTML, yuck) is in the
ZODB. This went out of fashion a long time ago, most serious development
happens on the filesystem (in Python packages) which can obviously be
source-controlled very well.


A good deal of the code is in the ZODB, because it's (yuck) DTML
documents, yes. We have another sizable chunk that lives on the
filesystem. The challenge in managing the build/deploy process has
been trying to find a way to keep those two conjoined. I suspect that
any dependency on the ZODB at all is likely to be considered an
impediment, and my quick eyeballing says it's not gone or even really
optional under Zope 3 (but I'm sure we could work something out.)


The ZODB is still there in Zope 3, but Zope 3 is much less dependent on 
it. In fact, there are people who are using Zope 3 without any ZODB 
instance at all, but directly talk to a relational database. Currently 
this requires a bit of hacking, but our good man Chris Withers has 
expressed interest in making the next release of Zope 3 more flexible in 
this regard.


What's already possible is to have a minimal ZODB with only one 
persistent object: a SQLObject or SQLAlchemy container. That's a 
container (e.g. like a folder) whose items aren't persisted in the ZODB 
but come from a relational database.


You seem to already have come to the conclusion that having code live in 
both the filesystem and the ZODB can be painful. I think a good first 
step for you would be to migrate your remaining ZODB-based code to the 
filesystem. That not only makes deployment easier, you're also free to 
refactor it then (e.g. using Zope 3 idioms). In the long run, this also 
means saying good-bye to things like External Methods because they 
require code on the filesystem and configuration in the ZODB.



Regarding "oh you'll hafta start over", it's pretty much true, if you
want to switch to Zope 3. But nobody says you have to. You can do it
incrementally by porting some of your app's functionality to Zope 3
components step by step (as mentioned already, most work in Zope 2). Big
projects like Plone aren't rewriting their whole codebase either, but
new development is completely Zope3-based. Their target platform still
is Zope 2, though.


"You'll hafta start over" is only ever true in degrees, though, and
I'm still trying to figure out what the degrees are. The business
logic will still be the same. Can we hack together a DTML processor
that allows us to export the DTML documents to the filesystem and
publish them from there? Maybe, I don't know. Did someone else already
do that? Don't know that either. How dramatically will our products
need to change? Probably 75% of our Python code is written in a
bastardized form of ExternalMethod; we might be able to leverage that
unfortunate architectural choice to significant advantage during our
porting phase. These are the kinds of questions I have, and I think
the answers probably aren't easy or someone would have offered them
up.


It is certainly possible to execute filesystem-based DTML (using 
Globals.DTMLFile). It's hard to say how much your products will have to 
change without knowing the codebase. If you have external methods, it 
shouldn't be too hard to refactor this code into components in "proper" 
Python modules. To make things easy, the external methods could stay at 
first, for backwards compatibility. I would take this one step at a time 
(that's at least what everybody else seems to do and it looks like it's 
working out for everybody).



Someone's going to need to learn enough Zope 3 to answer the
questions. I'm not sure it will be me, but maybe. :)


Well, whoever it'll be, there are books (e.g. http://worldcookery.com) 
and trainings (e.g. http://trizpug.org/boot-camp/camp5) that should help 
with the learning :).



--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Zope 2 and Zope 3

[Philipp von Weitershausen]

Geoff Gerrietts wrote:
I have a couple questions about the current game plan for Zope 
development that I was unable to answer for myself by searching through 
mailing list archives and the zope.org  website. I hope 
my inability to answer them is not merely a symptom of poor search term 
choices, and I hope someone can answer them for me.


You're right, it is a bit tricky to google for this.

Zope 3 release notes usually contain the following notice (from 
http://mail.zope.org/pipermail/zope-announce/2006-September/002016.html):


  Zope 3 is the next major Zope release and has been written from
  scratch based on the latest software design patterns and the
  experiences of Zope 2.

  Cleanup of the Zope 3 packages has continued to ensure a flexible and
  scalable platform. We continued the work on making the transition from
  Zope 2 to Zope 3 by making Zope 2.10 use even more of the Zope 3
  packages. But the transition is far from complete yet. **You can't run
  Zope 2 applications in Zope 3.**

I've posted a couple times before (a long time ago) about the large web 
application I work on; it's many hundreds of KLOC and an unfortunately 
large percentage of it is DTML. It's still more or less in that state; 
the realities of being a for-profit business in a rapidly evolving 
marketplace permit very little time for maintenance or aggressive 
refactoring of the application. That's the background for my questions; 
I'm trying to figure out how loudly I can shout "Impending doom!" to 
upper management without endangering my credibility.


1. Last time I talked to anyone from Zope Corp, the plan was to quiesce 
Zope 2 in favor of Zope 3. At that time, I think I remember people 
saying 2.9 would be the last in the Zope 2 series. Now there's a 2.10, 
so clearly it wasn't. How long does a business like mine have before 
there is no clear upgrade path in the Zope 2 series? Is 2.10 now the 
final Zope 2 release, or will there be a 2.11 and 2.12?


There will definitely be a Zope 2.11 and at this point I see no reason 
why there shouldn't be a Zope 2.12. We (the Zope Community, not 
necessarily Zope Corporation) will maintain Zope 2 as long as it's 
necessary. "Maintaining" in this case also means integrating more Zope 3 
technologies with each release. Nowadays (Zope 2.10) you can already 
write applications, or at least base libraries, that work on both Zope 3 
and Zope 2.


2. Whenever someone asks about moving an existing application from Zope 
2 to Zope 3, there's a round of flip "oh you'll hafta start over" 
responses. I understand that the two architectures are fundamentally 
different, and that I'll need to rebuild my object database, etcetera. 
Am I also correct in believing that all products must be completely 
rewritten, and that DTML is no longer a supported templating language? 
Has the users/roles/permissions security structure disappeared or been 
supplanted? I am trying to ascertain at a glance how much we will need 
to rebuild for ourselves; if it's enough then the problems we have had 
with Zope (poor scaling, poor integration with source control) may 
outweigh the advantages of remaining on the platform.


I'm surprised you're experiencing poor scaling. I think Zope can scale 
pretty well, or at least it can be *made* to scale pretty well. It all 
depends on your setup and, of course, on your application.


As for source control, I figure all of your code (DTML, yuck) is in the 
ZODB. This went out of fashion a long time ago, most serious development 
happens on the filesystem (in Python packages) which can obviously be 
source-controlled very well.


Regarding "oh you'll hafta start over", it's pretty much true, if you 
want to switch to Zope 3. But nobody says you have to. You can do it 
incrementally by porting some of your app's functionality to Zope 3 
components step by step (as mentioned already, most work in Zope 2). Big 
projects like Plone aren't rewriting their whole codebase either, but 
new development is completely Zope3-based. Their target platform still 
is Zope 2, though.



--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: [Warning] Zope 3 component architecture (CA) not reliably usable for registrations from Python

[Philipp von Weitershausen]

Chris Withers wrote:

Stephan Richter wrote:

If you are populating the CA before ZCML is fully parsed, then:


Why is the CA predicated on ZCML?!


It's not. And Stephan's "Collect all registrations before executing 
them!" isn't actually necessary either (it's just necessary for conflict 
resolution; grok doesn't do it, for example). The only problem lies with 
registrations upon import:


* You can't import the module/package w/o having the registration to 
take place (so you can't subclass the components and have those 
registered instead of the orginial ones, for example)


* Import happens once, so when you have unit tests that set up and clear 
the Component Architecture properly, you will loose all of those 
registrations that happened on import pretty fast.



--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: [Warning] Zope 3 component architecture (CA) not reliably usable for registrations from Python

[Philipp von Weitershausen]

Dieter Maurer wrote:

I tried to use Zope3 events to get informed when requests start and end.

One of our modules (the interface module to "jpype") requires such
a notification for reliable work. Therefore, it tried to register
the corresponding subscriptions on import of this module.


That is an uncommon approach, at least it used to be. Typically, we 
first have a bootstrap level and then we register things. During the 
bootstrap level, the Component Architecture is initialized.


Things changed a bit after Zope 2.8/X3 3.0. Nowadays, the Component 
Architecture doesn't need any setup anymore and you can do registrations 
on import. I'd still recommend against that.



Unfortunately, this works very unreliably -- for the following reasons:


  The CA performs by itself only extremely minimal initialization.
  Especially, it does not register the "Adapters" service, necessary
  for the registration of event subscriptions.

  The full CA initialization is only performed quite late, in the call
  to "Products.Five.initialize".
  Event notification registration attempts before this time will fail
  (with a "ComponentLookupError: 'Adapters'"), 
  those performed after this time will succeed.


The "Five" initialization is stupid enough that it will fail
when the service registration for 'Adapters' has already been performed.


That's because Five assumes it's responsible for the setup layer. I 
suggest to register components through ZCML. Five will pick up 
configure.zcml in products automatically *after* everything has been set 
up properly. That's the canonical way, at least in Zope 2.8/X3 3.0


At the current state, event notifications can reliably only be defined 
via ZCML. This is unfortunate for our use case where the registration

should be bound to the import of a given module.


I typically find it quite magic when application policy things happen at 
import:


  Never mix mechanism with policy
-- Brooks' Second Law of Software Reuse

Philipp


P.S.: I agree with Martijn, the big "warning" is uncalled for. You're 
just trying to fight the semantics of the framework.


--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] 2nd edition of Zope 3 book available!

[Philipp von Weitershausen]

I'm proud to announce that -- as the first Zope book ever -- my book 
titled "Web Component Development with Zope 3" has been released as a 
second edition and is now available from online and local bookstores.


Like the first edition, the new book is targeted at all web developers 
who want to get into Zope 3 or learn more about Zope 3 and Zope 3 
technology than they already know.  It's accompanied by an extensive 
example application that's extended throughout the book.


*Unlike* the first edition, the second edition is...

- up-to-date.

  The book covers the latest Zope 3 release, Zope 3.3, which has only
  been released recently. All chapters, all examples, and the appendices
  have been revised to match the most current Zope 3 codebase.

- bigger.

  Five (!) new chapters, all describing new features in Zope, have been
  added, many others were extended notably. In total, the book is more
  than 80 pages thicker than the old one -- at the same price as the old
  one.

- better.

  With the second edition, the book has been completely revamped. My
  excellent reviewers from the Zope and Plone community have done a
  tremendous good job at improving the book's language and technical
  details. I also improved the didactics in various places.

- for you!

  No matter if you're a Zope 3 developer or just starting to get into
  Zope 3, I suggest you keep the book under your pillow. Even as a Zope
  2 or Plone developer, you'd be surprised how much Zope 3 technology
  you can now use in Zope 2 -- and this book tells you how! This makes
  it a must-buy especially for Plone developers as Plone 3.0 is using
  Zope 3 components for all new development.

Find out more at http://worldcookery.com.

Philipp


--
http://worldcookery.com -- Professional Zope documentation and training
2nd edition of Web Component Development with Zope 3 is now shipping!
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: View classes based on Page Templates in Zope2

[Philipp von Weitershausen]

Peter Bengtsson wrote:

Something I like about Zope3 is the View classes.
What I like about it especially is that it's a brilliant place for 
putting in little extra silly python methods that are specific to your 
template rather than the object class. Eg.


class ViewProduct(BrowserPage):
__call__=ViewPageTemplateFile('productview.pt')
def showPrice(self, product):
return "£%.2f" % product.getPrice()

What options do we have for this in Zope2?
If Five is the answer, what options do we have without Five?

Has anybody written a convenient class like this? Perhaps based in 
PageTemplateFile or something?


from Products.Five.browser.pagetemplatefile import ViewPageTemplateFile

--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Extra Fancy Template Manipulation

[Philipp von Weitershausen]

Edward Pollard wrote:

Hi all,

I've got three subsites that formerly used three different templates. I'd
like for them now to use the same template, but I'd prefer not to have to
touch the thousands of pages of content that currently point in three
different places for their template.

The easy solution is to copy/paste the template to three different places.

But I don't like that solution. It will be obnoxious in the long run.

I've never tried to manipulate templates and the execution of said templates
with Python. Is there something I can do here to pass calls for the
templates back to one place rather than actually duplicating my template?


Read about PageTemplate macros.

--
http://worldcookery.com -- Professional Zope documentation and training

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: PageTemplate i18n migration from Zope2 to Zope2+Five / Zope3...

[Philipp von Weitershausen]

Pascal Peregrina wrote:
I would like to know the right way to manage messages and store them in 
ZODB with Zope2+Five or Zope3.

Currently, in Zope2, I use Localizer MessageCatalog objects.
Is there a new way already available through Five?
(note that I don’t want to use flat files for translations, they must be 
ZODB stored for my use case)


You can write your own ITranslationDomain utility. Each such utility 
corresponds ot a message catalog. Five >= 1.2 supports local utility 
registration.


You can also stick with Localizer for the time being.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: tal assignment

[Philipp von Weitershausen]

David Bear wrote:

I wanted to assign a list object to a tal global variable but I can't
seem to find the correct syntax. I tried:

 tal:content="">

 blah





This will print "['item1', 'item2']"


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-9-7 15:08 +0200:

Chris Withers wrote:

(Btw, just thought of another one possible name clash: 'response')

no-one uses that is Zope 2 land 'cos of RESPONSE...
Well. Could be that someone uses 'response' as a form variable, as in 
"the response to a question" in a QandA system, perhaps.


Then, he will loose already now:

  "response" *IS* an attribute of "ZPublisher.HTTPRequest.HTTPRequest".
  It contains the "response" object passed in when the request object
  was created.


Ah, didn't look closely enough. Thanks. Even better.

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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Chris Withers wrote:

(Btw, just thought of another one possible name clash: 'response')


no-one uses that is Zope 2 land 'cos of RESPONSE...


Well. Could be that someone uses 'response' as a form variable, as in 
"the response to a question" in a QandA system, perhaps.


The sad thing about this is that we can only do so much investigation of 
existing code. The rest is speculation. But it's better to be safe than 
sorry...


I've thought about introducing the adaption approach now. I think we'd 
be opening a can of worms since the request objects are likely to be 
passed from old style code to new style code and vice versa.


I think it's worth at least trying...


Agreed. This thing has always been on my agenda, but it needs thought 
and time to do it.


I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 
doesn't mean that everything from the 'zope' namespace has to work. 
Five has never made that promise.


Indeed, but in this circumstance, they probably should ;-)


Agreed.

That said, *if* we choose to go with such a configuration option, I 
think it woudl probably be a good idea to have it disabled by default 
in the first release and enabled in subsequent releases. That way 
applications could opt in for the new behaviour earlier than necessary 
(much like Python's __future__ imports).


OK, I'll buy that, annoying though it'll be for everyone (no-one has 
spoken up to say "you're gonna break all my code is you use debug, or 
locale, or response" ;-) )


True. Hey, don't get me wrong. I'm all *for* going forward and make Zope 
2's request more like IBrowserRequest. But in the end when I break other 
people's apps, everyone will be all over me. I'm sure if it was one of 
your apps, you'd be the first one to complain and declare Zope's rate of 
change too fast and harmful. ;)



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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Chris Withers wrote:

Philipp von Weitershausen wrote:

Practically, it will very rarely hinder you to add attributes (such as
"locale") to the request.


I think "locale" and "debug" are just common enough to be form variables.


Funny, I've never used either in 6 years of zoping ;-)


Me neither, but are we prepared to break the apps of the people who do?

(Btw, just thought of another one possible name clash: 'response')

You'd be surprised (I was too). Plus, TALES path expressions first try 
attribute access, then item access.


ZPT sux ;-)


TALES path expression sux (for various reasons).

Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I 
wouldn't mind. But I'm sure others would.


I thought adapters were for this exact kind of thing?
Existing Zoep 2 code would use a Zope 2 request, the Zope 3 components 
should be presented with a Zope 2 request that has been adapted to 
present IBrowserRequest rather than just being marked as implementing 
it, no?


This would have been a possible solution at the time, but it wasn't 
chosen. Neither the people who introduced IBrowserRequest to Zope 2 nor 
I who pretty much took on Five maintenance afterwards realized this 
problem back then.


I've thought about introducing the adaption approach now. I think we'd 
be opening a can of worms since the request objects are likely to be 
passed from old style code to new style code and vice versa.


Perhaps. A configuration option (that would usually be turned to 'off') 


What do you mean by "off" here? The config option should make the stfuf 
that ships (like the widgets!) work by default...


I'll repeat this again: Just because Zope 3 libraries ship with Zope 2 
doesn't mean that everything from the 'zope' namespace has to work. Five 
has never made that promise.


That said, *if* we choose to go with such a configuration option, I 
think it woudl probably be a good idea to have it disabled by default in 
the first release and enabled in subsequent releases. That way 
applications could opt in for the new behaviour earlier than necessary 
(much like Python's __future__ imports).


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: zope 3 invisibility

[Philipp von Weitershausen]

Jens Vagelpohl wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 6 Sep 2006, at 02:04, Fred Drake wrote:

On 9/5/06, Carlos de la Guardia 
<[EMAIL PROTECTED]> wrote:
I frequently blog about Zope, and recently posted a list of 10 
reasons why I
think Zope 3 is kind of invisible to the Python community (see my 
blog at

http://blog.delaguardia.com.mx ). One of the things that I talk about in
that post is that the Zope community tends to interact more through its
mailing lists than its blogs, as opposed to other so-called modern
frameworks, like Django and Turbogears.


Interesting.  I've always considered blogs to be fairly invisible
since I have to go look for them, whereas for mailing lists I can sign
up for things I'm interested in.


Exactly. This is a matter of taste, nothing else. Mailing list email 
comes to me. Blogs I have to seek out and go there. Sorry, too much 
effort for much hot air of dubious quality ;)


Lol, and lists like this one here do NOT have hot air of dubious quality?

It *is* a matter of taste, sure. However, the effects of buzz through 
blogging cannot be denied. My blog for instance is in the 
planet.python.org aggregator, which has made at least a few Pythonistas 
 aware of it. If Zope were to appear there more often, perhaps it won't 
be forgotten that often anymore.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Maciej Wisniowski wrote:


I'll call this an "issue" for now, but I won't argue semantics here. 
All I can say is that the Five project's promises were never that 
everything from Zope 3 works instantly. And it has also been Five's 
policy to make a quick lie here and there just to get things going. 
Five usually gives you 95% of a certain technology you know from Zope 
3. The remaining 5% are friction loss due to Zope 2isms like 
Acquisition, etc. 


I don't catch one thing. There is Five/formlib/formbase.py where Five
overrides handle_edit_action. Why it is overriden? "To remove
dependecy on request.locale".

Why can't be same thing done with DateDisplayWidget?
Isn't this a simple solution?


Sure. As I said earlier, we are happy to accept patches :)

Philipp

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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-9-5 20:57 +0200:

...
Note that I'm well aware of this issue and have thought hard about it. I 
think the only long term solution out of this mess is to get rid of the 
__getattr__ spelling once and for all.


The "__getattr__" may be a stumbling block in principle.

Practically, it will very rarely hinder you to add attributes (such as
"locale") to the request.


I think "locale" and "debug" are just common enough to be form variables.


True: you can use "REQUEST.locale" or "REQUEST.debug" and expect
to access in fact "REQUEST['locale'] and "REQUEST['debug']" respectively.

But, it is rare that the attribute access syntax is used


You'd be surprised (I was too). Plus, TALES path expressions first try 
attribute access, then item access.



and if it indeed results in the wrong result (because the request
grew additional  attributes), then it is easy to fix.


Sure, but it's a BBB foul. It's not *me* who has the legacy code, so I 
wouldn't mind. But I'm sure others would.



Adding the configuration option would (perhaps) make the administrator
aware of the potential cause when he gets informed about wrong values
read from the request.


Perhaps. A configuration option (that would usually be turned to 'off') 
would surely be a quick way of finding out where you have code that uses 
request.foo. It may be a good step leading an actual deprecation of the 
__getattr__ spelling (which I think is necessary for eliminating the 
reuquest.foo spelling once and for all, especially in newly created code).


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Hmm... Localizer or Localizer

[Philipp von Weitershausen]

Peter Bengtsson wrote:

HTTP_ACCEPT_LANGUAGE isn't a variable. It's an HTTP header
(Accept-Language) that you really shouldn't modify. The request should
be treated as read-only.

To test languages, either write your own IUserPreferredLanguages adapter
that returns the language you want or simply configure your browser to
send a different Accept-Language header. In Firefox, you can simply do
this by entering "about:config" in the URL bar and changing the setting
of the intl.accept_languages variable (e.g. to "se, en").

> Either I've missed something big and crucial or there's a bug in lack
> of errors or alerts.

You simply didn't read Five/doc/i18n.txt
(http://codespeak.net/z3/five/i18n.html). Googling "five i18n" gives you
that as a first hit. "RTFM" is all I can say here.


Don't RTFM me! I've read that page and unless you have a PhD in
physics and indept experience of Zope 3 is really doesn't make a lot
of sense. Plus, I've got your cookbook at home :)


You must be confusing me. I don't have a PhD in physics and I didn't 
write a cookbook. That was the other German ;).



So, should I use PTS or not??


No. I think I've answered that question before.


"The default behaviour for choosing languages in Five is the one of
Zope 3: analyze the Accept-Language HTTP header and nothing more."
This is not good enough.


Then implement your own IUserPreferredLanguages adapter. This is 
documented in my book which you may or may not have, not sure ;)



When I send out email alerts to people in my
app, that's a wget script that kicks if off, not a Mozilla browser.
Besides, what if an Englishman is using a Swedish
internetcafe-computer when on holiday; in that case I want to allow
him to manually configure his user profile on my site.


Sure. That's possible. With a custom IUserPReferredLanguages adapter.


I have no idea what this does or what I'm supposed to do with:



Nothing. The docs say that this is only for users who use PTS for 
legacy. You're not one of them.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-9-5 16:44 +0200:

...
It's an issue, not a bug.


According to Wikipedia:

A software bug is an error, flaw, mistake, failure, or fault in a
computer program that prevents it from working as intended, or
produces an incorrect result.

A request object that declares to implement "IBrowserRequest" but
does not, is not working as intended -- and constitutes a bug.


Fine. Call it a bug. I don't care.

Arguing semantics won't solve that problem now, will it. Remove the 
IBrowserRequest declaration and see Five break. Perhaps it was the wrong 
thing to do at the time (it certainly wasn't me who did it), but that's 
just how it is. We'll have to live with it now.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-9-5 16:28 +0200:

Maciej Wisniowski wrote:

 > I consider this a feature request but not as a bug.
Ehm... I'm not sure whether we understand each other.

I mean the bug

There is no bug.


Seems a funny interpretation of "no bug" for me...


It's an unfortunate situation. That's what it is.


is that DateDisplayWidget in Zope2.9.4 uses
request.locale which as you said is from Zope3 world. So, as far as I
understand, reference to 'request.locale' shouldn't appear in Zope
2.9.4 code at all but it does... Do you mean it is correct??
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only 
pretends to be an IBrowserRequest.


If that is not a bug (pretending to implement "IBrowserRequest" but not
doing so) what is a bug?


I'll call this an "issue" for now, but I won't argue semantics here. All 
I can say is that the Five project's promises were never that everything 
from Zope 3 works instantly. And it has also been Five's policy to make 
a quick lie here and there just to get things going. Five usually gives 
you 95% of a certain technology you know from Zope 3. The remaining 5% 
are friction loss due to Zope 2isms like Acquisition, etc.


In order to "sell" Zope 2's request to the Zope 3 machinery, Five 
originally made Zope 2's request an IBrowserRequest -- even though that 
was a lie. When Five was integrated into Zope 2, that lie was carried on 
in Zope 2. I was neither the one to make that initial "lie" nor was I 
there when Five was integrated.


At the current state, it can't 
implement the whole interface.


Which means, that there is a bug but you have currently little chance
to fix it...


The problem with going forward with this and fixing it is the following 
(quoting myself from an earlier email on this thread):


  We can't even just make the Zope 2 request have that attribute
  because of potential backward incompatibilities. Why? Because you
  can do request.locale in Zope 2 right now which is an equivalent
  spelling of request['locale'] (it looks up request variables). If
  existing applications use the attribute access instead of the item
  access (which should clearly be the preferred way, but there's lots
  of Zope 2 legacy), they would break because request.locale would now
  find something else.

  It's not a bug. It's Zope 2's obscenity with __getattr__ APIs
  instead of __getitem__ APIs that's preventing the harmonizing of the
  two implementations, that's all. Both the ObjectManager and the
  request are very good examples of how Zope 2 got this wrong, but
  Zope 3 got it right.


By the way, you could introduce a configuration option
that allows the user to determine whether he is more interested
in a true "IBrowserRequest" request or a more backward compatible
request.


I'm not sure that that will work. In complicated systems like Plone, you 
might end up with some products that rely on the old way of doing things 
while Plone uses Zope 3 components that obviously want the "true" 
IBrowserRequest request at same time.


Note that I'm well aware of this issue and have thought hard about it. I 
think the only long term solution out of this mess is to get rid of the 
__getattr__ spelling once and for all.


That's a known issue, but we can't do anything about it, at least not in 
DateDisplayWidget (and numerous other places where request.locale is 
used). The problem's roots go deeper.


That you know it and do not want to change it does not mean that
"bug" is not an appropriate term...


You're claiming that I don't *want* to change it. That's not true. I am 
thinking hard about this, but I see no easy solution. Of course, I'd be 
more than happy if an easy solution can be found.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Maciej Wisniowski wrote:
DateDisplayWidget expects an IBrowserRequest. Zope 2's request only 
pretends to be an IBrowserRequest. At the current state, it can't 
implement the whole interface.


That's a known issue, but we can't do anything about it, at least not 
in DateDisplayWidget (and numerous other places where request.locale 
is used). The problem's roots go deeper.


I just thought that if there is DateDisplayWidget class in Zope2.9.4 code
then it may be used. It is a bit strange for me that Zope contains code
that is unuseable. But ok, I'll use something different.


It is not unusable if your request correctly implements IBrowserRequest. 
And even though it is in Zope 2.9.4, it comes from a Zope 3 based 
library. Five never gave you a guarantee that *all* Zope 3 components 
would instantly work in Zope 2 as soon as they're shipped with it.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Martijn Pieters wrote:

On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:

Maciej Wisniowski wrote:
>  > I consider this a feature request but not as a bug.
> Ehm... I'm not sure whether we understand each other.
>
> I mean the bug

There is no bug.


Sure there is.


It's an issue, not a bug. All things that use DateTimeWidget are simply 
not supported at this stage.



The Five integration includes code that expects an
IBrowserRequest. Either Zope2 should implement that correctly, or Five
should not include that widget,


It'd be really really hard not to ship individual components from Zope 3.


or Five should register a widget that doesn't use request.locale.


Patches are welcome :)


This should be at a minimum be named as a known issue.


Sure. I just named it :).

Philipp

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Maciej Wisniowski wrote:

 > I consider this a feature request but not as a bug.
Ehm... I'm not sure whether we understand each other.

I mean the bug


There is no bug.


is that DateDisplayWidget in Zope2.9.4 uses
request.locale which as you said is from Zope3 world. So, as far as I
understand, reference to 'request.locale' shouldn't appear in Zope
2.9.4 code at all but it does... Do you mean it is correct??


DateDisplayWidget expects an IBrowserRequest. Zope 2's request only 
pretends to be an IBrowserRequest. At the current state, it can't 
implement the whole interface.


That's a known issue, but we can't do anything about it, at least not in 
DateDisplayWidget (and numerous other places where request.locale is 
used). The problem's roots go deeper.


Philipp

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: request.locale - do we have this in 2.9.4?

[Philipp von Weitershausen]

Martijn Pieters wrote:
On 9/5/06, Maciej Wisniowski 
<[EMAIL PROTECTED]> wrote:

I'm using Zope 2.9.4 with Five1.4 (linux box).
I'm trying to use DateDisplayWidget (from
/zope/app/form/browser/textwidgets.py)

[snip]

So is this something with my Zope that I don't have request.locale
or is that a bug?


I'd say it's a bug.


No it's not.


The Zope3 request has the locale attribute, but the Zope2 request
implementation doesn't.


Right. Who ever said that the Zope 2 request is compatible with the Zope 
3 request?


We can't even just make the Zope 2 request have that attribute because 
of potential backward incompatibilities. Why? Because you can do 
request.locale in Zope 2 right now which is an equivalent spelling of 
request['locale'] (it looks up request variables). If existing 
applications use the attribute access instead of the item access (which 
should clearly be the preferred way, but there's lots of Zope 2 legacy), 
they would break because request.locale would now find something else.


It's not a bug. It's Zope 2's obscenity with __getattr__ APIs instead of 
__getitem__ APIs that's preventing the harmonizing of the two 
implementations, that's all. Both the ObjectManager and the request are 
very good examples of how Zope 2 got this wrong, but Zope 3 got it right.


Philipp

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

http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] Re: Hmm... Localizer or Localizer

[Philipp von Weitershausen]

Peter Bengtsson wrote:

But how do you use it? I installed Five 1.2.6
In my product's directory I created a configure.zcml that looks like this::
http://namespaces.zope.org/zope";
  xmlns:browser="http://namespaces.zope.org/browser";
  xmlns:i18n="http://namespaces.zope.org/i18n";
  package="Products.RememberYourFriends">

 



Starts without errors. My ryf-sv.po file isn't automatically compiled
to .mo


Right. The Zope 3 machinery doesn't do that. Use msgfmt from the gettext 
utilities to compile catalogs.


You're also using PTS's non-standard directory layout. The standard 
gettext layout is somedir/LC_MESSAGES//.mo. PTS supports 
this as well but Plone continues not to go standard here and set a bad 
example :(



and I tried changing the HTTP_ACCEPT_LANGUAGE variable but
still just the old default English.


HTTP_ACCEPT_LANGUAGE isn't a variable. It's an HTTP header 
(Accept-Language) that you really shouldn't modify. The request should 
be treated as read-only.


To test languages, either write your own IUserPreferredLanguages adapter 
that returns the language you want or simply configure your browser to 
send a different Accept-Language header. In Firefox, you can simply do 
this by entering "about:config" in the URL bar and changing the setting 
of the intl.accept_languages variable (e.g. to "se, en").



Either I've missed something big and crucial or there's a bug in lack
of errors or alerts.


You simply didn't read Five/doc/i18n.txt 
(http://codespeak.net/z3/five/i18n.html). Googling "five i18n" gives you 
that as a first hit. "RTFM" is all I can say here.


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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: Hmm... Localizer or Localizer

[Philipp von Weitershausen]

Peter Bengtsson wrote:

What's going on here?? Which is which?

http://www.ikaaro.org/localizer
or
http://www.j-david.net/software/localizer/

They're both zope products and both with the same name.
Perhaps the author of the "deprecated" page could put a redirect or
something to the new one.


Do yourself a favour and do what ChrisW suggested: use Five's i18n 
machinery. Comes with Zope 2.9 included. For Zope 2.8, simply install 
Five 1.2. It's a no-brainer (isntalling Five 1.2).


Philipp

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

http://mail.zope.org/mailman/listinfo/zope-dev )

[Zope] Re: zope.org

[Philipp von Weitershausen]

Chris Withers wrote:
> Gaute Amundsen wrote:
>> Actually, I am starting to think there should be a big notice on the
>> frontpage of the http://www.zope.org/Documentation/ section saying:
>>
>> "don't bother with this, just read the source"
> 
> There's actually some merit to this, anyone mind if I implement?

All kidding aside, I recently volunteered [1] to put some thought and
work into a new documentation section. I've got a few ideas floating in
my head and will be posting them on zope-web soon.

Zope docs aren't a lost cause. There's lots of stuff out there, we just
need to bring it back to zope.org (which requires a zope.org that you
can actually work with, of course).

Philipp



[1]
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_08_27_sorry-fredrik

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

[Zope] Re: Packing Data.fs

[Philipp von Weitershausen]

Duncan Booth wrote:
> Tres Seaver wrote:
> 
>> Mark Gibson wrote:
>>> I know zope makes a copy of Data.fs before packing.  Is it possible to
>>> specify a location other than /var to place that copy?
>> Actually, it makes a *new* file when packing, and then unlinks the old
>> file and re-links the copy under its name after finishing the pack
>> successfully.  If you are looking to "spread the love" across multiple
>> partitions, you can symlink the original file into a directory on
>> another drive / partition, and then do the pack there.  One the pack
>> completes, you can move or copy the packed version back to the original
>> directory.
>>
> I recently had to move a fairly large Data.fs onto a different partition, 
> but just copying it would have involved downtime (at least for 
> authoring) that I wanted to avoid. 
> 
> The solution I came up with was to create a var folder on the new partition 
> symlinking back to Data.fs in the original location. Then I switched ZEO to 
> using the var on the new partition and packed the database. After packing 
> the database was on the new partition with no downtime apart from a single 
> ZEO restart.

Nice.

I should note that DirectoryStorage (http://dirstorage.sf.net) has
excellent replication support which make things like moving live Zope
instances from one partition to another one w/o lots of downtime almost
trivial.

Philipp

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

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal

[Philipp von Weitershausen]

Andrew Milton wrote:
> +---[ Philipp von Weitershausen ]--
> |
> | > | * putting a project/package under the wings of the ZF ensures long-term
> | > | IP protection
> | > 
> | > How? I think my death + 70 years is further away than the death of ZF, or 
> in
> | > fact the death of Zope.
> | 
> | But the end of your commitment to this particular software and/or Zope
> | might not be so far. Hunting developers down for getting their approval
> | of a license change or something like that after 5 years or so would be
> | a considerable pain.
> 
> One wonders, why you NEED to change the license of someone else's code.
> You take some Open Source code. You put it in your repository where you can
> work on it. You don't need to own it to work on it. You don't need to own it
> to package it up. You don't need to own it to put it into svn.
> 
> This is of course a distraction from the main question about the
> repository, not the who owns what and why, which has been beaten to death 
> in a hundred other discussions.

So let's not further discuss a dead point :).

> | > Requiring IP Handover? Makes a mockery of the Open Source movement. 
> | 
> | Plone does it, ASF does it, FSF does it. Seems to work.
> 
> The proposal currently requires 3rd party code to be handed over to Zope
> Foundation[1] AND checked into the ZF svn repository in order to be 
> 'certified'. You indicated this was indeed the case.

I did absolutely not. In the very first email in this thread, you asked
whether the requirement for getting your package listed (or certified
for that matter) was to put the code into svn.zope.org. Here's what I
responded:

  "No. The common repository under the wings of ZC/ZF is just *a*
  repository that implements the ZSCP. There can be others, for example
  the Plone repository, the collective repository (perhaps), etc."

In fact, because of that I suggested to keep the repository proposal
separate from the ZSCP proposal, as the very same email continues:

  "I had earlier suggested to Stephan that we should keep the common
  repository separate from ZSCP and there out of this proposal. IMO
  there should be a separate proposal for the common repository. I guess
  he didn't agree."

> So in order to gain ANY level of certification, even "Listed" Zope Foundation 
> has to own the code.

Wrong.

Philipp

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

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal

[Philipp von Weitershausen]

Andrew Milton wrote:
> +---[ Philipp von Weitershausen ]--
> |
> | Handing over ownership to the ZF and therefore having signed a
> | Contributor Agreement are the terms of the svn.zope.org repository, just
> | like that code is to be made ZPL. 
> 
> The license part is irrelevant after you've signed over the IP.
> 
> | These are the rules of the repository, even today (except for s/ZF/ZC).
> 
> This is for the core product. This is not add-on code. It makes sense for the
> core product.
> 
> | If you're not happy with that, then use
> | your another repository. Nobody is forcing you to put your stuff there.
> 
> Indeed. Anyone that wants to try is welcome to come around and have a go d8)

FWIW, Martijn and I did this with the z3base (http://codespeak.net/z3).

> | Putting stuff into svn.zope.org *does* have advantages:
> | 
> | * it's easy to feed packages upstream to Zope for a later inclusion into
> | a Zope distribution.
> 
> Putting into svn isn't the same as requiring IP handover. You can still put
> things into the repository without IP handover.
> 
> | * putting a project/package under the wings of the ZF ensures long-term
> | IP protection
> 
> How? I think my death + 70 years is further away than the death of ZF, or in
> fact the death of Zope.

But the end of your commitment to this particular software and/or Zope
might not be so far. Hunting developers down for getting their approval
of a license change or something like that after 5 years or so would be
a considerable pain.

> | * code in svn.zope.org will be under the common control of the Zope
> | developers which makes long-term maintenance easier to ensure.
> 
> This has nothing to do with handing over IP either. Noone disputes that the
> Zope Developers lives will be easier if things are in a central svn. Why this
> should require someone to hand over their IP to ZF is a mystery.

I never said the advantages of putting stuff into svn.zope.org
necessarily have to have anything to do with handing over IP (actually,
it's joint-ownership so it's sharing IP).

> | * the common license (ZPL) and the common ownership of the ZF do away
> | with some legal headaches...
> 
> The ONLY legal headache common ownership does away with, is that ZC or ZF (or
> future owners) are free to change the license without asking permission of the
> original author. The license itself is irrelevant, it doesn't apply to the
> copyright holder.
> 
> IP "sharing" certainly has no advantages to the original author. Any lawsuit
> arising from some problem with the code would almost certainly name all 
> stakeholders.
> 
> Repository of 3rd party code? Great Idea.
> Packaging standards? Great Idea.
> Compliance Rating? Great Idea.
> 
> Requiring IP Handover? Makes a mockery of the Open Source movement. 

Plone does it, ASF does it, FSF does it. Seems to work. Note that with
ZC (and I presume this will continue with the ZF) it's joint-ownership,
not a total handover.

> Why should Mark Shuttleworth who has plenty of means, hand over IP for (parts 
> of) 
> SchoolTool?

Good question. Why would Zope Corporation hand over IP of Zope to the
Zope Foundation? Why would we contribute code to the Plone Foundation or
anyone else? In order to put the code under public govenance.


Anyways, you're welcome to contribute code to the z3base if you'd prefer
a public repository that doesn't require IP handover/sharing. Who knows,
perhaps we'll even manage to implement the ZSCP for some packages there :).

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

Re: [Zope] Re: The Zope Software Certification Program and Common Repository Proposal

[Philipp von Weitershausen]

Andrew Milton wrote:
> +---[ Philipp von Weitershausen ]--
> | Andrew Milton wrote:
> | > +---[ Stephan Richter ]--
> | > | Hello everyone,
> | > | 
> | > | With the development of Zope 3, the Zope developers committed to a new 
> | > | development process and higher software quality guidelines. With the 
> adoption 
> | > | of Zope 3 technologies in the wider Zope community, we should also 
> start 
> | > | using the process for third party package development.
> | > | 
> | > | I have spent the last two weeks working on a proposal that defines a 
> Zope 
> | > | Software Certification Program (ZSCP) and a Common Repository that 
> implements 
> | > | this process. The proposal is attached to this mail. I welcome any 
> comments 
> | > | about it!
> | > 
> | > So in order to even get your Open Source package LISTED, you have to sign 
> over 
> | > the rights of your code to Zope Corp (currently, Zope Foundation later), 
> and then
> | > check it into the svn respository. 
> | > 
> | > Is this is correct?
> | 
> | No. The common repository under the wings of ZC/ZF is just *a*
> | repository that implements the ZSCP. There can be others, for example
> | the Plone repository, the collective repository (perhaps), etc.
> 
> 
> The Common Repository is *not* a replacement for other high-level repositories
> like Plone's or ECM's. It does not aim at assimilating everything in the wider
> Zope community. It is merely a place for high-quality packages that are
> supported by the Zope development team.
> ^^^
> 
> Code in the Common Repository *must* also use the license stated in
> section 3.5 and developers *must* sign the contributor agreement. The
> ^
> agreement is necessary to ensure that contributions originated from the
> contributing developer.
> 
> 
> 
> a) Supported by Zope development team
> b) Must sign contributor agreement.
> 
> I don't see why a 'repository' of 3rd party packages needs any
> agreement signed, unless some kind of indemnity is required which it
> wouldn't need if it's "just a repository". Any 'infringement' would
> simply result in the offending code being removed from the repository
> (which would have to happen anyway in case someone 'lied' about
> owning it). After all the repository is not claiming ownership of the
> code is it (unless you have to sign it over)
> 
> The license for the code should also be irrelevant, since it's just a
> repository right? Just a convenient one stop shop for packages. So
> each package should be able to have its own license, no need for a
> common license.
> 
> Having to sign the agreement serves no purpose unless there's some
> other IP issue involved other than simply storing the code.

Handing over ownership to the ZF and therefore having signed a
Contributor Agreement are the terms of the svn.zope.org repository, just
like that code is to be made ZPL. These are the rules of the repository,
even today (except for s/ZF/ZC). If you're not happy with that, then use
your another repository. Nobody is forcing you to put your stuff there.

Putting stuff into svn.zope.org *does* have advantages:

* it's easy to feed packages upstream to Zope for a later inclusion into
a Zope distribution.

* putting a project/package under the wings of the ZF ensures long-term
IP protection

* code in svn.zope.org will be under the common control of the Zope
developers which makes long-term maintenance easier to ensure.

* the common license (ZPL) and the common ownership of the ZF do away
with some legal headaches...

Perhaps there are others.

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

[Zope] Re: The Zope Software Certification Program and Common Repository Proposal

[Philipp von Weitershausen]

Andrew Milton wrote:
> +---[ Stephan Richter ]--
> | Hello everyone,
> | 
> | With the development of Zope 3, the Zope developers committed to a new 
> | development process and higher software quality guidelines. With the 
> adoption 
> | of Zope 3 technologies in the wider Zope community, we should also start 
> | using the process for third party package development.
> | 
> | I have spent the last two weeks working on a proposal that defines a Zope 
> | Software Certification Program (ZSCP) and a Common Repository that 
> implements 
> | this process. The proposal is attached to this mail. I welcome any comments 
> | about it!
> 
> So in order to even get your Open Source package LISTED, you have to sign 
> over 
> the rights of your code to Zope Corp (currently, Zope Foundation later), and 
> then
> check it into the svn respository. 
> 
> Is this is correct?

No. The common repository under the wings of ZC/ZF is just *a*
repository that implements the ZSCP. There can be others, for example
the Plone repository, the collective repository (perhaps), etc.

I had earlier suggested to Stephan that we should keep the common
repository separate from ZSCP and there out of this proposal. IMO there
should be a separate proposal for the common repository. I guess he
didn't agree.

I think both the ZSCP and the common repository (in the context of the
ZF) are a great idea. We should try to have as much stuff as possible in
the common repository, but we shouldn't make the process dependent on it.

I'm therefore still suggesting to divide up the proposal.

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

[Zope] Short tutorial on I18n with Five

[Philipp von Weitershausen]

I'm happy to announce that I've finally managed to document the
internationalization (i18n) features that Five has brought to the Zope 2
world since version 1.1:

http://worldcookery.com/files/fivei18n

This short tutorial compares current Zope-2-based solutions to the i18n
problem with the Zope 3 i18n framework.  It also gives a few pointers on
how to use the latter in Zope 2 applications through the means of Five.
 It is not a full-blown tutorial and it expects the reader to be quite
familiar with i18n-aware software development in Zope already.  Target
audience is mostly people switching over their Zope 2 products to Zope 3
technology which i18n is a part of.  The tutorial also serves as a
documentation of a new Zope 2 core feature because Five 1.3 is included
in Zope 2.9 which is thus the first Zope 2 version to come with built-in
i18n support!
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )

Re: [Zope] DateTime mess

[Philipp von Weitershausen]

Lennart Regebro wrote:
> I agree, official deprecation and warnings should only happen when we
> have a real backwards compatibility and transition-path. Which would
> include what you call a "frankendatetime". :-)
> 
> Which, as I understand it, is what Jürgen Herrman wanted to create...

Not if I understand
http://article.gmane.org/gmane.comp.web.zope.general/49975 correctly.
There he says something about using datetime as a storage, but not as
the end point of a deprecation period.

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

Re: [Zope] DateTime mess

[Philipp von Weitershausen]

Chris Withers wrote:
> Philipp von Weitershausen wrote:
> 
>> I think we need Zope to use some frankendatetime (a datetime.datetime
>> that also supports the old DateTime API) throughout the deprecation
>> period. Whenever people make a call to the old DateTime API on a
>> frankendatetime object, they'll get a deprecation warning telling them
>> to use the datetime.datetime API instead. After the deprecation phase is
>> over, Zope 2 can return pure datetime.datetime objects.
> 
> 
> I don't see any need for diabolical creations ;-) Just the deprecation
> warnings will suffice.
> (...which will promptly be added to warn filters, and only fixed when
> DateTime really goes away *sigh*)

Ok, so take this example:

A piece of code calls bobobase_modification_time() which currently
returns a DateTime; after that the piece of code calls some
DateTime-specific methods on the returned object. Now in Zope 2.12 we
make bobobase_modification_time() return a datetime.datetime and
subsequently the piece of code would fail. There are a lot of pieces of
code like this in third party products...

We could deprecate DateTime now to warn people about that. But then
their product would only either work with Zope <2.12 or with Zope >2.12
(depending on whether it still expects the DateTime API or the
datetime.datetime API); it would not with both versions. That's a harsh
upgrade plan and it would probably take ages before people would adopt
Zope 2.12.

With a frankendatetime in Zope 2.10, however, they could still call
DateTime-specific methods on the return value of
bobobase_modification_time(). They'd get deprecation warnings telling
them to use the datetime.datetime API instead. That would work
instantly, not only in Zope 2.12. That way they could smoothly upgrade
their products.


By the way, I've come to think that touching the current DateTime
implementation wouldn't be a good idea, mostly because of the old
pickles issue. The frankendatetime should be a separate class that
subclasses datetime.datetime, provides old-style DateTime compatability
and has datetime.datetime-compatible pickles.

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

Re: [Zope] DateTime mess

[Philipp von Weitershausen]

Lennart Regebro wrote:
>>Datetimes are dull values, they should just pickle nicely.
> 
> They do.

Yes, that's my point. That's why we don't need added persistency.

> A module with extra utilities + timezone support would be nice.

pytz provides some extensive timezone support. Not sure what the extra
utilities are, but I don't have a lot of complicated datetime use cases
so I could be missing stuff here.

>>1. Create some extensive tests about how DateTime currently works. I'm
>>currently working on this to see whether any further procedure makes sense.
> 
> I'm not worried about how it works now. DateTime is buggy and it's
> behaviour has undergone several subtle changes, sometimes for the
> worse, without much screaming. :-)

Well, I'm not so worried about the past but about the future. I'm
currently diving into the matter by writing doctests. If we find that
DateTime and datetime.datetime are semantically incompatible, we'll have
to think up a different strategy. We'll see :).

>>2. If we find it's possible, we rid the current DateTime implementation
>>and recreate the DateTime class by subclassing datetime.datetime. For
>>backwards compatability, we make sure that old pickles can be revived
>>and that the old DateTime API is supported for two more Zope releases.
> 
> Yeah, it's that pickling revival that worries me. It's non-trivial.

I agree.

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

Re: [Zope] DateTime mess

[Philipp von Weitershausen]

Andrew Milton wrote:
> +---[ Philipp von Weitershausen ]--
> 
> | 2. If we find it's possible, we rid the current DateTime implementation
> | and recreate the DateTime class by subclassing datetime.datetime. For
> | backwards compatability, we make sure that old pickles can be revived
> | and that the old DateTime API is supported for two more Zope releases.
> | 
> | 3. After two releases we get rid of the old DateTime API and will
> | provide a script to migrate old DateTime pickles to datetime.datetime
> | pickles in the ZODB.
> 
> -1 for any scheme that deliberately breaks currently working code / installs.

Agreed. Deprecation is a way of deliberately killing you softly :).
Seriously, there's no going forward without getting rid of stuff.
Deprecation is a good way of dealing with getting rid of stuff without
having currently working code broken instantly.

> -1 for any scheme that involves diddling the ZODB to 'fix' pickles, because
>you just know you're going to corrupt someone's ZODB, and that's just
>noone's idea of fun.

There are sensible ways of upgrading the ZODB. Zope 3 has had it since
3.0 (called generations) and they've been working reasonably well for
these things.

> Didn't see any mention of fixing ZClasses (not sure if that's an issue).

I'm not sure it is either, but this would be something to be discussed
in the proposal discussion process, I guess. But now that you've
mentioned it, I will investigate and possibly include notions in the
proposal.

> I'm the first in line of the people wanting Zope DateTime to die. However, you
> need to leave it there. Fix Zope to internally use something different, and
> provide a new implementation that 'sensible' people can use going forwards.

I don't think that'll work. I've thought about just letting DateTime die
and switch to datetime.datetime over completely. However, code that
expects Zope to return DateTime-compatible objects would break.

I think we need Zope to use some frankendatetime (a datetime.datetime
that also supports the old DateTime API) throughout the deprecation
period. Whenever people make a call to the old DateTime API on a
frankendatetime object, they'll get a deprecation warning telling them
to use the datetime.datetime API instead. After the deprecation phase is
over, Zope 2 can return pure datetime.datetime objects.

By the way, this is really not a thread for zope@zope.org but for
[EMAIL PROTECTED] From the beginning, actually. I suggest we move all
further discussion there.

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

Re: [Zope] DateTime mess

[Philipp von Weitershausen]

Chris Withers wrote:
> Andreas Jung wrote:
> 
>>
>> I agree that is should be replaced but I also mentioned that we tried
>> to achieve that already some years ago and we gave upso talking
>> about deprecation really makes sense when someone puts a replacement
>> module on the table. I know that the DateTime module is a piece of
>> crap but crap you can live mostly with (as long as you don't need
>> timezones :-)).
> 
> 
> Okay, well, I'd advocate replacement with a zope.datetime that
> subclasses python's datetime, mixes in persistence and provides some of
> the extra helper methods.
> 
> What do people think?
> 
> cheers,
> 
> Chris
> 
> (CC'ing Phillip 'cos I saw him doing some Zope 3'ish DateTime stuff...)

Hey Chris, hey Hermann, hey others,

I've secretly being working on some evil plans to make DateTime more
understandable so that we can work out a migration strategy. In my
strong opinion, Zope should not maintain its own date/time
implementation and I don't even see the need for a zope.datetime like
Chris suggests. Why does it need to be persistent? Datetimes are dull
values, they should just pickle nicely. If someone needs more than
datetime.datetime and pytz, I would be very interested in their usecase...

Anyway, my long-term plans are roughly this:

1. Create some extensive tests about how DateTime currently works. I'm
currently working on this to see whether any further procedure makes sense.

2. If we find it's possible, we rid the current DateTime implementation
and recreate the DateTime class by subclassing datetime.datetime. For
backwards compatability, we make sure that old pickles can be revived
and that the old DateTime API is supported for two more Zope releases.

3. After two releases we get rid of the old DateTime API and will
provide a script to migrate old DateTime pickles to datetime.datetime
pickles in the ZODB.

I have a proposal for this in works, but you guys made me blurt it out
prematurely :).

By the way, I only skimmed over this thread, but I haven't actually
found anywhere explained what Hermann's problem with strftime was and a
detailed suggestion on how his "rewrite" would take place... Maybe it'd
be a good idea to adopt the proposal process we have for Zope 3.

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

[Zope] New mailinglist for Zope 3 translators

[Philipp von Weitershausen]

Hello all,

[Sorry for the cross-post, please CC replies to [EMAIL PROTECTED] only.]

two months ago, I started an initiative [1] to translate Zope 3.1 using
Ubuntu's Launchpad system [2]. Since then, I've received a lot of emails
from numerous volunteers around the world and many of them made some
excellent progress [3]. Thanks to everyone who contributed so far.

A new mailinglist at [EMAIL PROTECTED] will now help translators and
developers like me to coordinate their work. For example, all those
translations will have to be integrated back into the Zope 3.1
repository at some point which has to be coordinated somehow. Also,
translators themselves will want to coordinate the work among them. The
mailinglist will serve as a forum for discussing and coordinating things
like that.

So, if you're involved into Zope 3 translations OR if you would like to
contribute something to Zope 3 by helping to translate it into your
language, please subscribe to the new list [4]. If you have any
questions, feel free to email me or even better the new list.

Best regards

Philipp


[1] http://mail.zope.org/pipermail/zope3-dev/2005-August/015113.html
[2] https://launchpad.net
[3] https://launchpad.net/products/zope/+series/zope3.1/+pots/zope
[4] http://mail.zope.org/mailman/listinfo/zope3-i18n

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

[Zope] Re: MVC Approach

[Philipp von Weitershausen]

Thomas Adams wrote:
> Hi all,
> 
> I'm a newbie to Zope, using version 2.7.3 (okay it is not the newest one)
> and I want to know if there is something
> like a MVC approach available for Zope, i.e. Model-View-Controller
> approach, as it is for instance in Java with  the Struts framework from
> Apache.
> 
...
> 
> P.S: I don't know Zope 3 (Is that apossible answer of my questions?)

Yes, Zope 3 has a MVC-like architecture. We call it the Component
Architecture. It lets you separate responsibilities into different
components (objects), e.g. content objects (they can be persistent, for
example, or come from an RDBMS), views (e.g. browser views that produce
HTML), adapters (enhance components with functionality), and utilities.

For a structured introduction, see
http://dev.zope.org/Zope3/ProgrammerTutorial or http://worldcookery.com.

It is also possible to use Zope 3 style components in Zope 2 already, by
using the Five product: http://codespeak.net/z3/five/. However, if you
don't have any Zope 2 legacy, I can only recommend you start with Zope 3
from the beginning.

Best regards,

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

[Zope] Re: working with urls

[Philipp von Weitershausen]

Nicholas Wieland wrote:
First of all thanks everyone for the help, I've resolved my problems one 
after the other thanks to the suggestions I've found here.
 
Now I'm rewriting urls by substituting the href attribute with custom 
data, and everything works fine.
What I'd like is having an url like: myproduct/generate/20050301/PG2, 
and actually that's exactly what I've got. This url will make my app 
generate a pdf report for the ref_date 2005/03/01 and code PG2 (ref_date 
and code are internal data).
Zope obviously maps the url as an object, but that's not what I want: I 
want to parse the url and use the ref_date and code data inside a 
generate method.


You want to write a __bobo_traverse__ method for your class:

def __bobo_traverse__(self, REQUEST, name):
# do something with 'name' here.
return an_object_that_is_to_be_published

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

http://mail.zope.org/mailman/listinfo/zope-dev )