Em Sexta 28 Abril 2006 10:43, Kevin Dangoor escreveu:
>
> Can (or should) it actually be a CompoundWidget?
No. It can't and shouldn't. Imagine, for example, the basic situation:
class CurrentPasswordField(widgets.WidgetsList):
current = widgets.PasswordField(...)
class NewPasswordFields(widgets.WidgetsList):
new = widgets.PasswordField(...)
confirmation = widgets.PasswordField(...)
Those should be used for:
- clients changing password
- employees changing password
- suppliers changing password
So, they are in fact three widgets and they are common to these situations,
but there are cases where I want to have just a prompt for the current
password.
Of course, this simple example can perfectly be split in multiple
instantiations in almost any form without prejudice, but they are here just
to show a similar situation for what I have.
Some real case here, is with the following data:
- suppliers
- equipment vendor
- equipment calibration
- clients payment condition (number of working days to receive)
- suppliers payment condition (idem to the above for paying)
So, there are some cases where I need a supplier field to be in the middle of
a form as in: "analysis name", "analysis mnemonical", "supplier", "equipment
used", "days for standard result", "days for urgent result", etc.
Breaking this flow would change the way they had it before and hence introduce
a point of discomfort to the software operator where (s)he'll have to "think"
instead of just do what (s)he was used to for the last years.
In some other points, the position makes no sense in other places than right
after a previous field, so ordering is really important.
> I'm not really comfortable with a WidgetList being used in this way. A
> WidgetList is just a little syntax sugar around a list. What you end
> up with is a list of widgets ready to drop into a form.
So, if it is a list, why can't we use all the features a list provides?
(my original example)
> I see what you're getting at: you essentially want to define a widget
> with all of its options once and then use it in different contexts.
Exactly. I want to define things just once and reuse them.
> While a single widget can be used in many requests, it *is* fairly
> tightly bound to its name. The cleaner solution, to me, than nesting
I don't have a problem with keeping the same name if the functionality can be
achieved.
> WidgetLists is to subclass the widget that you want to use commonly.
I haven't thought about that. It also solves the problem, indeed. I just
have to "remember" to wrap it inside a list to add to other widgets when I
can use the "+" syntax.
> This is untested, but I think it will work:
As soon as I can recover from [1279] -- I went back to 1278 but it is still
giving me the same error I had with 1278 -- I'll give it a try.
> class MyCommonWidget(widgets.SomeField):
> option1 = "foo"
> option2 = "bar"
>
> class UseCommonWidget(widgets.WidgetsList):
> one_widget = widgets.OneField(...)
> another_widget = widgets.AnotherField(...)
> common =MyCommonWidget()
>
> class UseCommonWidgetAsWell(widgets.WidgetsList):
> other_widget = widgets.OtherField(...)
> yet_another_widget = widgets.YetAnotherField(...)
> common = MyCommonWidget()
> after_common_widget = widgets.AfterCommonField(...)
Thanks for your help :-)
--
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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---
