> 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.
Well, there are ways around that. I'm thinking a new interface, say ScriptUpdatable, which could be a marker interface or even have a method to generate the change element. PartialViewContext would check for it and if present on the component or its renderer, call the interface method to generate the change item rather than calling startUpdate and encode*. Components & renderers that don't implement the interface would not see any change.
I'd be happy to produce an implementation if it fits into your process at this time in the release cycle. It would be really important to me to have my component play together well with the Ajax support in JSF 2.
>
> 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.
Ah, I wondered how that eval code in the blog got triggered. I'll be out for a couple of days, I'll give those a try when I get back.
>
> 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
>
I will keep an eye on it. Thanks again for your help.
Judy
[Message sent by forum member 'judys' (judys)]
http://forums.java.net/jive/thread.jspa?messageID=361249