Skip to main content

JSF2: using JavaScript to update a component

41 replies [Last post]
judys
Offline
Joined: 2009-07-23
Points: 0

My components (porting from 1.2) currently use JavaScript/JSON for Ajax updates, so I would like to put something like the following in my renderer's encodeEnd method:

if (context.getPartialViewContext().isAjaxRequest()) {
PartialResponseWriter w = (...) context.getResponseWriter();
w.startEval();
w.write("myUpdateFunction();");
w.endEval();
}

By the time my renderer's encodeEnd gets called, someone has (understandably) already called the responseWriter's startUpdate, and I get a nested CDATA error. Closing the update first doesn't work either. What should I be doing to prevent the startUpdate call being made?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
judys
Offline
Joined: 2009-07-23
Points: 0

Yes! That does make all the difference! Thank you. I'll test the rest of the browsers.

driscoll
Offline
Joined: 2003-06-06
Points: 0

> Jim,
> Here's a rundown of yesterday's experiences with the
> Aug28 nightly build.
>
> #1: It doesn't seem to be executing my JavaScript. My
> renderer writes something like this:
>
> <div id="diagram" ... > ... html here
> ...</div> <script> ... javascript here
> ... </script>
>
> I tried putting the script inside the div, but to no
> avail. The subtree does get replaced though, and the
> responseText on the client side looks good.

OK, this should work, so I'd like to concentrate on this for now.

First, what browser? Have you tried it in more than one? Have you tried something simple like alert("it works"); in your inline script? (You're missing type="text/javascript", but I don't think that will cause a failure, even in Firefox.)

If you could give me the [b]exact[/b] text of the response, I can try to see what's happening.

judys
Offline
Joined: 2009-07-23
Points: 0

Jim,
Here's a rundown of yesterday's experiences with the Aug28 nightly build.

#1: It doesn't seem to be executing my JavaScript. My renderer writes something like this:

<div id="diagram" ... > ... html here ...</div> <script> ... javascript here ... </script>

I tried putting the script inside the div, but to no avail. The subtree does get replaced though, and the responseText on the client side looks good.

#2: So, try the script execution function from Hakem's blog. It immediately trips up when assigning the CDATA contents to the tmp node's innerHtml, but I deleted the offending JavaScript and got it to work. It blinks badly though when replacing the diagram.

#3: Try working around the blinking by rendering an empty div with the diagram's id on it followed by the real stuff, and then on the partial update replace the empty div and execute the JavaScript/JSON update code.

The JSON includes an array enclosed in square brackets. When the ResponseWriter encountered the left square bracket, it replaced it with a right one, closed the CDATA block and opened a new one. Because this code should in theory work in a non-JSF environment, I use the writer's write(String) method, not the higher-level methods, so I wouldn't expect it to do something like that.

After replacing the square brackets with new Array(...) it works well, still using the script execution function from the blog. I worry that the empty div hack will come back to bite me though.

judys
Offline
Joined: 2009-07-23
Points: 0

>
> #1: It doesn't seem to be executing my JavaScript.

My apologies, I was using SeaMonkey. It doesn't execute the scripts in SeaMonkey but it works in Firefox.

driscoll
Offline
Joined: 2003-06-06
Points: 0

> My apologies, I was using SeaMonkey.

I hate it when that happen. I've (once or twice) made a similar mistake.

I've tested the code functionality in Opera 10, IE 6,7,&8, FF 3.5, Safari 4 and Chrome 4. Essentially, any browser with a decent market share that isn't utterly broken for ajax (which is why IE 5.5 was left out).

No real plans on testing SeaMonkey. Or Konqueror. And I've gotta say, I was really disappointed by the Ajax support in Lynx - I had such high hopes :-)

But if for some reason SeaMonkey is important to you, you may want to check which version you're running - the first google hit for "seamonkey javascript" doesn't fill me with confidence on the stability of their js code - though that user had his problems resolved by upgrading to 1.1.7. So I'd start there first. Current version seems to be 1.1.9, with a 2.0 beta on deck.

I have used SeaMonkey in the past for some things like testing comet, but I'd be pretty surprised if it had any serious usage in the wild... And given that I'm already forking the code path in three directions to do script eval, if they can't manage one of them, I'm not inclined to go out of my way for this browser, though I'm always willing to accept patches.

driscoll
Offline
Joined: 2003-06-06
Points: 0

FYI: Because any error report bothers me, I went ahead and tested JSF with Seamonkey 1.1.7 on Ubuntu.

It works fine.

So it's likely not even SeaMonkey that's the problem, but more likely your installation of it, or it may be a previous version.

judys
Offline
Joined: 2009-07-23
Points: 0

> FYI: Because any error report bothers me, I went
> ahead and tested JSF with Seamonkey 1.1.7 on Ubuntu.
>
> It works fine.

Thanks, that's good to know. I'm aware that I'm one of the last people on earth to be using SeaMonkey and I'm not expecting you to support it.

judys
Offline
Joined: 2009-07-23
Points: 0

I hate to revive this again but...

Yesterday I decided to modernize and I downloaded Firefox 3.0.14 and 3.5.3 onto my Linux box (I won't say what version I was using ;-). I discovered that neither one executes the script in the Partial Response. So I tried Firefox 3.0.13 and 3.5.3 on my WinXP box, and they're not executing it either.

I do apologize for not trying them earlier.

What does work for me is Firefox 2.0.0.2 on Linux, and IE7 and Safari (probably not the latest) on WinXP.

Here's the output from my Dojo console. printData is my onevent function. My onerror function did not get called. (and there were no server errors or JavaScript errors either).

printData, type=event, status=begin
printData, type=event, status=complete
responseText=

]]>


printData, type=event, status=success

In browsers that do execute the script, I would see "Hello from DRH" either before or after the 'status=success' line. (Oh, and I have become compulsive about clearing browser caches:-)

Is anyone else having problems (or successes) with this in Firefox?

driscoll
Offline
Joined: 2003-06-06
Points: 0

What version are you using? This area went through quite a few revisions.

We test on FF 3.5 - so I'd be surprised if this is failing on the current version.

judys
Offline
Joined: 2009-07-23
Points: 0

> What version are you using? This area went through
> quite a few revisions.
>
> We test on FF 3.5 - so I'd be surprised if this is
> failing on the current version.

I tried sep 28 and oct 5 nightly builds.

Jim Driscoll

OK, I'll check it out and let you know.

Jim

On 10/6/09 9:00 AM, webtier@javadesktop.org wrote:
>> What version are you using? This area went through
>> quite a few revisions.
>>
>> We test on FF 3.5 - so I'd be surprised if this is
>> failing on the current version.
>
> I tried sep 28 and oct 5 nightly builds.
> [Message sent by forum member 'judys' (judy@apprisant.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=367018
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

driscoll
Offline
Joined: 2003-06-06
Points: 0

Bug confirmed, and filed as 1353.

It doesn't effect all scripts, only some. Why it only effects some is what I'm trying to discover right now.

driscoll
Offline
Joined: 2003-06-06
Points: 0

It's an escaping issue.

For today, you should use ' (single quote) instead of " (double quote).

I'm working on a fix that I hope to have ready for tonight's build.

Thanks for finding this!

driscoll
Offline
Joined: 2003-06-06
Points: 0

Fix checked in into nightly.

If the problem persists, please reopen bug 1353.

Again, thanks for finding this and reporting it.

judys
Offline
Joined: 2009-07-23
Points: 0

I just downloaded the oct 7 nightly, but I see no change from before. I tried both single and double quotes around the "Hello from DRH" (assuming that's what you meant). I looked for some distinguishing identification in the jsf.js script to make absolutely sure I had the new one but couldn't find anything.

I don't think I have access to reopen the issue because it's not mine.

I'll assume the fix didn't make the build and I'll try again tomorrow.

driscoll
Offline
Joined: 2003-06-06
Points: 0

The change wasn't in the jsf.js, so cacheing isn't the problem.

If you're getting a failure with single quotes, then you are experiencing a different problem than the one I fixed.

Does this work?

alert('it works');

?

Note single quotes. Because that works for me.

If that works, then it's a problem getting access to the console object - which is going to be an interesting issue to fix remotely. That should work - and I have tests to make sure that it does.

Message was edited by: driscoll

judys
Offline
Joined: 2009-07-23
Points: 0

> The change wasn't in the jsf.js, so cacheing isn't
> the problem.
I was thinking it had to be because the responseText is correct, and it works in other browsers.
>
> If you're getting a failure with single quotes, then
> you are experiencing a different problem than the one
> I fixed.
>
> Does this work?
>
> alert('it works');
>
> ?
>
> Note single quotes. Because that works for me.

No it doesn't. That is, it works in IE7, Safari and Firefox 2.0, but not in FF 3.0 and 3.5, on either WinXP or Linux. Here's my console output:

printData, type=event, status=begin
printData, type=event, status=complete
responseText=

]]> printData, type=event, status=success

>
> If that works, then it's a problem getting access to
> the console object - which is going to be an
> interesting issue to fix remotely. That should work
> - and I have tests to make sure that it does.

It has to be something more than the console because the original problem was that my diagrams weren't getting updated, no console involved.

If you can give me an instrumented jsf.js file, or tell me whereabouts to look in it, I could try playing with it here.

The other thought that comes to mind, more so with the PreDestroy problem, is that I'm running Glassfish 2.1 and Tomcat (the latest) with the mojarra libs, and not Glassfish 3.0. Maybe it's time I tried 3.0. I'll let you know how I get on.

judys
Offline
Joined: 2009-07-23
Points: 0

Just wanted to add that I took out dojo and my own script file, and the alert still did not appear.

driscoll
Offline
Joined: 2003-06-06
Points: 0

I just noticed that the div you are updating does NOT include the script tag that follows it.

That's probably the problem, but let me do a code trace, and see if that's the issue.

And I'd be inclined to say that that's a program bug, rather than a framework bug, but I'll have to read the spec for that one too.

Wanted to reply immediately, rather than wait to figure that out, so you can resolve your issue immediately if possible.

driscoll
Offline
Joined: 2003-06-06
Points: 0

Finished the code trace, and yep, that's what happening.

Since I don't expect there to be a script tag after the element for update, the behavior is inconsistent, and I'm inclined not to change that unless there's a good use case.

In your case, putting the script tag inside the div should fix everything.

The next question is, is this required by the spec? Well, I think it's vague:
--------------
# For any other element:



Find the DOM element with the identifier that matches the element identifier, and replace its contents with the element's CDATA contents.
---------------

While that [b]seems[/b] to imply that you can update with multiple elements on first reading, it actually doesn't say that at all - since the update action itself needs to apply to a single element - which implies only a single element as a CDATA argument.

I'll file the spec bug for clarification once java.net decides to visit the waking world again.

In the meantime, please let me know if this doesn't fix your problem... We're almost at ship, and I'm eager to get any bug reports early - I'd love to ship something as rock solid as possible. (And thanks for reporting this.)

driscoll
Offline
Joined: 2003-06-06
Points: 0

P.S. Sorry I didn't spot this earlier! On the bright side, you got me to find and fix a serious, if utterly unrelated bug :-)

judys
Offline
Joined: 2009-07-23
Points: 0

Well, I'm sorry, I should have tried that earlier.
Anyway, all my browsers check out as expected (incl. Seamonkey)

I did notice one odd thing though. If I write this:

responseText=

]]>

]]>

The src param is a URL. If I write it as is, it fails on Seamonkey, Firefox 2.0, and Safari 3.2 and 4. If I escape the ampersands, it fails on everything else. I know you don't care about Seamonkey and FF2, but Safari 4 is the latest & greatest, downloaded in the last hour.

This is not an issue for me, I'm sure I can find a workaround and rebuild the URL on the client side, but I thought you should know.

Jim Driscoll

I'll try to look at this tonight.

Do you mean that the object isn't created? That's odd, and may be
related to your not escaping the actual JS code inside the script with
CDATA (which is complicated, since CDATA doesn't nest). But I won't
know until I try, I guess.

Jim

On 10/7/09 4:25 PM, webtier@javadesktop.org wrote:
> Well, I'm sorry, I should have tried that earlier.
> Anyway, all my browsers check out as expected (incl. Seamonkey)
>
> I did notice one odd thing though. If I write this:
>
> responseText=
>

>

]]>
>

]]> >
> The src param is a URL. If I write it as is, it fails on Seamonkey, Firefox 2.0, and Safari 3.2 and 4. If I escape the ampersands, it fails on everything else. I know you don't care about Seamonkey and FF2, but Safari 4 is the latest& greatest, downloaded in the last hour.
>
> This is not an issue for me, I'm sure I can find a workaround and rebuild the URL on the client side, but I thought you should know.
> [Message sent by forum member 'judys' (judy@apprisant.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=367185
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

On Safari with unescaped ampersands I get the following in the console (printErr is my onerror function):

printData, type=event, status=begin
printData, type=event, status=complete
responseText=

]]>

]]> printErr, status=malformedXML
desc=NO_MODIFICATION_ALLOWED_ERR: DOM Exception 7
responseCode=200
errorName=undefined
errorMessage=undefined

On IE7 and FF3.5 with escaped ampersands I don't get an error but the diagram goes blank, meaning it couldn't get an image for the url.

driscoll
Offline
Joined: 2003-06-06
Points: 0

I've filed this as issue 1357, and will be tackling this one next.

driscoll
Offline
Joined: 2003-06-06
Points: 0

Bug confirmed, it effects all Webkit browsers, which include Safari, Chrome and mobile Safari (iPhone).

Thanks for finding this.

Fix in progress.

driscoll
Offline
Joined: 2003-06-06
Points: 0

This bug is now fixed, and should be available in the nightly.

driscoll
Offline
Joined: 2003-06-06
Points: 0

P.S. Thanks for catching this, and feel free to reopen the bug if you're still encountering problems.

driscoll
Offline
Joined: 2003-06-06
Points: 0

Just as a notice to anyone reading this - the ability to parse inline JavaScript has been added, as well as fixing a bug with as well - so if you would like to use this functionality, you need to use a more recent build than the 2.0RC - either a nightly, or the FCS release when it comes out.

Jim Driscoll

I'm afraid I don't understand your question... What class is calling
startUpdate?

Jim

On 8/18/09 2:15 PM, webtier@javadesktop.org wrote:
> My components (porting from 1.2) currently use JavaScript/JSON for Ajax updates, so I would like to put something like the following in my renderer's encodeEnd method:
>
> if (context.getPartialViewContext().isAjaxRequest()) {
> PartialResponseWriter w = (...) context.getResponseWriter();
> w.startEval();
> w.write("myUpdateFunction();");
> w.endEval();
> }
>
> By the time my renderer's encodeEnd gets called, someone has (understandably) already called the responseWriter's startUpdate, and I get a nested CDATA error. Closing the update first doesn't work either. What should I be doing to prevent the startUpdate call being made?
> [Message sent by forum member 'judys' (judys)]
>
> http://forums.java.net/jive/thread.jspa?messageID=361050
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

I don't have the source so I don't know who is calling startUpdate. From reading the spec and the API doc I'm suspecting PartialViewContext.processPartial just because it's his job to update the components on his list. It could also be UIComponentBase, it doesn't say. UIInput (the class I'm extending) doesn't have any encode methods.

It would make sense to do it that way if your components are all simple and not ajax-aware, but I hope there's a way around it for those where it matters.

If I do what I said above, I get "IllegalStateException: CDATA tags may not nest" in the glassfish log.

If I put in a call to endUpdate before I start the eval, and a startUpdate after ending the eval, then the server part runs to completion, but the client side fails while trying to update the DOM, presumably because of the empty update tag. But I can print the response on the client side with an onevent handler, and there it is, an update element with an empty CDATA, an eval with my output, and another update with an empty CDATA.

Jim Driscoll

OK, still not understanding exactly what you're doing. But let me make
a guess.

You're updating a section of your page with an ajax call, yes?

That section of page is larger than the single component which you've
written, right? Maybe, say, @form?

Just a guess. That's one thing that would explain what you're seeing.
There are others, but without details, it's hard to say.

If so, why not just update only that component?

But this is only guessing - you haven't really said much about what
you're doing.

Jim

On 8/18/09 9:14 PM, webtier@javadesktop.org wrote:
> I don't have the source so I don't know who is calling startUpdate. From reading the spec and the API doc I'm suspecting PartialViewContext.processPartial just because it's his job to update the components on his list. It could also be UIComponentBase, it doesn't say. UIInput (the class I'm extending) doesn't have any encode methods.
>
> It would make sense to do it that way if your components are all simple and not ajax-aware, but I hope there's a way around it for those where it matters.
>
> If I do what I said above, I get "IllegalStateException: CDATA tags may not nest" in the glassfish log.
>
> If I put in a call to endUpdate before I start the eval, and a startUpdate after ending the eval, then the server part runs to completion, but the client side fails while trying to update the DOM, presumably because of the empty update tag. But I can print the response on the client side with an onevent handler, and there it is, an update element with an empty CDATA, an eval with my output, and another update with an empty CDATA.
> [Message sent by forum member 'judys' (judys)]
>
> http://forums.java.net/jive/thread.jspa?messageID=361089
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: webtier-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

Sorry, I didn't mean to be obtuse.

My component is a diagram, showing different data for different dates. The page has a h:selectOneRadio which lets you select between two dates. You can see the JSF1.2 incarnation of the page here:

http://www.apprisantj.com/jsfdemos/camp/reserve.faces

In the h:selectOneRadio I put the following:

The spec tells me that execute defaults to @this, so I would expect the radio button to update its value expression, and the diagram to get re-rendered. In fact looking at the output, the diagram is the only thing it is trying to render.

Jim Driscoll

On 8/19/09 8:52 AM, webtier@javadesktop.org wrote:
> Sorry, I didn't mean to be obtuse.
>
> My component is a diagram, showing different data for different dates. The page has a h:selectOneRadio which lets you select between two dates. You can see the JSF1.2 incarnation of the page here:
>
> http://www.apprisantj.com/jsfdemos/camp/reserve.faces
>
> In the h:selectOneRadio I put the following:
>
>
>
> The spec tells me that execute defaults to @this, so I would expect the radio button to update its value expression, and the diagram to get re-rendered. In fact looking at the output, the diagram is the only thing it is trying to render.
> [Message sent by forum member 'judys' (judys)]
>
> http://forums.java.net/jive/thread.jspa?messageID=361194

OK, now we're getting somewhere.

Yes, by updating the diagram (which appears to be what, a PanelGrid?),
you're launching an render update of the entire section, including
everything underneath it, including the radio button. That kicks off a
large update, which will in turn wrap your component - meaning that you
can't do an eval in the middle of it.

If you want to use eval, you'll have to be more specific about what
you're rendering, and list each component one by one. (Space separated
list). Then, it should work.

Or, if you look at my blog (Google Jim Driscoll java), about three or
four entries back you'll see a pointer to a blog that explains how to
use the event system to execute a script returned inline from a component.

As for what is getting executed vs what is not, @this is supposed to be
executed by default, yes. Is that not what you're seeing? (A debug run
with a break on your set method should show it being executed.)

Jim

P.S. Your example is an excellent argument for allowing inline
execution of scripts without having to use eval - I'm going to take this
example to the Expert Group as part of the argument.

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

> On 8/19/09 8:52 AM, webtier@javadesktop.org wrote:
> >
> OK, now we're getting somewhere.
>
> Yes, by updating the diagram (which appears to be
> what, a PanelGrid?),
> you're launching an render update of the entire
> section, including
> everything underneath it, including the radio button.
> That kicks off a
> arge update, which will in turn wrap your component -
> meaning that you
> can't do an eval in the middle of it.

Jim,
Thanks for your efforts looking at this.

My diagram component is written in Java (not a composite component), and doesn't contain any other facets, children, or HTML. It renders as a div containing lots of HTML with scripts around it. The radio button is not inside it, it is another component in the form. I don't want the form updated, just the diagram, and when I print the response I see updates for the diagram and the view state, that's all.

(Having said that, I have no control over what my users might want to do, but lets stay with this scenario for now.)

>
> If you want to use eval, you'll have to be more
> specific about what
> you're rendering, and list each component one by one.
> (Space separated
> list). Then, it should work.

But, isn't that what I'm doing? Is there something else I need to do? Here's the outline of my page:


...
...


...

...

>
> Or, if you look at my blog (Google Jim Driscoll
> java), about three or
> four entries back you'll see a pointer to a blog that
> explains how to
> use the event system to execute a script returned
> inline from a component.
>
I did see that, I was hoping to use the eval solution, not the script execution solution. I'll try it if there's no way with eval.

> As for what is getting executed vs what is not, @this
> is supposed to be
> executed by default, yes. Is that not what you're
> seeing? (A debug run
> with a break on your set method should show it being
> executed.)

I'm assuming it works for now.
>
> Jim
>
> P.S. Your example is an excellent argument for
> allowing inline
> execution of scripts without having to use eval - I'm
> going to take this
> example to the Expert Group as part of the argument.
>

Thanks for your consideration, but I would really prefer the eval solution so it doesn't replace my component's DOM subtree. Besides being less efficient I worry that it will be visually disruptive, especially in IE, which was the whole point of doing Ajax.

Jim Driscoll

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

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

> 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

Jim Driscoll

On 8/19/09 2:52 PM, webtier@javadesktop.org wrote:
> 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.

Unfortunately it doesn't - the spec is final, and not able to be
modified right now.

I'd encourage you to file your suggestion as a spec enhancement request,
it sounds like a good one (and easy to do, as well).

https://javaserverfaces-spec-public.dev.java.net/issues/enter_bug.cgi

Jim

---------------------------------------------------------------------
To unsubscribe, e-mail: webtier-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: webtier-help@glassfish.dev.java.net

judys
Offline
Joined: 2009-07-23
Points: 0

>
>
> On 8/19/09 2:52 PM, webtier@javadesktop.org wrote:
>
> Unfortunately it doesn't - the spec is final, and not
> able to be
> modified right now.

Yes, I understand.

>
> I'd encourage you to file your suggestion as a spec
> enhancement request,
> it sounds like a good one (and easy to do, as well).

Will do. Thanks again for all your help.

Jim Driscoll

I've filed a 616, 619, and 620 against the spec.

I've also just checked in code against Mojarra bug 1260 - it fixes a big
problem with , where it wasn't working correctly in all browsers.
It also allows execution of inline