Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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)
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:
- Names:
{'args': (),
'context': ,
'default': ,
'loop': {},
'nothing': None,
'options': {},
'repeat': {},
'request': http://127.0.0.1:8080/ap1/szemely/uno/@@edit.html>,
'template':
,
'usage': ,
'view': ,
'views': }
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=u"Hozzarendelt szerepek",
description=u"Hozzarendelt 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)
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): u"""Check 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)
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)
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)
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
Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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 . 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). 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)
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 . 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). does support that case. -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] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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 " 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 . 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)
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)
Dear Gary and Stephan, Would you please have a look at my messages with the subject "[Zope3-dev] problems with " 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)
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
Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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)
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)
> 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)
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 don
Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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)
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)
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)
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)
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. > 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. > 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'. > 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'? > 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 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. > 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 widge
Re: [Zope3-dev] Proposed widget/schema work for the Rivah sprint (Thursday and Friday this week)
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)
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
