Oh heck. I'm afraid that I've wasted some of your time - yes, of course
you're right in your first guess - the render action itself is what
kicks off the startUpdate exactly where you thought it was, and you
won't be able do do any other, non-update actions in your render code.
And I don't think that's changeable - that behavior would be required to
seamlessly use existing components with ajax calls.
So, that leaves two ways to do it - the first, by doing the script eval
in an event listener on the client (which you've said you'd prefer not
to do - fair enough). Though replacing the component's DOM shouldn't
really cause any more disruption than replacing the DOM of the diagram
div, I can understand a desire for caution. There are other related
mechanisms you could use as well, such as a onevent param to the ajax
call that looks at hidden fields emitted by your component, but again,
that would require a rerender of your custom component.
The second way would be to have a value change listener on the radio,
calling to a method that you have hung off the component, for instance -
that would then issue the eval. Should work - I've got some similar
code up and running for testing purposes. I think it'll send the eval
before the render, though, and that might not be what you want. If it's
not obvious on how to do that, let me know, and I'll send along a sample
- but you seem pretty clued in (to say the least - you were right about
the behavior, and I was not), so I'm assuming that you'll know what I'm
getting at.
All this talk has gotten me thinking about including inline script eval
into our FCS, though, and I'm going to start looking at that now. So
you should be able to do something inline by the time you move into
production with JSF 2 FCS - no promises, but I think I should be able to
get that in (filed as bug 1260 on Mojarra). Track the bug to see my
progress, and consider trying it out with your code on the nightly build
once that fix is in.
Jim