Marius Gedminas wrote:
On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote:
Why does the caller care? She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context. If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning a
gh I might quibble that "adapt()" would be better spelled
"utility()", there is a nice symmetry about your idea.
- Both patterns make it explicit to anyone reading the code when a
default value is being passed, which should vastly reduce surprise.
+1
- Mine feels more n
Dear form-framework experts/users,
Yesterday I applied the first time an editform to a schema containing a
'List' field of value_type 'Choice'.
The OrderedMultiSelectWidget is invoked by default. At the first glance
it works fine but by and by I discovered the following bugs/missfeatures:
- Does
Hi Gary
Thanks for your inputs. I was also offline this days...
Gary Poster wrote:
[...]
Well, first of all, I suspect your situation, based on what I've seen
so far, looks something like this:
- code creates obj P1
- code puts P1 in intids, with connection.
- code does something incorrect (e
Gary Poster wrote:
I object. :-)
Thanks for the feedback!
First, your change effectively adds _database_name to an unspoken
interface for persistent IKeyReferences. That's not a good idea.
Yup, I did not respect that point.
Second, the error you are getting is an error condition and should be
Hi,
Today I got a weird error caused by the __cmp__ method of
KeyReferenceToPersistent. Unfortunately I couldn't setup a dedicated
environment to reproduce the error within a test :(. The only evidence
is this traceback:
Traceback (most recent call last):
File "E:\workspace\bopp.ms\src\pers
Hi Pete
I'm very interested in that subject but I can't find any time at the
moment. We have planned to use the ZSI to embed OPC-DAXML-Server in a
customer-application based on Zope 3. So maybe I can give you some
feedback in one or two month but I have to establish the essential know
how fir
Excuse my abscence. I'm a little busy and cannot find the time to track
the list daily.
Small summary of zope.generic:
it's a not-yet-fully-implemented, experimental prototype trying to find
a high-level-usage pattern or framework for zope 3.
During the easter-sprint I decided to put the code
luis wrote:
Jean-Marc Orliaguet wrote:
luis wrote:
are you sure? I tried with:
[EMAIL PROTECTED] ~/Zope3/src $ python2.4
Python 2.4.2 (#1, Dec 4 2005, 15:28:38)
Type "help", "copyright", "credits" or "license" for more information.
>>> from zope.app.file import file
>>> f = file.File()
Lennart Regebro wrote:
On 3/20/06, Tres Seaver <[EMAIL PROTECTED]> wrote:
[...]
This doens't really make the number of statements smaller, and it
doesn't save very many lines of ZCML. But it *does* make it pretty
darn obvious what to do. Because you can't do much else.
Note again that this is no
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
Dominik Huber wrote:
I really appreciate your effort in all other cases, but in this case I
think its not a simplification.
At least in case of class/implements it is. I&#
n Weitershausen wrote:
Dominik Huber wrote:
Philipp von Weitershausen wrote:
* class/implements and class/factory weren't removed -- yet. I guess
removing these might be a bit controversial. I'd therefore like to take
this opportunity to bring this topic up again and to give everyon
Philipp von Weitershausen wrote:
* class/implements and class/factory weren't removed -- yet. I guess
removing these might be a bit controversial. I'd therefore like to take
this opportunity to bring this topic up again and to give everyone a
chance to look at the proposal once again, before I st
Benji York wrote:
Dominik Huber wrote:
We came up with the same solution first. But our problem appears
within the following use case.
A few developers are sharing code on application level (not package
level!) for different dedicated customer projects. They have problems
to setup
Stephan Richter wrote:
On Wednesday 22 February 2006 10:58, Dominik Huber wrote:
Do you have an other solutions for this problem?
Honestly, I had not thought about this case, but it is clearly a valid use
case.
What about this structure?
repos/main/
NAMESPACE/
branches
Stephan Richter wrote:
[...]
3.2. Layout
~~~
Packages in the Common Repository *must* have the following layout:
repos/main/.
branches/
tags/
trunk/
... setup files ...
src/
/
/
... code ...
zscp/ [optional]
ZSCP.cfg
Philipp von Weitershausen wrote:
[...]
I would vote to leave at least the class/factory and class/implements
subdirectives.
The class/implements subdirective is debatable because putting an
interface on a class might be considered some sort of policy. So I don't
feel too strong about it.
Th
Philipp von Weitershausen wrote:
Now that this proposal has been dealt with, I will turn my focus of
attention to
http://dev.zope.org/Zope3/ReducingTheAmountOfZCMLDirectives. Since my
initial announcement of the proposal I made some minor ammendments
regarding the 'content' directive. Please chec
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
One issue with subscribers currently is that ZCML subscriber directives
can't be overridden. We need a fix for this.
In my understanding this usecase is covered by the new
implementation, isn't it?
What new implementat
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from "provide" to
"register"
as "unprovide" doesn't make sense. (This also conglicts less with
existing APIs.)
I like the new wording. Do y
Jim Fulton wrote:
One issue with subscribers currently is that ZCML subscriber directives
can't be overridden. We need a fix for this.
In my understanding this usecase is covered by the new implementation,
isn't it?
Regards,
Dominik
___
Zope3-de
Jim Fulton wrote:
I've updated the proposed APIs. I changed wording from "provide" to
"register"
as "unprovide" doesn't make sense. (This also conglicts less with
existing APIs.)
I like the new wording. Do you offer the new wording within the zapi
too? That would be cool.
zapi.registerAdap
Adam Groszer wrote:
Hello,
I had some time to finalize the widgets overview.
You can download it from here in various formats:
http://www.zope.org/Members/adamg/widget
thanks, super!
dominik
--
Dominik Huber
Perse Engineering GmbH
Jurastrasse 9a
CH-5406 Baden
E-Mail
Stephan Richter wrote:
On Thursday 02 February 2006 07:38, Jim Fulton wrote:
Comments and questions are welcome.
I like the proposal in general. The big missing use case that is missing for
me is the task of unregistering or reregistering a persistent component.
I like the proposal
Gary Poster wrote:
I'm pretty sure there's a proposal on the wiki somewhere with Jim's
full lookup algorithm that you want, but the iro for the pertinent
object(s) usually gets me far enough.
That might be the proposal you mentioned
http://dev.zope.org/Zope3/ComponentArchitectureSimplifica
Steve Alexander wrote:
Who will use these interfaces? In what parts of the code will they be
present?
I think these marker interfaces are used only in infrastructure code to
do with setting up layers and skins. In this case, they will not be
typed often, and will not even be read often. So,
Philipp von Weitershausen wrote:
(http://dev.zope.org/Zope3/SimplifySkinning) yet another overhaul.
Basically, it now proposes to go one step further: Layers and skins will always
be simple
interfaces extending IBrowserRequest. The only difference between skins and
layers is
that only skins a
Philipp von Weitershausen wrote:
Thanks for the input so far, please revise it and let me know if
you see any other issues.
+1 I like it. Thank you!
Your connotation assertion here is incorrect. The default layer stands for:
"If the browser directive did not specify a layer, use the defau
tions/zope3-dev/dominik.huber%40perse.ch
--
Dominik Huber
Perse Engineering GmbH
Jurastrasse 9a
CH-5406 Baden
E-Mail: [EMAIL PROTECTED]
Telefon: ++41 56 534 7730
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-
Phillip's Proposal:
Furthermore, I propose to remove the |IDefaultLayer| interface. We've
been using the |default| layer as a connotation of "always being
available unless overridden by a more specific layer." However, this
does not apply all the time: When the |default| layer is not included i
Andres Freund wrote:
Hi,
I'm working with the combination of Zope3 and sqlobjet over sqlos and
discovered a problem (about SecurityProxy as i already asked about in
#zope3-dev).
Some code in sqlobject is using isinstance() to decide what to do. The
problem is, that sometimes sqlobject gets
Florent Guillaume wrote:
Excuse my insistence, but the only thing I *added* was a modification
event when you reorder the children of an ordered container. Before
attacking it, please undestand what I checked in.
Excuse the confusion of my mail. I was to tired yesterday. I try it
another
Florent Guillaume wrote:
On 28 Nov 2005, at 19:30, Dominik Huber wrote:
Florent,
But at least the event notifications within the setitem function is
kind of redundant.
An add-, move- and remove- event is a part of the container
framework. Therefore we can assume that the underlying
Florent,
But at least the event notifications within the setitem function is kind
of redundant.
An add-, move- and remove- event is a part of the container framework.
Therefore we can assume that the underlying container referenced by the
event.object.__parent__ has changed too.
file: zope.ap
Florent Guillaume wrote:
Dominik Huber wrote:
The modification descriptiors were introduced by Uwe Ostermeier to
handle the versioning and cataloging stuff. I'm not an expert in that
field, but in my understanding the modification descriptors are more
general and your case is a subset
Florent Guillaume wrote:
I didn't follow Dominik's suggestion of using IModificationDescription
because I feel this a case sufficiently fundamental that we really
want a subclass.
Excuse my intervention...
The modification descriptiors were introduced by Uwe Ostermeier to
handle the version
Florent Guillaume wrote:
I'd like to do a few simple fixes to events in Zope 3.2 before it's
too late:
- Add the source to IObjectCopiedEvent, per
http://www.zope.org/Collectors/Zope3-dev/478
I believe I received a +1 on this
- Make OrderedContainer.updateOrder send an IObjectModifiedEvent.
Philipp von Weitershausen wrote:
Stephan Richter wrote:
I will always vote -1 on such a move. I just simply punishes all those early
adopters of Zope 3 and throw it in their face. Great appreciation!
You know I can turn this around and say that by focusing all development on
Zope 3, t
Philipp von Weitershausen wrote:
Really, I'm quite tired of trench wars like Zope 2 vs. Zope 3. Like Martijn
said, we need
to come together, not apart. I'm starting to get the feeling that some Zope 3
developers
rather see Zope 2 die than embrace some of its experience and community.
At th
Stephan Richter wrote:
This may raise the contribution bar too high.
IMO that 's the most important point.
I' m -1, too.
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30
x-mozilla-html:FALSE
version:2.1
end:vcard
Martijn Faassen wrote:
I don't think using any of these patterns is a big style problem (I'm
much less opinionated about this than about code in __init__.py); it's
hard to recommend a single practice, so perhaps we shouldn't.
+1
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
Johan Carlsson wrote:
Dominik Huber wrote:
Johan Carlsson wrote:
Anywhere I can read up on what's happening with this issue/bug?
- The class attribute of the widget-directive can handle a custom
factory or a widget class.
- The __call__ method of custom widget fa
Johan Carlsson wrote:
Anywhere I can read up on what's happening with this issue/bug?
- The class attribute of the widget-directive can handle a custom
factory or a widget class.
- The __call__ method of custom widget factory
(zope.app.form.CustomWidgetFactory)
invokes collection, choice a
Jean-Marc Orliaguet wrote:
OK, so to summarize this thread:
- __init__.py files are empty
One ore two years ago garett raised a similar issue too. IMO (Excuse me,
I could not find the mail) then we decided to import the interfaces.py
within __init__.py: from interfaces import *
Regards,
Johan Carlsson wrote:
Anywhere I can read up on what's happening with this issue/bug?
Regards,
Johan
NotYetError ;)
I have to dig into the subject this weekend, but I have to sort the
partial solutions first.
Dominik
begin:vcard
fn:Dominik Huber
n:Huber;Dominik
email;internet:[EMAIL PROTECTE
Hi Adam
DH> Are you fixing issue 451? Otherwise, I could do it this weekend.
Anyway I can't do it directly, because I don't have SVN access.
I think I'll sit here, so if you need any help...
Thanks for your inputs! I will do that this weekend.
Regards,
Dominik
begin:vcard
fn:Dominik Huber
n:
Adam Groszer wrote:
As I'm digging through zope.app.form.browser to fix the
CustomWidgetFactory collector issue, I found the following:
IWidget has no __init__ defined
class Widget(object):
def __init__(self, context, request):
class ItemsWidgetBase(TranslationHook, SimpleInputWidget):
f __init__(self):
SampleContainer.__init__(self)
sm = LocalSiteManager(self)
self.setSiteManager(sm)
...
ensureUtility(self, IWorkflowUtility,
'WorkflowUtility', WorkflowUtilit
self)
sm = LocalSiteManager(self)
self.setSiteManager(sm)
...
ensureUtility(self, IWorkflowUtility,
'WorkflowUtility', WorkflowUtility, 'wfu')
--
Dominik H
Martijn Faassen wrote:
Hey,
Martijn Faassen wrote:
Would there be any interest in merging hurry.query into Zope 3.2?
Apparently not, or at least people are lacking in time, which is
understandable as I do too. :) I'll try in more advance for Zope 3.3.
We find it very useful here at Infra
Gary Poster wrote:
...
and to sketch the difference between widgets and viewlets out.
The zope.widget package in the branch is currently in disrepair, but
the intent is for widgets to be subviews. The subview package
actually grew out of the widget work. This won't be ready for 3.2.
Hi Stephan,
I just looked at the examples. I like the current implementation much
more, because a viewlet is adapted to its original context (-> complex
example) and content providers (or viewlet managers) can render itself.
Those changes are providing a better encapsulation and a more ca-like
Stephan Richter wrote:
On Tuesday 11 October 2005 12:41, Philipp von Weitershausen wrote:
If anyone here really needs WYSIWYG, please make a point, but I doubt that
there will be one...
It's a top priority for Jim. Uwe and I agreed we would prefer ReST.
I would definitely prefer R
Hi Alec
Your derivative of principalfolder is a local authentication. Therefore it can
be only invoked if a location can be computed and the pricipalfolder can be
found starting from it.
Content objects are regularly locatable but adapters not. To force locations to
adapters you can derive th
Jim Fulton wrote:
A change in style, if applied everywhere can lead to massive
code changes. This can have serious downsides. If people
are working on branches, where most new work should be done,
then merging is made more difficult. People who read the checkins
have a lot of extra code to r
Excuse my delay, I was out of office last week...
A month ago, I got an error while using a sequence widget factory
referenced by the widget subdirective of an editform. I used the
zope.app.form package of philips branch and that solved my problem:
svn+ssh://svnzope/repos/main/Zope3/branches/p
Adam Groszer wrote:
I'm having problems with using .
I have an interface:
class ISzerep(Interface):
name = TextLine(
title=u"Szerep nev",
description=u"Szerep nev",
required=True
)
szemelyek = List(
title=u"Hozzarendelt szemelyek",
description=u"H
Florent Guillaume wrote:
Does it work to just set __parent__ to the container? Or does the
zopesecuritypolicy require more accurate context?
Yes, the unset location is the problem, why the local security cannot
be looked up.
Martijn Faassen wrote:
Benji York wrote:
Martijn Faassen wrot
Velko Ivanov wrote:
Dominik Huber wrote:
Provide ILocation by those adapters, use the
'locatalbe' attribute of the adapter directive (-> location proxied)
or set the permission explicitly to zope.Public.
Thanks for the reply
PsycopgAdapter inherits ZopeDatabaseAdapter, w
Velko Ivanov wrote:
My bigger problem is that when I grant zope.Manager to an user in the
principals folder, it somehow doesn't get all permitions. I can still
manage the site and do everything, except use DA connections
(psycopgDA ones to be specific, I didn't check Gadfly), which require
zo
Julien Anguenot wrote:
Is it supposed to work with the double \ ('\\') on windows ?
The error reported was different on this issue but seems to be related
though.
I don't know. I never used it with double '\' before.
Dominik
___
Zope3-dev mailin
Julien Anguenot wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Could someone try to launch the tests with a Zope3 checkout under
Windows this way ? :
$ python bin/test -vpu --dir src\\zope\\
E:\dev\zope3_trunk>python test -vpu --dir src\\zope\\
Configuration file found.
Runnin
Garanin Michael wrote:
Ok, but my setup code very like your code with little difference:
- your code: default[folder_name] = utility
- my code: site[folder_name] = utility (my question: is it legal?)
As result i have url "MySite/PAU/USERS" instead
"MySite/++etc++site/default/PAU/USERS". And it
Garanin Michael wrote:
Hello!
My app setup code do follow step:
1) create simple AppSite (as ISite) in top
2) create local-utility object,
for example PAU = PluggableAuthentication()
3) AppSite['PAU'] = PAU
4) registrati
Philipp von Weitershausen wrote:
Actually, I'm not entirely satisfied with the implementation yet. It
still doesn't work sufficiently with subwidgets of sequence widgets.
I'm not sure if I use the sequence widgets correctly. Two days ago I
used the sequence widget the second time (The first t
Cool, thanks!
Philipp von Weitershausen wrote:
I have implemented these changes on a branch because they break API
backward compabatility on CustomSequenceWidgetFactory. Before I merge
these changes, I would like to hear your comments, especially from
people who are heavily involved into form
Florent Guillaume wrote:
Log message for revision 30706:
Revert changes to IIntIdsSet interface.
Could you expand a bit in the checkin message on the motivations behind
your changes?
I discussed with Jim a problem raised by the intid utility during
registration of objects that can not
way for a first impression would be copying the whole
tiks package to
/X3-3.0.0/lib/python/tiks
and all its package includes
(svn://svn.tiks.org/repos/Tiks/trunk/package-includes-tiks)
to /X3-3.0.0/instance/etc/package-includes
regards,
Dominik Huber
(p.s. attention their is a bug using the fs direc
with the name 'xy'
- switch to the content area
- add file system directory manager (FS Directory Manager)
select directory 'xy'
- you can add and remove new files and directories
regards,
Dominik Huber
___
Zope3-dev mailing
Jim Fulton wrote:
I already raised the question what the precedence should be if the
OK, I'll anser that. If a permission is used in an adapter directive,
it takes precedence over declarations made in a class directive.
(In the future, I'd like to change the way security declarations work
so that
I would like to add an additional 'content_factory_id' attribute to the
addform- addwizard directive in order that utility based factories can
be invoked within the adding view. See diff for details.
Any objections?
Regards,
Dominik Huber
Index: metadir
(This mail seems to be lost some where so I take another try.)
Hi Jim,
I cleaned up the locatableadapters-branch, but I did not implement an
additonal locate attribute to the adapter directive yet, because it's
pretty tricky to separate trusted-ness from location-ness.
I already raised the questi
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
...
Here are 2 other alternatives to consider:
1. Add a "locate" option to the adapter directive, which
defaults to false. If true (locate="1"), then a location
proxy is always added to the adapter.
Yup.
-1 That
Jim Fulton wrote:
So at the moment I do not see any another possibility to set those
permissions than using an additional
All 'bugs' related to this issue (that I'm aware of) including the
zwiki-bug that was reported uses the above pattern and breaks.
The reason for my branch was to solve this
Stephan Richter wrote:
On Monday 25 April 2005 10:52, Roger Ineichen wrote:
The alphabtice order of configure.zcml like Stephan proposed
is one solution. But I like a more explicit solution for this
like Dominik proposed with a additional application level
for 3rd party packages.
I did not
Shane Hathaway wrote:
Dominik Huber wrote:
We should have an application/framework-level hook within the site.zcml
that is processed before *-configure.zcml are invoked.
Problem: A framework package 'b.x' registers a dedicated menu 'b_views'.
A package 'a.x'
Stephan Richter wrote:
On Monday 25 April 2005 09:03, Dominik Huber wrote:
Problem: A framework package 'b.x' registers a dedicated menu 'b_views'.
A package 'a.x' using 'b.x' should be able to register menu items
refering 'b_views'. The initi
Stephan Richter wrote:
IMO multi-typed interfaces would make sense. Would you have any
objections if I change the code the following way:
module: zope.app.component.interface.py, line 78
75if iface_type is not None:
76if not iface_type.extends(IInterface):
77raise TypeError(
We should have an application/framework-level hook within the site.zcml
that is processed before *-configure.zcml are invoked.
Problem: A framework package 'b.x' registers a dedicated menu 'b_views'.
A package 'a.x' using 'b.x' should be able to register menu items
refering 'b_views'. The initi
Hi Stephan,
Is there a specific reason why only one interface type is directly
provided per interface?
If two types are registered for one interface the first type is chucked
out of the interface during the registration of the second,
but the first stays still registered within the utitlity servi
addendum...
I tried to implement your solution [Revision 30053], but then I
noticed the following problems:
1. no permission (None) and zope.Public within a trusted adapter
registration provokes different behavior (example below
KeyReferenceToPersistent)
2. the zwiki bug and my related impleme
Jim Fulton wrote:
It is not generally the case that you need to use separate security
declarations with trusted adapters.
I declare those additional class directive all the time if I'm
using trusted adapters.
IMO this kind of registration is the common pattern
For example stephan richter uses thi
Jim Fulton wrote:
It is not generally the case that you need to use separate security
declarations with trusted adapters.
I declare those additional class directive all the time if I'm using
trusted adapters.
IMO this kind of registration is the common pattern
For example stephan richter uses thi
Jim Fulton wrote:
Dominik Huber wrote:
Excuse me late response I was busy that weekend...
Jim Fulton wrote:
I fixed that issue within the branch
'Zope3/branches/dominik-locatableadapters'
Jim, could you take a look at that please. Thank you very much in
advance!
[...]
We should *onl
Excuse me late response I was busy that weekend...
Jim Fulton wrote:
I fixed that issue within the branch
'Zope3/branches/dominik-locatableadapters'
Jim, could you take a look at that please. Thank you very much in
advance!
[...]
We should *only* add the location if the adapter requires a permis
Jim Fulton wrote:
Dominik Huber wrote:
Jim Fulton wrote:
OK, here's an alternate proposal:
If the permission attribute is used in the adapter directive and the
permission is not zope.Public, then:
If the adapter doesn't provide ILocation, we location proxy it and
set the pare
nd that is leading to
this failure.
Temporary workaround: zwiki\wikipage.py line 73, derive
WikiPageHierarchyAdapter from Location
from zope.app.location import Location
class WikiPageHierarchyAdapter(Location):
...
We' ve planed to fix that problem correctly:
http://mail.zope
Jim Fulton wrote:
OK, here's an alternate proposal:
If the permission attribute is used in the adapter directive and the
permission is not zope.Public, then:
If the adapter doesn't provide ILocation, we location proxy it and
set the parent.
If the adapter does provide ILocation and
Jim Fulton wrote:
Whether something is trusted or not is an implementation decision of the
adapter.
Yup.
But if developer 'A' writes a framework such as the form framework, he
does not implement the adapter himself. The adapters are implemented by
others within different application for example d
Dominik Huber wrote:
Summary:
--
I try to collect + and -:
location helper function:
+ Performance: We don't have to build location proxies all the time
+ Explicitness: Excplicit in relation to the location issue after
adaption
0 Developer: Have to be aware of the location issue
ass
Jim Fulton wrote:
- 1
It might be a trap too, because developers must be aware of the
pretty implicit differnces between trusted and unstrusted adapters.
We just need to make this explicit.
We already "implicitly" set __parent__ in the trusted adapter
factory. I suggest we make this explicit. If
Jim Fulton wrote:
Here's an alternate proposal:
Let's put the proxying in the trusted adapter factory.
Let's make the trusted adapter factory add the proxy
if the adapter doesn't set ILocation. Then the form code
stays clean and other code will benefit. This would become
part of the definition of
change?
If yes, where should I place this test for best (dependencies)
Regards,
Dominik Huber
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Jim Fulton wrote:
Dominik Huber wrote:
A few months ago the following code block was removed in editview.py,
editwizard.py and schemadisplay.py (revision 29418):
def _setUpWidgets(self):
adapted = self.schema(self.context)
if adapted is not self.context:
if not
licit adapts and implements informations.
- A regular schema does not extend ILocation therefore it is not obvious to
write an adapter implementing ILocation.
Any objections?
Regards,
Dominik Huber
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub:
95 matches
Mail list logo
