You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Werner Punz <we...@gmail.com> on 2009/04/16 17:13:42 UTC
MyFaces 2.0 Ajax
Hello Alex and Ganesh
Following:
I have coded most of the response handling parts which were still
missing. There is one big todo left in the update regarding the
viewstate + forms the spec and jsdoc is not entirely clear in this area
I have to
recheck that before going further in this area!
However the parts I coded are not tested yet, I just coded them for now
trying to be syntax error free and trying to follow the spec, I am
writing as we speak some testcases to iron out the bugs as well as
browser inconsistency bugs (setAttribute still needs testing on the IE 6
and 7 due to lousy bug ridden implementations on that browsers of the
original W3C spec)!
All javascript code is committed...
Feel free to take over!
I will finish the testcases tomorrow (which I cannot for now commit into
myfaces because we do not have selenium tests yet) but I then have to
work on another project, which has higher priority due to customer
demands! I will iron my code out thursday and friday next week! During
my opensource days!
Ok what needs to be done, my code needs to be ironed out (I will do it
next week anyway so there is no big rush, I just want to get some tests
in place to have a testing ground for the code)
we could start to work on the iframe handling for fileuploads, to have
that corner case covered,
The two todos in the response part still need some treatment!
Your visual stuff can be moved into the planned extensions (Ganesh seems
to be working on that currently afair the jira issue opened)
Werner
Re: MyFaces 2.0 Ajax
Posted by Werner Punz <we...@gmail.com>.
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 <werner.punz@gmail.com <ma...@gmail.com>>
>
> 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: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 Ajax
Posted by Alexander Bell <Al...@j4fry.org>.
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 <we...@gmail.com>
> 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: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 Ajax
Posted by Werner Punz <we...@gmail.com>.
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
>>
>>
>
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
We probably have to point this out to the EG, since it is rather easy to
fix this this should be fixed, after all to deal with those cases
is what the name attribute in inputs exists for.
It would be easy to have several viewState hidden fields
one per form with <formId>:javax.faces.ViewState and the name
javax.faces.ViewState...
Werner
Alexander Bell schrieb:
> Hi,
>
> in the past we did it in this way that we looking for the element only
> in the affected form.
> So in the form there is only one element with the id javax.faces.ViewState.
> It is also necessary that every form contains a hidden field with this
> id. So for JSF ok but it breaks the w3c standard and you can't use
> document.getElementById.
> We've got a appropriate code snippet in the j4fry code.
>
>
> 2009/4/19 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>
> Hi Werner,
>
> 2 elements with the same id truely brake the HTML standard. And it's
> true, with Mojarra 2.0 and 2 forms on a page I get 2 identical
> <input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2"
> name="javax.faces.ViewState"/>
> elements!
>
> Still, I'm not able to find this in the specs, can you please point
> me to the section you are referring to?
>
> 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!
>
>
> Best Regards,
> Ganesh
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
Hi Alexander/Ganesh there are two parts of the spec one being the PDF
the other being the JavaDocs and JSDocs, you can find the issue in the
JSDocs for jsf.ajax.response specifically in the section dealing with
the updates in the responseXML!
here is the section:
If an update element is found in the response with the identifier
javax.faces.ViewState:
..... snip other behavior
if the <form> element does not contain an element with the identifier
javax.faces.ViewState, create an <input> element of the type hidden,
with the identifier javax.faces.ViewState, set its contents to the
<update> element's CDATA contents, and add the <input> element as a
child to the <form> element.
note the term identifier here, which leaves no discussion that the id
has to be used identifier == id in my opinion not the name which would
be the proper way to resolve this in a html conform manner!
Werner
Alexander Bell schrieb:
> Hi,
>
> in the past we did it in this way that we looking for the element only
> in the affected form.
> So in the form there is only one element with the id javax.faces.ViewState.
> It is also necessary that every form contains a hidden field with this
> id. So for JSF ok but it breaks the w3c standard and you can't use
> document.getElementById.
> We've got a appropriate code snippet in the j4fry code.
>
>
> 2009/4/19 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>
> Hi Werner,
>
> 2 elements with the same id truely brake the HTML standard. And it's
> true, with Mojarra 2.0 and 2 forms on a page I get 2 identical
> <input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2"
> name="javax.faces.ViewState"/>
> elements!
>
> Still, I'm not able to find this in the specs, can you please point
> me to the section you are referring to?
>
> 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!
>
>
> Best Regards,
> Ganesh
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
Matthias Wessendorf schrieb:
> On Mon, Apr 20, 2009 at 9:05 AM, Werner Punz <we...@gmail.com> wrote:
>> Hia...
>>
>> I sent a comment regarding this issue towards the given jcp-comments mail
>> address. Lets see what happens.
>
> :-) /dev/null ?
>
That was mean :-)
I will also talk to Martin about it as you said, btw...
Another thing which really irks me generally. Since day zero about 90%
of the problems of the end users revolve around the fact that there is
no decent direct validation control for endusers within the spec.
We have immediate, which does not work out for many cases, since it just
shifts phases, we have
since jsf1.2 the possibility of adding alternate lifecycles which is
frankly spoken to complicated for many users and component sets add
subforms which also is outside of the spec but work out best so far
although they are still more complicated than a simple validation attribute!
An attribute in the command links or buttons with validation=true/false
would go a long way of removing a huge issue most users have with jsf.
(the other one the component api thankfully has been resolved)
I am glad Gerhard is adding something along those lines now to extVal,
but I think in the long run a simple attribute in the button or command
link which automatically turns off validation could help users
tremendously. I am not sure why this still has not made it into the spec.
Werner
Re: jsdoc spec enhancement request from MyFaces 2.0 development team
Posted by Matthias Wessendorf <ma...@apache.org>.
Ganesh,
have you filed an issue on their bug tracker ?
-M
On Tue, Apr 21, 2009 at 9:10 AM, Ganesh <ga...@j4fry.org> wrote:
> Hi,
>
> When developing the AJAX part of MyFaces 2.0 we encountered 2 locations
> within the jsdoc part of the spec we'd propose for enhancement.
>
> The first is about the hidden inputs for view state: The jsdocs for
> jsf.ajax.response imply that each hidden input receives the id
> "javax.faces.ViewState" which would result in multiple hidden inputs with
> this id in a multi form document. This is how Mojarra is currently working
> things out, but other implementations should get a chance to use a w3c
> conformant approach - the hidden inputs don't need ids at all, but only
> name=javax.faces.ViewState. A comment on this was already posted by Werner
> Punz.
>
> The second is about replacing the body section of a document if the server
> sends the id javax.faces.ViewRoot: The jsdocs for jsf.ajax.response say that
> the impl should >>extract the contents of the <body> element from the
> <update> element's CDATA content and replace the document's <body> section
> with this contents<<. According to this the attributes of the body element
> wouldn't be replaced with the new attributes, which probably isn't the
> intended behaviour. Preserving the attributes can either be achieved by
> copying them or by using contextualRagen/adjacentHTML instead of innerHTML.
>
> Here is a proposal for changing the jsdocs for jsf.ajax.response to enable
> both enhancements mentioned above - please correct the jsdoc for <static>
> jsf.ajax.response(request, context)
> like this:
>
> If an update element is found in the response with the identifier
> javax.faces.ViewRoot:
>
> <update id="javax.faces.ViewRoot">
> <![CDATA[...]]>
> </update>
>
> Update the entire DOM as follows:
>
> * Extract the CDATA content and trim the <html> and </html> from the
> CDATA content if it is present.
>
> <<<<<<< (remove the following lines)
>
> * If the CDATA content contains a <head> element, and the document has a
> <head> section, extract the contents of the <head> element from the <update>
> element's CDATA content and replace the document's <head> section with this
> contents.
> * If the CDATA content contains a <body> element, and the document has a
> <body> section, extract the contents of the <body> element from the <update>
> element's CDATA content and replace the document's <body> section with this
> contents.
>
> ======= (add the following lines)
>
> * If the CDATA content contains a <head> element, and the document has a
> <head> section, replace the document's <head> section with the <head>
> section contained within the CDATA content.
> * If the CDATA content contains a <body> element, and the document has a
> <body> section, replace the document's <body> section with the <body>
> section contained within the CDATA content.
>
>>>>>>>>
>
> * If the CDATA content does not contain a <body> element, replace the
> document's <body> section with the CDATA contents.
>
> If an update element is found in the response with the identifier
> javax.faces.ViewState:
>
> <update id="javax.faces.ViewState">
> <![CDATA[...]]>
> </update>
>
> Include this state in the document as follows:
>
> * Extract this <update> element's CDATA contents from the response.
>
> <<<<<< (remove the following lines)
>
> * If the document contains an element with the identifier
> javax.faces.ViewState replace its contents with the CDATA
> contents.
> * For each <form> element in the document:
> o If the <form> element contains an <input> element with
> the identifier javax.faces.ViewState, replace the
> <input> element contents with the <update> element's
> CDATA contents.
> o If the <form> element does not contain an element with the
> identifier javax.faces.ViewState, create an <input>
> element of the type hidden, with the identifier
> javax.faces.ViewState, set its contents to the <update>
> element's CDATA contents, and add the <input> element as
> a child to the <form> element.
>
> ======= (add the following lines)
>
> * Set the value of all elements within the document with the name
> javax.faces.ViewState to the CDATA contents
> * Perform the following optionally, implementations my omit this to
> enhance performance, as it enforces a search within the DOM tree. For each
> <form> element in the document:
> o If the <form> element does not contain an element with the
> name javax.faces.ViewState, create an <input> element of
> the type hidden, with the name javax.faces.ViewState,
> set its value to the <update> element's CDATA contents,
> and add the <input> element as a child to the <form>
> element.
>
>>>>>>>>
>
> Best Regards,
> Ganesh Jung
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
jsdoc spec enhancement request from MyFaces 2.0 development team
Posted by Ganesh <ga...@j4fry.org>.
Hi,
When developing the AJAX part of MyFaces 2.0 we encountered 2 locations
within the jsdoc part of the spec we'd propose for enhancement.
The first is about the hidden inputs for view state: The jsdocs for
jsf.ajax.response imply that each hidden input receives the id
"javax.faces.ViewState" which would result in multiple hidden inputs
with this id in a multi form document. This is how Mojarra is currently
working things out, but other implementations should get a chance to use
a w3c conformant approach - the hidden inputs don't need ids at all, but
only name=javax.faces.ViewState. A comment on this was already posted by
Werner Punz.
The second is about replacing the body section of a document if the
server sends the id javax.faces.ViewRoot: The jsdocs for
jsf.ajax.response say that the impl should >>extract the contents of the
<body> element from the <update> element's CDATA content and replace the
document's <body> section with this contents<<. According to this the
attributes of the body element wouldn't be replaced with the new
attributes, which probably isn't the intended behaviour. Preserving the
attributes can either be achieved by copying them or by using
contextualRagen/adjacentHTML instead of innerHTML.
Here is a proposal for changing the jsdocs for jsf.ajax.response to
enable both enhancements mentioned above - please correct the jsdoc for
<static> jsf.ajax.response(request, context)
like this:
If an update element is found in the response with the identifier
javax.faces.ViewRoot:
<update id="javax.faces.ViewRoot">
<![CDATA[...]]>
</update>
Update the entire DOM as follows:
* Extract the CDATA content and trim the <html> and </html> from
the CDATA content if it is present.
<<<<<<< (remove the following lines)
* If the CDATA content contains a <head> element, and the document
has a <head> section, extract the contents of the <head> element from
the <update> element's CDATA content and replace the document's <head>
section with this contents.
* If the CDATA content contains a <body> element, and the document
has a <body> section, extract the contents of the <body> element from
the <update> element's CDATA content and replace the document's <body>
section with this contents.
======= (add the following lines)
* If the CDATA content contains a <head> element, and the document
has a <head> section, replace the document's <head> section with the
<head> section contained within the CDATA content.
* If the CDATA content contains a <body> element, and the document
has a <body> section, replace the document's <body> section with the
<body> section contained within the CDATA content.
>>>>>>>
* If the CDATA content does not contain a <body> element, replace
the document's <body> section with the CDATA contents.
If an update element is found in the response with the identifier
javax.faces.ViewState:
<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>
Include this state in the document as follows:
* Extract this <update> element's CDATA contents from the response.
<<<<<< (remove the following lines)
* If the document contains an element with the identifier
javax.faces.ViewState replace its contents with the CDATA
contents.
* For each <form> element in the document:
o If the <form> element contains an <input> element with
the identifier javax.faces.ViewState, replace the
<input> element contents with the <update> element's
CDATA contents.
o If the <form> element does not contain an element with the
identifier javax.faces.ViewState, create an <input>
element of the type hidden, with the identifier
javax.faces.ViewState, set its contents to the <update>
element's CDATA contents, and add the <input> element as
a child to the <form> element.
======= (add the following lines)
* Set the value of all elements within the document with the name
javax.faces.ViewState to the CDATA contents
* Perform the following optionally, implementations my omit this to
enhance performance, as it enforces a search within the DOM tree. For
each <form> element in the document:
o If the <form> element does not contain an element with the
name javax.faces.ViewState, create an <input> element of
the type hidden, with the name javax.faces.ViewState,
set its value to the <update> element's CDATA contents,
and add the <input> element as a child to the <form>
element.
>>>>>>>
Best Regards,
Ganesh Jung
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
Hia, my mail was not answered so it probably went to /dev/null
because it was with the same content but not as exact as the one from
Ganesh regarding the id issue :-)
Werner
Matthias Wessendorf schrieb:
>
>
> Sent from my iPod.
>
> Am 21.04.2009 um 06:05 schrieb Ganesh <ga...@j4fry.org>:
>
>> Hi Matthias and Werner,
>>
>> The partial submit issue I posted to jsr-314-comments@jcp.org received
>> nearly instant response from Roger Kitain. Definitely not /dev/null,
>> these guys really take their job serious.
>
> That was a joke about the hidden discussions on almost all EGs.
>
>> Werner, it would be great, if you forwarded your mail to the
>> dev@myfaces list, so we can see what happens to it.
>
> CC to the original list would be good
>>
>> Afaik the spec doesn't say anything about the view state issue apart
>> from the JS docs (does anybody know any other places that talks about
>> the id of the hidden view state inputs?). The Javascript shouldn't
>> work based on the hidden inputs ids, but based
>
>
> In trinidad we render no ID b/c of that ...
>
>> on the hidden inputs names. Here's a proposal on how to change the JS
>> docs. If you agree, I'll post it to jsr-314-comments@jcp.org.
>>
>
> +1 and a CC to this list? That would be great
>
> Thx
> Matthias
>
>> Correct the jsdoc for <static> jsf.ajax.*response*(request, context)
>> like this:
>>
>> If an |update| element is found in the response with the identifier
>> |javax.faces.ViewState|:
>>
>> |<update id="javax.faces.ViewState">
>> <![CDATA[...]]>
>> </update>|
>>
>> Include this |state| in the document as follows:
>>
>> * Extract this |<update>| element's |CDATA| contents from the response.
>>
>> <<<<<< (remove thes following lines)
>>
>> * If the document contains an element with the identifier
>> |javax.faces.ViewState| replace its contents with the |CDATA|
>> contents.
>> * For each |<form>| element in the document:
>> o If the |<form>| element contains an |<input>| element with
>> the identifier |javax.faces.ViewState|, replace the
>> |<input>| element contents with the |<update>| element's
>> |CDATA| contents.
>> o If the |<form>| element does not contain an element with the
>> identifier |javax.faces.ViewState|, create an |<input>|
>> element of the type |hidden|, with the identifier
>> |javax.faces.ViewState|, set its contents to the |<update>|
>> element's |CDATA| contents, and add the |<input>| element as
>> a child to the |<form>| element.
>>
>> ======= (add the following lines)
>>
>> * Set the value of all elements within the document with the name
>> |javax.faces.ViewState |to the CDATA contents
>> * For each |<form>| element in the document:
>> o If the |<form>| element does not contain an element with the
>> name |javax.faces.ViewState|, create an |<input>| element of
>> the type |hidden|, with the name |javax.faces.ViewState|,
>> set its value to the |<update>| element's |CDATA| contents,
>> and add the |<input>| element as a child to the |<form>|
>> element.
>>
>> >>>>>>>
>>
>> Best Regards,
>> Ganesh
>>
>>
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Matthias Wessendorf <mw...@gmail.com>.
Sent from my iPod.
Am 21.04.2009 um 06:05 schrieb Ganesh <ga...@j4fry.org>:
> Hi Matthias and Werner,
>
> The partial submit issue I posted to jsr-314-comments@jcp.org
> received nearly instant response from Roger Kitain. Definitely not /
> dev/null, these guys really take their job serious.
That was a joke about the hidden discussions on almost all EGs.
> Werner, it would be great, if you forwarded your mail to the
> dev@myfaces list, so we can see what happens to it.
CC to the original list would be good
>
> Afaik the spec doesn't say anything about the view state issue apart
> from the JS docs (does anybody know any other places that talks
> about the id of the hidden view state inputs?). The Javascript
> shouldn't work based on the hidden inputs ids, but based
In trinidad we render no ID b/c of that ...
> on the hidden inputs names. Here's a proposal on how to change the
> JS docs. If you agree, I'll post it to jsr-314-comments@jcp.org.
>
+1 and a CC to this list? That would be great
Thx
Matthias
> Correct the jsdoc for <static> jsf.ajax.*response*(request, context)
> like this:
>
> If an |update| element is found in the response with the identifier |
> javax.faces.ViewState|:
>
> |<update id="javax.faces.ViewState">
> <![CDATA[...]]>
> </update>|
>
> Include this |state| in the document as follows:
>
> * Extract this |<update>| element's |CDATA| contents from the
> response.
>
> <<<<<< (remove thes following lines)
>
> * If the document contains an element with the identifier
> |javax.faces.ViewState| replace its contents with the |CDATA|
> contents.
> * For each |<form>| element in the document:
> o If the |<form>| element contains an |<input>| element with
> the identifier |javax.faces.ViewState|, replace the
> |<input>| element contents with the |<update>| element's
> |CDATA| contents.
> o If the |<form>| element does not contain an element with the
> identifier |javax.faces.ViewState|, create an |<input>|
> element of the type |hidden|, with the identifier
> |javax.faces.ViewState|, set its contents to the |<update>|
> element's |CDATA| contents, and add the |<input>| element as
> a child to the |<form>| element.
>
> ======= (add the following lines)
>
> * Set the value of all elements within the document with the name
> |javax.faces.ViewState |to the CDATA contents
> * For each |<form>| element in the document:
> o If the |<form>| element does not contain an element with the
> name |javax.faces.ViewState|, create an |<input>| element of
> the type |hidden|, with the name |javax.faces.ViewState|,
> set its value to the |<update>| element's |CDATA| contents,
> and add the |<input>| element as a child to the |<form>|
> element.
>
> >>>>>>>
>
> Best Regards,
> Ganesh
>
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Ganesh <ga...@j4fry.org>.
Hi Matthias and Werner,
The partial submit issue I posted to jsr-314-comments@jcp.org received
nearly instant response from Roger Kitain. Definitely not /dev/null,
these guys really take their job serious. Werner, it would be great, if
you forwarded your mail to the dev@myfaces list, so we can see what
happens to it.
Afaik the spec doesn't say anything about the view state issue apart
from the JS docs (does anybody know any other places that talks about
the id of the hidden view state inputs?). The Javascript shouldn't work
based on the hidden inputs ids, but based on the hidden inputs names.
Here's a proposal on how to change the JS docs. If you agree, I'll post
it to jsr-314-comments@jcp.org.
Correct the jsdoc for <static> jsf.ajax.*response*(request, context)
like this:
If an |update| element is found in the response with the identifier
|javax.faces.ViewState|:
|<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>|
Include this |state| in the document as follows:
* Extract this |<update>| element's |CDATA| contents from the response.
<<<<<< (remove thes following lines)
* If the document contains an element with the identifier
|javax.faces.ViewState| replace its contents with the |CDATA|
contents.
* For each |<form>| element in the document:
o If the |<form>| element contains an |<input>| element with
the identifier |javax.faces.ViewState|, replace the
|<input>| element contents with the |<update>| element's
|CDATA| contents.
o If the |<form>| element does not contain an element with the
identifier |javax.faces.ViewState|, create an |<input>|
element of the type |hidden|, with the identifier
|javax.faces.ViewState|, set its contents to the |<update>|
element's |CDATA| contents, and add the |<input>| element as
a child to the |<form>| element.
======= (add the following lines)
* Set the value of all elements within the document with the name
|javax.faces.ViewState |to the CDATA contents
* For each |<form>| element in the document:
o If the |<form>| element does not contain an element with the
name |javax.faces.ViewState|, create an |<input>| element of
the type |hidden|, with the name |javax.faces.ViewState|,
set its value to the |<update>| element's |CDATA| contents,
and add the |<input>| element as a child to the |<form>|
element.
>>>>>>>
Best Regards,
Ganesh
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Matthias Wessendorf <ma...@apache.org>.
On Mon, Apr 20, 2009 at 9:05 AM, Werner Punz <we...@gmail.com> wrote:
> Hia...
>
> I sent a comment regarding this issue towards the given jcp-comments mail
> address. Lets see what happens.
:-) /dev/null ?
Another option is to have Martin (he is the ASF guy in the EG)
bringing this to the EG.
-Matthias
>
> I think even if you can resolve those things on the javascript side
> this needs to be fixed, on the Spec side!
>
> After all the name attribute normally is there for what the spec and
> the RI tries to achieve by using multiple elements with the identifier
> javax.faces.ViewState!
>
> Werner
>
>
>
> Alexander Bell schrieb:
>>
>> Hi,
>>
>> in the past we did it in this way that we looking for the element only in
>> the affected form.
>> So in the form there is only one element with the id
>> javax.faces.ViewState.
>> It is also necessary that every form contains a hidden field with this id.
>> So for JSF ok but it breaks the w3c standard and you can't use
>> document.getElementById.
>> We've got a appropriate code snippet in the j4fry code.
>>
>>
>> 2009/4/19 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>>
>> Hi Werner,
>>
>> 2 elements with the same id truely brake the HTML standard. And it's
>> true, with Mojarra 2.0 and 2 forms on a page I get 2 identical
>> <input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2"
>> name="javax.faces.ViewState"/>
>> elements!
>>
>> Still, I'm not able to find this in the specs, can you please point
>> me to the section you are referring to?
>>
>> 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!
>>
>>
>> Best Regards,
>> Ganesh
>>
>>
>>
>>
>> --
>> Mit freundlichen Grüßen / Kind regards
>> Alexander Bell
>>
>> J4Fry OpenSource Community
>> Internet: http://www.j4fry.org
>> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
>> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
Hia...
I sent a comment regarding this issue towards the given jcp-comments
mail address. Lets see what happens.
I think even if you can resolve those things on the javascript side
this needs to be fixed, on the Spec side!
After all the name attribute normally is there for what the spec and
the RI tries to achieve by using multiple elements with the identifier
javax.faces.ViewState!
Werner
Alexander Bell schrieb:
> Hi,
>
> in the past we did it in this way that we looking for the element only
> in the affected form.
> So in the form there is only one element with the id javax.faces.ViewState.
> It is also necessary that every form contains a hidden field with this
> id. So for JSF ok but it breaks the w3c standard and you can't use
> document.getElementById.
> We've got a appropriate code snippet in the j4fry code.
>
>
> 2009/4/19 Ganesh <ganesh@j4fry.org <ma...@j4fry.org>>
>
> Hi Werner,
>
> 2 elements with the same id truely brake the HTML standard. And it's
> true, with Mojarra 2.0 and 2 forms on a page I get 2 identical
> <input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2"
> name="javax.faces.ViewState"/>
> elements!
>
> Still, I'm not able to find this in the specs, can you please point
> me to the section you are referring to?
>
> 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!
>
>
> Best Regards,
> Ganesh
>
>
>
>
> --
> Mit freundlichen Grüßen / Kind regards
> Alexander Bell
>
> J4Fry OpenSource Community
> Internet: http://www.j4fry.org
> E-Mail: Alexander.Bell@j4fry.org <ma...@j4fry.org>
> Webprofil: http://www.j4fry.org/alexanderbell.shtml
>
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Alexander Bell <Al...@j4fry.org>.
Hi,
in the past we did it in this way that we looking for the element only in
the affected form.
So in the form there is only one element with the id javax.faces.ViewState.
It is also necessary that every form contains a hidden field with this id.
So for JSF ok but it breaks the w3c standard and you can't use
document.getElementById.
We've got a appropriate code snippet in the j4fry code.
2009/4/19 Ganesh <ga...@j4fry.org>
> Hi Werner,
>
> 2 elements with the same id truely brake the HTML standard. And it's true,
> with Mojarra 2.0 and 2 forms on a page I get 2 identical
> <input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2"
> name="javax.faces.ViewState"/>
> elements!
>
> Still, I'm not able to find this in the specs, can you please point me to
> the section you are referring to?
>
>> 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!
>>
>
> Best Regards,
> Ganesh
>
--
Mit freundlichen Grüßen / Kind regards
Alexander Bell
J4Fry OpenSource Community
Internet: http://www.j4fry.org
E-Mail: Alexander.Bell@j4fry.org
Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Ganesh <ga...@j4fry.org>.
Hi Werner,
2 elements with the same id truely brake the HTML standard. And it's
true, with Mojarra 2.0 and 2 forms on a page I get 2 identical
<input id="javax.faces.ViewState" type="hidden" value="j_id1:j_id2" name="javax.faces.ViewState"/>
elements!
Still, I'm not able to find this in the specs, can you please point me
to the section you are referring to?
> 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!
Best Regards,
Ganesh
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Posted by Werner Punz <we...@gmail.com>.
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
>
>
Re: MyFaces 2.0 Ajax
Posted by Werner Punz <we...@gmail.com>.
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
Re: MyFaces 2.0 Ajax
Posted by Ganesh <ga...@j4fry.org>.
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.
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.
Best Regards,
Ganesh
Werner Punz schrieb:
> Hello Alex and Ganesh
>
> Following:
>
> I have coded most of the response handling parts which were still
> missing. There is one big todo left in the update regarding the
> viewstate + forms the spec and jsdoc is not entirely clear in this
> area I have to
> recheck that before going further in this area!
>
> However the parts I coded are not tested yet, I just coded them for
> now trying to be syntax error free and trying to follow the spec, I am
> writing as we speak some testcases to iron out the bugs as well as
> browser inconsistency bugs (setAttribute still needs testing on the IE
> 6 and 7 due to lousy bug ridden implementations on that browsers of
> the original W3C spec)!
>
> All javascript code is committed...
> Feel free to take over!
>
> I will finish the testcases tomorrow (which I cannot for now commit
> into myfaces because we do not have selenium tests yet) but I then
> have to work on another project, which has higher priority due to
> customer demands! I will iron my code out thursday and friday next
> week! During my opensource days!
>
> Ok what needs to be done, my code needs to be ironed out (I will do it
> next week anyway so there is no big rush, I just want to get some
> tests in place to have a testing ground for the code)
> we could start to work on the iframe handling for fileuploads, to have
> that corner case covered,
>
> The two todos in the response part still need some treatment!
>
> Your visual stuff can be moved into the planned extensions (Ganesh
> seems to be working on that currently afair the jira issue opened)
>
>
> Werner
>