bojangles-devel

[Bojangles-devel] dynamic widgets

[Nathan E. <neh...@cs...>]

hey guys,

i was working on getting bojangles to work with widgets.xml from
centrallix-doc.  i'm running into more and more issues with dynamic widgets
and want to hash some of this out on the list.  the problem i'm running into
is that i need all kinds of data about each widget that maybe shouldn't go
into centrallix's widgets.xml.  things like this:

- max_per_document - how many of this widget can be in an application
(example: widget/page should only be 1)
- width and height for widgets like the checkbox where it isn't a centrallix
property but is needed by the ide for drawing purposes
- speaking of drawing purposes, another thing is how each widget presents
itself to the IDE.  for example, textbuttons should have a raised border,
edit boxes should be lowered, imagebuttons should be able to display the
image, that kind of thing.
- what does a particular property mean (like bgcolor -- call setBackground
method on widget).

i'm not sure that all this kind of stuff should be going into centrallix for
bojangles' use only.

here's my current line of thinking:  what if we would have subclasses of the
Widget class to handle things such as the widget's visual representation in
bojangles and use the widgets.xml def to handle properties and individual
property types, etc.?  this does mean the widgets in bojangles need to be
synced with those in centrallix when new ones are added, but leaves the us
with the dynamic property list functionality.

what do you guys think?  bad idea?  good idea?  i like 100% dynamic, but we
just can't be 100% dynamic without adding all kinds of crazy stuff to
widgets.xml for handling drawing in bojangles that i can see.

other ideas?

nre

RE: [Bojangles-devel] dynamic widgets

[Jonathan R. <jo...@cs...>]

hey,

> hey guys,
>
> i was working on getting bojangles to work with widgets.xml from
> centrallix-doc.  i'm running into more and more issues with
> dynamic widgets
> and want to hash some of this out on the list.  the problem i'm
> running into
> is that i need all kinds of data about each widget that maybe shouldn't go
> into centrallix's widgets.xml.  things like this:
>
> - max_per_document - how many of this widget can be in an application
> (example: widget/page should only be 1)
well, there's only one widget that can only appear once (that I can think of
right now anyway) -- widget/page.  Maybe you could just add some special
handling for it?

> - width and height for widgets like the checkbox where it isn't a
> centrallix property but is needed by the ide for drawing purposes
hmm... didn't think of that one.... if we allow custom images (which I
forget if we do), maybe we _should_ have height and width specifers, even if
it's just to be more constitent.

> - speaking of drawing purposes, another thing is how each widget presents
> itself to the IDE.  for example, textbuttons should have a raised border,
> edit boxes should be lowered, imagebuttons should be able to display the
> image, that kind of thing.


> - what does a particular property mean (like bgcolor -- call setBackground
> method on widget).

again -- I think there's only a limited number of these.  Maybe there should
be another definition file that maps a property to what to do with it. (ie,
the image property sets the background image, the bgColor property sets the
background color, the background property sets the background image, etc.)


>
> i'm not sure that all this kind of stuff should be going into
> centrallix for
> bojangles' use only.
neither do I.  I think Greg would concur.

> here's my current line of thinking:  what if we would have
> subclasses of the
> Widget class to handle things such as the widget's visual
> representation in
> bojangles and use the widgets.xml def to handle properties and individual
> property types, etc.?  this does mean the widgets in bojangles need to be
> synced with those in centrallix when new ones are added, but leaves the us
> with the dynamic property list functionality.

see my comment above about a definition file providing a mapping of
properties to methods/actions/etc.

> what do you guys think?  bad idea?  good idea?  i like 100%
> dynamic, but we
> just can't be 100% dynamic without adding all kinds of crazy stuff to
> widgets.xml for handling drawing in bojangles that i can see.

I'd like 100% dynamic for basic functionality, with additional information
needed added to a special file bojangles maintains about the widgets.  IE,
when a new widget is added to centrallix that bojangles has never seen, have
it read the centrallix definition and provide basic functionality.  Later,
the bojangles developers can decide how to render it in it's full glory, and
add 'extra' definition info the the bojangles definition file (while still
getting the basic info from the centrallix one)


That's the extent of my thoughts for the evening..


Jonathan