Re: [Zope-dev] Problems with schema Date field - year is truncated
On Wednesday 27 August 2008, Hermann Himmelbauer wrote: > I'm somehow stuck on the following problem: > > I defined a Date() schema field in one of my interfaces. I currently have a > de-AT locale, so I'd like to enter the value of my date as e.g. > "dd.MM.", e.g. "01.02.1980" in my z3c.form based form. > > What happens is, that the locale silently assumes a format of "dd.MM.yy", > which means, that the "YY / 80" is truncated and "01.02.19" is stored in my > database, when updating. > > So, I'd like to know if: > > - It is possible to change the format to "dd.MM.", which is a lot more > appropriate for my application (a birth date) The formatting string comes from the ICU locales files. I am welcoming any patch (with tests) that makes the date format pluggable in the z3c.form data converter. > - Make the application more strict, meaning that no data is truncated in > any case. This has been done for the latest zope.i18n release. 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 )
Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
On Friday 29 August 2008, Fred Drake wrote: > On Fri, Aug 29, 2008 at 5:13 PM, Malthe Borch <[EMAIL PROTECTED]> wrote: > > Log message for revision 90599: > > Move test-dependencies to 'extras'. > > This is a controversial change; can we avoid making changes like this > until a policy is agreed upon? > > The controversy surrounding this has been discussed on zope-dev > several times; I don't want to rehash it *right now*, since we all > have things we need to get done. Last time we discussed it, the conclusion was that it is a necessary evil for now. 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 )
Re: [Zope-dev] z3c.form - extraction from sequence widget
On Thu, 2008-08-28 at 22:55 +0100, Martin Aspeli wrote: > Hermann Himmelbauer wrote: > > Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas: > >> On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote: > >>> On Wednesday 27 August 2008, Martin Aspeli wrote: > This means that if the request contains the empty-marker only (no > selection was made) for a checkbox widget (say), then the return value > is [], rather than default (NOVALUE). > > Is that a bug? I have a custom checkbox widget derived from the > standard checkbox widget, (z3c.formwidget.query, in fact), and I never > get any "required missing" exceptions, even when I untick all the > checkboxes and click OK. > > Am I missing something? > >>> I think you have a point. Have you tried changing the behavior to > >>> return "default" and see what tests fail? If no major failures come out > >>> of this, I would say change it. > >> Wait a second, maybe I'm misunderstanding this, but I certainly oppose > >> any change that would make an unchecked checkbox an error during form > >> validation. > >> > >> A required Bool field can have two values: True or False. One is > >> represented by a checked checkbox, the other by an unchecked checkbox. > >> An unchecked checkbox is not missing input and should not trigger > >> "required missing" errors. > > > > I see this the same way - in my application I have a similar case (Accept > > some > > policy by a checkbox-click). I solved this simply by checking the value in > > the action handler and raising a WidgetExecutionError if it is unchecked. > > The notion of a "required" boolean field is a bit weird anyway. I remember Windows UI introducing 3-state-checkboxes back in ... uuh ... I think I saw it with Delphi 2. They had the ability to say unchecked, checked and grey meaning: the user didn't say anything. > I think you *could* interpret it so that a boolean field that's required > really means "you have to tick this box" (e.g. an "I agree to these > terms and conditions" type scenario). > > To put it the other way - how would you have a non-required boolean > field represented by a checkbox? You really need three states then: True > False and None, which you can't get with a checkbox. Actually that shouldn't be None. It's more that the attribute wouldn't be set in the first place as None can't be globally used as a marker for 'no user input'. Christian -- Christian Theune · [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Hi Martin > Betreff: Re: [Zope-dev] z3c.form - extraction from sequence widget > > Hi Roger, > > >> Btw., it is possible to have a three-state widget for > booleans, such > >> as a drop-down widget, that includes "True/False/None", > although it > >> may not make much sense. > > > > No that's not possible! Because you can't save anything > then False or > > True in a Bool field. I was a little bit unclear. I meant that the widget can't save back None as a new value after True/False was set. > Really? How is this different to having a not-required Int, > Float, TextLine or whatever field, with no default? Do they > then semantically default to 0, 0.0, "" etc, or are they > expected to be None? My assumption is that they're None when > not explicitly set. Yes, you are right the default is set to None like any other field which doesn't define something else. The problem is, if you use a widget and the widget uses None as an option e.g. True/False/None for act as (True, False and not set) then the field validation whould not allow to set anything then True or False as a value. The initial value could be None, but after set to True or False this initial (None) state can't get set again. That's sometimes useful but sometime not. > > I think it's always bad idea to use default=None for Bool fields. > > Because of it's invalid defaults. > > I guess that depends on whether you think "not set" means > "invalid". In SQL, for example, any field type can accept > NULL (unless the column is defined NOT NULL). I see your point, None is often use as an indicator for a not set value. I'm not so sure if this is a good concept for any use case. I use that concept too im my projects for Bool fields. But I also use some Choice fields with explicit (True/False/None) values for allow to reset a already set value. What I tried to say is: None is a possible inital value but this value is invalid for Bool fields. If the goal is to indicate a *not set value* then we are fine. If you set the field to require=True and that's fundamental part of your business logic, then it could end in a nightmare because of the invalid default. At least if the application will access the field value before someone changed that to a valid value. Regards Roger Ineichen > Martin > -- > Author of `Professional Plone Development`, a book for > developers who want to work with Plone. See > http://martinaspeli.net/plone-book > > ___ > 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 ) > ___ 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 )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Hi Roger, >> Btw., it is possible to have a three-state widget for >> booleans, such as a drop-down widget, that includes >> "True/False/None", although it may not make much sense. > > No that's not possible! Because you can't save anything > then False or True in a Bool field. Really? How is this different to having a not-required Int, Float, TextLine or whatever field, with no default? Do they then semantically default to 0, 0.0, "" etc, or are they expected to be None? My assumption is that they're None when not explicitly set. > I think it's always bad idea to use default=None for Bool > fields. Because of it's invalid defaults. I guess that depends on whether you think "not set" means "invalid". In SQL, for example, any field type can accept NULL (unless the column is defined NOT NULL). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
Re: [Zope-dev] "zipped" versus "unzipped" eggs (was: Re: SVN: Zope2.buildout/trunk/ Don't pin setuptools.)
On Sat, Aug 30, 2008 at 2:03 AM, Dieter Maurer <[EMAIL PROTECTED]> wrote: > However, I am not sure whether our observations for a single > large zip (in fact, we use two: one for our application, the other for > Python's > runtime library) is valid for the case of many small zipped eggs. The single-large-zip and the many-small-zips are distinctly different; the zip-import support was intended to support the single-large-zip (or small-number-of-zips) cases. Having many small zips is not a win at all. (Don't recall if there's a real penalty over many unzipped directories.) -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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 )
Re: [Zope-dev] SVN: zope.dublincore/trunk/ Move test-dependencies to 'extras'.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On Fri, Aug 29, 2008 at 5:26 PM, Malthe Borch <[EMAIL PROTECTED]> wrote: >> I didn't know there was a controversy, but I do remember that there was >> consensus that ``extras_require`` is not the most elegant solution. > > Oh, there is! > >> If you can advise a different way to avoid pulling in >> ``zope.app.testing`` I'm happy to revert the change; otherwise I think >> we should live and let live with it since it at the very least does the job. > > There's no good way to avoid dependencies like zope.app.testing; > because that's part of the test environment, the tests won't show > whether there are problems when it's removed. If you want to fly what > you test, test dependencies can't be eliminated. BTW, that phrase is disingeuous: as one who worked on testing one of the earliest fly-by-wire fighter jets[1] (long ago in a galaxy far far away), I can assure you that the plane did *not* have all its various test jigs attatched to it as it rolled down the runway. - Before assembly, components get tested in isolation using whatever jigs were appropriate, with testing done at each "rollup" of a new assembly. - After integration into the airframe, the set of tests possible were vastly reduced: a minimal set of tests could be done in a preflight check without external equipment, but any failure in such a test resulted in pulling the indicated part for diagnosis using dedicated equipment. [1] http://en.wikipedia.org/wiki/F-16_Falcon#Fly-by-wire Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] 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 iD8DBQFIuWiZ+gerLs4ltQ4RAkzBAKCY7ldytq7k9TqaDWljm2gk39DhGQCgl+c9 R+dM/gOr/v/O4f8Ww/xV61o= =Yy63 -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 )
Re: [Zope-dev] Bug in z3c.form.browser.orderedselect
On Wednesday 20 August 2008, Dan Korostelev wrote: > In the OrederedSelectWidget's input template there's a little bug in > options displaying. Options (for selectedItems and notSelectedItems) > are displayed using expression like this (simplified): > > > > Which will result in calling entry['content'] if it is callable, which > is true (for example) for the standard zope's "Content Types" > vocabulary from zope.app.content, because by default the term.value is > used for the "content" and then, if the term provides > ITitleTokenizedTerm it is replaced with translated term.title. But in > the "Content Types" vocabulary, terms are not titled, so term.value is > used, which is some Interface subclass and which is callable. > > So, as far as I understand, to fix little issue, we need to add the > "nocall" modifier in the template, so option expression will look like > this (simplifed): > > > > Thanks! I agree with that analysis. If you could send me a patch that includes a test (I know already you know how to do that ;-) I will apply it for the z3c.form 2.0.0 release. BTW, alternatively you could also get checkin rights to the zope.org repository and do the checkins yourself. :-) I am reviewing all checkins to z3c.form* all the time anyways. > PS Is there any bug tracking system for z3c.form package (like zope's > general one on launchpad)? No, just use the standard Zope 3 one on Launchpad. 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 )
Re: [Zope-dev] Make simple ISource usable
Hi Chritian > Betreff: Re: [Zope-dev] Make simple ISource usable > > On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote: > > [...] > > > > The only query API defined for ISource in zope.schema is the > > ISourceQueriables API. That's defently to less and makes it > required > > to implement custom query APIs in UI frameworks if we need to work > > with terms. > > > > I no one objects, I'll start a zope.schema branch and let you know > > about the progress and a hopfully a simple solution. Additional to > > them I started allready a z3c.form branch for adjust the ITerms > > implementation. > > As far as I can see right now this refactoring will only provides > > additional features. > > > > What do you think? Any objections or hints about that? > > Terms require access to a request. Any application's model > code should be happy to only deal with the values of sources. I agree, ITerm lookup from an ISource should work without the request. > Terms are used to map values to the UI parts of an > application (by providing identification tokens and user > readable titles). > > IMHO zope.schema doesn't need to know about terms. I agree if you think about the ITerms adapter pattern like defined in zope.app.form using (source, request) as discriminators. But zope.schema does already know about term. ITerm is a part of zope.schema. ISource uses ITerm as items. But the only query API is ISourceQueriables. There is no simple query API for work with terms. > I do agree that the whole issue of searching/querying sources > is currently underdesigned. What do you think about an ITerm interface next to the ISourceQueriables interface. This interface could offer getTerm and getValue and offer a base for access none queriable ISource implementations. Of corse such a ITerms adapter for ISource doesn't adapt the request. The PrincipalSource ITerms implementation from zope.app.security doesn't even use the implemented request. Probably we should named the new interface in zope.schema ISourceTerms instead of ITerms? Regards Roger Ineichen > Christian > > -- > Christian Theune · [EMAIL PROTECTED] > 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 > ___ 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 )
Re: [Zope-dev] Make simple ISource usable
On Fri, 2008-08-29 at 15:01 +0200, Roger Ineichen wrote: > [...] > > The only query API defined for ISource in zope.schema > is the ISourceQueriables API. That's defently to less > and makes it required to implement custom query APIs > in UI frameworks if we need to work with terms. > > I no one objects, I'll start a zope.schema branch and > let you know about the progress and a hopfully a simple > solution. Additional to them I started allready a > z3c.form branch for adjust the ITerms implementation. > As far as I can see right now this refactoring will only > provides additional features. > > What do you think? Any objections or hints about that? Terms require access to a request. Any application's model code should be happy to only deal with the values of sources. Terms are used to map values to the UI parts of an application (by providing identification tokens and user readable titles). IMHO zope.schema doesn't need to know about terms. I do agree that the whole issue of searching/querying sources is currently underdesigned. Christian -- Christian Theune · [EMAIL PROTECTED] 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 signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] z3c.form - extraction from sequence widget
Martin Aspeli schrieb: > Marius Gedminas wrote: >> On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote: >>> On Wednesday 27 August 2008, Martin Aspeli wrote: [...] >> Wait a second, maybe I'm misunderstanding this, but I certainly oppose >> any change that would make an unchecked checkbox an error during form >> validation. >> >> A required Bool field can have two values: True or False. One is >> represented by a checked checkbox, the other by an unchecked checkbox. >> An unchecked checkbox is not missing input and should not trigger >> "required missing" errors. > > What about the case when you have a list of options of which you need to > chose one or more? In that case, ticking none is a validation error. Use "min_length = 1" and the Field will raise TooShort. ..Carsten ___ 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 )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Fri Aug 29 11:00:00 2008 UTC to Sat Aug 30 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Fri Aug 29 20:52:13 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010085.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Fri Aug 29 20:53:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010086.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Fri Aug 29 20:55:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010087.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Fri Aug 29 20:56:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010088.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Fri Aug 29 20:58:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010089.html ___ 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 )
Re: [Zope-dev] ZPT and strict namespace mapping
--On 30. August 2008 07:39:05 +0200 Wichert Akkerman <[EMAIL PROTECTED]> wrote: Previously Malthe Borch wrote: Trying to get a feeling here on whether we want to require proper XML namespace definition (current z3c.pt behavior) or implicitly fallback to the standard mappings (current zope.pagetemplate behavior). +1 for requiring proper XML namespace. Tools like xmllint which are incredibly practical to validate your templates require this as well. -1 for having to write boilerplate code. Andreas pgpSeMGlHPHyr.pgp Description: 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 )
