On 12/16/05, bruno desthuilliers <[EMAIL PROTECTED]> wrote: > > 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>
You're right that hidden inputs are different from typical widgets. However, when it comes to the input/output (specifically thinking of the conversions that validators do), you having them be widgets has some benefits in terms of code-reuse. People are also used to thinking in terms of hidden <input>s so it's not a mental leap to make them widgets. Kevin
