Hi Werner
we had the same problem with insertBefore/insertAfter. Check our solution in
Utils.js:
if (newTag != "") {
if (typeof window.Range != 'undefined'
&& typeof Range.prototype.createContextualFragment ==
'function') {
try {
var range = document.createRange();
range.setStartBefore(item);
var fragment = range.createContextualFragment(newTag);
} catch (t) {
var fragment = range.createContextualFragment
(org.j4fry.script.common.Utils.replaceHtmlEntity(newTag));
}
item.parentNode.insertBefore(fragment, item);
} else {
item.insertAdjacentHTML('beforeBegin', newTag);
}
if (org.j4fry.script.common.Utils.isUserAgentInternetExplorer())
{
org.j4fry.script.common.Utils.runScripts(item.previousSibling);
}
}
You don't need to call the "runScripts" method becaus in JSF2.0 Ajax there's
a special "eval" area for JavaScripts so you don't have to check and execute
the tag if this is a script tag or not.
We haven't used a browser check. We call a method if this method throws an
exception we try another method ;-)
That would be greatful if we use a browser check now :-)
@Ganesh
In my oppinion the insert and delete elements in the response XML make sense
in some cases.
If you've got an element which wasn't rendered at first time you can't
replace it with JavaScript becaus it doesn't exists. So you have to insert
it.
But there's no possibility (in the response xml) to define where the new
element should be inserted, right?
2009/4/17 Werner Punz <[email protected]>
> Another thing I noticed after trying out the Auto eval triggered
> by insertBefore and insertAfter
>
> This method seems to work only on Firefox and Opera, Webkit definitely does
> not like it and needs a manual eval of embedded scripts
> so we need to extend our browser checks in the code!
>
> Cheers
>
> Werner
>
>
>
> Werner Punz schrieb:
>
>> Ok Ganesh most of the response cycle now works as expected
>> I did not manage in time however to fix up the code for the
>> update for a full body or head replacement to use
>> beforeNode or afterNode to auto trigger embedded scripts!
>>
>> You might work that in instead of me.
>>
>> Another thing wich came to my mind if anyone from the EG is reading this.
>> There is a weird issue regarding the viewState handling in the spec!
>>
>> The spec says that an element with the identifier javax.faces.ViewState
>> has to be added to every form if it does not exist within the update phase
>> if viewState itself is responded!
>>
>> The funny thing is, that normally no two elements with the same
>> identifiers are allowed within the dom tree. The API clearly supports this
>> by limiting the getter function within the dom by getElementById!
>>
>> Well the browsers mostly support this, one way or the other but this
>> causes sideeffects by the browsers if you do direct dom access!
>>
>> So is this really as it should be or do the viewState elements just have
>> the name javax.faces.ViewState and have a different id like
>> formId:javax.faces.ViewState
>>
>> Does anyone have any idea?
>>
>> I did not code this part yet because this was rather unclear to me!
>>
>>
>> Werner
>>
>>
>> Werner Punz schrieb:
>>
>> Ganesh schrieb:
>>>
>>>> Hi Werner,
>>>>
>>>> There are some corners within the ajax response XML format that doesn't
>>>> make much sense for me in respect to JSF. Especially for the insert, delete
>>>> and attributes sections of the update element I cannot see how to trigger
>>>> them from the existing jsf.ajax.request interface. Still they must be
>>>> implemented because they make part of the spec and I'm thankful that you
>>>> are
>>>> taking on these hard-to-test tasks.
>>>>
>>>> Actually I have to recheck the entire java part especially the JavaDocs
>>> (have in mind the about half of the specs functionality is documented in the
>>> javadocs instead of the PDF)
>>> if there are cases where the deletes and inserts can be triggered from
>>> within the components automatically.
>>>
>>> My personal guess is that this stuff is a handful of shortcuts for the
>>> component writers so that they can gain some additional functionality easily
>>> which would be hard to deal without.
>>>
>>> After all within the context of a classical response writer api
>>> the inserts and deletes are hard to process but sometimes you need them.
>>> I´d rather have a protocol which is more extensive in this area than
>>> having a few missing parts which then cannot really be added!
>>>
>>> But I haven´t been too much concerned with the java side of the jsf spec
>>> for now because I usually focus on one area before going into the next!
>>> So I am not sure if I have missed something there!
>>>
>>>
>>> The jira task on the extensions (MYFACES-2174) is NOT for the visual
>>>> part. The visual part (disable components and show loading bar during
>>>> request) would truely make a good extension, but I've set this aside until
>>>> the core is fully functional. The jira is for the addional attributes for
>>>> the xhr core: pps, queuesize and errorlevel.
>>>>
>>>>
>>> Ok thanks for the clarification.
>>>
>>>
>>> Werner
>>>
>>>
>>>
>>
>>
>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: [email protected]
Webprofil: http://www.j4fry.org/alexanderbell.shtml
