At 04:28 PM 5/31/01 -0700, brian moseley wrote:
>On Thu, 31 May 2001, Gunther Birznieks wrote:
>
> > I think it can be supported through a custom subclass of
> > what you have been describing as a container/controller
> > for the widgets. I think if it is done at the widget
> > level it is bloating the widget set and I honestly don't
> > see why a widget should know about languages.
>
>depends on how granular your widgets are. if you have a menu
>widget that also displays a label, the widget needs to know
>where to place the label relative to the menu. this choice
>will probably differ for various languages. course you add
>some kind of location api to the widget, but then you're
>bloating again. or you can just keep labels outside widgets
>;)
Yes, but this is a more direct containment than a form which is likely to
have many elements in it other than widgets. In this case, a widget
directly contains other widgets. I think this is potentially OK and makes
it easy to create a template-based tag. But when you have to keep track of
a form tag that has widgets inside but may have arbitrary HTML as well,
it's a more difficult/complex problem.
As I have mentioned in a previous mail here, I think a composite widget is
probably reasonable (for the locale and html vs wml output) but likewise, a
composite widget could also be used to configure other widgets displaying
simultaneously (and not as a switch based on language) to determine order
of menu items and labels and whatnot.
While I think these examples are good and they show advanced thought in all
sorts of things widgets can be used for. The reality is many of these
things are exceptions that are usually more an issue for windows systems
than the abstraction that I would like to deal with a majority of the time
-- just making my dealing with FORMs easier than it is now, within a short
period of time was and is my primary goal.
If you can accomplish the things you want without changing the basic
behavior and without forcing me to fill-in a huge API whenever I write a
widget class, then that is fine. But I think we need to focus on the
*core* API and getting the *core* objects out so that they can be used.
I believe atomic widgets, if we can at least agree on that can be fine for
me and all of you who want fancy stuff can write controllers and composite
widgets that do you fancy stuff exactly the way you want. I just don't want
the widgets themselves to be large and difficult to implement.
