Re: WOComponent children
Re: WOComponent children
- Subject: Re: WOComponent children
- From: Chuck Hill <email@hidden>
- Date: Mon, 7 Jan 2008 10:15:08 -0800
On Jan 5, 2008, at 3:46 AM, Lachlan Deck wrote:
Hi there, just a couple of thoughts if it's of any value...
On 05/01/2008, at 4:05 PM, Chuck Hill wrote:
On Jan 4, 2008, at 3:13 PM, email@hidden wrote:
If you ask a WOComponent for its template (which is roughly
its .html/.wod structure), you can then *almost* ask the template
to go down the tree for its children as WOComponents. This is not
straightforward because as far as I can tell, you got to do a lot
of "cursor incrementing" and tricky instantiation of
WOComponents. Not only do you have to deal with the "template"
but you must also consider a "_childTemplate" for when you've got
WOComponentContent and WOComponentReference objects. I've got
some code now that doesn't quite work because on a complex page
it gets the bindings confused when I try to push a
WOComponentReference into context.
I've asked a similar question about a day ago on the WOnder list,
but I've learned a bit more and realize it may be more
appropriate to ask the question here. So sorry if this appears to
be a bit of deja vu for those who read both lists but it's
actually a bit more than that. If you read the earlier message,
please disregard it as I believe this one is more meaningful.
Consider the following code snippet offered by Mr. Rentzsch:
http://www.wodeveloper.com/omniLists/webobjects-dev/2002/July/
msg00246.html
I got so excited when I saw this only to find out that this
example only works in the trivial case, when you don't have any
WOComponentContent such as a PageWrapper component. To make it
work in the general case appears to be very tricky and also
inefficient.
Yes, it gets interesting when you go beyond the simple case.
I was curious as to your reason...
WOSwitchComponent, WOComponentContent, custom WODynamicElement
subclasses...
It becomes impossible at a certain point.
The reason why I'm doing this is because I'm trying to bootstrap
a phase into the request-response loop. In any given reuseable
subcomponent I'm designing, I want to be able to simply implement
"addRequiredWebResources(WOResponse, WOContext)". Inside this
method I would make calls that would examine the HTML response
content and insert multiple lines between the HTML head tags. For
example, CSS file resources and Javascript file resources. This
way I don't need monolithic CSS and JS files but can break the
files down and associate them with the reusable components that
need them. When a page is rendered to the user, only the
necessary JS and CSS resources are referred to in the link and
import statements of the head tag, automatically.
For this to work fully, appendToResponse() must go first so that
we have some "head" tags to discover. But before appendToResponse
() is done, it needs to call "addRequiredWebResources()" on every
possible subComponent in the tree... *every* one of them. This
means it needs to contact even those subComponents that are
inside of WOConditional containers that evaluated to false.
There, I think you might hit a brick wall. If WOConditional
evaluates to false, the contents essentially do not exist. You
will also have trouble with things like WOSwitchComponent.
Yeah. Two thoughts FWIW:
* perhaps the app could make these decisions by building up a cache
at runtime of the reduced possibilities. e.g., when the app starts
you could scan disk for the list of components and if their
accompanying java file implements a certain interface build up some
kind of tree of data.
* I'd be looking at be using the userInfo dictionary of the
WOResponse to store the bootstrapping content as each component
draws in the normal phase of the rr loop and then inserting that
into the head of the content prior to releasing the response. That
would save the double pass.
So yes, there would be many components whose "appendToResponse()"
was not called but "addRequiredWebResources()" was in fact called.
Before the world of partial page refreshes via AJAX and other
means, none of this mattered. But now, because I can refresh a
portion of the screen and show a previously missing "coolWidget"
subComponent that requires "coolLib.js" I'm in trouble. Problem
is, in a partial page refresh, there is no "head" tag so
"coolWidget" will fail horribly because "coolLib.js" is not
referenced between the head tags of the page. In a full page
refresh (before the Web 2.0 era) there is no problem because the
head tag is readily available. Get the picture?
I really need some advice here or a sample of how to get to all
the children and children's children of the outmost WOComponent.
Conceptually it would also be interesting to understand why Apple
only exposes the "parent" relationship of a WOComponent. When you
*really* think about it, it makes a lot of sense to get to your
children and not so much to get to the parent. Obviously
internally WebObjects knows how to get to the children, otherwise
appendToResponse won't work. You kind of need to know how to get
to the guys underneath you. Every time I think about the "parent"
relationship the usefulness of it smacks of *clever*. Like maybe
executing the action of a parent WOComponent. But once you do
something like that, you've heavily tied the subComponent to the
parent and it no longer becomes reuseable. Think of a car tire.
That tire should work no matter what car I put it on. I should be
able to pull it from one truck and place it on another without a
care in the world. If the tire wants to let us know that its air
pressure is low then it would just shout "airPressureLow()" and
the right components of the car should be registered to listen to
that message, so there is no need to get to the "parent()".
I fear, without an adequate answer to the question of "how do I
get to my children", our beloved tool of choice can no longer
provide truely reusable WOComponents for the Web 2.0 era.
It is regrettable, but I don't think it can. There is no way to
know all possible states of the page when it is first rendered.
You can probably get past the WOConditional problem, but I can't
see any way past data driven decisions like WOSwitchComponent.
Your (very desirable) wish "This way I don't need monolithic CSS
and JS files but can break the files down and associate them with
the reusable components that need them." seems particularly unlikely.
Not being a js guru, but thinking about the possibilities:
* I'd imagine that prototype etc could be used to dynamically load
new or reload javascript/css on_complete, no?
* is it possible to have a js lazy @import a file only as needed?
That sounds like an interesting and probably much better approach.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden