Tom Sawyer <transami / transami.net> wrote in message news:<1027481479.853.582.camel / silver>...
> let me paint a picture:
> 
> you have this super application you wrote --the underbelly of an
> factastic hoogy-me-whatsy-do-it-all app and now you have to figure out
> how to put a front-end on her. so you need a gui. hmmm...you think, i
> want a gui thats flexible and fast nad highly functional, runs on just
> about any platform, looks good, preferably just like the native
> interface, and is easy as pie to code so as not to require much fussing
> with the app you've alredy written. 

What are the relative priorities of these requirements?

> well, if you look around you're going to discover that everything out
> there now has shortcomings. beleive me i've looked. so what do you do?
> you either pick one that minimizes the shortcomings as suited to your
> application, or you do what i'm trying to do: put an end to the problem.
> how does that bode for what i'm trying to achieve?

I don't think it will ever be possible to 'put an end to the problem'.
 The problem is that interface code, whether it's html, gui, whatever,
has it's own set of objects with their own hierarchies, etc.  Matching
the interface relationships to your existing object relationships will
always be a mess.

This is where I like your x.widgitize() idea -- it's a great *pattern*
for integrating the presentation code into your objects.  This pattern
requires you to discard notions about the "separation of
presentation", and instead follow rules such as "put functionality
near the required data".  I'm just not sure if it makes a good
*library*, b/c as I said before, x.widgetize() benefits from providing
generalized application specific widgets.

~ Patrick