The only solution I see right now is to modify the ajax request to
return in a structured way what are the needed resources and build a
js library that will interpret this and adjust the dom to include
those needed resources.
- jfv
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.
Le 08-01-15 à 12:23, [EMAIL PROTECTED] a écrit :
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
