- Zope-Dev - Zope lists

Where is the position of BlueBream in Zope ecosystem ?
by Baiju M 23 Jan '10

23 Jan '10

Hi All, I would like to get your opinion about this position statement, as it involve the wider Zope ecosystem. However, we tried to be diplomatic about other project's relationship with ZTK as we don't want to claim anything about others: http://wiki.zope.org/bluebream/BlueBreamName Regards, Baiju M

10 42

Zope Tests: 6 OK
by Zope Tests Summarizer 23 Jan '10

23 Jan '10

Summary of messages to the zope-tests list. Period Fri Jan 22 12:00:00 2010 UTC to Sat Jan 23 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: Fri Jan 22 20:37:02 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013431.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri Jan 22 20:39:03 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013432.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Fri Jan 22 20:41:03 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013433.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Jan 22 20:43:03 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013434.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Fri Jan 22 20:45:03 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013435.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Fri Jan 22 20:47:03 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013436.html

1 0

Wrong check out path on zope site
by Yuan HOng 22 Jan '10

22 Jan '10

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

2 1

Zope Tests: 6 OK
by Zope Tests Summarizer 22 Jan '10

22 Jan '10

Summary of messages to the zope-tests list. Period Thu Jan 21 12:00:00 2010 UTC to Fri Jan 22 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: Thu Jan 21 20:36:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013425.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Jan 21 20:38:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013426.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Jan 21 20:40:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013427.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Jan 21 20:42:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013428.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Jan 21 20:44:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013429.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Jan 21 20:46:54 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013430.html

1 0

BFG Logo
by Jan Ulrich Hasecke 21 Jan '10

21 Jan '10

Hi, is there a black on white BFG-logo we can use on zope.de? The white on black logo from the website is not suitable. juh DZUG e.V.

3 6

Zope Tests: 6 OK
by Zope Tests Summarizer 21 Jan '10

21 Jan '10

Summary of messages to the zope-tests list. Period Wed Jan 20 12:00:00 2010 UTC to Thu Jan 21 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: Wed Jan 20 20:36:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013419.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Jan 20 20:38:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013420.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Wed Jan 20 20:40:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013421.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Jan 20 20:42:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013422.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Wed Jan 20 20:44:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013423.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Wed Jan 20 20:46:36 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013424.html

1 0

Zope Tests: 6 OK
by Zope Tests Summarizer 20 Jan '10

20 Jan '10

Summary of messages to the zope-tests list. Period Tue Jan 19 12:00:00 2010 UTC to Wed Jan 20 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: Tue Jan 19 20:37:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013413.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Jan 19 20:39:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013414.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Jan 19 20:41:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013415.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Jan 19 20:43:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013416.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Jan 19 20:45:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013417.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Jan 19 20:47:21 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-January/013418.html

1 0

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 to access the context of the form and allows nested groups to have a different context than the main form.
by Laurent Mignon 20 Jan '10

20 Jan '10

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

1 0

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 to access the context of the form and allows nested groups to have a different context than the main form.
by Michael Howitz 20 Jan '10

20 Jan '10

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 · mh(a)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

1 0

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 to access the context of the form and allows nested groups to have a different context than the main form.
by Laurent Mignon 19 Jan '10

19 Jan '10

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.txt 2010-01-12 16:55:11 UTC (rev 108076) > +++ z3c.form/trunk/CHANGES.txt 2010-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 interfaces.IGroup.providedBy(groupClass): > group = groupClass > else: > - group = groupClass(self.context, self.request, self) > + group = groupClass(self.getContent(), self.request, self) > group.update() > groups.append(group) > self.groups = tuple(groups) > @@ -130,7 +130,7 @@ > if interfaces.IGroup.providedBy(groupClass): > group = groupClass > else: > - group = groupClass(self.context, self.request, self) > + group = groupClass(self.getContent(), self.request, self) > group.update() > groups.append(group) > self.groups = tuple(groups)

2 3