Hi, Is there any indication on when we'll see a 2.0 release of z3c.form? We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered? BTW, at Keas we are currently using z3c.form trunk and it all looks okay. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hello, Coverage seems to burp on chameleon File "/home/adi/z3c.form/src/z3c/form/tests/../adding.txt", line 13, in adding.txt Failed example: testing.setupFormDefaults() Exception raised: Traceback (most recent call last): File "/home/adi/.buildout/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/doctest.py", line 1356, in __run compileflags, 1) in test.globs File "<doctest adding.txt[1]>", line 1, in <module> testing.setupFormDefaults() File "/home/adi/z3c.form/src/z3c/form/testing.py", line 226, in setupFormDefaults widget.WidgetTemplateFactory(getPath('text_input.pt'), 'text/html'), File "/home/adi/z3c.form/src/z3c/form/widget.py", line 399, in __init__ filename, content_type=contentType) File "/home/adi/.buildout/eggs/z3c.pt-1.0b4-py2.5.egg/z3c/pt/pagetemplate.py", line 70, in __init__ self, filename, **kwargs) File "/home/adi/.buildout/eggs/chameleon.zpt-1.0b4-py2.5.egg/chameleon/zpt/template.py", line 25, in __init__ doctype, **kwargs) File "/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/template.py", line 124, in __init__ self.registry = filecache.TemplateCache(filename) File "/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/filecache.py", line 9, in __init__ self.load() File "/home/adi/.buildout/eggs/chameleon.core-1.0b9-py2.5.egg/chameleon/core/filecache.py", line 37, in load self.registry = pickle.load(f) ImportError: No module named translation Monday, December 8, 2008, 8:27:01 AM, you wrote: SR> On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
SR> I am considering the code feature complete. I would like to get confirmation SR> from people that (a) the z3c.pt integration works well and (b) the object SR> widget is useful. Oh yes, and since I have not done the development, are we SR> 100% test covered? SR> BTW, at Keas we are currently using z3c.form trunk and it all looks okay. SR> Regards, SR> Stephan -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Our scientific power has outrun our spiritual power. We have guided missiles and misguided men. - Martin Luther King, Jr.
2008/12/8 Adam GROSZER <agroszer@gmail.com>:
Coverage seems to burp on chameleon
I just tried a buildout in newest mode and I did not see the error you pasted. It's important that the CHAMELEON_CACHE flag be set to '0' in an automated test setup (this is set in the buildout for the test runner). Note that I did get some test errors when running the tests, one seems to happen with and without z3c.pt enabled, but some others are output-related. \malthe
Am 08.12.2008 um 08:27 schrieb Stephan Richter:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered?
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk. But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress. [1] ... http://www.mail-archive.com/zope-dev@zope.org/msg26480.html Yours sincerely, -- Michael Howitz · mh@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
Hi Michael
Betreff: Re: [Zope-dev] z3c.form 2.0 release
Am 08.12.2008 um 08:27 schrieb Stephan Richter:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered?
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk.
But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress.
Uhh, that's me. I will defently move the ITerms arround like proposed in this and other mails. But the leak of time is the problem. I think it should not be a show stopper. Or is it? If so I should probably do that ASAP? A dependency to zope.app.form is defently a no go for z3c.form! What do you think?
[1] ... http://www.mail-archive.com/zope-dev@zope.org/msg26480.html
Yours sincerely, -- Michael Howitz · mh@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 http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Am 09.12.2008 um 11:01 schrieb Roger Ineichen: [...]
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk.
But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress.
Uhh, that's me. I will definitely move the ITerms around like proposed in this and other mails. But the leak of time is the problem.
I think it should not be a show stopper. Or is it? If so I should probably do that ASAP?
As Stephan suggested a zope.browser package with only the ITerms interface would be enough for the first step.
A dependency to zope.app.form is definitely a no go for z3c.form!
ACK. Yours sincerely, -- Michael Howitz · mh@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
On Tuesday 09 December 2008, Michael Howitz wrote:
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk.
I would love to have this branch merged and even wait a few days with the release process.
But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress.
That is a real problem, as I really do not want a dependency on zope.app.form. I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Am 09.12.2008 um 11:06 schrieb Stephan Richter:
On Tuesday 09 December 2008, Michael Howitz wrote:
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk.
I would love to have this branch merged and even wait a few days with the release process.
Nice.
But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress.
That is a real problem, as I really do not want a dependency on zope.app.form.
I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now.
+1
Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change.
-1 This does not work with other products like zc.sourcefactory which expect the interface in zope.app.form. As zc.sourcefactory has to work with zope.formlib, it can't use an interface from z3c.form to register its adapters. Yours sincerely, -- Michael Howitz · mh@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
Hi Stephan, Michael, others
Betreff: Re: [Zope-dev] z3c.form 2.0 release
On Tuesday 09 December 2008, Michael Howitz wrote:
There is still the zagy-sources branch which makes z3c.form usable together with sources (not only vocabularies). I'd be happy to merge it to the trunk.
I would love to have this branch merged and even wait a few days with the release process.
But it adds a dependency to zope.app.form as it needs zope.app.form.browser.interfaces.ITerms. There was a discussion to move this interface to a new package called zope.browser [1]. But I don't know if there was any progress.
That is a real problem, as I really do not want a dependency on zope.app.form.
I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change.
Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*? Christian, are you fine with this? Can you based on that merge your branch to z3c.form? Regards Roger Ineichen
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Am 09.12.2008 um 12:15 schrieb Roger Ineichen: [...]
Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*?
zc.sourcefactory, but I can migrate it myself.
Christian, are you fine with this? Can you based on that merge your branch to z3c.form?
Which Christian? If you mean me (I added tests to Christian Zagrodnick's branch.), I can merge it when zope.browser.interfaces.ITerms is there. Yours sincerely, -- Michael Howitz · mh@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
On Tue, 2008-12-09 at 12:39 +0100, Michael Howitz wrote:
[...] Which Christian? If you mean me [...]
I hope he doesn't mean you. That would increase gocept's "Christian"-ratio back to 38%. SCNR. -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, On Tue, 2008-12-09 at 12:15 +0100, Roger Ineichen wrote:
[...] I do not think there has been progress on the discussion, but we should just release the zope.browser package with this one interface in it for now. Another alternative would be for z3c.form to specify an ITerms interface. Porting from zope.app.form to z3c.form would be easy, since only one import would need to change.
Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*?
Re-import into the old place, put BBB warnings in place without the need to have them removed immediately. At least zc.sourcefactory does and other software out in the wild. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Am 09.12.2008 um 12:15 schrieb Roger Ineichen: [...]
Should I do that tomorrow? And adjust all related packages like zope.app.form, z3c.form etc. Are there other packages which use ITerms except the one in zope.*?
Christian, are you fine with this? Can you based on that merge your branch to z3c.form?
I merged the zagy-sources branch to the trunk. Yours sincerely, -- Michael Howitz · mh@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
Hello, A different question now: Do we need the attributes size="" alt="" maxlength="" for *hidden* text and textarea inputs? I'm not an HTML guru, but does not seem to make much sense. (textarea does not have a hidden pt yet, but soon) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: No wonder I feel so tired - I'm older now than I've ever been before.
On Thursday 11 December 2008, Adam GROSZER wrote:
size="" alt="" maxlength=""
for *hidden* text and textarea inputs? I'm not an HTML guru, but does not seem to make much sense.
No, I think they are not even valid HTML. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well
I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package. The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be "merely a container for modules and subpackages." [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts. I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support. [1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
and (b) the object widget is useful. Oh yes, and since I have not done the development, are we 100% test covered?
BTW, at Keas we are currently using z3c.form trunk and it all looks okay.
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
Hi Brian
Betreff: Re: [Zope-dev] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release of z3c.form?
We need a widget that's not in the 1.9 release, but is on trunk (for a list with textline value type), and are wondering whether to roll our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well
I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package.
The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be "merely a container for modules and subpackages." [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts.
I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support.
[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages. Some distribution concept can work with this but others don't. Malthe are you aware of this? Can you change it? Regards Roger Ineichen
2008/12/9 Roger Ineichen <dev@projekt01.ch>:
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Seems to work fine for e.g. ``repoze.bfg``.
Malthe are you aware of this? Can you change it?
I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat. \malthe
On Tue, Dec 09, 2008 at 04:31:33PM +0100, Malthe Borch wrote:
2008/12/9 Roger Ineichen <dev@projekt01.ch>:
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Seems to work fine for e.g. ``repoze.bfg``.
It works under most situations, but not the ones that are important to me. I've never tried to use repoze.bfg.
Malthe are you aware of this? Can you change it?
I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat.
Great, then sometime this week I'll: * rename the package * upload a release to pypi * change the imports and dependencies in z3c.form Please let me know if there's a step I'm missing?
\malthe
-- Brian Sutherland
On Tue, Dec 09, 2008 at 09:09:26PM +0100, Brian Sutherland wrote:
On Tue, Dec 09, 2008 at 04:31:33PM +0100, Malthe Borch wrote:
2008/12/9 Roger Ineichen <dev@projekt01.ch>:
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Seems to work fine for e.g. ``repoze.bfg``.
It works under most situations, but not the ones that are important to me. I've never tried to use repoze.bfg.
Malthe are you aware of this? Can you change it?
I do regret the package name and I would not be opposed to renaming it to z3c.ptcompat.
Great, then sometime this week I'll: * rename the package
I've done this.
* upload a release to pypi
I got caught on this, for 2 reasons: * The z3c.pt.compat tests are broken and were broken before I started. I don't want to release a package with broken tests. [1] * 93339 breaks the z3c.form tests [2] Below are the failures, Malthe, would you mind having a look at these?
* change the imports and dependencies in z3c.form
I've done this on a branch for now. I'll have a look at the other z3c.* packages once this is all working. The test failures: [1] Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Failure in test /Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/unittest.py", line 260, in run testMethod() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/doctest.py", line 2128, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for zcml.txt File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 0 ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 27, in zcml.txt Failed example: factory.index Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 45, in zcml.txt Failed example: factory.index Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 70, in zcml.txt Failed example: factory.template Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 90, in zcml.txt Failed example: factory.template Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 111, in zcml.txt Failed example: factory.index Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/zcml.txt", line 131, in zcml.txt Failed example: factory.index Expected: <z3c.ptcompat.ViewPageTemplateFile object at ...> Got: <z3c.ptcompat.BoundViewPageTemplateFile '/Users/jinty/src/z3c.ptcompat/src/z3c/ptcompat/tests/test.pt'> [2] Failure in test /Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt Failed doctest test for form.txt File "/Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt", line 0 ---------------------------------------------------------------------- File "/Users/jinty/src/z3c.form/src/z3c/form/tests/../form.txt", line 478, in form.txt Failed example: print addForm.render() # doctest: +NOPARSE_MARKUP Expected: <html xmlns="http://www.w3.org/1999/xhtml"> <body> <i>There were some errors.</i> <ul> <li> <div class="error">The id and name cannot be the same.</div> </li> </ul> ... </body> </html> Got: <html xmlns="http://www.w3.org/1999/xhtml"> <body> <i>There were some errors.</i> <ul> <li> <div class="error">The id and name cannot be the same.</div> </li> </ul> <form action="."> <div class="row"> <label for="form-widgets-id">ID</label> <input class="text-widget required textline-field" id="form-widgets-id" name="form.widgets.id" type="text" value="Stephan"> </div> <div class="row"> <label for="form-widgets-name">Name</label> <input class="text-widget required textline-field" id="form-widgets-name" name="form.widgets.name" type="text" value="Stephan"> </div> <div class="row"> <label for="form-widgets-gender">Gender</label> <select class="select-widget choice-field" id="form-widgets-gender" name="form.widgets.gender:list" size="1"> <option id="form-widgets-gender-novalue" value="--NOVALUE--">no value</option> <option id="form-widgets-gender-0" selected="selected" value="male">male</option> <option id="form-widgets-gender-1" value="female">female</option> </select> <input name="form.widgets.gender-empty-marker" type="hidden" value="1"> </div> <div class="row"> <label for="form-widgets-age">Age</label> <input class="text-widget int-field" id="form-widgets-age" name="form.widgets.age" type="text" value="23"> </div> <div class="action"> <input class="submit-widget button-field" id="form-buttons-add" name="form.buttons.add" type="submit" value="Add"> </div> </form> </body> </html> Diff: <html xmlns="http://www.w3.org/1999/xhtml"> <body> <i>There were some errors.</i> <ul> <li> <div class="error">The id and name cannot be the same.</div> </li> </ul> -<form action="."> <div class="row"> <label for="form-widgets-id">ID</label> <input class="text-widget required textline-field" id="form-widgets-id" name="form.widgets.id" type="text" value="Stephan"> </div> <div class="row"> <label for="form-widgets-name">Name</label> <input class="text-widget required textline-field" id="form-widgets-name" name="form.widgets.name" type="text" value="Stephan"> </div> <div class="row"> <label for="form-widgets-gender">Gender</label> <select class="select-widget choice-field" id="form-widgets-gender" name="form.widgets.gender:list" size="1"> <option id="form-widgets-gender-novalue" value="--NOVALUE--">no value</option> <option id="form-widgets-gender-0" selected="selected" value="male">male</option> <option id="form-widgets-gender-1" value="female">female</option> </select> <input name="form.widgets.gender-empty-marker" type="hidden" value="1"> </div> <div class="row"> <label for="form-widgets-age">Age</label> <input class="text-widget int-field" id="form-widgets-age" name="form.widgets.age" type="text" value="23"> </div> <div class="action"> <input class="submit-widget button-field" id="form-buttons-add" name="form.buttons.add" type="submit" value="Add"> </div> </form> </body> </html>
Please let me know if there's a step I'm missing?
\malthe
-- Brian Sutherland _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
Am Dienstag 09 Dezember 2008 16:24:41 schrieb Roger Ineichen:
Hi Brian
Betreff: Re: [Zope-dev] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release
of z3c.form?
We need a widget that's not in the 1.9 release, but is on
trunk (for
a list with textline value type), and are wondering
whether to roll
our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well
I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package.
The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be "merely a container for modules and subpackages." [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts.
I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support.
[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Ah, that's interesting. Because I recently released a package called "z3c.iban", which is basically about a schema about the international bank account number. Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace. So what's your suggestion in this case? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Wed, Dec 10, 2008 at 11:05:06AM +0100, Hermann Himmelbauer wrote:
Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace.
So what's your suggestion in this case?
There's no problem as long as z3c.schema is truly empty, i.e. there are no other packages that put any files in it. The problem with z3c.pt.compat is that z3c.pt is not empty (see http://svn.zope.org/z3c.pt/trunk/src/z3c/pt/). That's what causes the problems I've been seeing.
Best Regards, Hermann
-- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
-- Brian Sutherland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Sutherland wrote:
On Wed, Dec 10, 2008 at 11:05:06AM +0100, Hermann Himmelbauer wrote:
Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace.
So what's your suggestion in this case?
There's no problem as long as z3c.schema is truly empty, i.e. there are no other packages that put any files in it.
The problem with z3c.pt.compat is that z3c.pt is not empty (see http://svn.zope.org/z3c.pt/trunk/src/z3c/pt/). That's what causes the problems I've been seeing.
The issue comes not from having modules inside the namespace package (which is fine: the __path__ of namespacee packages is extended to include all eggs which use it). Rather, the problem is having a non-empty __init__.py in a namespace package (specifically, one which does anything else than declare that it is a namespace). The problem arises because only one of the __init__.py files will be imported (the first one found). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQAOO+gerLs4ltQ4RAq7iAJ9u2qd+iBHh3NMMGtO/pdPuNbcHAgCgqQxQ 3Sixt5Nslc7Lzw2CKjJrkaA= =DQvL -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Brian Sutherland wrote:
On Wed, Dec 10, 2008 at 11:05:06AM +0100, Hermann Himmelbauer wrote:
Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace.
So what's your suggestion in this case? There's no problem as long as z3c.schema is truly empty, i.e. there are no other packages that put any files in it.
The problem with z3c.pt.compat is that z3c.pt is not empty (see http://svn.zope.org/z3c.pt/trunk/src/z3c/pt/). That's what causes the problems I've been seeing.
The issue comes not from having modules inside the namespace package (which is fine: the __path__ of namespacee packages is extended to include all eggs which use it). Rather, the problem is having a non-empty __init__.py in a namespace package (specifically, one which does anything else than declare that it is a namespace). The problem arises because only one of the __init__.py files will be imported (the first one found).
A points I missed the first time: - - If having modules inside a namespace package was somehow broken under setuptools, then having sub-pacakges would be too: there isn't any magical difference between the two in how Python imports them. Please see the setuptools docs for an explanation of what namespace pacakges must do: I created a pair of packages to demonstrate having a module inside a namespace package (see attachment). To play with them, run 'python setup.py develop' in each of them using a setuptools-enabld Python environment in whose site-packages you don't mind scribbling (a virtualenv is perfect for this kind of stuff). E.g.:: $ /path/to/virtualenv --no-site-packages /tmp/nstest $ cd /tmp/nstest $ mkdir src $ cd src $ tar xzf /tmp/nstest.tar.gz $ cd foo $ ../../bin/python setup.py develop $ cd ../foo.bar $ ../../bin/python setup.py develop $ cd ../.. $ bin/python ...
import foo print foo.__file__ '/tmp/nstest/src/foo.bar/foo/__init__.pyc' import foo.qux import foo.bar foo.qux.quack foo.bar.cheer
Note that the __file__ of the namespace package is not guaranteed to be in one or the other egg, which is why namespace packages must have nothing more in their __init__.py than the boilerplate which declares the namespace. Tres - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJQAqd+gerLs4ltQ4RAvHgAKCgjeyLLFqZUmhmhsd81Wm6RXlXyQCg2r0D PNIFGNtvOwkYzsh9VSHEIy4= =pcdI -----END PGP SIGNATURE-----
On Wed, Dec 10, 2008 at 01:29:49PM -0500, Tres Seaver wrote:
Note that the __file__ of the namespace package is not guaranteed to be in one or the other egg, which is why namespace packages must have nothing more in their __init__.py than the boilerplate which declares the namespace.
With system packaged the __init__.py is guaranteed to not even be installed. Try this: $ python setup.py install --single-version-externally-managed --root xxx Also, if there are files alongside the __init__.py, they can cause filesystem conflicts in system packagers. dpkg will refuse to install a package if it would overwrite a file owned by another package.
Tres - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJQAqd+gerLs4ltQ4RAvHgAKCgjeyLLFqZUmhmhsd81Wm6RXlXyQCg2r0D PNIFGNtvOwkYzsh9VSHEIy4= =pcdI -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
Hi Herman
Betreff: Re: [Zope-dev] z3c.form 2.0 release
Am Dienstag 09 Dezember 2008 16:24:41 schrieb Roger Ineichen:
Hi Brian
Betreff: Re: [Zope-dev] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release
of z3c.form?
We need a widget that's not in the 1.9 release, but is on
trunk (for
a list with textline value type), and are wondering
whether to roll
our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well
I have an issue with this. z3c.pt.compat creates a nasty issue when trying to package it as a Debian package.
The root cause seems to be that z3c.pt.compat declares z3c.pt as a namespace package. These are defined in the setuptools documentation to be "merely a container for modules and subpackages." [1]. z3c.pt doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which point you get file conflicts.
I've been thinking about it a while, and I think the only solution is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that if there's enough support.
[1]
http://peak.telecommunity.com/DevCenter/setuptools#namespace-package
s
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Ah, that's interesting. Because I recently released a package called "z3c.iban", which is basically about a schema about the international bank account number.
Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace.
So what's your suggestion in this case?
You should move the iban folder to the existing z3c.schema package. But only if the z3c.schema.iban doesn''t depend on any other package the z3c.schema already does. Otherwise you should rename the package to z3c.iban or anything you like. Or we could do it the other way arround. We could split the z3c.schema package into different pacakges like z3c.schema.iban. This whould be nicer because we can share th z3c.schema package as a namespace. I'm fine with everything as long as we don't use real packages as namespace for packages. Regards Roger Ineichen
Best Regards, Hermann
-- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Am Mittwoch 10 Dezember 2008 13:02:02 schrieb Roger Ineichen:
Hi Herman
Betreff: Re: [Zope-dev] z3c.form 2.0 release
Am Dienstag 09 Dezember 2008 16:24:41 schrieb Roger Ineichen:
Hi Brian
Betreff: Re: [Zope-dev] z3c.form 2.0 release
On Sun, Dec 07, 2008 at 11:27:01PM -0800, Stephan Richter wrote:
On Friday 05 December 2008, Martin Aspeli wrote:
Is there any indication on when we'll see a 2.0 release
of z3c.form?
We need a widget that's not in the 1.9 release, but is on
trunk (for
a list with textline value type), and are wondering
whether to roll
our own or wait for a new z3c.form release.
I am considering the code feature complete. I would like to get confirmation from people that (a) the z3c.pt integration works well
I have an issue with this. z3c.pt.compat creates a nasty
issue when
trying to package it as a Debian package.
The root cause seems to be that z3c.pt.compat declares
z3c.pt as a
namespace package. These are defined in the setuptools
documentation
to be "merely a container for modules and subpackages."
[1]. z3c.pt
doesn't conform to that as it contains files. This doesn't matter till you try to install it using the --single-version-externally-managed option, at which
point you get
file conflicts.
I've been thinking about it a while, and I think the only
solution
is to rename z3c.pt.compat to z3c.ptcompat, make a new release of that and migrate z3c.form. I'm willing to implement that
if there's
enough support.
[1]
http://peak.telecommunity.com/DevCenter/setuptools#namespace-package
s
I agree A package should never use another package as it's namespace. Which means a package can not be both a package and namespace for other packages.
Ah, that's interesting. Because I recently released a package called "z3c.iban", which is basically about a schema about the international bank account number.
Someone recently suggested to rename it to z3c.schema.iban, which sounds a good idea to me, however, in this case my package would use another package, namely z3c.schema, as namespace.
So what's your suggestion in this case?
You should move the iban folder to the existing z3c.schema package. But only if the z3c.schema.iban doesn''t depend on any other package the z3c.schema already does.
Yes, that's exactly the problem - it depends on the "iban" module (a package, which I also wrote).
Otherwise you should rename the package to z3c.iban or anything you like.
Or we could do it the other way arround. We could split the z3c.schema package into different pacakges like z3c.schema.iban. This whould be nicer because we can share th z3c.schema package as a namespace.
That was what I was thinking about, as I estimate that there will be quite some packages over time which will rely on other packages and can hence not go into z3c.schema. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
participants (11)
-
Adam GROSZER -
Brian Sutherland -
Christian Theune -
Hermann Himmelbauer -
Malthe Borch -
Martin Aspeli -
Michael Howitz -
Roger Ineichen -
Stephan Richter -
Stephan Richter -
Tres Seaver