Re: WOComponent children
Re: WOComponent children
- Subject: Re: WOComponent children
- From: Paul Hertz <email@hidden>
- Date: Wed, 9 Jan 2008 17:42:10 -0600
Belatedly (rogue server-wrangling intervened) arriving at this
thread, I wonder if a document architecture model I developed might
also suggest some possibilities.
Essentially there are three parts to the docuemnt architecture: a
data store class (EO), a document node class that serves to build
trees where each node has an arbitrarily long list of child nodes,
and document component class, subclass of WOComponent.
For each subclass of data store there is a corresponding node class.
When I build a document, I start with the root store, build the tree
from the corresponding root node, and then pass the tree to the
subclass of document component that is the first-but-one component in
the display graph (a PageWrapper is the root). The graph gets built
be traversing the tree--each node/store pair encodes the necessary
information about resources, component class, etc.
Now, this does not currently handle components wrapped in
WOConditionals that don't fire, but I suppose potentially it could.
The tree is developed before I actually construct the corresponding
component graph. It has various Vistor classes that can traverse it
to set anchors, delete, add, save nodes, change editing state, find
parents once-removed, etc. A visitor could build resource lists even
for components that will be switched off, since a node could be in
the tree even if its component ends up not loading. All that can be
done before passing the document tree (nodes and associated stores)
to an actual component, which builds the document by getting
component class names (passed to WOSwitchComponent) and other
necessary data from the node/store pairs.
The inconvenience, of course, is that you have to build a mediating
structure. Still, it's fairly light weight, and stores much of its
structure as XML. I have not yet made it cross over into the Ajax
world, but that is certainly a goal.
However, I have to say that I am a little unclear about the design
merits of loading CSS and JS scripts piecemeal into the header.
Probably just my own design prejudice, but I try to design a handfull
of stylesheets and script files that will cover the situations that I
anticipate, and plan for them to stay in the client cache once
loaded. It may be that I simply don't do anything complicated
enough--and I note that caching was one of the concerns expressed.
Anyhow, my late-clinking 2c.
-- Paul
At 10:40 AM -0800 1/7/08, Chuck Hill wrote:
On Jan 7, 2008, at 10:27 AM, email@hidden wrote:
Thank you Chuck, Simon, Anjo, Lachlan, and others. You've all given
good insight and I appreciate you thinking about the problem.
The idea of WOComponent.awake() sounds appealing but I got a
question about it. I like the idea of every WOComponent on the page
getting the awake() message and then building an ordered "array" of
items that need to be placed between the head tags. Then, later
through various means that people have already mentioned, we slap
those resources between the "head" tags before we return the
response to the user. Problem is, I don't think that *every*
component on the page gets that "awake" message. Can someone verify
this for me? I did a test which I'll explain below but the results
are confusing.
No, it is only called for WOComponent subclasses that will get
rendered. e.g. it is not called for the children of a WOConditional
that evaluates to false.
I have a "DateWidget.wo" WOComponent that uses complex Javascript
to validate the date the user types and keeps them on the field
until the data is either in the correct format or is blank. It even
disables the form from submitting or the user from closing the web
browser while the data is invalid. This is complex stuff that is
contained in "DateWidget.js"
I made a quick test by adding "awake()" to "DateWidget.java". All I
did was log out a statement to let me know when the "awake" message
was invoked. I then went to a page that showed a list of search
results. Clicking on any search result would do a partial page
refresh to show editable fields and other detailed information.
That "detail view" is inside a WOConditional which is also under an
AjaxUpdateContainer. Here's what happened:
1) Initial page load with nothing in the detail view:
No logging information. I was bummed when I realized this. I was so
hoping that the component, even though it was inside a
WOConditional that evaluated to false, would still have it's
"awake" message fired. Seems reasonable that it would "awake" but
not have "appendToResponse" called, but that's not what happened.
Things inside a conditional that evaluates to false do not exist.
That is one of the reasons that hacking a WO app is harder than some
other architectures.
2) Clicking on a search result to do a partial page refresh and
show the detail view:
"awake" message was logged. Makes sense, especially since it had
it's "appendToResponse" called too.
3) Deselected the search result so that no detail view was
displayed, then refreshed the page (full page load):
To my amazement, even though there was no "DateWidget.wo" currently
displayed via "appendToResponse", it *did* in fact have its "awake"
message fired. Wow! How does that work given that in test #1 above
"awake" never happened. Seems to me that this should be the same
situation as test #1, but somehow, just by having been displayed at
least one time, it is now in the "awake" graph even when it is not
visible any longer.
Is the conditional around it true or false?
See, I'm all confused. Maybe it's something wrong with my test that
I'm overlooking. Does anyone know if this is the proper behavior
for "awake"? Should "awake" always be called even if
"appendToResponse" is not called?
Awake is just not going to give you what you want. I think the only
thing that will do that is some major changes to WO. It would
probably be best to do something like record the needed resources in
the .api file and when the .wo template is parsed, this information
gets propagated up to the page. I think this would be more
successful and trying to handle this as part of the RR loop.
Conceptually, this seems more associated with interpreting the
template than with a specific request. And when you are parsing the
WOD file, it is easy to see what is used, regardless of later
WOConditional states. That said, WOSwitchComponent is still going
to break that.
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
--
Paul Hertz <email@hidden>
|(*,+,#,=)(#,=,*,+)(=,#,+,*)(+,*,=,#)|
<http://collaboratory.nunet.net/phertz>
_______________________________________________
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