[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: Kevin Dangoor wrote: I don't think we need to do that. for_widget = TextField(the_text = Foobar) (where the_text is a horrible replacement for value :) The widget description template can just do for_widget.display() unless it's doing something fancy with values that change in some way. You're quite right! No need at all to override something at display since you're just providing a example you already know params value to pass at init! ;-) Another complexity removal... bye bye value from WidgetDescription. :D An update on this, it turns out using params could be a problem at this point, the implementation is pretty straightforward and does simplify things but I don't feel like putting it in so late is a smart move at this point (maybe for 1.1 we could talk again about it, not sure thought) since you need to change all templates to just use **params_for and to explicitly pass value=..., the problem is providing backward compatibles hooks, this becomes a big pain but we need them. So here is the new program, it's definitely less dramatic but I still see it as a very good improvements: - rename update_data to update_params (deprecation warning for the former) - move validator and ajust_value to InputWidget - keep value even in a normal widget, but no covert parameter for display - ... other small things that don't come to mind atm probably We may also want to keep the default/value asymmetry probably, rationale: value is somewhat special and different from params, for example it's a positional parameter at display, if default is a dict it's not updated like we do with params but totally replaced, hence default does probably make more sense in this scenario I think. Today is a public holiday here in Italy (liberation day), this means I will probably provide a patch late today or tomorrow. ;-) Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: Michele Cella wrote: Kevin Dangoor wrote: I don't think we need to do that. for_widget = TextField(the_text = Foobar) (where the_text is a horrible replacement for value :) The widget description template can just do for_widget.display() unless it's doing something fancy with values that change in some way. You're quite right! No need at all to override something at display since you're just providing a example you already know params value to pass at init! ;-) Another complexity removal... bye bye value from WidgetDescription. :D An update on this, it turns out using params could be a problem at this point, the implementation is pretty straightforward and does simplify things but I don't feel like putting it in so late is a smart move at this point (maybe for 1.1 we could talk again about it, not sure thought) since you need to change all templates to just use **params_for and to explicitly pass value=..., the problem is providing backward compatibles hooks, this becomes a big pain but we need them. So here is the new program, it's definitely less dramatic but I still see it as a very good improvements: - rename update_data to update_params (deprecation warning for the former) - move validator and ajust_value to InputWidget - keep value even in a normal widget, but no covert parameter for display - ... other small things that don't come to mind atm probably We may also want to keep the default/value asymmetry probably, rationale: value is somewhat special and different from params, for example it's a positional parameter at display, if default is a dict it's not updated like we do with params but totally replaced, hence default does probably make more sense in this scenario I think. Today is a public holiday here in Italy (liberation day), this means I will probably provide a patch late today or tomorrow. ;-) Actually I discovered that *many* (almost all) of the problems I was experiencing were related to a typo... :-( http://trac.turbogears.org/turbogears/changeset/1226 Late today or tomorrow I will finally decide the right approach to this issue and provide a patch to discuss, most probably with value as first positional paramer in InputWidget but not as params. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: Actually I discovered that *many* (almost all) of the problems I was experiencing were related to a typo... :-( http://trac.turbogears.org/turbogears/changeset/1226 Late today or tomorrow I will finally decide the right approach to this issue and provide a patch to discuss, most probably with value as first positional paramer in InputWidget but not as params. Ok, actually *all* problems were related to this damn thing. I've uploaded a first step patch (nice) that's *totally* backward compatible with forms users only datagrid needs to be fixed (will do): http://trac.turbogears.org/turbogears/attachment/ticket/490/no-validator.patch Things to do here: - rename update_data to update_params - rename default to value? (this one day *not in 1.0* could help with an *eventual* transition of InputWidget to use params) - ... I will provide the final patch later today, see you guys. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On Tue, 25 Apr 2006 22:13:40 - Michele Cella [EMAIL PROTECTED] wrote: Kevin Dangoor wrote: On 4/25/06, Michele Cella [EMAIL PROTECTED] wrote: I've uploaded a first step patch (nice) that's *totally* backward compatible with forms users only datagrid needs to be fixed (will do): http://trac.turbogears.org/turbogears/attachment/ticket/490/no-validator.patch Does it make sense to remove value from Widget while leaving it in InputWidget? Especially given Jason's just-described use case? Yes, but that's what Jason said: We have widgets that are double clickable to edit. When you double click them, they change from text to a text field and then *send* a JSON call on completion. To me this widget looks definitely like an InputWidget since it's a label and then a TextField then it *sends* a JSON call with a value (submits something), isn't that what you're doing Jason? if so, why this should be a simple Widget instead of an InputWidget? I think that's another good reason for separating things with a clear use cases that suggests the right use case, by using InputWidget you get all the input related feature you need (we are using and have tested them for our forms) the validator and schema generation and also the very important path handling mechanism for nested structures. Jason, opinions? Ciao Michele I thought InputWidgets were meant to be put into forms, to be validated, etc. This widget won't ever be on a form, it's initially display, but only once it's activated does it become inputable. I'm pretty sure you can only use @validate with form widgets, so you wouldn't even be able to validate the widget (either way, it doesn't submit its value based off of its name). Now that I think about it more, will an InputWidget have a different display signature than a simple Widget? One would have to have a value variable as the first argument and the other would probably only have a **kw... I'm not quite sure if that makes things simpler to think about or not... Jason signature.asc Description: PGP signature
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Terça 25 Abril 2006 19:46, Jason Chu escreveu: I thought InputWidgets were meant to be put into forms, to be validated, etc. This widget won't ever be on a form, it's initially display, but only once it's activated does it become inputable. I'm pretty sure you can only use @validate with form widgets, so you wouldn't even be able to validate the widget (either way, it doesn't submit its value based off of its name). Actually this is not the case. I have one place where I submit data using JavaScript and validate it with a validators.Schema. It is the same thing since this JavaScript of mine does a post with the data. So, you don't need a form. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/25/06, Michele Cella [EMAIL PROTECTED] wrote: Again, to recap: - update_data - update_params - validator and ajust_value moved to InputWidget - the display and render signatuer becomes: display(self, value=None, **params) render(self, value=None, format=html, **params) - value in a InputWidget is managed with the validator, while on normal Widget you can use it in the same way you use a params attribute with the difference that, for example if it's a dict it's not updated but replaced, that's why I think at the end we may want to keep the default/value asymmetry in this case. convert will be passed as a keyword argument for InputWidget's at display. I'm going to prepare a patch to show that. Ok, take a look here: http://trac.turbogears.org/turbogears/attachment/ticket/490/move-validator-to-iw.patch Thanks for getting this done quickly, Michele! That all sounds good. I haven't looked at the patch, but I will do so tomorrow. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 24/04/2006, at 2:22, Michele Cella wrote: Just lovely IMHO (probably more with __javascript__ and __css__ :P:P). +1 an all this (Widget simplifcaction, input related stuff to InputWidget). -1 on that underscore__crazyness__ :P Ok, I know we shouldn't continue to touch things but I can't think of any backward incompatibility (please point them out if you can see them) and these functionalities are just shifted to InputWidget, that's where they really belong IMHO. Better now than never. But as Jorge said, we're all longing for stability... :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 24/04/2006, at 2:41, Michele Cella wrote: mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. I was just thinking of exactly this when writing the docstrings. Another +1 from me. Hopefully, all changes you're proposing will be as backward compatible as this one... ;) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Alberto Valverde wrote: +1 an all this (Widget simplifcaction, input related stuff to InputWidget). -1 on that underscore__crazyness__ :P Well, this morning I'm also -1 on the __ thing and yesterday with it I was just joking. :D Better now than never. But as Jorge said, we're all longing for stability... :) Me too :D, in reality is just a semantic shift from Widget to InputWidget nothing more. Anyway I'm checking that all tests runs fine (or with little modifications). Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: Alberto Valverde wrote: +1 an all this (Widget simplifcaction, input related stuff to InputWidget). -1 on that underscore__crazyness__ :P Well, this morning I'm also -1 on the __ thing and yesterday with it I was just joking. :D Better now than never. But as Jorge said, we're all longing for stability... :) Me too :D, in reality is just a semantic shift from Widget to InputWidget nothing more. If you want to take a look at the first attempt (all tests passing with really little fixes for 2 things): http://trac.turbogears.org/turbogears/attachment/ticket/490/moving-validator-to-input-widget.patch I just needed to update the DataGrid to use a rows parameter that (as I said) also make a lot more sense IMHO. Here update_data is still there but if we agree on update_params I'm +1 on renaming it. Another good side effect is that the schema generation effectively happens only where is needed (InputWidget) ATM I just check if the class hasattr(validator) I think is the best beat since we need the validator attribute but let me know. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 24/04/2006, at 12:14, Michele Cella wrote: If you want to take a look at the first attempt (all tests passing with really little fixes for 2 things): http://trac.turbogears.org/turbogears/attachment/ticket/490/moving- validator-to-input-widget.patch Looks good to my colorized-diff-viewer-eye (read: haven't actually tested it... sorry but a bit busy right now) I just needed to update the DataGrid to use a rows parameter that (as I said) also make a lot more sense IMHO. Here update_data is still there but if we agree on update_params I'm +1 on renaming it. me too Nice work :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Jorge Godoy wrote: Em Segunda 24 Abril 2006 07:14, Michele Cella escreveu: I just needed to update the DataGrid to use a rows parameter that (as I said) also make a lot more sense IMHO. Please, update fastdata as well. It will save me time from looking at what has changed writing a patch and waiting for it to be accepted ;-) Since you're already doing it, I believe it will be faster for you. :-) Yep, will do that. I'm just waiting to hear Kevin before going ahead. To recap, main things: - move validator (along with schema generation, default/value, value_for, adjust_value) to InputWidget - rename update_data to update_params Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/24/06, Michele Cella [EMAIL PROTECTED] wrote:
I'm just waiting to hear Kevin before going ahead.
To recap, main things:
- move validator (along with schema generation, default/value,
value_for, adjust_value) to InputWidget
- rename update_data to update_params
Sorry to be coming in late (as usual) to this thread. I haven't had
much time on the weekends of late.
I was about to say that validator needed to be on Widget for diplay
widgets that are showing complex values. But, then I realized that
that is a bogus statement because the template can do whatever
formatting it needs to with complex values. So, I think it's okay to
move validator to InputWidget.
As far as removing value, what about this:
${widget.display(person.name)}
${otherwidget.display(list_of_things)}
Without value, you have to do something like this:
${widget.display(text=person.name)}
${otherwidget.display(items=list_of_things)}
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
Also, how do forms work with this? (Maybe I should just go read the
patch and find out :)
Kevin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/24/06, Kevin Dangoor [EMAIL PROTECTED] wrote:
As far as removing value, what about this:
${widget.display(person.name)}
${otherwidget.display(list_of_things)}
Without value, you have to do something like this:
${widget.display(text=person.name)}
${otherwidget.display(items=list_of_things)}
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
Also, how do forms work with this? (Maybe I should just go read the
patch and find out :)
OK, I read the patch and I see that value just moved over to
InputWidget. So, now I understand how forms handle it :)
I'm still not certain that I like the loss of ${widget.display(foo)}
for display-only widgets, though.
Kevin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/23/06, Michele Cella [EMAIL PROTECTED] wrote: Ok, I know we shouldn't continue to touch things but I can't think of any backward incompatibility (please point them out if you can see them) and these functionalities are just shifted to InputWidget, that's where they really belong IMHO. By the way, this is really the last week for changes like this on 1.0. I realize that backwards compatibility is maintained, but the API needs to settle so that we can document and release. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 24/04/2006, at 18:12, Michele Cella wrote:
Kevin Dangoor wrote:
OK, I read the patch and I see that value just moved over to
InputWidget. So, now I understand how forms handle it :)
I'm still not certain that I like the loss of ${widget.display(foo)}
for display-only widgets, though.
Ok, this is also needed by the widget browser...
What about this display signature?
def display(self, *positional_params, **params)
*positional_params is automatically mapped to the corresponding
parameter position into the self.params list if the corresponding key
is not present inside **params.
You cannot do this Michele, there's no guaranteed order in this list
because it's converted to a set and back in meta.py to remove
duplicates. And other problems would arise if these params come from
many bases... how would you sort them?
Apart, I don't think it's convenient to change all widget's
signatures at this time, I mean, IIRC, we decided long ago to use kw
params except for name.
Regards,
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Alberto Valverde wrote: You cannot do this Michele, there's no guaranteed order in this list because it's converted to a set and back in meta.py to remove duplicates. And other problems would arise if these params come from many bases... how would you sort them? You're right Alberto, I was doing something other now and didn't tried this yet. Apart, I don't think it's convenient to change all widget's signatures at this time, I mean, IIRC, we decided long ago to use kw params except for name. What widget signatures changes are you talking about? Thanks. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Kevin Dangoor wrote:
As far as removing value, what about this:
${widget.display(person.name)}
${otherwidget.display(list_of_things)}
Without value, you have to do something like this:
${widget.display(text=person.name)}
${otherwidget.display(items=list_of_things)}
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
Mmm, ok given that I can't see any solution to this problem [1], anyway
I personally don't think this is a bad part, is just more typing but
it's more explicit and IMHO makes more sense for a generic widget to
use descriptive terms than assuming and suggesting the use of a not so
generic value term when you're outside of an input related
environment, in a InputWidget it makes perfect sense since value will
be the input value of this widget (c.r.input_values) but when we are
talking about Tim example or a DataGrid I really prefer to use
something like:
display(rows=...)
display(players=...)
and I will rather use:
py:for=row in rows or py:for=player in players inside my template
then
py:for=row in value or py:for=player in value, where is the
relationship laying here?
I really don't buy such an explanation for a generic widget value is
how you pass data to a widget, what data? and when we have other
parameters? you still end-up to look at params, and anyway:
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
When you first look at the DataGrid you have to look-up even deeper to
understand that value is mapped to rows in this case, in another one
value is mapped to items, this isn't explicitly stated anywhere if not
inside the template, with the other solution you simply look at params
and notice that there is the rows parameter explicitly stated here and
the logical connection is immediate IMHO. :-)
Ultimately this let's for a lowered barrier entry to understanding the
Widget philosophy and for an easier introduction tutorial to these
concepts IMHO.
Ciao
Michele
[1] ok, we could also use something like this, but I'm not so sure I
like it so much even if it saves typing is something really magic IMHO
(dumb name in the example):
params = [rows]
positional_paramter = rows
and we map it to the first positional parameter passed to display, but
I really *dislike* this *big* magic just for saving some typing at
display.
Ciao
Michele
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 24/04/2006, at 19:06, Michele Cella wrote:
Kevin Dangoor wrote:
As far as removing value, what about this:
${widget.display(person.name)}
${otherwidget.display(list_of_things)}
Without value, you have to do something like this:
${widget.display(text=person.name)}
${otherwidget.display(items=list_of_things)}
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
Mmm, ok given that I can't see any solution to this problem [1],
anyway
I personally don't think this is a bad part, is just more typing but
it's more explicit and IMHO makes more sense for a generic widget to
use descriptive terms than assuming and suggesting the use of a not so
generic value term when you're outside of an input related
environment, in a InputWidget it makes perfect sense since value will
be the input value of this widget (c.r.input_values) but when we are
talking about Tim example or a DataGrid I really prefer to use
something like:
I agree with Kevin in this point. Keep in mind that with the current
implementation you can still pass your value(s) as kw args. Juts make
sure you list it at params and let update_params (I like that
name... ;) ) do the conversion/whatever to it before passing it to
the template. My point is that for more complicated values (fields @
Datagrid) it's exactly what we're doing right now, no need for change
IMO.
Regards,
Alberto
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Alberto Valverde wrote: I agree with Kevin in this point. Keep in mind that with the current implementation you can still pass your value(s) as kw args. Juts make sure you list it at params and let update_params (I like that name... ;) ) do the conversion/whatever to it before passing it to the template. My point is that for more complicated values (fields @ Datagrid) it's exactly what we're doing right now, no need for change IMO. Ehm, I know that I can pass my values as kw args. :-) That's what I'm doing inside my own generics widgets, that's why I raised this issue. IMHO validator and the default/value concept is somewhat too much specific to the input side of things (hence belongs to InputWidget) and only adds complexity in understanding the widget concept. Cutting my post since it was getting (again) too long :D, just read my first message where I explain why value doesn't belong to the base Widget class (and where you said +1). Does saving the typing of a very meaningful parameter name at display balance the higher complexity we introduce to understand the basic widget concept at fist? I don't think so, but if this is the general agreement I will keep it there. I just want to make things easier for widgets newbie. Thanks again. ;-) Ciao Michele PS Apply the patch and take a look at the resulting base.Widget API then (virtually) try to explain it to a newbie then make the same with the actual one. ;-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/24/06, Alberto Valverde [EMAIL PROTECTED] wrote: Does saving the typing of a very meaningful parameter name at display balance the higher complexity we introduce to understand the basic widget concept at fist? I don't think so, but if this is the general agreement I will keep it there. I'm not sure it's more complex... I believe that passing a value at display() to widgets is usually the most common thing (except, ironically enough, on forms). For example, have a widget to render Fooball player's teams, each team is actually the value of the TeamWidget (too lazy to go back to the tutorial, sorry, I might be inventing this name here ;) I'm going to backtrack here. When value first came into existence, there was nothing like the parameters we have today that flow nicely through from __init__ to display. For simple widgets value is okay, but I think that as folks make more complex widgets you'll often have multiple parameters and using more descriptive terms for the main parameter is likely of value. So, now that I've convinced Alberto, I'll go ahead and side with Michele :) Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/24/06, Alberto Valverde [EMAIL PROTECTED] wrote: Well... I'll still defend my recently abandoned side. I liked that special one-and-only positional paramater that value was while he was alive... I guess 1 + 1 1 is universal so unless someone puts more weight at this side of the boat I'll humbly say farewell to v ... :) I think there were a couple things that did it for me: 1) I believe that widgets are easier to write than they used to be and more likely to be created by more people (which means that being able to choose a nice, representative name in a widget becomes more important) 2) __init__ has a default parameter. maybe I would've been more comfortable if that was called value, because then value is being managed *more* like the other params. How will WidgetDescription work? You just pass in your sample value in for_widget? Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Segunda 24 Abril 2006 16:28, Kevin Dangoor escreveu: On 4/24/06, Alberto Valverde [EMAIL PROTECTED] wrote: Well... I'll still defend my recently abandoned side. I liked that special one-and-only positional paramater that value was while he was alive... I guess 1 + 1 1 is universal so unless someone puts more weight at this side of the boat I'll humbly say farewell to v ... :) I think there were a couple things that did it for me: 1) I believe that widgets are easier to write than they used to be and more likely to be created by more people (which means that being able to choose a nice, representative name in a widget becomes more important) 2) __init__ has a default parameter. maybe I would've been more comfortable if that was called value, because then value is being managed *more* like the other params. How will WidgetDescription work? You just pass in your sample value in for_widget? I believe this change will be good but only if implemented together with Alberto's proposal of params_doc (or something like that) where we can see the name that will receive the value in any given widget (i.e., making params_doc *required* for widgets to work). The thing is that today one can just go and say widget.display(value) and that's it. There's no need to know the name of such parameter or anything else and this is /universal/ in that it works with everything. I also don't believe that we should go to lengths of changing our API just to prevent users from shooting themselves in their feet. But since this has other benefits -- mainly code simplification -- then this doesn't apply. So, with params_doc I side with Kevin and Michele. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Kevin Dangoor wrote:
On 4/24/06, Alberto Valverde [EMAIL PROTECTED] wrote:
Well... I'll still defend my recently abandoned side. I liked that
special one-and-only positional paramater that value was while he
was alive... I guess 1 + 1 1 is universal so unless someone puts
more weight at this side of the boat I'll humbly say farewell to
v ... :)
LOL
I think there were a couple things that did it for me:
1) I believe that widgets are easier to write than they used to be and
more likely to be created by more people (which means that being able
to choose a nice, representative name in a widget becomes more
important)
Yes. ;-)
2) __init__ has a default parameter. maybe I would've been more
comfortable if that was called value, because then value is being
managed *more* like the other params.
Well, I haven't popped this up to avoid being flamed but the very same
idea has always flow inside my mind since we introduced
template_vars...
This default/value asymmetry is so incoherent, I really dislike it.
Also I will point out that the very ideal approach that again will
simplify things a lot with methods signatures (changing the signature
of display and render is quite a kick in the ass I've noticed, I've
finally made it work right after many attempts today with the patch I
proposed) will be to use something like this in InputWidget just to
show that params is the intended way for every parameter without any
need to override display/render.
I haven't proposed this before since we had the default/value
asymmetry, but this is really neat IMHO:
class InputWidget(Widget):
params = [value, convert]
params_doc = {value: value of the widget...
convert: apply from_python conversion
using the validator...}
value = None
convert = True
If we really want to keep the positional value thing we can do that
with a special trick for it (maybe issue a deprecation warning for it
and for default and say change your code to use value at init and at
display, this will not work anymore once 1.0 is out just to remove the
nasty hack at some point), or we definitely being coherent in every
place of our code and rename default to value and require it at display
like any other param, this will require a lot less jumping in the code
base and a small adjustment to mention on the release notes for widgets
users.
We should decide let's do things in the right way once for all and
finally freeze them, I promise that's really the last thing that
struggled on me and (surprisingly) even for Kevin, I think we should
fix it and finally be in peace. :D
I'm going to prepare a patch that uses this methodology to show you the
final result I'm envisioning it to be quite nice, it shouldn't take too
much time... tests will tell.
How will WidgetDescription work? You just pass in your sample value in
for_widget?
I think we should rename value to params_values for example and just
pass a dict here, then in the widget description template:
for_widget.display(**params_values)
This will work for any widget and for any param.
Ciao
Michele
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On 4/24/06, Michele Cella [EMAIL PROTECTED] wrote: I think we should rename value to params_values for example and just pass a dict here, then in the widget description template: for_widget.display(**params_values) This will work for any widget and for any param. I don't think we need to do that. for_widget = TextField(the_text = Foobar) (where the_text is a horrible replacement for value :) The widget description template can just do for_widget.display() unless it's doing something fancy with values that change in some way. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Kevin Dangoor wrote: I don't think we need to do that. for_widget = TextField(the_text = Foobar) (where the_text is a horrible replacement for value :) The widget description template can just do for_widget.display() unless it's doing something fancy with values that change in some way. You're quite right! No need at all to override something at display since you're just providing a example you already know params value to pass at init! ;-) Another complexity removal... bye bye value from WidgetDescription. :D Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
On Mon, 24 Apr 2006 17:06:18 -
Michele Cella [EMAIL PROTECTED] wrote:
Kevin Dangoor wrote:
As far as removing value, what about this:
${widget.display(person.name)}
${otherwidget.display(list_of_things)}
Without value, you have to do something like this:
${widget.display(text=person.name)}
${otherwidget.display(items=list_of_things)}
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
Mmm, ok given that I can't see any solution to this problem [1],
anyway I personally don't think this is a bad part, is just more
typing but it's more explicit and IMHO makes more sense for a generic
widget to use descriptive terms than assuming and suggesting the use
of a not so generic value term when you're outside of an input
related environment, in a InputWidget it makes perfect sense since
value will be the input value of this widget (c.r.input_values) but
when we are talking about Tim example or a DataGrid I really prefer
to use something like:
display(rows=...)
display(players=...)
and I will rather use:
py:for=row in rows or py:for=player in players inside my template
then
py:for=row in value or py:for=player in value, where is the
relationship laying here?
I really don't buy such an explanation for a generic widget value is
how you pass data to a widget, what data? and when we have other
parameters? you still end-up to look at params, and anyway:
The bad part of this is that you have to look up the widgets to see
that the parameter is text or items or whatever.
When you first look at the DataGrid you have to look-up even deeper to
understand that value is mapped to rows in this case, in another one
value is mapped to items, this isn't explicitly stated anywhere if not
inside the template, with the other solution you simply look at params
and notice that there is the rows parameter explicitly stated here and
the logical connection is immediate IMHO. :-)
Ultimately this let's for a lowered barrier entry to understanding the
Widget philosophy and for an easier introduction tutorial to these
concepts IMHO.
Ciao
Michele
[1] ok, we could also use something like this, but I'm not so sure I
like it so much even if it saves typing is something really magic IMHO
(dumb name in the example):
params = [rows]
positional_paramter = rows
and we map it to the first positional parameter passed to display, but
I really *dislike* this *big* magic just for saving some typing at
display.
Ciao
Michele
Just to inject some of our usage here.
We have widgets that are double clickable to edit. When you double
click them, they change from text to a text field and then send a JSON
call on completion. They just replace straight text. They're called
UpdatableLabels. You'll never see them in a form, but it makes a lot
of sense that they just take in one parameter which is a value. I
don't know how it gets clearer than that.
Jason
signature.asc
Description: PGP signature
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Michele Cella wrote: class Widget(object): __metaclass__ = MetaWidget template = None params = [] css = [] javascript = [] def __init__(self, template=None, **params) def update_data(self, params) def display(self, **params) def render(self, format=html, **params) def retrieve_javascript() def retrieve_css() Just lovely IMHO (probably more with __javascript__ and __css__ :P:P). mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. Everything that's inside params ends up in the dict passed to update_data, so this should really be update_params, well Kevin named this method update_data before we introduced something like template_vars/params... Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 21:22, Michele Cella escreveu: (...) The base Widget class should be the most basic one and should present a general concept of component without making assumptions regarding the params that will be used (value is assumed in this case). I don't believe we should try solving or enforcing good practices by making it harder for them to shoot themselves in their feet. We shouldn't change things just because of that. We have a nice, clean, slim and easy to use, explain and understand Widget base class that is *only* focused on the creation of reusable-components. This looks good to have... But it is achievable as of today. I've done that with Select-Shuttle and MochiInterpreter, both on CheeseShop... Ok, I know we shouldn't continue to touch things but I can't think of any backward incompatibility (please point them out if you can see them) and these functionalities are just shifted to InputWidget, that's where they really belong IMHO. Enough craziness for today? good night guys. If no test fails and nobody sees any trouble with that I have no objection. Besides, better doing that before 0.9a5 than later. But I really would like that this became more stable. If it is to make it easier, go for it. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 21:41, Michele Cella escreveu: mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. I have the same opinion. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Em Domingo 23 Abril 2006 22:01, Michele Cella escreveu: - why should I name my grid? (mmm, to have more then one in the same page and distinguish them for javascript purpose, +1 for keeping name inside widget) ;-) We should always plan for more than one per page or per form. :-) It is safer and allows some unusual design. -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Please flame me: I would like to move validator to InputWidget...
Jorge Godoy wrote: Em Domingo 23 Abril 2006 21:41, Michele Cella escreveu: mmm while we are at it and since you will flame anyway, to be even more lovely I will also add that the ideal thing will be renaming update_data to update_params to enforce the strong relationship between the two things. I have the same opinion. Mmm, but in a Compound update_data also receives member_widgets so it probably makes more a more generic name... But well, haven't I said that I should sleep? :D Good night, for real this time. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
