Kevin Dangoor wrote: > 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.
You're probably right on this point. > People are also used to thinking > in terms of hidden <input>s so it's not a mental leap to make them > widgets. For sure, and that's why my first take was to make them widgets. But having'em in the widgets list of a form means handling a special case, and not having'em in this list also means handling a special case. We may want to have in fact three list attributes in the form : visible widgets, hidden widgets and all widgets (implementing the last one as a property returning the concatenation of the two others). My 2 cents -- bruno desthuilliers développeur [EMAIL PROTECTED] http://www.modulix.com
