Re: [Zope3-dev] KeywordIndex
On Jul 19, 2005, at 1:06 AM, Jeff Shell wrote: Hi Gary! I'd be very interested in this. It's not critical for me right now, so there's no need to rush making something available. I have an inefficient but fun solution for my system that can be replaced when this comes along. I primarily wanted to know the state of the indexes. Hey again Jeff (and Michel, since you said you were interested too :-) ). I got snapshots of the catalog stuff up tonight (along with 'listcontainer', which is not as general interest) on zope.org as ZPL. Here's the README: http://svn.zope.org/Sandbox/zc/README.txt?rev=37377&view=auto And, of course, check them out from svn.zope.org/repos/main/Sandbox/ zc/catalog and svn.zope.org/repos/main/Sandbox/zc/listcontainer, respectively. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] [Fwd: SVN: Zope3/trunk/src/zope/app/form/browser/ Fixed a bug in SimpleInputWidget. _getFormValue had an evil side]
As the person who refactored SimpleInputWidget (not the author), I concur that it can be trying to use. We've actually forked that code, so I can't say whether it makes things easier or harder. There's certainly enough collective experience with forms/widgets that we could stand another round of refactoring. Jim, it sounds like you've got some specific ideas in mind. I know you mentioned helper functions at one point. Do you have some widgets at ZC that illustrate your thinking? -- Garrett > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Jim Fulton > Sent: Thursday, July 21, 2005 10:08 AM > To: zope3-dev@zope.org > Subject: [Zope3-dev] [Fwd: SVN: > Zope3/trunk/src/zope/app/form/browser/ Fixed a bug in > SimpleInputWidget. _getFormValue had an evil side] > > > I wanted to call this to attention of the wider list. I > corrected a bug/missfeature in SimpleInputWidget. I had to > comment out some tests that were testing this feature. If > anyone wants to defend the feature that the tests were > testing, I'm willing to discuss it. > See my comments in the forwarded check-in message if you're > interested. > > I strongly dislike SimpleInputWidget. (Apologies to the > author.) I'd love someone to move standard widgets away from using it. > Writing widgets is not very hard, but you wouldn't know it by > looking at this base class. Trying to use this base class > makes widget creation harder (unless you are the author of > SimpleInputWidget :). > > Jim > > -- > Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! > CTO (540) 361-1714http://www.python.org > Zope Corporation http://www.zope.com http://www.zope.org > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Formatting dates
On 7/21/05, Garrett Smith <[EMAIL PROTECTED]> wrote: > I just want to avoid applying special handing for time zones outside the > widget/schema framework. Right. One use case if for date/time values that have a tzinfo that's always UTC, and for which the input is always done in UTC. That seems like a minor twist, but we'll have to keep that in mind. (Yes, that's a real use case, dragged forth by a real client.) -Fred -- Fred L. Drake, Jr. Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formatting dates
> -Original Message- > From: Fred Drake [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 21, 2005 12:25 PM > To: Garrett Smith > Cc: Zope3-Dev (zope3-dev@zope.org) > Subject: Re: [Zope3-dev] Formatting dates > > On 7/21/05, Garrett Smith <[EMAIL PROTECTED]> wrote: > > I guess my question was whether you see the widget handling the > > setting of the time zone, or the application. My vote would be that > > the widget deal with this, using adaptation to black box > the process > > of finding the implicit tzinfo (assuming the widget doesn't > have a UI for explicitly setting it). > > I'll agree that adaptation should be used to get the implied tzinfo. > > Whether the widget should be responsible for filling in a > tzinfo at all depends on how the application is going to use > the value; there should be a way for a field to indicate > whether the value contains a tzinfo as well as whether the > actual value should be normalized to a specific timezone. > > It should still be up to the application to specify what kind > of timezone handling is needed (via the schema). Good point -- that should definitely be in the schema. I just want to avoid applying special handing for time zones outside the widget/schema framework. -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Formatting dates
On 7/21/05, Garrett Smith <[EMAIL PROTECTED]> wrote: > I guess my question was whether you see the widget handling the setting of the > time zone, or the application. My vote would be that the widget deal with > this, > using adaptation to black box the process of finding the implicit tzinfo > (assuming > the widget doesn't have a UI for explicitly setting it). I'll agree that adaptation should be used to get the implied tzinfo. Whether the widget should be responsible for filling in a tzinfo at all depends on how the application is going to use the value; there should be a way for a field to indicate whether the value contains a tzinfo as well as whether the actual value should be normalized to a specific timezone. It should still be up to the application to specify what kind of timezone handling is needed (via the schema). -Fred -- Fred L. Drake, Jr. Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Using zopectrl to restart Zope
I noticed some discussion along the line of using CTRL-C to stop Zope. I think the conclusion was that it was okay for development only. We use zopectrl as the base for a Linux service (using chkconfig). Does "zopectrl stop" allow pending transactions to complete (and presumably ignore/reject incoming requests)? -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Formatting dates
> That application of the user's timezone might be done before the > datetime is actually generated, or with a datetime.replace > (tzinfo=ITZInfo(request)) call. (The immutable nature of strings, > datetimes, and other similar types doesn't prevent us from > performing > operations with them or from replacing one attribute value with > another, of course). Of course :-) I guess my question was whether you see the widget handling the setting of the time zone, or the application. My vote would be that the widget deal with this, using adaptation to black box the process of finding the implicit tzinfo (assuming the widget doesn't have a UI for explicitly setting it). -- Garrett ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [Fwd: SVN: Zope3/trunk/src/zope/app/form/browser/ Fixed a bug in SimpleInputWidget. _getFormValue had an evil side]
I wanted to call this to attention of the wider list. I corrected a bug/missfeature in SimpleInputWidget. I had to comment out some tests that were testing this feature. If anyone wants to defend the feature that the tests were testing, I'm willing to discuss it. See my comments in the forwarded check-in message if you're interested. I strongly dislike SimpleInputWidget. (Apologies to the author.) I'd love someone to move standard widgets away from using it. Writing widgets is not very hard, but you wouldn't know it by looking at this base class. Trying to use this base class makes widget creation harder (unless you are the author of SimpleInputWidget :). Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org --- Begin Message --- Log message for revision 37365: Fixed a bug in SimpleInputWidget. _getFormValue had an evil side effect of setting _error. I assumed that this was unintentional, but there were tests supporting it, which is weird. If client code had not called getInputValue directly, then there is no reason to set _error. _getFormValue is only called by widget rendering code, which should not produce this side effect. Consider the following use case: - We present a form - The form contains widgets that have sub-forms. Here "sub-forms" are collections of input widgets without a form tag. Many logical subforms share a common form tag. Processing is dispatched based on the submit button used in a request. - A user interacts with a widget by clicking on a sub widget, for example do do "search and select". They did not click on a submit button for the overall form. - The application does not ytry to get input from any of the widgets nor does it try to validate user input. User input, of any, is know to be incomplete, because the form-submit buttons haven't been used. - In response to the users action, the application generates an updated form by rendering the widgets. Because the user hasn't tried to submit the form, they should not be presented with error messages, at least not at the form level. In summary, widgets should not generate error messages if they haven't been asked for valid values. Changed: U Zope3/trunk/src/zope/app/form/browser/tests/test_itemswidget.py U Zope3/trunk/src/zope/app/form/browser/tests/test_textwidget.py U Zope3/trunk/src/zope/app/form/browser/widget.py -=- Modified: Zope3/trunk/src/zope/app/form/browser/tests/test_itemswidget.py === --- Zope3/trunk/src/zope/app/form/browser/tests/test_itemswidget.py 2005-07-21 14:51:20 UTC (rev 37364) +++ Zope3/trunk/src/zope/app/form/browser/tests/test_itemswidget.py 2005-07-21 14:54:59 UTC (rev 37365) @@ -216,11 +216,13 @@ u'Two', u'Three']) -def test_error(self): -widget = self._makeWidget(form={'field.choice': 'ten'}) -widget.setPrefix('field.') -widget._getFormValue() -self.assert_(isinstance(widget._error, ConversionError)) +# This test is disabled because it tests for the presense of a missfeature, +# which has been removed. Did someone actually *want* this? +## def test_error(self): +## widget = self._makeWidget(form={'field.choice': 'ten'}) +## widget.setPrefix('field.') +## widget._getFormValue() +## self.assert_(isinstance(widget._error, ConversionError)) def test_hidden(self): widget = self._makeWidget(form={'field.choice': 'token2'}) @@ -413,11 +415,13 @@ '>One\n', 'value="token2"', '>Two\n', 'value="token3"', '>Three', '']) -def test_error(self): -widget = self._makeWidget(form={'field.numbers': ['ten']}) -widget.setPrefix('field.') -widget._getFormValue() -self.assert_(isinstance(widget._error, ConversionError)) +# This test is disabled because it tests for the presense of a missfeature, +# which has been removed. Did someone actually *want* this? +## def test_error(self): +## widget = self._makeWidget(form={'field.numbers': ['ten']}) +## widget.setPrefix('field.') +## widget._getFormValue() +## self.assert_(isinstance(widget._error, ConversionError)) def test_hidden(self): widget = self._makeWidget( Modified: Zope3/trunk/src/zope/app/form/browser/tests/test_textwidget.py === --- Zope3/trunk/src/zope/app/form/browser/tests/test_textwidget.py 2005-07-21 14:51:20 UTC (rev 37364) +++ Zope3/trunk/src/zope/app/form/browser/tests/test_textwidget.py 2005-07-21 14:54:59 UTC (rev 37365) @@ -253,7 +253,24 @@ value="" /> +""" +def test_n
[Zope3-dev] Re: [Zope3-checkins] SVN: Zope3/trunk/src/zope/pagetemplate/ Now input encoding of a PageTemplateFile in 'html' mode is determined
On 7/21/05, Dmitry Vasiliev <[EMAIL PROTECTED]> wrote: > Log message for revision 37358: > Now input encoding of a PageTemplateFile in 'html' mode is determined > by declaration and then the declaration will stripped. > > Open question: > Shouldn't / stripping be in PageTemplate.__call__()? This should be stripped by the compilation phase. Since those should never be part of the output, they need not be represented in the compiled template at all. -Fred -- Fred L. Drake, Jr. Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com