random thought ...
I think the problem come from the component design in place, where we essentially build a stream of html text.
In the web2 world, we would instead build a dom graph object.
If we where to redesign the component model, so that every component is a valid dom object, and can be expressed either by java call (dom4j for example), or by using a xml-like template (xhtml like the current .wo template that would unfreeze in real dom java objects), we could build from that a nice InterfaceBuilder-like (WOBuilder on steroids) application with palette !
Considering that an ajax request can result in a dom not representing the whole document, we would need a _javascript_ library, designed in a specific way (compliant with the wo-dom-component model) so that it can insert in the browser the desired _javascript_/css dom element to include the missing resources.
We could build a dom-component-architecture _above_ WO (wo providing a rich and efficient plumbing infrastructure). I think that the actual wonder way of doing, which is to mix-match the actual text-stream model with a higher level dom-component is like asking for incompatible model to fit together. Hard work from Mike and Anjo succeeded to minimize the pain we inflict on ourselves trying to do so (but still it doesn't make the concept right, it just hide it a bit longer).
Building a dom-like component architecture should be the work of Apple at this point, not the community work.
Considering that the community/other already build similar architecture (flex, openlaslo just come to mind and many others that I either not know or don't remember the name), it's tempting to just use what is already there instead of trying to build a new one above wo.
Thank you Paul Hertz, Lachlan Deck, and Alexandar Spohr for your recent thoughts on the subject.
The ultimate goal is "resusability." If you were to post to me and say "Aaron, those widgets you made are cool, can I use them?" I would like to be able to just give you a framework file and let you just link it into your project. All you should have to worry about is dropping "CoolDateWidget" on a page and it would just work. You shouldn't be concerned with the following three points:
1) Don't worry that CoolDateWidget is inside a WOConditional that is inside an AjaxUpdateContainer. When the page loads you won't see the CoolDateWidget, but after selecting a choice from a dependent popup (dropdown), it would appear. I don't want this widget to break on you in this circumstance.
2) I shouldn't have to tell you to place one or more _javascript_ and CSS resources in some static HTML web directory and then add them to the head of your page wrapper. You might forget one of them, you might place them out of order, the site admin might forget to upload them, moreover... why should you care? The CoolDateWidget should be a black box with exposed bindings that just works. You don't *have* to know how it works.
3) I shouldn't have to tell you to extend all of your page level components from MyGenericComponent in my framework instead of WOComponent. Doing this might allow me to get things right with some special logic but now you are in a bind. What if not only I did this but some guy named Tom also did this in his framework. Now you have to choose between Tom's framework and mine because you can't extend from both MyGenericComponent and TomsGenericComponent at the same time. Bummer.