Kevin Dangoor <[EMAIL PROTECTED]> writes: > That's good to hear! Hopefully, I'm not breaking things too badly with > the refactoring I'm doing. I do think the widget API is going to look > quite streamlined and easier-to-subclass when I finish. (The next > commit will actually have quite a bit of cleanup in it.)
C'mon man! Commit it! ;-) Hehehehe... I'm trying something and I'm liking it. I just miss some stuff from writing my raw code in HTML templates (such as adding JavaScript to perform some functions such as data validation, integrating controllers (e.g. one SelectWidget that through AJAX populate the next widget), or to provide hints on how to fill a certain field), but in general they make things easier and I can write raw code for more complex forms instead of for every form. Another thing I miss are better means to position widgets on the form. Using a TableForm, for example, I can't put two widgets on the same row to save vertical space. > This was discussed either in a ticket or on the list... Here was the > thinking: just giving a column name isn't good enough. (Consider a > table with last name, first name and middle initial). Of course, you > can use a property instead. But, what I was figuring was that what > we're really angling for when you're displaying that is the > human-understandable form of that particular object. And that's what > __unicode__ or __str__ are all about, right? I really would love being able to return HTML / XHTML / XML / ... here. This way for some widgets we'd be able to provide more dinamicity. And it would also solve the "problems" I've talked above (since if I can return HTML I can embed JavaScript on it). The idea is that we be able to replace the active parts of widgets (e.g. for a DataGrid be able to return HTML for the contents of each cell, for a CheckableList be able to modify the input element and so on) and not the whole widgets (otherwise we could write templates on our own for each widget -- this is not a bad idea ;-)). -- Jorge Godoy <[EMAIL PROTECTED]>
