Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-09-06 Thread Gary Poster


On Sep 1, 2005, at 6:05 AM, Adam Groszer wrote:


Dear Gary,

Maybe not too late, I have here one more thing to look at:


Hi Adam.  Unfortunately, we did not get to your bug issues.

If you have not already, please do put your issues in the Zope 3  
collector (http://www.zope.org/Collectors/Zope3-dev) and we will work  
on them as we can.


Thanks

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-09-01 Thread Adam Groszer
Dear Gary,

Maybe not too late, I have here one more thing to look at:

It happened that the szerepek attribute of the object implementing the
ISzemely interface was left by default at a value None. As I tried
to modify the object with a standard generated editform, the exception
below came. I think None should be considered the same as [].
If we agree on that I would maybe consider that even as a bug.


...
  Module zope.tales.tales, line 684, in setRepeat
expr = self.evaluate(expr)
  Module zope.tales.tales, line 698, in evaluate
return expression(self)
   - Y:\zope\svn_zope3\src\zope\app\form\browser\orderedSelectionList.pt
   - Line 166, Column 8
   - Expression: PathExpr standard:u'view/selected'
   - Names:
  {'args': (),
   'context': zope.schema._field.List object at 0x0384A330,
   'default': object object at 0x008DD488,
   'loop': {},
   'nothing': None,
   'options': {},
   'repeat': {},
   'request': zope.publisher.browser.BrowserRequest instance 
URL=http://127.0.0.1:8080/ap1/szemely/uno/@@edit.html,
   'template': 
zope.app.pagetemplate.viewpagetemplatefile.ViewPageTemplateFile object at 
0x01797F50,
   'usage': zope.pagetemplate.pagetemplate.TemplateUsage object at 
0x0386AAB0,
   'view': zope.app.form.browser.itemswidgets.OrderedMultiSelectWidget 
object at 0x0384A390,
   'views': zope.app.pagetemplate.viewpagetemplatefile.ViewMapper object 
at 0x0386ABB0}
  Module zope.tales.expressions, line 204, in __call__
return self._eval(econtext)
  Module zope.tales.expressions, line 198, in _eval
return ob()
  Module zope.app.form.browser.itemswidgets, line 585, in selected
for value in self.context.get(self.context.context):
TypeError: iteration over non-sequence

class ISzemely(Interface):
...
szerepek = List(
title=uHozzarendelt szerepek,
description=uHozzarendelt szerepek,
required=False,
value_type=Choice(vocabulary=szerep)
)
...

-- 
Best regards,
 Adammailto:[EMAIL PROTECTED]
--
Quote of the day:
Diplomacy is the art of saying nice doggy until you can find a rock.

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Adam Groszer
Dear Gary and Stephan,



  Would you please have a look at my messages with the subject

  [Zope3-dev] problems with browser:widget

  I'm also having problems with CustomWidgetFactory, but in an other

  usecase.



-- 

Best regards,

 Adam  mailto:[EMAIL PROTECTED]

--

Quote of the day:

We desire most what we ought not to have 

- Publilius Syrus 
__
   Nyaralás 50,000 Ft alatt: http://ad.advert.hu/url.php?u=226
   Nyaralás Horvátországban: http://ad.advert.hu/url.php?u=227
 További akciós utazási ajánlatok: http://utazas.swi.hu
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Jim Fulton

Garrett Smith wrote:

I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.



Funnily, I just faced this dilema earlier today. I nearly created an interface 
like this:

  class IInitialValue(Interface):
  An interface for obtaining an initial value for an object.

  def get():
  Returns the initial value.

IMO, this is superior to field.initial. E.g.

  zapi.getMultiAdapter((field, context), IInitialValue).get()

Perhaps this pattern could be used for getting an ISource from a field. E.g.

  zapi.getMultiAdapter((field, context), ISource)


I think that sources are different than initial value.  I really don't
see any role that initial value has in an object specification.

A schema is a specification for an object that provides the schema.
An initial value doesn't constrain or specify the object.  If anything,
it constrains applications that create the object, but in a rather unclear
way.

Sources, OTOH, are about the specification of a value. A source defines the
set from which a choice is made.

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Gary Poster


On Aug 30, 2005, at 2:43 AM, Adam Groszer wrote:


Dear Gary and Stephan,



  Would you please have a look at my messages with the subject

  [Zope3-dev] problems with browser:widget

  I'm also having problems with CustomWidgetFactory, but in an other

  usecase.


Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We  
are using the zope.formlib package exclusively now (http:// 
svn.zope.org/zope.formlib/), which does not use custom widget  
factories or browser:widget.  Dominik's email sounds promising.


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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Fred Drake
On 8/30/05, Gary Poster [EMAIL PROTECTED] wrote:
 Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We
 are using the zope.formlib package exclusively now (http://
 svn.zope.org/zope.formlib/), which does not use custom widget
 factories or browser:widget.  Dominik's email sounds promising.

Actually, I have used the two together, using the custom_widget
attribute of form fields.  It's not necessarily a good fit, though,
especially from Python code, since CustomWidgetFactory requires that
you specify the concrete widget factory (it can't simply modify
whatever gets looked up without real help).  browser:widget does
support that case.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Gary Poster


On Aug 30, 2005, at 10:56 AM, Fred Drake wrote:


On 8/30/05, Gary Poster [EMAIL PROTECTED] wrote:


Adam, I'm sorry, I don't know much about the CustomWidgetFactory.  We
are using the zope.formlib package exclusively now (http://
svn.zope.org/zope.formlib/), which does not use custom widget
factories or browser:widget.  Dominik's email sounds promising.



Actually, I have used the two together, using the custom_widget
attribute of form fields.  It's not necessarily a good fit, though,
especially from Python code, since CustomWidgetFactory requires that
you specify the concrete widget factory (it can't simply modify
whatever gets looked up without real help).  browser:widget does
support that case.


OK, if you understand the problem, then maybe we can look at that a  
bit at the sprint, as Adam suggested.


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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Jim Fulton

Gary Poster wrote:


On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:


Gary Poster wrote:
...

4 Recognize and document that the 'default' field argument is   
actually 'initial value'.  That is, if you set a field with a  
default  to the missing_value, the default does not become the  
field's value:  the 'default' value is only used if the value has  
never been set  (i.e., during creation or when there is no  previous 
state of the  value).  Possibly rename to  'initial_value' (with 
deprecation  support).  *would need proposal*
5 Allow fields to accept a default (or initial_value, as above)  
*or*  a default_getter (or initial_value_getter, as above).   
default_getter/ initial_value_getter would be a callable passed  the 
field's context.   It should return the desired initial  value.  Use 
cases include  initializing to now, today, the current  user, etc.  
*would need small  proposal* *code exists*




I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.



Initial value is a concept in XMLSchema (http://www.w3.org/TR/ 
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty sure  
they are talking about what we are talking about.  I think it does  
belong in a statement about a logical schema.


I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)

Here's what we say about default in the schema package's README.txt:

  Default field values are assigned to objects when they are
   first created.

This is a statement either:

- about the past history of an object, or

- about some tool used to create an object.

I don't really see that this is of value in a schema.  A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past.  There's no way to
evaluate, for example, whether an object satisfies this aspect of
it's schema.

Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms.  We then create the object with whatever data
we get from an add form.  IOW, we don't really use it is an initial
value to create the object.

I suggest that the default should become a field in a formlib form-field
definition, and should be deprecated from schema field.

Moreover, I regard any lookup code as an intellectual cost for  
developers: a cost both for making and for finding the associated  
configuration.  For schemas, being able to look in one place is very  
valuable, at least to me.  APIDoc can help, but is not a panacea.  I  
don't think this particular configuration division would be a win.


Agreed, but I think we are mixing concerns. Default is not a property
of the specification, but of a form definition.

I think dropping the functionality of default would be a loss for  
reasonable schema functionality.  I think renaming it to initial or  
initial_value would be a win for accurate names.  I'm willing to drop  
the getter: it is kind of ugly, I admit.


You ok with just changing the name?


I'd really prefer to move it to form field, and change the name.


...


7 add combination field and widget to schema and form,  
respectively.   A combination field allows a user to fill in  
multiple values  simultaneously, and returns a tuple of the  combined 
values.  Use  cases overlap somewhat with object field/ widget, but 
this is simpler  to use for simple use cases.  Use  cases include 
range fields.  *would  need small proposal* *code  exists*



I have an open mind, but I'm a bit skeptical (as you know :).  I  expect
this proposal to be a bit controversal.  Perhaps we can plan to go  
another

round of brainstorming during the sprint.



OK--I must admit that I have a bit of the hack willies about it  too.  
:-)  It's useful, though, and I haven't been convinced by any  
alternatives yet.  This one's off the table for the sprint then,  except 
perhaps for discussion.


For the record, here are the use cases that the Combination field  fills 
now:


- range
- main value plus modifier(s): find something supervised by X (a  
person), directly or indirectly (a Bool); and select something for  
publication (an object), in a given context (local, global, whatever).


I know you don't like the first one, and I do ATM :-).  The second  one 
makes me more suspicious, though.  A combination field can  fulfill it, 
but we have had a real use case, or at least desire, for  a list widget 
of this sort of 

Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Gary Poster


On Aug 30, 2005, at 11:31 AM, Jim Fulton wrote:


Gary Poster wrote:

On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:

Gary Poster wrote:
...
4 Recognize and document that the 'default' field argument is
actually 'initial value'.

...


I'm uncomfortable with this.

...
Initial value is a concept in XMLSchema (http://www.w3.org/TR/  
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty  
sure  they are talking about what we are talking about.  I think  
it does  belong in a statement about a logical schema.


I can't figure what they are saying. I mean i really have no clue.
I asked my pointy-bracket consultant, but he couldn't make sense of
it either, although he didn't think it had anything to do with that
we were using the term for. :)


Heh, ok.


Here's what we say about default in the schema package's README.txt:

  Default field values are assigned to objects when they are
   first created.

This is a statement either:

- about the past history of an object, or

- about some tool used to create an object.

I don't really see that this is of value in a schema.  A schema
constrains object values, bit default isn't about object values,
it's about something that happened in the past.  There's no way to
evaluate, for example, whether an object satisfies this aspect of
it's schema.

Furthermore, we rarely, if ever, use a default definition in a
schema to constrain how an object is created. For example, I doubt
this often effects how __init__ methods are defined. Rather, we use
it to initialize forms.  We then create the object with whatever data
we get from an add form.  IOW, we don't really use it is an initial
value to create the object.

I suggest that the default should become a field in a formlib form- 
field

definition, and should be deprecated from schema field.


Hm.  I'm not the one to quote computer science definitions, but I  
don't think the concept of schema is constrained to 'constraints'.  A  
schema is a data model.  The initial value of a given instance of the  
model, whether it be used for object creation or any other kind of  
model instantiation (e.g., collecting the data for a search form) is  
not unreasonably part of a data model.  I agree it is not a  
constraint, but I'm not sure that's pertinent.


That said, as we discussed verbally yesterday, a purity perspective  
suggests we are moving towards a more explicit three-layer cake for  
schema fields: interface, relationship, and form field.  If that  
perspective wins out, then yes, I agree that it fits better on the  
form field.


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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Stuart Bishop
Gary Poster wrote:

 2 Clean up the exceptions widget framework.  The use of the widget 
 input error is quite messy: see collector issue 273.  The idea would  be
 to make the use of the errors argument more consistent and more 
 restricted, and make the 'doc' implementation simpler.

I've just had to wade through this recently. In particular, I had to resort
to ZCML overrides to get around the HTML quoting embedded in the guts of the
form validation error rendering - we need XHTML markup in our error
messages. If this is worked on it would be nice if this use case was
remembered ;) I suspect we want to use views on the exceptions so we can
easily provide HTML snippets or plain text string renderings.

 3 Make the arbitrary constraints in the schema framework more  powerful:
 specifically, allow a field to accept more than one  constraint, and
 have the constraints raise errors (with an i18n doc,  if desired) rather
 than return an uninformative Boolean.  This can be  done in a backwards
 (and deprecation) compatible way by keeping the  constraint argument and
 adding a constraints argument wit the new  semantics; or with another
 approach. *would need small proposal*  *code exists*

Constraints can already raise ValidationError whose doc() method returns the
error message. Although this seems to be undocumented and may only be
working for us by accident...

 8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets 
 provide a drop down of suggested (specifically most recently used for 
 the MRU widget) values for a choice field.  They really make using 
 choice widgets much nicer in many cases.  *code exists* *proposal 
 needed for also adding another of our packages to the core, on which 
 this relies*

You mention code exists - is it available anywhere? We were looking into
similar things but I'm not sure what the status is (I think we have some
suitable client side javascript, but I havn't seen it running yet).



-- 
Stuart Bishop [EMAIL PROTECTED]
http://www.stuartbishop.net/


signature.asc
Description: OpenPGP digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-30 Thread Gary Poster


On Aug 30, 2005, at 9:13 PM, Stuart Bishop wrote:


Gary Poster wrote:



2 Clean up the exceptions widget framework.  The use of the widget
input error is quite messy: see collector issue 273.  The idea  
would  be

to make the use of the errors argument more consistent and more
restricted, and make the 'doc' implementation simpler.


I've just had to wade through this recently. In particular, I had  
to resort
to ZCML overrides to get around the HTML quoting embedded in the  
guts of the

form validation error rendering - we need XHTML markup in our error
messages. If this is worked on it would be nice if this use case was
remembered ;) I suspect we want to use views on the exceptions so  
we can

easily provide HTML snippets or plain text string renderings.


OK, good feedback.  Thanks.

3 Make the arbitrary constraints in the schema framework more   
powerful:

specifically, allow a field to accept more than one  constraint, and
have the constraints raise errors (with an i18n doc,  if desired)  
rather
than return an uninformative Boolean.  This can be  done in a  
backwards
(and deprecation) compatible way by keeping the  constraint  
argument and

adding a constraints argument wit the new  semantics; or with another
approach. *would need small proposal*  *code exists*


Constraints can already raise ValidationError whose doc() method  
returns the

error message. Although this seems to be undocumented and may only be
working for us by accident...


Interesting point.  The interface doesn't seem to support this  
approach...


def constraint(value):
uCheck a customized constraint on the value.

You can implement this method with your Field to
require a certain constraint.  This relaxes the need
to inherit/subclass a Field you to add a simple constraint.
Returns true if the given value is within the Field's  
constraint.



...but that doesn't mean we can't bless it retroactively. :-)  That's  
definitely worth evaluating, as that would mean fewer changes.  I  
think I'd be fine with just expanding the contract a bit...



8 Add suggestion and MRU (Most Recently Used) widgets.  These widgets
provide a drop down of suggested (specifically most recently used for
the MRU widget) values for a choice field.  They really make using
choice widgets much nicer in many cases.  *code exists* *proposal
needed for also adding another of our packages to the core, on which
this relies*


You mention code exists - is it available anywhere? We were looking  
into
similar things but I'm not sure what the status is (I think we have  
some

suitable client side javascript, but I havn't seen it running yet).


We have not yet released this--it is in a package that needs some  
TLC, as I said at the beginning of the original note, and it relies  
on another piece that we are in the process of proposing.  If there  
is some time pressure for this, let us know, and we'll see if we can  
accelerate some of this enough for you all to at least evaluate from  
the sandbox.


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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Stephan Richter
On Monday 29 August 2005 15:30, Gary Poster wrote:
 We'll be doing some work on the widget/schema code at the Rivah  
 sprint, Thursday and Friday this week.  This email identifies the  
 possible tasks, and proposes the actual choice of work (short answer:  
 potentially all but the biggest, and last, 2).  Interested parties  
 are invited to comment and suggest, whether or not you plan to be at  
 the Rivah sprint.

I am open for any of them. However, I would be most interested in writing 
proposals on things that we want to get implemented in the near future, i.e. 
for Zope 3.2. We will have a unique combination of developers there, since 
all of the participants I know of have significant Zope 3 experience. If all 
developers there agree on an approach, it is very unlikely that anyone will 
have issues. On the other hand, I realize that writing proposals is a very, 
very dry and boring task for a sprint.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Gary Poster


On Aug 29, 2005, at 3:44 PM, Stephan Richter wrote:


On Monday 29 August 2005 15:30, Gary Poster wrote:


We'll be doing some work on the widget/schema code at the Rivah
sprint, Thursday and Friday this week.  This email identifies the
possible tasks, and proposes the actual choice of work (short answer:
potentially all but the biggest, and last, 2).  Interested parties
are invited to comment and suggest, whether or not you plan to be at
the Rivah sprint.



I am open for any of them. However, I would be most interested in  
writing
proposals on things that we want to get implemented in the near  
future, i.e.
for Zope 3.2. We will have a unique combination of developers  
there, since
all of the participants I know of have significant Zope 3  
experience. If all
developers there agree on an approach, it is very unlikely that  
anyone will
have issues. On the other hand, I realize that writing proposals is  
a very,

very dry and boring task for a sprint.


I agree that would be useful, and I know you have some big ideas.   
Maybe we can do some of both.  What I sprint on is up to Jim. :-)  He  
mentioned the schema/form stuff, which makes sense too.


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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Jim Fulton

Stephan Richter wrote:

On Monday 29 August 2005 15:30, Gary Poster wrote:

We'll be doing some work on the widget/schema code at the Rivah  
sprint, Thursday and Friday this week.  This email identifies the  
possible tasks, and proposes the actual choice of work (short answer:  
potentially all but the biggest, and last, 2).  Interested parties  
are invited to comment and suggest, whether or not you plan to be at  
the Rivah sprint.



I am open for any of them. However, I would be most interested in writing 
proposals on things that we want to get implemented in the near future, i.e. 
for Zope 3.2.


I thought you and I would work on publisher-related topics.

 We will have a unique combination of developers there, since
all of the participants I know of have significant Zope 3 experience. If all 
developers there agree on an approach, it is very unlikely that anyone will 
have issues.


Lots of people have a stake in the widget framework, especially Garrett.

 On the other hand, I realize that writing proposals is a very,

very dry and boring task for a sprint.


But sprints are a good place to brainstorm.  One topic I'd like to
brainstorm is the last stage of the publishing process.  Now,
we don't have a formal publishing interface. Informally, an object is
called and returns something. I'd like to flesh this out a bit more. :)
I'd also like to make it possible to plug in additional processing, for
example to provide site look at feel.

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Jim Fulton

Gary Poster wrote:
...
4 Recognize and document that the 'default' field argument is  actually 
'initial value'.  That is, if you set a field with a default  to the 
missing_value, the default does not become the field's value:  the 
'default' value is only used if the value has never been set  (i.e., 
during creation or when there is no previous state of the  value).  
Possibly rename to 'initial_value' (with deprecation  support).  *would 
need proposal*


5 Allow fields to accept a default (or initial_value, as above) *or*  a 
default_getter (or initial_value_getter, as above).  default_getter/ 
initial_value_getter would be a callable passed the field's context.   
It should return the desired initial value.  Use cases include  
initializing to now, today, the current user, etc.  *would need small  
proposal* *code exists*


I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.

...

7 add combination field and widget to schema and form, respectively.   A 
combination field allows a user to fill in multiple values  
simultaneously, and returns a tuple of the combined values.  Use  cases 
overlap somewhat with object field/widget, but this is simpler  to use 
for simple use cases.  Use cases include range fields.  *would  need 
small proposal* *code exists*


I have an open mind, but I'm a bit skeptical (as you know :).  I expect
this proposal to be a bit controversal.  Perhaps we can plan to go another
round of brainstorming during the sprint.

10 The big restructuring of schema: divide up schema into interface  
values and usage relationships.  This is too big to explain in this  
email, and probably too big to even adequately begin in two days.   This 
is the direction Jim wants to take schema, though, and I'm +1.


See:
http://mail.zope.org/pipermail/interface-dev/2004-June/48.html

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Jim Fulton

Garrett Smith wrote:
...


Jim has been complaining vociferously about SimpleInputWidget. It's probably 
time to nuke it (fine, deprecrete) and replace it with helper functions ala 
utility.py.

There's quite a bit on the plate here. I'd be inclined to flesh out in more detail 
the infrastructural pieces (vocab - source, constraints, widget API refactor) 
and leave new fields and widgets for later.

I can probably free up some time to look at SimpleInputWidget.


Ah, this is a good one.  My suggestion would be to write a
SingleInputWidget that:

- Addresses inputs that map onto single HTML inputs (e.g.
  text, float, int, etc.)

- provides a good well-documented example of how to use
  the lower-level widget framework.

This would be an excellent sprint topic, IMO.

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Gary Poster


On Aug 29, 2005, at 4:50 PM, Jim Fulton wrote:


Gary Poster wrote:
...

4 Recognize and document that the 'default' field argument is   
actually 'initial value'.  That is, if you set a field with a  
default  to the missing_value, the default does not become the  
field's value:  the 'default' value is only used if the value has  
never been set  (i.e., during creation or when there is no  
previous state of the  value).  Possibly rename to  
'initial_value' (with deprecation  support).  *would need proposal*
5 Allow fields to accept a default (or initial_value, as above)  
*or*  a default_getter (or initial_value_getter, as above).   
default_getter/ initial_value_getter would be a callable passed  
the field's context.   It should return the desired initial  
value.  Use cases include  initializing to now, today, the current  
user, etc.  *would need small  proposal* *code exists*




I'm uncomfortable with this. Right now, I think fields do too much.
They have too much application logic.  This would add more.  The whole
concept of initial value seems to be very application dependent.
Maybe it would be best to just drop the default field altogether
and introduce adapters for computing initial values in those special
cases when we need them.


Initial value is a concept in XMLSchema (http://www.w3.org/TR/ 
xmlschema-1/#key-iv).  The qoute is in W3C-speak, but I'm pretty sure  
they are talking about what we are talking about.  I think it does  
belong in a statement about a logical schema.


Moreover, I regard any lookup code as an intellectual cost for  
developers: a cost both for making and for finding the associated  
configuration.  For schemas, being able to look in one place is very  
valuable, at least to me.  APIDoc can help, but is not a panacea.  I  
don't think this particular configuration division would be a win.


I think dropping the functionality of default would be a loss for  
reasonable schema functionality.  I think renaming it to initial or  
initial_value would be a win for accurate names.  I'm willing to drop  
the getter: it is kind of ugly, I admit.


You ok with just changing the name?


...


7 add combination field and widget to schema and form,  
respectively.   A combination field allows a user to fill in  
multiple values  simultaneously, and returns a tuple of the  
combined values.  Use  cases overlap somewhat with object field/ 
widget, but this is simpler  to use for simple use cases.  Use  
cases include range fields.  *would  need small proposal* *code  
exists*


I have an open mind, but I'm a bit skeptical (as you know :).  I  
expect
this proposal to be a bit controversal.  Perhaps we can plan to go  
another

round of brainstorming during the sprint.


OK--I must admit that I have a bit of the hack willies about it  
too.  :-)  It's useful, though, and I haven't been convinced by any  
alternatives yet.  This one's off the table for the sprint then,  
except perhaps for discussion.


For the record, here are the use cases that the Combination field  
fills now:


- range
- main value plus modifier(s): find something supervised by X (a  
person), directly or indirectly (a Bool); and select something for  
publication (an object), in a given context (local, global, whatever).


I know you don't like the first one, and I do ATM :-).  The second  
one makes me more suspicious, though.  A combination field can  
fulfill it, but we have had a real use case, or at least desire, for  
a list widget of this sort of data structure.  Without a concept of  
main value and secondary values (and a combination widget doesn't  
promise anything like that) you can't get what we wanted.


10 The big restructuring of schema: divide up schema into  
interface  values and usage relationships.  This is too big to  
explain in this  email, and probably too big to even adequately  
begin in two days.   This is the direction Jim wants to take  
schema, though, and I'm +1.




See:
http://mail.zope.org/pipermail/interface-dev/2004-June/48.html


Cool, thanks.

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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Gary Poster


On Aug 29, 2005, at 4:24 PM, Garrett Smith wrote:

To ease our own development, I forked the schema and widgets code a  
while back. I don't think we've deviated too severely, but I've  
added whatever 2 cents based on my experience below.




1 Flesh out the 'source' design and implementation so it can replace
and deprecate vocabularies.  Specifically, to match the capabilities
of vocabularies, we'll add an interface that a source can implement
if they want to be bound to a context; and we will make it possible
to have iterable sources (for small collections as would be
appropriate for selections, radio button groups, checkbox groups,
etc.).  This will reduce the potential for confusion by letting
sources be the 'one true way' to describe possible options for a
choice, instead of the current overlap of vocabularies and sources.
The primary advantage to sources over vocabularies are that
the model
is cleaner; the only additional feature is the ability to configure
different tokens for a given source.



This sounds good. The one main hassle I've faced with vocabularies  
is the seeming complexity of the queriables UI scheme. I've spent  
much time tracking down how everything fits together, but  
unfortunately never spent the time to figure out a simpler  
approach. If it's already as simple as possible, fine -- sometimes  
stuff's just hard to simplify.


It isn't the easiest thing to grok, no.  We don't have any ideas to  
improve it either, except to add more documentation, which is still  
lacking AFAIK.  Maybe writing more documentation will reveal other  
ideas...



2 Clean up the exceptions widget framework.  The use of the widget
input error is quite messy: see collector issue 273.  The idea would
be to make the use of the errors argument more consistent and more
restricted, and make the 'doc' implementation simpler.



I have a ValidationError that looks like this:

class ValidationError(zope.schema.interfaces.ValidationError):

def __init__(self, msg, *args):
zope.schema.interfaces.ValidationError.__init__(self, *args)
self.msg = msg

def doc(self):
return self.msg

This was to workaround the strangeness of displaying a class-level  
description, rather than the specific msg provided with the error.


Cool: yes, that's very, very similar to our internal one, except I  
have an optional mapping arg (for values to be placed in the  
i18n.Message) and no *args.



3 Make the arbitrary constraints in the schema framework more
powerful: specifically, allow a field to accept more than one
constraint, and have the constraints raise errors (with an i18n doc,
if desired) rather than return an uninformative Boolean.
This can be
done in a backwards (and deprecation) compatible way by keeping the
constraint argument and adding a constraints argument wit the new
semantics; or with another approach. *would need small proposal*
*code exists*

4 Recognize and document that the 'default' field argument is
actually 'initial value'.  That is, if you set a field with a
default
to the missing_value, the default does not become the field's value:
the 'default' value is only used if the value has never been set
(i.e., during creation or when there is no previous state of the
value).  Possibly rename to 'initial_value' (with deprecation
support).  *would need proposal*



Our version of IField has an 'initial' attribute. We don't use  
default. I prefer 'initial' to 'initial_value'.


That sounds good to me.  I don't feel strongly about initial_value:  
short is good.



5 Allow fields to accept a default (or initial_value, as above) *or*
a default_getter (or initial_value_getter, as above).
default_getter/
initial_value_getter would be a callable passed the field's
context.
It should return the desired initial value.  Use cases include
initializing to now, today, the current user, etc.  *would
need small
proposal* *code exists*



Couldn't 'initial_getter' just be implemented using a property  
version of 'initial'?


Yes, it could.  The only downside is that it wouldn't be usable as an  
initialization argument.  I don't feel very strongly about it one way  
or the other.  It sounds like Jim is a definite -1 (as I thought he  
might be :-) so I'm happy to drop it.



6 Add union field and widget to schema and form, respectively.  A
union field allows a user to fill in one of several types of
values.
Use cases include faux combo boxes (i.e., a choice or a text line),
date/duration choices, etc.  Widget is reasonable and has been used
by ZC for more than a year.  *would need small proposal* *code  
exists*


7 add combination field and widget to schema and form,
respectively.
A combination field allows a user to fill in multiple values
simultaneously, and returns a tuple of the combined values.  Use
cases overlap somewhat with object field/widget, but this is simpler
to use for simple use cases.  Use cases include range fields.
 *would
need small proposal* *code exists*


Cool. I 

RE: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Garrett Smith

 I'm uncomfortable with this. Right now, I think fields do too much.
 They have too much application logic.  This would add more.  The whole
 concept of initial value seems to be very application dependent.
 Maybe it would be best to just drop the default field altogether
 and introduce adapters for computing initial values in those special
 cases when we need them.

Funnily, I just faced this dilema earlier today. I nearly created an interface 
like this:

  class IInitialValue(Interface):
  An interface for obtaining an initial value for an object.

  def get():
  Returns the initial value.

IMO, this is superior to field.initial. E.g.

  zapi.getMultiAdapter((field, context), IInitialValue).get()

Perhaps this pattern could be used for getting an ISource from a field. E.g.

  zapi.getMultiAdapter((field, context), ISource)

 -- 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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Garrett Smith
On Monday, August 29, 2005 4:33 PM, Gary Poster wrote:

 Couldn't 'initial_getter' just be implemented using a property
 version of 'initial'?
 
 Yes, it could.  The only downside is that it wouldn't be
 usable as an
 initialization argument.  I don't feel very strongly about it
 one way
 or the other.  It sounds like Jim is a definite -1 (as I thought he
 might be :-) so I'm happy to drop it.

I think I agree with Jim, see my other post.
 
  Cool. I don't know if this is the same thing, but we have a widget
 that handles editing two related fields. One field is a boolean
 that, when False, renders the other field not-applicable. E.g. when
 the user unselects a checkbox, a list box becomes disabled. Our
 implementation is a bit of a hack, since the widget has to cheat
 and get access to additional fields.
 
 Huh, interesting.  It sounds different.  What is the typical use for
 this sort of field? 

It's not a field -- it's a widget that cheats and updates multiple fields 
because the fields are closely related. Probably not worth worrying about at 
this point.
 
 I can probably free up some time to look at SimpleInputWidget.
 
 That would be great--you mean, during the same time as the
 sprint, or
 before, or after?  If before or during, we should probably coordinate.

If the API falls into a collaboration category, I can try to be available via 
IRC. I suspect it will be more efficient to just have a brainstorm during the 
sprint, put together a simple proposal and work up a prototype. The 
SingleInputWidget Jim's talking about will end up looking a lot like 
SimpleInputWidget.

When is the sprint anyway? :-)

 -- 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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Stephan Richter
On Monday 29 August 2005 16:43, Jim Fulton wrote:
  I am open for any of them. However, I would be most interested in writing
  proposals on things that we want to get implemented in the near future,
  i.e. for Zope 3.2.

 I thought you and I would work on publisher-related topics.

Great! This is definitely my favorite topic too. :-) I am glad we are on the 
same line. :-)

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)

2005-08-29 Thread Gary Poster


On Aug 29, 2005, at 6:37 PM, Garrett Smith wrote:


On Monday, August 29, 2005 4:33 PM, Gary Poster wrote:



Couldn't 'initial_getter' just be implemented using a property
version of 'initial'?


Yes, it could.  The only downside is that it wouldn't be
usable as an
initialization argument.  I don't feel very strongly about it
one way
or the other.  It sounds like Jim is a definite -1 (as I thought he
might be :-) so I'm happy to drop it.


I think I agree with Jim, see my other post.


OK.  He and I brainstormed a bit more about it.  That does sound like  
part of a fruitful area for sprint conversations.



Cool. I don't know if this is the same thing, but we have a widget
that handles editing two related fields. One field is a boolean
that, when False, renders the other field not-applicable. E.g. when
the user unselects a checkbox, a list box becomes disabled. Our
implementation is a bit of a hack, since the widget has to cheat
and get access to additional fields.



Huh, interesting.  It sounds different.  What is the typical use for
this sort of field?



It's not a field -- it's a widget that cheats and updates multiple  
fields because the fields are closely related. Probably not worth  
worrying about at this point.


OK


I can probably free up some time to look at SimpleInputWidget.


That would be great--you mean, during the same time as the
sprint, or
before, or after?  If before or during, we should probably  
coordinate.


If the API falls into a collaboration category, I can try to be  
available via IRC. I suspect it will be more efficient to just have  
a brainstorm during the sprint, put together a simple proposal and  
work up a prototype. The SingleInputWidget Jim's talking about will  
end up looking a lot like SimpleInputWidget.


:-)


When is the sprint anyway? :-)


This Thursday and Friday, Sept. 1  2.

Gary
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com