Re: [Zope3-dev] KeywordIndex

2005-07-21 Thread Gary Poster


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]

2005-07-21 Thread Garrett Smith
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

2005-07-21 Thread Fred Drake
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

2005-07-21 Thread Garrett Smith
 

> -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

2005-07-21 Thread Fred Drake
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

2005-07-21 Thread Garrett Smith
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

2005-07-21 Thread Garrett Smith
> 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]

2005-07-21 Thread Jim Fulton


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

2005-07-21 Thread Fred Drake
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