On Jul 7, 2009, at 5:15 PM, Fabio Tranchitella wrote:
Hello,
I would like to break the dep cycle between zope.container and
zope.filerepresentation. I already prepared the two patches
(attached to
this e-mail), but I'm not confident enough with the zope3 repository
to
check in them
Hi Gerhard
Betreff: [Zope-dev] z3c.form pass context to multi widgets in
MultiConverter
Hi,
some widgets may require a valid context to work properly.
one such widget is z3c.formquery.
The attached patch passes the current widget's context to the
sub widgets during data conversion
Hi Roger,
Roger Ineichen wrote:
Hi Gerhard
Betreff: [Zope-dev] z3c.form pass context to multi widgets in
MultiConverter
Hi,
some widgets may require a valid context to work properly.
one such widget is z3c.formquery.
The attached patch passes the current widget's context to the
Hello,
* 2009-07-08 12:51, Jim Fulton wrote:
I find it a bit hard to believe that there are no clients of these
interfaces, but, if that's the case, I suggest deprecating
zope.filerepresentation and zope.container.directory. In that case, I'd
just remove the dependency in zope.container on
Hi Gerhard
Betreff: Re: AW: [Zope-dev] z3c.form pass context to multi
widgets in MultiConverter
[...]
If this makes sense, the patch should probably do soemthing like:
if not widget.ignoreContext
widget.context = widget.form.context
This whould prevent to set an ignored
On Jul 8, 2009, at 8:21 AM, Fabio Tranchitella wrote:
Hello,
* 2009-07-08 12:51, Jim Fulton wrote:
I find it a bit hard to believe that there are no clients of these
interfaces, but, if that's the case, I suggest deprecating
zope.filerepresentation and zope.container.directory. In that
Hi,
I'am just playing with repoze.bfg in google appengine (gae) and stumbled
over zope.proxy. I tried to use zodict.node.Node which depends on
zope.location. zope.location depends on zope.proxy. Latter has mandatory
C-extensions.
Are there any plans to get rid of them as a fallback for those
Hello,
I just committed the removal of the dependency from zope.filerepresentation
to zope.container, breaking the dependency cycle.
* 2009-07-08 15:13, Jim Fulton wrote:
Sure, but if they want to *use* zope.container.directory, they have to
separately import
Hi Roger,
Roger Ineichen wrote:
I'm really not sure if this is working, but does this make
sense to you?
Regards
Roger Ineichen
Thanks for the comment. For this particular use case it won't
work without the context,. The context is used to look up
further
Hello,
I'd like to release some packages with fixed/improved dependencies:
- zope.location
- zope.sendmail
- zope.pagetemplate
- zope.app.publisher
- zope.filerepresentation
These packages are already ok in the repository, but I don't have the rights to
do the upload to pypi. Can
On Jul 8, 2009, at 4:19 PM, Fabio Tranchitella wrote:
Hello,
I'd like to release some packages with fixed/improved dependencies:
- zope.location
- zope.sendmail
- zope.pagetemplate
- zope.app.publisher
- zope.filerepresentation
These packages are already ok in the repository, but
Hello,
I'm sorry if I am flooding the list with all my requests/messages, but I
don't want to introduce changes without approval of more experienced zope
developers.
I was analyzing zope.app.publisher, and I found that it would be possible
to remove its dependency on zope.container because the
12 matches
Mail list logo
