Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
Hi,
I doesn't understand the motivation behind this change and I've the
feeling that it'll break some existing code
May be am I wrong but ``getContent`` method is used to provides values
to widgets and actions as described into the interface: '''Return the
content to be displayed and/or edited.''' Why do you want to give the
content to the subform. Providing the wright content according to its
definition is under the subform responsability.
If not overrided, it's true that ``getContent`` return by default the
context. But for me the fact that you give the result of a call to
getContent as context for groupForm will break the following code:
Class IAddress(Interface):
street = zope.schema.TextLine(
title='street')
Class IPerson(Interface);
firstname = zope.schema.TextLine(
title='firstname')
address = zope.schema.Object(
title='address',
schema = IAddress)
class Address(object):
implements(IAddress)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class Person(object):
implements(IPerson)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
return {
'owner': self.context.firstname,
'street': self.context.address.street}
class PersonGroup(group.Group):
label = 'Person'
fields += field.Fields(IPerson).select('firstname')
class PersonEditForm(group.GroupForm, form.EditForm):
fields = field.Fields(zope.schema.TextLine(
__name__=description',
title='Description',
readOnly=True)
groups = (PersonGroup, AddressGroup)
def getContent(self):
return {'description': 'Form used to edit a person and its
Address'}
person = Person(firstname='fName', address=Address(street='street'))
request = testing.TestRequest()
edit = PersonEditForm(person, request)
Before the changes the previous 'not tested' code worked as expected.
Since you give the result of getContent when instantiating the SubForms,
This code is now broken and I've to modify the getContent method on each
subfoms to take the context on the parentForm pointer.
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
return {
'owner': self.parentForm.context.firstname,
'street': self.parentform.context.address.street}
As I've said, may be am I wrong but I've the feeling that using the
``getContent`` as context for a subform introduce a mismatch between the
2 concepts behind ``context`` and ``getContent`` and can break existing
code.
The same result can be achieved, by explicitly instantiating the
subforms into the parentForm constructor.
class MyEditForm(group.GroupForm, form.EditForm):
def __init__(self, context, request):
super(MyEditForm, self).__init__(context, request)
firstContext = {}
secondContext = {}
self.groups = (
MyFirstGroup(firstcontext, request, self),
MySecondGroup(secondContext, request, self))
Regards,
sagblmi
Michael Howitz wrote:
Log message for revision 108077:
``GroupForm`` and ``Group`` now use ``getContent`` method when
instantiating group classes instead of directly accessing ``self.context``,
as this is the usual way to access the context of the form and allows nested
groups to have a different context than the main form.
Changed:
U z3c.form/trunk/CHANGES.txt
U z3c.form/trunk/src/z3c/form/group.py
-=-
Modified: z3c.form/trunk/CHANGES.txt
===
--- z3c.form/trunk/CHANGES.txt2010-01-12 16:55:11 UTC (rev 108076)
+++ z3c.form/trunk/CHANGES.txt2010-01-12 17:33:51 UTC (rev 108077)
@@ -5,7 +5,9 @@
2.3.1 (unreleased)
--
-- Nothing changed yet.
+- ``GroupForm`` and ``Group`` now use ``getContent`` method when
+ instantiating group classes instead of directly accessing
+ ``self.context``.
2.3.0 (2009-12-28)
Modified: z3c.form/trunk/src/z3c/form/group.py
===
--- z3c.form/trunk/src/z3c/form/group.py 2010-01-12 16:55:11 UTC (rev
108076)
+++ z3c.form/trunk/src/z3c/form/group.py 2010-01-12 17:33:51 UTC (rev
108077)
@@ -52,7 +52,7 @@
if
Re: [Zope-dev] z3c.password and failedAttempts andSessionCredentialsPlugin
Adam GROSZER agros...@gmail.com wrote: Thank you for your reply! Right. Well right now the lame solution is to try to count the number of resources needed to load the page and multiply maxFailedAttempts by that number. Other than that you _will_ want to offload resources in production. Oh, sure in _production_ I will. But what about testing and development. And counting the number of resources is highly unpredictable - esp. as I'm working on applications that can be easily skinned for different clients. (An other idea could be to try to identify requests that are not for resources, but how?) There's no real way as far as I can tell :| Even worse, if Zope were to handle one or more login page requisites, you can easily get database write conflicts as multiple simultaneous requests will try to increase the failed login attempts counter on the internal principal object. Can I conclude this particular feature of z3c.password is not really in use by anyone else (at least not in combination with the SessionCredentialsPlugin)? regards, jw Tuesday, January 19, 2010, 12:16:38 AM, you wrote: Betreff: [Zope-dev] z3c.password and failedAttempts andSessionCredentialsPlugin Hi, I'm looking into integrating z3c.password into an application that also uses the PAU with the principal folder, InternalPrincipals and the SessionCredentialsPlugin. One of the features of z3c.password that I'd like to use is locking out an user account after a number of failed login attempts. z3c.password provides such a feature. However, it seems this feature does not play well with the SessionCredentialsPlugin: The SessionCredentials will store the login and password that were submitted through the login form in a session. This login/password combination then is checked against the internal principal stored in the principal folder. If the password is correct then (obviously) everything is fine. When the password is incorrect, the user is directed back to the login form as authentication failed. If the page with the login form retrieves resources (like images or css of javascript files) and since the zopepublication will _try_ to authenticate every request, the wrongful login/password combination is checked multiple times for that page and its resources against the internal principal object. The internal principal mixin of z3c.password will count the number of failed checks. If you tell it to lock out an user after, say, three failed attempts, you have a problem, as the number of login page resources (thus requests) will quite easily outnumber the maximum number of attempts. Questions: is anyone using this feature of z3c.password in combination with the SessionCredentialsPlugin? If this is working for you, do you have any idea what I am doing wrong here? What type of authentication are the authors of z3c.password using? R Probably Adam can tell you more about that. R One solution could be to offload your resources and R deliver them from Apache or Nginx Frontend. R Regards R Roger Ineichen Thanks for any insight here. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) R ___ R Zope-Dev maillist - Zope-Dev@zope.org R https://mail.zope.org/mailman/listinfo/zope-dev R ** No cross posts or HTML encoding! ** R (Related lists - R https://mail.zope.org/mailman/listinfo/zope-announce R https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK
Summary of messages to the zope-tests list. Period Mon Jan 18 12:00:00 2010 UTC to Tue Jan 19 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Jan 18 20:36:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013407.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Jan 18 20:38:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013408.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 18 20:40:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013409.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 18 20:42:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013410.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 18 20:44:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013411.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Mon Jan 18 20:46:48 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013412.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
Am 19.01.2010 um 09:44 schrieb Laurent Mignon:
Hi,
I doesn't understand the motivation behind this change and I've the
feeling that it'll break some existing code
The motivation is the following:
self.getContent() seems to be the pattern to access the context of a form. I
used grep: there is no place where self.context is used directly besides in
group.py. So it seems to be an error in the code not to use the common pattern.
But after reading the doctests of z3c.form I'm no longer sure whether this is
correct.
My use case is the following:
I have a folder with contained items. In a form I display the schema of the
folder in the group form and the schemas of all contained items as groups. Each
group has a nested group displaying the meta data for the group's content. As
the context of the groups was the folder (group = groupClass(self.context,
self.request, self)) the meta data displayed was wrong.
May be am I wrong but ``getContent`` method is used to provides values
to widgets and actions as described into the interface: '''Return the
content to be displayed and/or edited.''' Why do you want to give the
content to the subform. Providing the wright content according to its
definition is under the subform responsability.
If not overrided, it's true that ``getContent`` return by default the
context. But for me the fact that you give the result of a call to
getContent as context for groupForm will break the following code:
Class IAddress(Interface):
street = zope.schema.TextLine(
title='street')
Class IPerson(Interface);
firstname = zope.schema.TextLine(
title='firstname')
address = zope.schema.Object(
title='address',
schema = IAddress)
class Address(object):
implements(IAddress)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class Person(object):
implements(IPerson)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
Should be getContent, I think.
return {
'owner': self.context.firstname,
'street': self.context.address.street}
class PersonGroup(group.Group):
label = 'Person'
fields += field.Fields(IPerson).select('firstname')
class PersonEditForm(group.GroupForm, form.EditForm):
fields = field.Fields(zope.schema.TextLine(
__name__=description',
title='Description',
readOnly=True)
groups = (PersonGroup, AddressGroup)
def getContent(self):
return {'description': 'Form used to edit a person and its
Address'}
I had never seen this before but according to the doctests of z3c.form it is a
valid use case.
person = Person(firstname='fName', address=Address(street='street'))
request = testing.TestRequest()
edit = PersonEditForm(person, request)
Before the changes the previous 'not tested' code worked as expected.
Since you give the result of getContent when instantiating the SubForms,
This code is now broken and I've to modify the getContent method on each
subfoms to take the context on the parentForm pointer.
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
return {
'owner': self.parentForm.context.firstname,
'street': self.parentform.context.address.street}
As I've said, may be am I wrong but I've the feeling that using the
``getContent`` as context for a subform introduce a mismatch between the
2 concepts behind ``context`` and ``getContent`` and can break existing
code.
The same result can be achieved, by explicitly instantiating the
subforms into the parentForm constructor.
class MyEditForm(group.GroupForm, form.EditForm):
def __init__(self, context, request):
super(MyEditForm, self).__init__(context, request)
firstContext = {}
secondContext = {}
self.groups = (
MyFirstGroup(firstcontext, request, self),
MySecondGroup(secondContext, request, self))
I'm not sure whether this works. (I'll try it.) Whether it works it obsoletes
my changes.
Michael Howitz wrote:
Log message for revision 108077:
``GroupForm`` and ``Group`` now use ``getContent`` method when
instantiating group classes instead of directly accessing ``self.context``,
as this is the usual way to access the context of the
Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
Michael Howitz wrote:
The motivation is the following:
self.getContent() seems to be the pattern to access the context of a form. I
used grep: there is no place where self.context is used directly besides in
group.py. So it seems to be an error in the code not to use the common
pattern.
But after reading the doctests of z3c.form I'm no longer sure whether this is
correct.
My use case is the following:
I have a folder with contained items. In a form I display the schema of the
folder in the group form and the schemas of all contained items as groups.
Each group has a nested group displaying the meta data for the group's
content. As the context of the groups was the folder (group =
groupClass(self.context, self.request, self)) the meta data displayed was
wrong.
But if your Groupform override getContent to provide an object
implementing the expected interface, that's right
Class IAddress(Interface):
street = zope.schema.TextLine(
title='street')
Class IPerson(Interface);
firstname = zope.schema.TextLine(
title='firstname')
address = zope.schema.Object(
title='address',
schema = IAddress)
class Address(object):
implements(IAddress)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class Person(object):
implements(IPerson)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
Should be getContent, I think.
return {
'owner': self.context.firstname,
'street': self.context.address.street}
class PersonGroup(group.Group):
label = 'Person'
fields += field.Fields(IPerson).select('firstname')
class PersonEditForm(group.GroupForm, form.EditForm):
fields = field.Fields(zope.schema.TextLine(
__name__=description',
title='Description',
readOnly=True)
groups = (PersonGroup, AddressGroup)
def getContent(self):
return {'description': 'Form used to edit a person and its
Address'}
I had never seen this before but according to the doctests of z3c.form it is
a valid use case.
My understand of ``getContent`` is to provide a way to give values used
by the widgets. By default, since the common use case is to edit /
display values from the context, the implementation return the context.
If your form has to deal with fields defined in an interface not
provided by the context, you have a lot of ways to provides the related
values.
* The first one is to provide an adapter adapting the context to the
interface defining the field
* The second one is to override the ``getContent`` implementation so
it'll return an object implementing the right interface
* The thirds one is to override the ``getContent`` implementation so
it'll return a dictionary where key = field.__name__ and value = the
value expected by the field. (In fact a default adapter exist that adapt
a dict to an interface)
* ...
Have a look to datamanager.txt
class MyEditForm(group.GroupForm, form.EditForm):
def __init__(self, context, request):
super(MyEditForm, self).__init__(context, request)
firstContext = {}
secondContext = {}
self.groups = (
MyFirstGroup(firstcontext, request, self),
MySecondGroup(secondContext, request, self))
I'm not sure whether this works. (I'll try it.) Whether it works it obsoletes
my changes.
According to the z3c.form implemention, the right place to put your
subform initialization is into the ``update`` method.
class MyEditForm(group.GroupForm, form.EditForm):
def update(self):
self.groups = (
MyFirstGroup(self.context.obj1, request, self),
MySecondGroup(self.context.obj2, request, self))
super(MyEditForm,self).update()
Yours sincerely,
sagblmi
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
Am 19.01.2010 um 16:58 schrieb Laurent Mignon:
Michael Howitz wrote:
The motivation is the following:
self.getContent() seems to be the pattern to access the context of a form. I
used grep: there is no place where self.context is used directly besides in
group.py. So it seems to be an error in the code not to use the common
pattern.
But after reading the doctests of z3c.form I'm no longer sure whether this
is correct.
My use case is the following:
I have a folder with contained items. In a form I display the schema of the
folder in the group form and the schemas of all contained items as groups.
Each group has a nested group displaying the meta data for the group's
content. As the context of the groups was the folder (group =
groupClass(self.context, self.request, self)) the meta data displayed was
wrong.
But if your Groupform override getContent to provide an object
implementing the expected interface, that's right
This might be a solution.
Class IAddress(Interface):
street = zope.schema.TextLine(
title='street')
Class IPerson(Interface);
firstname = zope.schema.TextLine(
title='firstname')
address = zope.schema.Object(
title='address',
schema = IAddress)
class Address(object):
implements(IAddress)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class Person(object):
implements(IPerson)
def __init__(self, **kw):
for name, value in kw.items():
setattr(self, name, value)
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
Should be getContent, I think.
return {
'owner': self.context.firstname,
'street': self.context.address.street}
class PersonGroup(group.Group):
label = 'Person'
fields += field.Fields(IPerson).select('firstname')
class PersonEditForm(group.GroupForm, form.EditForm):
fields = field.Fields(zope.schema.TextLine(
__name__=description',
title='Description',
readOnly=True)
groups = (PersonGroup, AddressGroup)
def getContent(self):
return {'description': 'Form used to edit a person and its
Address'}
I had never seen this before but according to the doctests of z3c.form it is
a valid use case.
My understand of ``getContent`` is to provide a way to give values used
by the widgets. By default, since the common use case is to edit /
display values from the context, the implementation return the context.
I see it differently. So I'd like to ask what was the original intention of
``getContent``?
Anyone here to answer this question?
If your form has to deal with fields defined in an interface not
provided by the context, you have a lot of ways to provides the related
values.
* The first one is to provide an adapter adapting the context to the
interface defining the field
* The second one is to override the ``getContent`` implementation so
it'll return an object implementing the right interface
* The thirds one is to override the ``getContent`` implementation so
it'll return a dictionary where key = field.__name__ and value = the
value expected by the field. (In fact a default adapter exist that adapt
a dict to an interface)
* ...
I might argue the other way round: when you override ``getContent`` in your
form resp. group class you are on your own as you changed the default behavior
of the form. Then you have to take care for for your groups to get the correct
context.
Have a look to datamanager.txt
class MyEditForm(group.GroupForm, form.EditForm):
def __init__(self, context, request):
super(MyEditForm, self).__init__(context, request)
firstContext = {}
secondContext = {}
self.groups = (
MyFirstGroup(firstcontext, request, self),
MySecondGroup(secondContext, request, self))
I'm not sure whether this works. (I'll try it.) Whether it works it
obsoletes my changes.
I tried it, it works, both in __init__ and in update. But this also works four
your use case.
According to the z3c.form implemention, the right place to put your
subform initialization is into the ``update`` method.
class MyEditForm(group.GroupForm, form.EditForm):
def update(self):
self.groups = (
MyFirstGroup(self.context.obj1, request, self),
MySecondGroup(self.context.obj2, request, self))
super(MyEditForm,self).update()
Yours sincerely,
sagblmi
Yours sincerely,
--
Michael Howitz · m...@gocept.com · software developer
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49
[Zope-dev] Wrong check out path on zope site
Hi, The svn check out path for Zope 3.4 given on the following page: http://docs.zope.org/developer/subversion-readonly-checkouts.html is not correct. The correct one should be: svn co svn://svn.zope.org/repos/main/Zope3/branches/3.4 Zope Can someone correct this please. -- Hong Yuan 大管家网上建材超市 装修装潢建材一站式购物 http://www.homemaster.cn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
Am 19.01.2010 um 21:30 schrieb Stephan Richter: On Tuesday 19 January 2010, Michael Howitz wrote: My understand of ``getContent`` is to provide a way to give values used by the widgets. By default, since the common use case is to edit / display values from the context, the implementation return the context. I see it differently. So I'd like to ask what was the original intention of ``getContent``? Anyone here to answer this question? Originally we only supported the context to be modified. We later found this far too limiting as a form should be able to modify any sort of objects within a context or not caring about the context at all. getContent() can return anything it wants to as long as a data manager can map the fields to it. So I think Laurent is correct. Okay, then I'll revert my changes and make a new release. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: z3c.form/trunk/ ``GroupForm`` and ``Group`` now use ``getContent`` method when instantiating group classes instead of directly accessing ``self.context``, as this is the usual way
On Tue, 2010-01-19 at 15:33 -0500, Stephan Richter wrote:
On Tuesday 19 January 2010, Michael Howitz wrote:
class AddressGroup(group.Group):
label = 'Address'
fields = field.Fields(zope.schema.TextLine(
__name__ = 'owner',
title='Owner',
readOnly=True)
fields += field.Fields(IAddress).select('street')
def getContext(self):
Should be getContent, I think.
Yes, probably a typo. the context is already exposed publically via the
context attribute, while the content is generally a lookup.
Yes it's a typo, sorry...
sagblmi
Regards,
Stephan
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
