Hi Pierre, I hear what you're saying. Adding a new method to WOComponent that would only be used for HTML generation feels unclean. But, to play devil's advocate, you wouldn't implement that method in your WOComponent unless you are generating HTML and it sure provides an elegant solution. You could make a WOHTMLComponent (child of WOComponent) if you really want to keep WOComponent completely agnostic.
Alternatively, if there was an easy way to get to the "children" and descendants of a WOComponent, we would then have the ability to modify things enough on our own to get this kind of functionality when desired. As far as I can tell, the only thing stopping this is a WOSwitchComponent. I've never used these because the only binding is a String denoting the name of a reusable component and any potential components that you hook up must exhibit the same API bindings. I've always found a couple of WOConditionals around a handful of resuseable components just worked better for me than conditionial logic in a method returning the String name of a component to a switch component. I'm trying to understand your Direct Action suggestion but I can't get my head around it. I don't see the inner plumbing that will figure out what reusable components are going to be displayed on the page, even after many partial AJAX update container refreshes, and then put that information into one or more cacheable references between the head tags during the initial page load. Thanks, -- Aaron >This is an interesting issue. Currently WebObjects component system does not know >what kind of page it is generating, XML, HTML, _javascript_ and I am not too keen on >specializing with knowledge of HTML head tags. >I would like to make another suggestion why not generate your _javascript_ in a direct >action. Just create a direct action Create a response that will hold your _javascript_ and >call a method on each of your component to push there _javascript_ when it is all done >just return it. WebObjects can be used to generate _javascript_ not just HTML.
_______________________________________________ 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]
