Hi Alexander this method only works on Firefox and Opera it fails on IE
(which is covered) and on Webkit (Safari, Konqueror and Chrome)
So we need to extend the browser checks and also add versions to the
browser checks like dojo does (the eval behavior changes over versions
IE for instance does it up to 5.5 or so automatically then has turned it
off)!
As for the response XML!
I am aware of the eval area, I just recently coded it in, however bear
in mind following:
This method is limiting because the eval area only can be filled
if the ResponseWriter can handle it, normally response writers
react only to writer.startElement("script" to trigger the evals. If they
do it this way you can do it in linear runtime complexity.
However there are corner cases where it still makes sense to do a manual
eval / or browser based ones.
What if someone writes writer.write("bla bla bla <script type... ">);
You either need to add an extra parsing layer, and you have to performe
a two pass operation (first buffer and concatenate until you have
sufficient info to do the parsing) or you can offload it to the browser
where you really can handle it properly. In any way you would introduce
an operation which slows down the rendering at a vital part which is
triggered a lot! So it is better to offload such a thing to the browser
where a server side operation would slow things down!
For performance reasons we could add a config param which turns the
inline browser eval off, or have it turned off by defalt, but I am not
sure if all component sets
will behave nicely and will go over the PrintWriter api accordingly.
Past has shown that they don´t!
So if a component set performes nicely leave it off, if it does not turn
the runtime switch on on your page...
(Btw. Trinidad for instance does only the startElement("script"
behavior, I have not checked the RI in this area, but I rather doubt
they will do a lot more! It simply does not make sense to slow down the
responsewriter if the browsers at least some of them can deal with this
issue in performant ways!)
Werner
Alexander Bell schrieb:
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] <mailto:[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] <mailto:[email protected]>
Webprofil: http://www.j4fry.org/alexanderbell.shtml
