Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #490 (closed enhancement: fixed)

Opened 13 years ago

Last modified 12 years ago

Widgets redux

Reported by: michele Owned by: anonymous
Priority: normal Milestone: 0.9
Component: TG Widgets Version: 0.9a6
Severity: normal Keywords:
Cc:

Description

Attaching here a quickstarted project to show what I've done on widgets.

Posting an email to the group to call for testers. :)

Attachments

NewWidgets-0.5.tar.gz Download (12.1 KB) - added by michele 13 years ago.
The project
NewWidgets-0.6.tar.gz Download (12.0 KB) - added by michele 13 years ago.
New version, move some things around, add Ronal suggestion and an example of using dynamic options
base.py.patch Download (701 bytes) - added by alberto@… 13 years ago.
newbase.patch Download (1.3 KB) - added by aberto@… 13 years ago.
A little patch... (ignore a previous one, this one replaces it)
newforms.patch Download (451 bytes) - added by aberto@… 13 years ago.
Another…
datacontroller.patch Download (641 bytes) - added by aberto@… 13 years ago.
And another…
widgets.patch Download (7.1 KB) - added by alberto@… 13 years ago.
widgets.2.patch Download (7.0 KB) - added by alberto@… 13 years ago.
This patch replaces the previous widgets.patch, corrects a small error in a create_dict().
widgets.3.patch Download (7.4 KB) - added by alberto@… 13 years ago.
Last one, I promise! ;) Adds sample values to RadioButtonList?
michele.patch Download (2.0 KB) - added by michele 13 years ago.
Can you try this for callable options?
newbase.2.patch Download (1.3 KB) - added by anonymous 13 years ago.
widgets.4.patch Download (15.2 KB) - added by michele 13 years ago.
Porting to the new API, some fixes, some new tests, callable options (with Alberto's patch integrated)
widget-attrs.patch Download (2.0 KB) - added by michele 13 years ago.
New patch that fixes this problem and test added, I'm being unittest infected (thanks Kevin)
newbase_widget_vars.patch Download (5.6 KB) - added by alberto@… 13 years ago.
newbase_widget_vars.2.patch Download (5.2 KB) - added by alberto@… 13 years ago.
removes the new_widgets() patch so it doesn't break old widgets
newbase_widget_vars.3.patch Download (5.2 KB) - added by alberto@… 13 years ago.
One of the comments was the oposite way around..
newbase_widget_vars.4.patch Download (5.2 KB) - added by alberto@… 13 years ago.
One of the comments was the oposite way around…
small-polishing.patch Download (7.5 KB) - added by michele 13 years ago.
Move the last bit of logic out of forms, fix the FieldSet?, add back callable support for display
field_label.patch Download (484 bytes) - added by michele 13 years ago.
Fix for label management (needed for declarative style)
options-r633.patch Download (868 bytes) - added by michele 13 years ago.
Another patch to fix some problems with options
flipped.patch Download (2.0 KB) - added by michele 13 years ago.
This fixes all tests and #527 with your patch Aberto, and adds some simplifications to Buttons ;-)
moving-validator-to-input-widget.patch Download (15.3 KB) - added by michele 13 years ago.
No validator on Widget
no-validator.patch Download (8.4 KB) - added by michele 13 years ago.
nice one
move-validator-to-iw.patch Download (27.0 KB) - added by michele 13 years ago.
that's good
optgroup-support.patch Download (2.0 KB) - added by michele 13 years ago.
optgroup support, initial patch
optsupport.patch Download (5.0 KB) - added by michele 13 years ago.
Final version

Change History

Changed 13 years ago by michele

The project

Changed 13 years ago by michele

New version, move some things around, add Ronal suggestion and an example of using dynamic options

comment:1 Changed 13 years ago by alberto@…

Hi, I've integrated the new widgets into one of my projects and everything seems to be working fine for now, I'm going to work all day on it's widgets part and keep you informed.

I'm attaching a patch to make the widget's 'option' attribute work with a callable (as I needed it for a Selectionwidget).

BTW, how about a new branch for the new widgets framework to make patching, testing, etc easier?

Nice work!

Changed 13 years ago by alberto@…

comment:2 Changed 13 years ago by michele

Hi Albero,

glad that things are working fine, today I'm busy so I will not hack.

Anyway since you're going to test them report here any problem and if you're making other patches attach them here (use the unified format if you can please).

I think the last things that remain is porting the two DateTime?* widgets to this new version (it shouldn't be difficult but I would like them to follow the code style I've used), any volunteer?

Regarding a branch, we should ask Kevin, another possible and more agile option is using bazaar-ng (really nice product). I'm developing with it and I can make a repository (dunno where) so that people can make patches easily instead of making a branch on TG that requires commit privileges.

Once things are working fine tests should be ported and updated.

One thing regarding options, have you seen my example of passing new options? are you sure you need a callable? just wondering what use cases it will cover before adding it back.

I looked at the patch, is this the best way of should we use callable(...)?

Anyway late today I will come back and update the package with suggestions and patches.

Thanks for the feedback, really appreciated.

comment:3 Changed 13 years ago by michele

I will provide the CalendarDatePicker? late today, I'm half done but now I have to go.

comment:4 Changed 13 years ago by alberto@…

I think a callable is good for options which always have to be looked up for widgets which are inserted in a template (not necessarily a form) which is used by many controllers (such as master.kid), as for not having to pass the new options in every controller.

The new style is good for options that change on every request but on one particular controller (such as an email field that automatically inserts the domain name depending on which domain you're working on, this is a real case from the app i'm working on).

Regarding the branch, maybe Kevin could grant you commit privileges just on the branch (subversion allows this). I've got no experience with bazaar-ng so I can't comment on that, but I think a SVN branch would be more appropiate as it would be easier to merge later (even merge from the trunk back into the branch) and doesn't take up much extra space on the server, oh, and the svn diffs look prettier on Trac ;) I'll send him an email pointing him to this ticket let's see what he says...

Regarding the callable(), I think it's just matter of style (look-before-you-leap vs. better-ask-forgiveness-than-permission) Proably better to use callable() in this case as I've seen other parts of TG using it, just to be consistent...

I've done a copuple more changes/small-bug-fixes so I'll send a unified patch before going home with all the changes.

comment:5 Changed 13 years ago by michele

Hi again Alberto,

just some quick notes before I disconnect:

  • Probably Kevin will look closely at this thing today, I hope we will not need any branch. :-)
  • Thanks for pointing out your use case for the callable, I guess the best solution is to just support it at construction time and assign it to self.options then we just check for the callable (since as you said other part of TG use this way and I like it more, it's ore explicit) when we assign something to widget_options.
  • Thanks for any bug fixing, send a unified patch not only as one patch but even as unified format, I prefer it over the one you have used in your first patch, it's way more readable.

 http://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html

Ciao!

comment:6 Changed 13 years ago by alberto@…

  • Summary changed from Widgets redux to [PATCH] Widgets redux

Hi again,

Here are the patches I promised. I've done the callable stuff at construction time (though I think maybe it should be supported as widget_options too, just for consistency... the change is trivial).

another fixes FieldSet? @ newforms.py as it ignores the label argument to the constructor.

another one fixes datacontroller.py as it uses the old-style calling convention (shouldn't be applied until widgets switch to newwidgets as it's not backwards compatible)

I guess more to come along this morning as I'll be messing with them...

Regards, Alberto

P.S. Adding [PATCH] to the summary so commiters get to see them (more easily)

Changed 13 years ago by aberto@…

A little patch... (ignore a previous one, this one replaces it)

Changed 13 years ago by aberto@…

Another...

Changed 13 years ago by aberto@…

And another...

comment:7 Changed 13 years ago by alberto@…

Bigger patch, includes all of the above (which can be happily ignored):

  • Makes the widget browser work and show sample values.
  • Corrects a little bug in SelectionWidget? (I do believe is a bug, Michele, please correct me if I'm wrong...) where the widget_value was being converted via the validator, causing an AttributeError? as it's a ForEach? validator with no 'from_python' method.
  • Makes the DataWidget? work with the widget browser. Replaces the update_dict method with you new style. However, probably leaveas a copule of deprecated style quirks behind.

No tests however as I still don't know how to properly unit-test widgets (at least the widget browser provides some sort of test)

Enough for today... ;) Bye, Alberto

Changed 13 years ago by alberto@…

Changed 13 years ago by alberto@…

This patch replaces the previous widgets.patch, corrects a small error in a create_dict().

Changed 13 years ago by alberto@…

Last one, I promise! ;) Adds sample values to RadioButtonList?

comment:8 Changed 13 years ago by michele

Hi albero,

as you can see from changeset 609 Kevin has commited my work but today it will continue with other modifications to the widget API, so I think we should wait to submit those things.

Some notes:

  • Do you have an example where SelectionsField? breaks doing the conversion? it's stange I'm catching the validation exception, by the way widget_value is a list but if it's coming from the web I need to convert because it's a list of strings:

for example: dwidget_value? = ['1', '2'] instead of dwidget_value? = [1, 2]

  • The FieldSet? label problem is solved by removing label from the init so that it's passed to the FormField? constructor that does all the work
  • This thing you added to the FieldSet? is not needed:

if dwidget_value? is None:

dwidget_value? = {}

it's already done by its base class that's a CompoundWidget? (at least it should).

Anyway I will now post a new version with your updates (and a bug fix for the CheckBoxList? where I'm using field.id instead of field_id).

Thanks again.

Hold any other work until Kevin has finished working on widgets API improvements, just to not waste your time. ;-)

comment:9 Changed 13 years ago by michele

Well sorry Albero I was viewing the patch inside trac and haven't noticed you're already diffing against svn. ;-)

comment:10 Changed 13 years ago by michele

Some updates:

  • I checked and we don't need the things you added to the FieldSet? create_dict, this is always managed in the right way by the CompoundWidget? base class
  • The right fix for the label thing is removing it from create_dict then it's added by the base class as it should be (i left it in for error while porting FieldSet?)

This is the session I get using only the label fix:

>>> prova = w.FieldSet(fields=[w.TextField(name="ciao")], label="pippo")
>>> prova.label
'pippo'
>>> d = prova.create_dict()
>>> d
{'widget': <newwidgets.widgets.forms.FieldSet object at 0xb74bf3cc>, 'widget_options': {}, 'fields': [<newwidgets.widgets.forms.TextField object at 0xb74bfcac>], 'form_errors': {}, 'widget_value': {}, 'input_values': None}
>>>

as you can see widget_value is already an empty dict.

The sample/toolbox thing will change with the new API kevin is working on.

Finally conversion is absolutely needed, for example try your patch with a RadioButtonList? like this:

RadioButtonList?(name="another", options=options, default=2)

where options is:

options = [('1', "python"), ('2', "java"), ('3', "ruby")]

with your patch your radiobuttonlist will start with the wrong default option selected, if you remove kwconvert? = False it will work (at least that's the way I intended it and the way it works here), I know that's a dumb example but conversion is needed to ensure that we are always doing a comparison using the same "type".

Where are you getting problems here? can you provide me an example? I'm interested.

Thanks again.

Changed 13 years ago by michele

Can you try this for callable options?

comment:11 Changed 13 years ago by alberto@…

Hmmm, I've just read Kevin's post on the list saying he was rewriting the browser stuff... maybe I should stop reading the list just at g-groups and subscribe...

The problem i think is when you pass widget_value to the insert() method (as sample() does), If you apply my patch to r610, remove it (kwconvert? = False), and try the browser you'll see... Formencode raises an AttributeError? somewhere inside ForEach?.

I wasn't very sure when I did it as I haven't grasped entirely all this new widget's stuff, just wanted to integrate with the browser (before I knew it was being rewritten, damn! ;) to test them and get my hand's dirty with it before I start doing some serious stuff (the one that pays ;) with it.

Regarding your patch:

  • the label fix looks better...
  • _collect_options: Can't test it right now as i'm at a friends house but it looks as it'll work, just another way of doing it, whichever you prefer... (the code is yours ;). I guess your's better as it also handles "dynamic options" case.

Thanks you too, I really hope this gets stabilized soon as I need to work with it... I'll continue testing/bugfixin/pathing etc... until it's done.

Regards, Alberto.

comment:12 Changed 13 years ago by kevin

Yeah, I want to see this stabilized soon as well. Unless there's an already-scheduled ticket I'm forgetting about, this is the last API change slated for 0.9.

comment:13 Changed 13 years ago by kevin

I committed michele.patch in [612].

comment:14 Changed 13 years ago by anonymous

Hi Michele,

Just testing out r620 and the callable stuff breaks at newforms.py.SelectionField? when used with a callable:

File "/home/alberto/src/turbogears/turbogears/widgets/newforms.py", line 209, in __init__
    if isinstance(self.options[0][0], int):
TypeError: unsubscriptable object

Maybe it should be coded as a property? I think coding it as a property would be better as self.options will always return a list of options (which is what is normally expected, right?), regardless if it's ser to a callable (which returns a list of options) or a a list. What do you think?

I've attached a patch for this using _collect_options to test for callabillity, it fixes the problem I mention. Take it if you want...

Regards, Alberto

Changed 13 years ago by anonymous

comment:15 Changed 13 years ago by michele

  • Cc dangoor+turbogears@… added

Hi Alberto,

Yes, sorry for forgetting this you are *more* than right! A property looks good indeed. ;-)

I will ping Kevin (adding him to the CC field) so that your patch gets applied.

Thanks again for testing things.

Changed 13 years ago by michele

Porting to the new API, some fixes, some new tests, callable options (with Alberto's patch integrated)

comment:16 Changed 13 years ago by anonymous

Hi,

I'm testing the new widgets and I've seen that the attrs attribute can't be passed to the constructor anymore:

    domain_selector = W.SingleSelectField(
            name="dominios",
            options=get_domain_list,
            attrs= {'onchange':
                    'panel.set_domain(this.options[this.selectedIndex].value)'}
    )

Doesn't work (it did before). Is this new behaviour or a bug? I guess it's new behaviour as the above code could become unthreadsafe if attrs were updated at insert, err, display time, right?

comment:17 Changed 13 years ago by kevin

That's a bug. I believe I eliminated attrs thinking that the attributes could just be specified in the template, forgetting about the fact that the user instantiating the widget would want attrs.

As long as we make a shallow copy of the attrs dict, it should be threadsafe.

comment:18 Changed 13 years ago by michele

All right, didn't noticed you removed the code from the __init__ method with the revision, before (0.6 shows this) I was doing a shallow copy for attrs at display time.

I'm going to post a patch soon.

Changed 13 years ago by michele

New patch that fixes this problem and test added, I'm being unittest infected (thanks Kevin)

comment:19 Changed 13 years ago by michele

  • Cc dangoor+turbogears@… removed

Removing Kevin from CC and jumping into the turbogears-ticket group. :P

comment:20 Changed 13 years ago by michele

Another thing I noticed, in the TableForm? template there is:

 py:replace="field.display(value=value.get(field.name), 
                           **options.get(field.name, {}))" />

Should those be removed?

comment:21 Changed 13 years ago by anonymous

Hi,

I've applied widget.attrs.patch and my code worked as it did before (just in case the unittest didn't convince you ;)

Thanks Michele

comment:22 Changed 13 years ago by alberto@…

I've attached a patch to reduce the boilerplate code required at update_data() for passing attributes from the widget instance to the template:

Basically:

class MyWidget(Widget):
    def update_data(self, d):
        d['foo'] = self.foo
        d['bar'] = self.bar

becomes:

class MyWidget(Widget):
   template_vars = ['foo', 'bar']

update_data can still be used at usual

Special care is taken at MetaWidget?'s __new__ method so template_vars becomes the union of all the template_vars from all the bases. (see the unittest) Adapts existing code to take advantage of this, it's backwards compatible, includes unittests, it rolls and it dices ;)

Alberto

Changed 13 years ago by alberto@…

Changed 13 years ago by alberto@…

removes the new_widgets() patch so it doesn't break old widgets

Changed 13 years ago by alberto@…

One of the comments was the oposite way around..

Changed 13 years ago by alberto@…

One of the comments was the oposite way around...

comment:23 Changed 13 years ago by kevin

  • Summary changed from [PATCH] Widgets redux to Widgets redux

I committed patch 4 in [646].

Changed 13 years ago by michele

Move the last bit of logic out of forms, fix the FieldSet?, add back callable support for display

comment:24 Changed 13 years ago by michele

  • Summary changed from Widgets redux to [PATCH] Widgets redux

I added a new patch. There is also the one for attr support still anging around (probably it will not apply anymore).

comment:25 Changed 13 years ago by alberto@…

  • Summary changed from [PATCH] Widgets redux to Widgets redux

Hi Michele,

I've committed the polishing patch at r658.

I would like to ask you (and anyone who wants to help, of course) if you could look at the failling unit tests at turbogears.tests.test_form_controllers when you have a chance. Now that I've included the CalendarDatePicker widget, this test is getting to run and it looks as if something is broken around the validators at the widgets, but I don't know for sure...

I'll try to fix it tomorrow, just in case you get to see it before I do as I'm done for today (need some fresh air ;)

Regards, Alberto

comment:26 Changed 13 years ago by michele

Hi Alberto,

the problem seems to be there:

widgets.CalendarDatePicker("date",
                        validator=validators.DateConverter(
                                    if_empty=datetime.now()))])

passing "date" as the name to the CalendarDatePicker? will not work as with subclassing we changed the constructor signature where the first parameter is not name, adding 'name="date"' seems to work.

By the way IMO one of the last things to do is going through all the modified constructors and removing the abuse of kw to list first of all the original constructor parameters, the new one and then kw.

This will help to avoid those problems, will mean a strict rule to follow (instead of repeating only name as we do now), help consistency and finally is good from a doc POV.

Example:

    def __init__(self, name=None, label=None, **kw):
        super(FormField, self).__init__(name, **kw)

should be:

    def __init__(self, name=None, template=None, default=None,
                 validator=None, options=None, label=None, **kw):
        super(FormField, self).__init__(name, template, default,
                                        validator, options, **kw)
        ...

comment:27 Changed 13 years ago by aberto@…

Great! Better to have the bugs at the testing code than at the real code ;) I've fixed them at r660. There are still two tests regarding the new API that are failing... I'll take a look at it tomorrow and remove the kw abuse too.

Thanks! Albberto

comment:28 Changed 13 years ago by kevin

I'm going to work on removing options from base widgets and getting us switched over to the new API.

comment:29 Changed 13 years ago by michele

Great. :-)

Changed 13 years ago by michele

Fix for label management (needed for declarative style)

comment:30 Changed 13 years ago by michele

Added a small patch that fixes label management.

Changed 13 years ago by michele

Another patch to fix some problems with options

comment:31 Changed 13 years ago by michele

  • Summary changed from Widgets redux to [PATCH] Widgets redux

Fix some small but annoying problems with the above patch.

comment:32 Changed 13 years ago by alberto@…

I've commited widget-attrs.patch at r670

comment:33 Changed 13 years ago by alberto@…

Same with field_label.patch at r671. Thanks!

comment:34 Changed 13 years ago by anonymous

applied options-r633.patch at r672

comment:35 Changed 13 years ago by alberto@…

Hi,

I've tried to simplify the buttons and make them behave as the rest of the FormFields?, that is using "name" and "field_id" to set the name and id tag attribute instead of dattr?name? and dattr?id? (see r674) but it breaks test_submit() as the name is not overriden properly by the constructor somewhere around SimpleWidget? or FormField? (or their interaction as base classes of Button).

Is there any special reason the buttons use "attrs" to set their name and id instead of the standard Widget's "name" and FormField?'s "field_id"?

comment:36 Changed 13 years ago by michele

Hi Alberto,

we don't want buttons to behave like normal formfields, some times ago Widgets were stripping the submit name if there was a input value named "submit", but the right behavior is to not give a name to the submit button if this was not given to the constructor.

Also, we don't need to use attrs as you can see:

>>> from turbogears import widgets as w
>>> test = w.SubmitButton()
>>> test.render()
'<INPUT TYPE="submit" CLASS="submitbutton">'
>>> test = w.SubmitButton(name="submit")
>>> test.render()
'<INPUT TYPE="submit" CLASS="submitbutton" NAME="submit" ID="submit">'
>>>

Take a look at ticket #358

comment:37 Changed 13 years ago by anonymous

Yep,

But this fails on Declarative widgets (see #527) I'm commiting a failing unittest that shows this in 10 seconds ;)

Regards, Alberto

comment:38 Changed 13 years ago by michele

Yep it fails because on declarative the name is setted after widgets creation.

We need to make name on buttons a property that takes care of this.

Another thing, now that you added attrs support can you remove this line (added on r666) from the TextArea? widget?

attrs = dattrs?

This is already done in the right way by the base widget if I'm not wrong.

comment:39 Changed 13 years ago by anonymous

Oh, I see...

then the simplification at r674 shouldn't be done, right?

By the way, ticket #527 was a diferent story, sorry, but anyway, i'd like you too look at in two mins as i've made a patch that fixes it.... see what you think (maybe i'm missing something)

Thanks, Alberto

comment:40 Changed 13 years ago by michele

Will look after lunch wich I'm going to do now. ;-)

comment:41 Changed 13 years ago by alberto@…

¡Qué aproveché! ;)

comment:42 Changed 13 years ago by anonymous

I'm going to apply the changes Michele suggested yesterday to the widget's init signature to avoid kw abuse... be commiting soon.

comment:43 Changed 13 years ago by michele

Maybe I'm squared but I can't work out why I'm getting this strange behavior.

I was going to see if the test you added and 527 could be fixed (I think so) by just moving the field_class and field_id assignment on update_data but I'm getting a strange behavior.

That's how FormField? update_data looks:

    def update_data(self, d):
        super(FormField, self).update_data(d)
        d["field_class"] = self.__class__.__name__.lower()
        d["field_id"] = self.name

that's the strange things:

>>> from turbogears import widgets as w
>>> prova = w.TextField(name="ciao")
>>> prova.render()
'<INPUT ID="ciao" TYPE="text" CLASS="textfield" NAME="ciao">'

Perferct until I try the same inside a form:

>>> c = w.ListForm(fields=[prova])
>>> c.render()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/michele/Progetti/TurboGears/svn/turbogears/widgets/base.py", line 116, in render
    elem = self.display(value, **kw)
  File "/home/michele/Progetti/TurboGears/svn/turbogears/widgets/base.py", line 35, in lockwidget
    output = self.__class__.display(self, *args, **kw)
  File "/home/michele/Progetti/TurboGears/svn/turbogears/widgets/base.py", line 156, in display
    return view.transform(template_vars, template=self.template)
  File "/home/michele/Progetti/TurboGears/svn/turbogears/view.py", line 65, in t ransform
    return engine.transform(info, template)
  File "/home/michele/Progetti/TurboGears/svn/plugins/kid/turbokid/kidsupport.py ", line 114, in transform
    return ElementStream(t.transform()).expand()
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/pull.py", line 95, in expand
    for ev, item in self._iter:
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/pull.py", line 164, in _track
    for p in stream:
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/filter.py", lin e 21, in transform_filter
    for ev, item in apply_matches(stream, template, templates, apply_func):
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/filter.py", lin e 25, in apply_matches
    for ev, item in stream:
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/pull.py", line 164, in _track
    for p in stream:
  File "/home/michele/Progetti/TurboGears/svn/thirdparty/kid/kid/pull.py", line 206, in _coalesce
    for ev, item in stream:
  File "<string>", line 47, in _pull
AttributeError: 'TextField' object has no attribute 'field_id'
>>>

What's going on?

comment:44 Changed 13 years ago by michele

Damn, I'm flipped I've found the problem. Don't worry.

comment:45 Changed 13 years ago by alberto@…

Michele,

I've just commited at r692 the suggestions you made about the signatures.. is this what you were talking about (or am I flipped too ;)

Changed 13 years ago by michele

This fixes all tests and #527 with your patch Aberto, and adds some simplifications to Buttons ;-)

comment:46 Changed 13 years ago by alberto@…

Michele,

Just a quick question. Does the patch you're working on also solve the porblem the one at #527 does?? I'm thinking about commiting it... I'll wait for you opinion.

comment:47 Changed 13 years ago by anonymous

duh!! forget my last post....

comment:48 Changed 13 years ago by michele

[Got a trac Mind Air Collision :D]

Yep, that's what I was talking about. ;-)

I will take a closer look late tomorrow because now I should really go studying. :-(

The patch I posted fixes all problems and also uses your patch from #527.

Regarding field_id/field_class I have something in mind that I will try to materialize soon (I hope) that should help to reintroduce css_classes. I hope to move these things to the SimpleWidget?.

Ciao and thanks.

comment:49 Changed 13 years ago by michele

I've svn up before doing diff so my patch is not complete.

You can, or better you should (since it is now rendundant), remove the Button init method now.

Ciao

comment:50 Changed 13 years ago by alberto@…

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from [PATCH] Widgets redux to Widgets redux

commited at r693, thanks! I'll look at the buttons after a coffee... ;)

comment:51 Changed 13 years ago by anonymous

  • Status changed from closed to reopened
  • Resolution fixed deleted

oops, this forgot that this was the never-ending ticket.... ;)

PROPOSAL:

Shall we close it now that the new widgets are offcial?

comment:52 Changed 13 years ago by michele

Yep, take your coffee (hope for you that's an Italian "espresso" :P).

Button, as I said you can safely remove it, it was in my patch but got lost with svn up, run tests just to be sure after you've done it.

Your proposal, well I agree, now it's over and I will miss this ticket I think. :D

Ciao!

Now for some hours of study. :_(

comment:53 Changed 13 years ago by kevin

  • Status changed from reopened to closed
  • Resolution set to fixed

good luck with the studying.

bye, bye ticket 490!

Changed 13 years ago by michele

No validator on Widget

Changed 13 years ago by michele

nice one

Changed 13 years ago by michele

that's good

Changed 13 years ago by michele

optgroup support, initial patch

Changed 13 years ago by michele

Final version

Note: See TracTickets for help on using tickets.