• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WOComponent children
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: WOComponent children


  • Subject: Re: WOComponent children
  • From: Chuck Hill <email@hidden>
  • Date: Mon, 7 Jan 2008 10:40:45 -0800


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


  • Follow-Ups:
    • Re: WOComponent children
      • From: Paul Hertz <email@hidden>
    • Re: WOComponent children
      • From: Mike Schrag <email@hidden>
References: 
 >Re: WOComponent children (From: email@hidden)

  • Prev by Date: Tips for deployment under jBoss 5.2.2, Java 1.5?
  • Next by Date: Re: IllegalArgumentException
  • Previous by thread: Re: WOComponent children
  • Next by thread: Re: WOComponent children
  • Index(es):
    • Date
    • Thread