Those three points make it very clear. It is presently impossible to
develop effective reusable objects for the Web 2.0 era in
WebObjects. Mike's and Lachlan's ideas to manipulate the DOM to load
the required resources could work in the major browsers, but it's
tricky and appears to be the easiest way around a fatal flaw in the
WO component architecture. That fatal flaw is that the tree of
components that make up a page does not exist. Each node gets
temporarily built piece meal through a lot of pushing and popping in
and out of woContext in each phase of the request-response loop.
Another way to say this is that there is no notion of "children" and
that is what is really needed. The "parent" relationship should be
considered optional and avoided for reusable components.
I hardly thing this makes it "impossible to build reusable objects"
nor is it a "fatal flaw" in WebObjects. First of all, I'm not sure I
even grant that the proper behavior is that every component should
automatically get its javascript pre-included in the page. This is
not a fatal flaw in WebObjects, rather it's an _impossible_ problem to
solve in the way you're proposing. It is not possible to know every
component that might every be included in a page. You would have to
walk the entire component list and include EVERY SINGLE javascript in
the page (because a WOSwitch could switch to any component in your
entire app).
Fundamentally you're including components dynamically, so it seems to
me the proper solution is to include its javascript dynamically as
well. Have you looked at what your Ajax components are doing in
Javascript already? I'm not sure how dynamically including javascript
file references is any more trickery or hackery than the insanity
that's already happening to pull this stuff off. Not to mention it
will be written one time in something like Ajax framework and you'll
just automagically inherit it for all of your Ajax components (a
google quick search shows several implementations of this already).
For that matter, the default implementation of scriptaculous ALREADY
works this way -- look at scriptaculous.js -- it dynamically loads the
other parts of the framework (effects.js, builder.js).
The ideal solution is for "addWebResourcesInHead()" to not be static
and to be called automatically by the WO framework at the right time
so that it can put the proper values in the head. That way, no other
fiddling is necessary and "GenericComponent" is no longer needed. Do
I ask for too much? I think not.
Yes :)
I really feel for Mike, Anjo and others who continue to fight
valiantly against all odds. The WOnder team are the innovators right
now. WOnder should be packaged together with WebObjects... yea it
should BE WebObjects. You should be free to fix the problems with
rapid-turn-around-mode parsing of updated resources without having
to sit and wait for Apple to incorporate them. I can go on... But
our champions can't do this so long as WebObjects is closed source.
Apple, if you love WO, set it free.
I think you're looking at this in the negative. I don't see what Anjo
and I and other folks do as fight valiantly ... I see it as having an
amazing framework base that makes it easy to build upon. Imagine
trying to do half of the crazy things that Wonder does on top of any
other framework. Most do a TERRIBLE job at incorporating the necessary
hooks at the right levels to pull that stuff off. It's very rare that
I look at a problem with WO and think that I just can't make it work.
ms
_______________________________________________
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]
