On 1/17/06, Michele Cella <[EMAIL PROTECTED]> wrote: > > Mike Kent wrote: > > > > One thing I learned while doing this project is the current Widget base > > class is very form-input oriented. I see from comments from Kevin and > > Karl that what I set out to do is not really in line with the original > > intended use for widgets. It may be a mistake to limit our scope. We > > might want to take a look at refactoring the current Widget base class > > to move the form-input code out to a new 'FormWidget' class that would > > be the base class of form-oriented classes.
(Responding to Mike for a moment) The form input code is one method that is bounded with if self.validator If you don't set validator, you effectively have a display-only widget. Unless you're referring to the use of input_values when determining the appropriate display value for the widget? > My ideal vision: > > Widget > |__ TagWidget > |__ FormField > > TagWidget is a widget whose output/template is just a single tag and > hence supports attributes using py:attrs. TagWidget really sounds like STAN or htmlgen. I don't think that wheel needs reinvention, and widgets are designed to encapsulate something more complex than just "<foo>Bar</foo>". > > CompoundWidget (or ContainerWidget) > |__ Form > > I think TG should just focus on providing Form-oriented widgets and > entry-points for thirdparty widgets. That is definitely the focus. Kevin
