Kevin Dangoor wrote: > > On 12/15/05, Jared Kuolt <[EMAIL PROTECTED]> wrote: > >>I've created a Hidden widget and I'd like it so that it won't show up >>in the TableForm. What would be a best practice for that? Shall we >>have a "hidden" parameter? I'm more than willing to incorporate it >>into turbogears.widgets.forms. >> >>The real problem lies in the fact that each widget is for'd, like so: >> <tr py:for="widget in widgets"> >>And basically forced into the display. >> >>Thoughts?
> We could add a hidden parameter to the widget (by default False in the > base class). > > <tr py:for="widget in widgets" py:if="not widget.hidden"> > > I believe the for comes before the if in Kid's order of attributization :) I don't think this is the right way to go. The problem is that Hidden inputs are a 'type' by themselves - and yet they are a special case when it comes to display. My first go was to have two lists - one for 'ordinary' widgets, and one for hidden input widgets - but then we have another special case for any other processing on the widgets collection :( <thinking-out-loud> Should even hidden inputs be widgets ? Their real use is to maintain state informations between requests, not to be part of the UI. What about adding a 'stateData' dict to the form, that would be rendered as hidden inputs ? </thinking-out-loud> My 2 cents... -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com
