[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[
https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868182#action_12868182
]
Werner Punz commented on MYFACES-2714:
--
Ok I did a quick mockup of the loading mechanism
it mostly works fine however firebug after the internal eval drops all carriage
returns so that the scripts
which are loaded that way are impossible to debug.
So for now until I know the cause of this, I would recommend leos original
approach
of loading one big js file or making a set of direct include links.
Nevertheless for testing here is my testcase
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_Lang.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_Queue.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_ListenerQueue.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_Dom.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_UnitTest.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/_util/_HtmlStripper.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/xhrCore/_AjaxUtils.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/xhrCore/_AjaxRequestQueue.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/xhrCore/_AjaxRequest.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/xhrCore/_AjaxResponse.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/xhrCore/_Transports.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/_impl/core/Impl.js']}",
null, null, "UTF-8");
myfaces._impl.core._Runtime.loadScript("#{resource['scripts:/myfaces/api/jsf.js']}",
null, null, "UTF-8");
Anyway unless I can resolve that carriage return issue, this approach at least
for debugging porposes is not possible to use.
> Include uncompressed jsf.js file and use it when development mode is used
> -
>
> Key: MYFACES-2714
> URL: https://issues.apache.org/jira/browse/MYFACES-2714
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-314
>Affects Versions: 2.0.0
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
> Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch
>
>
> Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed
> jsf.js file and use it when development mode is used. It is difficult to
> debug myfaces javascript for users and I think it is worth to do it too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2721) Second part of the Javascript Refactoring
[ https://issues.apache.org/jira/browse/MYFACES-2721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2721. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed Ok my testcases including Trinidad work, the codebase scales down to ie6. I also have a slight feeling we are faster than before (a little bit), due to browser specific optimized dom walking routines and due to less direct access to the namespaces, as well as optimized namespec resolution. I guess the codebase now is refactored enough to be left alone for bugfixing again, and we now have a workable structure for the next revisions of JSF and also a codebase which we do not have to be ashamed of. As for the size difference to mojarra there are several reasons: a) We are highly modular b) we have a core framework for inheritance, namespaces etc... which will become invaluable once the codebase becomes bigger and also should be reused if possible for tomahawk and maybe as well for Tobago. c) We have partial page submit, xhr timeouts, queue control etc... already in all functionality which either will come with JSF 2.0reva or 2.1 d) We are already prepared for pluggable transport mechanisms and cover some extreme corner cases very likely never to occur but which increased the codebase as well. e) We cover absolut corner cases like detached controls, which are unfortunately present in modern javascript libraries, thanks to deficits in ie6+ In the end we are at a bearable size with 70kbyte for the deployment file and if the server supports gzpipped loading then it can compress the file down to 17kbyte (tested that prematurely by simply zipping our final jsf.js file) > Second part of the Javascript Refactoring > - > > Key: MYFACES-2721 > URL: https://issues.apache.org/jira/browse/MYFACES-2721 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.0 >Reporter: Werner Punz >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > Cleanup the entire queue and xhr part so that we do not have to rely on > singletons > and have an implementation specific free transport object itself, which can > be plugged and > replaced for different transports. > This step is vital due to the upcoming iFrame and websocket transports. > Also the PPS part needs some cleanup, it has functionality in which is > covered in a more optimized way > by our _Dom.js file (so we get an auto speedup by moving there) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869738#action_12869738 ] Werner Punz commented on MYFACES-2714: -- Hia Leonardo, sorry I was a few days on vacation, the method you mention here works only on firefoy and old ie5.5 browsers. It is fine with me if you add this functionality (btw. I will make another big commit tomorrow which reduces the overall compressed filesize by 10kb, I did some code optimizations while being on vacation) But you have to have in mind, that this will not work probably on all other browsers and might break on firefox too. That was the main reason why we did the whole code loading the way we did a global eval works on all browsers. But as I said, I am fine with it, but you have to be aware that this will only work in firebug :-) (I can add an eval fallback for the rest of the browsers if you want) > Include uncompressed jsf.js file and use it when development mode is used > - > > Key: MYFACES-2714 > URL: https://issues.apache.org/jira/browse/MYFACES-2714 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch, > MYFACES-2714-4.patch, MYFACES-2714-5.patch, MYFACES-2714-6.patch > > > Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed > jsf.js file and use it when development mode is used. It is difficult to > debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869760#action_12869760 ] Werner Punz commented on MYFACES-2714: -- Ok Leo, lets do it that way simply commit your patches, I will work the little bit of changes on the js side into my optimized files and then I will recommit my code, that way we will be in sync again. I cannot commit my code today, since I have to run additional tests on the codebase before committing. The changes were substancial, which means thorough testing. > Include uncompressed jsf.js file and use it when development mode is used > - > > Key: MYFACES-2714 > URL: https://issues.apache.org/jira/browse/MYFACES-2714 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch, > MYFACES-2714-4.patch, MYFACES-2714-5.patch, MYFACES-2714-6.patch > > > Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed > jsf.js file and use it when development mode is used. It is difficult to > debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869910#action_12869910 ] Werner Punz commented on MYFACES-2714: -- Ok Leo good news, I found a way to enable the proper eval handling without messing with firefoxes head. _this.globalEval(xhr.responseText + "\r\n//@ sourceURL=" + src); does the trick, that way you can tell firefox to reparse the original source url and use that one as source for all debugging needs, your dom head code now is obsolete, so far this works really well and is future proof. Since the old dom based code also only works on fox, I think this solution is better. > Include uncompressed jsf.js file and use it when development mode is used > - > > Key: MYFACES-2714 > URL: https://issues.apache.org/jira/browse/MYFACES-2714 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch, > MYFACES-2714-4.patch, MYFACES-2714-5.patch, MYFACES-2714-6.patch > > > Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed > jsf.js file and use it when development mode is used. It is difficult to > debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2714) Include uncompressed jsf.js file and use it when development mode is used
[ https://issues.apache.org/jira/browse/MYFACES-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869936#action_12869936 ] Werner Punz commented on MYFACES-2714: -- Ok I have to admit, I am an idiot, the method you just used is perfectly valid, only inline scripts are not evaled automatically by the browser if you work over innerHTML... I am going to submit the integration soon, I just renamed your method to loadScript and added a fallback mechanism just in case the browser prevents head alteration, and proper defer handling, so that everything should work across browsers. > Include uncompressed jsf.js file and use it when development mode is used > - > > Key: MYFACES-2714 > URL: https://issues.apache.org/jira/browse/MYFACES-2714 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.0 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2714-2.patch, MYFACES-2714-3.patch, > MYFACES-2714-4.patch, MYFACES-2714-5.patch, MYFACES-2714-6.patch > > > Reading some blogs about jsf 2.0, I notice mojarra include an uncompressed > jsf.js file and use it when development mode is used. It is difficult to > debug myfaces javascript for users and I think it is worth to do it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2729) Refactoring of the Javascript Codebase: Part 3. size improvement due to code optimizations
Refactoring of the Javascript Codebase: Part 3. size improvement due to code optimizations -- Key: MYFACES-2729 URL: https://issues.apache.org/jira/browse/MYFACES-2729 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.1-SNAPSHOT Environment: Javascript Reporter: Werner Punz There was lots of code which was not optimized we can apply some optimization patterns to reduce the final codesize for instance for map entried vars we can use if(bla) instead of an undefined or null check except for numerical values. Also we can reduce some of the overly long variable names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2729) Refactoring of the Javascript Codebase: Part 3. size improvement due to code optimizations
[ https://issues.apache.org/jira/browse/MYFACES-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2729. -- Resolution: Fixed > Refactoring of the Javascript Codebase: Part 3. size improvement due to code > optimizations > -- > > Key: MYFACES-2729 > URL: https://issues.apache.org/jira/browse/MYFACES-2729 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz > > There was lots of code which was not optimized we can apply some optimization > patterns to reduce the final codesize > for instance for map entried vars we can use if(bla) instead of an undefined > or null check except for numerical values. > Also we can reduce some of the overly long variable names. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2735) Javascript: Adding delegation as primary pattern for _Runtime.js moving the logging out from _Lang. into a debugging Lang.js
Javascript: Adding delegation as primary pattern for _Runtime.js moving the logging out from _Lang. into a debugging Lang.js Key: MYFACES-2735 URL: https://issues.apache.org/jira/browse/MYFACES-2735 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.0.1-SNAPSHOT Environment: Javascript Reporter: Werner Punz Priority: Minor Some smaller changes, the structural delegation pattern is now a first class pattern like inheritance and singleton in the runtime.js to make it easier to write delegations without additional delegation code. Also inheritance now works on objects by picking their original class. Additionally to that to keep the code size lean I am going to move the logging out into a debugging _Lang.js (_ExtLang.js) which is a plug in replacement for _Lang.js, this again should save a few bytes because for now we do not log in the core but only in the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2735) Javascript: Adding delegation as primary pattern for _Runtime.js moving the logging out from _Lang. into a debugging Lang.js
[ https://issues.apache.org/jira/browse/MYFACES-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2735. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed > Javascript: Adding delegation as primary pattern for _Runtime.js moving the > logging out from _Lang. into a debugging Lang.js > > > Key: MYFACES-2735 > URL: https://issues.apache.org/jira/browse/MYFACES-2735 > Project: MyFaces Core > Issue Type: New Feature >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > Some smaller changes, the structural delegation pattern is now a first class > pattern like inheritance and singleton in the runtime.js to make it easier to > write delegations without additional delegation code. > Also inheritance now works on objects by picking their original class. > Additionally to that to keep the code size lean I am going to move the > logging out into a debugging _Lang.js (_ExtLang.js) which is a plug in > replacement for _Lang.js, this again should save a few bytes because for now > we do not log in the core but only in the unit tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-133) _annotationScanner.scanClass(retVal); can cause recursive calls into itself
_annotationScanner.scanClass(retVal); can cause recursive calls into itself --- Key: EXTSCRIPT-133 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-133 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Final Environment: all Reporter: Werner Punz Assignee: Werner Punz The problem manifested itself with a custom converter by brunos example, recursive calls where triggered when a package whitelist was set. Further investigation showed that _annotationScanner.scanClass(retVal); was loaded after the initial classload and that one triggered another loadClass at registerConverter which then triggered again scanclass. I cannot prevent myfaces to call loadClass upon registering but I can prevent the recusion which was triggered by this environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-133) _annotationScanner.scanClass(retVal); can cause recursive calls into itself
[ https://issues.apache.org/jira/browse/EXTSCRIPT-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-133. --- Fix Version/s: 1.0-Final Resolution: Fixed > _annotationScanner.scanClass(retVal); can cause recursive calls into itself > --- > > Key: EXTSCRIPT-133 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-133 > Project: MyFaces Extensions Scripting > Issue Type: Bug > Components: MyFaces 2.0 Extension >Affects Versions: 1.0-Final > Environment: all >Reporter: Werner Punz >Assignee: Werner Punz > Fix For: 1.0-Final > > > The problem manifested itself with a custom converter by brunos example, > recursive calls where triggered > when a package whitelist was set. Further investigation showed that > _annotationScanner.scanClass(retVal); was loaded after the initial classload > and that one triggered another loadClass at registerConverter which then > triggered again scanclass. > I cannot prevent myfaces to call loadClass upon registering but I can prevent > the recusion which was triggered by this environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-134) JSF2 Extensions and composite components - error
JSF2 Extensions and composite components - error
Key: EXTSCRIPT-134
URL: https://issues.apache.org/jira/browse/EXTSCRIPT-134
Project: MyFaces Extensions Scripting
Issue Type: Bug
Components: MyFaces 2.0 Extension
Affects Versions: Beta-1
Reporter: Werner Punz
Assignee: Werner Punz
It seems that Ext-Scripting has not entirely nailed down the composite
components
brunos example application breaks on composite components with following error
After phase: RENDER_RESPONSE(6)
javax.el.PropertyNotFoundException:
/resources/components/intact/collapsiblePanel.xhtml at line 44 and column 138
value="#{cc.attrs.title}": The class
'org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper'
does not have the property 'title'.
at
org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:88)
at
javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:243)
at javax.faces.component.UIOutput.getValue(UIOutput.java:71)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue(RendererUtils.java:349)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:301)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput(HtmlTextRendererBase.java:92)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd(HtmlTextRendererBase.java:79)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:490)
at
org.primefaces.renderkit.CoreRenderer.renderChild(CoreRenderer.java:77)
at
org.primefaces.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:61)
at
org.primefaces.component.outputpanel.OutputPanelRenderer.encodeEnd(OutputPanelRenderer.java:44)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:490)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:618)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
at
org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
This is definitely ext-scripting related because without it, the example works
without errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2742) javax.faces.behavior.event = undefined
[
https://issues.apache.org/jira/browse/MYFACES-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876202#action_12876202
]
Werner Punz edited comment on MYFACES-2742 at 6/7/10 7:15 AM:
--
Hi I tried to cover everything for the refactoring via unit testing, but as it
seems alas, I introduced a bug.
I will fix that asap (which should be tomorrow)
Werner
was (Author: werpu):
Hi I tried to cover everything for the refactoring via unit testing, but as
it seems alas, I introduce a bug.
I will fix that asap (which should be tomorrow)
Werner
> javax.faces.behavior.event = undefined
> --
>
> Key: MYFACES-2742
> URL: https://issues.apache.org/jira/browse/MYFACES-2742
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: OS: Ubuntu 10.04
> Browser: FireFox 3.6.3
>Reporter: Radek Hodain
>
> Request parameter "javax.faces.behavior.event" has undefined value if we
> submit button by ajax. The server side code isn't able to recognise that the
> button is submitted.
> If we have xhtml like this:
>
>
>
>
>
> the commandButton is rendered to this html output
> onclick="jsf.util.chain(document.getElementById('buttonId'),
> event,'jsf.ajax.request(\'buttonId\',event,{\'javax.faces.behavior.event\':\'action\'})');
> return false;"
> name="buttonId"
> id="buttonId">
> When we submit the commandButton, javascript is performed and post parameters
> contain "undefined" value for key "javax.faces.behavior.event". I think that
> problem is in _Runtime.js in method exists. The method has two arguments root
> which is an array and subNms. In our case root contains
> execute : '@this', render : '@this', javax.faces.behavior.event : 'action'
> and subNms is "javax.faces.behavior.event". Next part of code tries to split
> subNms by dots. These parts are looked up in the root but the root contains
> whole key "javax.faces.behavior.event". The method returns false and the
> request parameter "javax.faces.behavior.event" stays undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2742) javax.faces.behavior.event = undefined
[
https://issues.apache.org/jira/browse/MYFACES-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876202#action_12876202
]
Werner Punz commented on MYFACES-2742:
--
Hi I tried to cover everything for the refactoring via unit testing, but as it
seems alas, I introduce a bug.
I will fix that asap (which should be tomorrow)
Werner
> javax.faces.behavior.event = undefined
> --
>
> Key: MYFACES-2742
> URL: https://issues.apache.org/jira/browse/MYFACES-2742
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: OS: Ubuntu 10.04
> Browser: FireFox 3.6.3
>Reporter: Radek Hodain
>
> Request parameter "javax.faces.behavior.event" has undefined value if we
> submit button by ajax. The server side code isn't able to recognise that the
> button is submitted.
> If we have xhtml like this:
>
>
>
>
>
> the commandButton is rendered to this html output
> onclick="jsf.util.chain(document.getElementById('buttonId'),
> event,'jsf.ajax.request(\'buttonId\',event,{\'javax.faces.behavior.event\':\'action\'})');
> return false;"
> name="buttonId"
> id="buttonId">
> When we submit the commandButton, javascript is performed and post parameters
> contain "undefined" value for key "javax.faces.behavior.event". I think that
> problem is in _Runtime.js in method exists. The method has two arguments root
> which is an array and subNms. In our case root contains
> execute : '@this', render : '@this', javax.faces.behavior.event : 'action'
> and subNms is "javax.faces.behavior.event". Next part of code tries to split
> subNms by dots. These parts are looked up in the root but the root contains
> whole key "javax.faces.behavior.event". The method returns false and the
> request parameter "javax.faces.behavior.event" stays undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2742) javax.faces.behavior.event = undefined
[
https://issues.apache.org/jira/browse/MYFACES-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876210#action_12876210
]
Werner Punz commented on MYFACES-2742:
--
Ok the issue is indeed a slight change in behavior for the exists, the exists
now tries to resolve subnamespaces if divided by .
this is not entirely correct, it should first check for a full key and then if
it does not exist try to resolve subnamespaces.
The old version of the function did not check for subnamespaces at all.
I added this functionality to make the function more useful regarding automated
namespacing, but I introduced this bug then.
> javax.faces.behavior.event = undefined
> --
>
> Key: MYFACES-2742
> URL: https://issues.apache.org/jira/browse/MYFACES-2742
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: OS: Ubuntu 10.04
> Browser: FireFox 3.6.3
>Reporter: Radek Hodain
>
> Request parameter "javax.faces.behavior.event" has undefined value if we
> submit button by ajax. The server side code isn't able to recognise that the
> button is submitted.
> If we have xhtml like this:
>
>
>
>
>
> the commandButton is rendered to this html output
> onclick="jsf.util.chain(document.getElementById('buttonId'),
> event,'jsf.ajax.request(\'buttonId\',event,{\'javax.faces.behavior.event\':\'action\'})');
> return false;"
> name="buttonId"
> id="buttonId">
> When we submit the commandButton, javascript is performed and post parameters
> contain "undefined" value for key "javax.faces.behavior.event". I think that
> problem is in _Runtime.js in method exists. The method has two arguments root
> which is an array and subNms. In our case root contains
> execute : '@this', render : '@this', javax.faces.behavior.event : 'action'
> and subNms is "javax.faces.behavior.event". Next part of code tries to split
> subNms by dots. These parts are looked up in the root but the root contains
> whole key "javax.faces.behavior.event". The method returns false and the
> request parameter "javax.faces.behavior.event" stays undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2742) javax.faces.behavior.event = undefined
[
https://issues.apache.org/jira/browse/MYFACES-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2742.
--
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
Ok it is fixed, the event handler now is passed down properly, sorry for
introducing this bug, I tried to eliminate all bugs upfront, since the entire
refactoring process was more or less a rewrite of 50% of the codebase, but I
missed this sidebhavior which triggered the bug. I hope it was the only one I
introduced in the codebase.
Nevertheless, the refactoring was needed to get the codebase into a cleaner
state for future extensions.
Again sorry for this.
> javax.faces.behavior.event = undefined
> --
>
> Key: MYFACES-2742
> URL: https://issues.apache.org/jira/browse/MYFACES-2742
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: OS: Ubuntu 10.04
> Browser: FireFox 3.6.3
>Reporter: Radek Hodain
> Fix For: 2.0.1-SNAPSHOT
>
>
> Request parameter "javax.faces.behavior.event" has undefined value if we
> submit button by ajax. The server side code isn't able to recognise that the
> button is submitted.
> If we have xhtml like this:
>
>
>
>
>
> the commandButton is rendered to this html output
> onclick="jsf.util.chain(document.getElementById('buttonId'),
> event,'jsf.ajax.request(\'buttonId\',event,{\'javax.faces.behavior.event\':\'action\'})');
> return false;"
> name="buttonId"
> id="buttonId">
> When we submit the commandButton, javascript is performed and post parameters
> contain "undefined" value for key "javax.faces.behavior.event". I think that
> problem is in _Runtime.js in method exists. The method has two arguments root
> which is an array and subNms. In our case root contains
> execute : '@this', render : '@this', javax.faces.behavior.event : 'action'
> and subNms is "javax.faces.behavior.event". Next part of code tries to split
> subNms by dots. These parts are looked up in the root but the root contains
> whole key "javax.faces.behavior.event". The method returns false and the
> request parameter "javax.faces.behavior.event" stays undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876248#action_12876248
]
Werner Punz commented on MYFACES-2745:
--
Ok as it seems, the integrated ecmascript parser of html unit is less lenient
than the browsers I was testing against (and I was testing against all browsers
since ie6)
it seems to me that the error message is issued somewhere in the inheritance
part of the _Runtime.js but since the error is referenced against the compiled
file I cannot fully tell.
I have to make a test setup against the uncompiled scripts to check where the
htmlunit ecmascript parser fails.
But bear in mind this is an error which occurs in HTMLUnit only and not in any
browser.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlu
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876255#action_12876255
]
Werner Punz commented on MYFACES-2745:
--
Ok I made a test setup and a small fixup and the problem seems to be the
exmascript parser of html unit which chokes on prototypes, which means the
entire inheritance part we are based of is invalidated by it.
I will dig further into the issue, but I think the ecmascript parser of
htmlunit has a problem here, which the normal browsers do not have.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.jav
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876256#action_12876256
]
Werner Punz commented on MYFACES-2745:
--
Ok I made a test setup and a small fixup and the problem seems to be the
exmascript parser of html unit which chokes on prototypes, which means the
entire inheritance part we are based of is invalidated by it.
I will dig further into the issue, but I think the ecmascript parser of
htmlunit has a problem here, which the normal browsers do not have.
Not sure why htmlunit is able to cope with other libraries which do exactly the
same as we do, in the meanwhile I will commit the first small fixup before
going further.
This is a nasty problem.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebC
[jira] Issue Comment Edited: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876256#action_12876256
]
Werner Punz edited comment on MYFACES-2745 at 6/7/10 11:00 AM:
---
Ok I made a test setup and a small fixup and the problem seems to be the
exmascript parser of html unit which chokes on prototypes, which means the
entire inheritance part we are based of is invalidated by it.
I will dig further into the issue, but I think the ecmascript parser of
htmlunit has a problem here, which the normal browsers do not have.
Not sure why htmlunit is able to cope with other libraries which do exactly the
same as we do, in the meanwhile I will commit the first small fixup before
going further.
This is a nasty problem.
The problem seems to be that the prototype inheritance mechanism which works
perfectly fine in any browser supporting prototype functions fails in the
ecmascript parts of html unit, please give me a few days to investigate the
problem (since I have to work in my sparetime on this)
I am not sure why it fails I have to isolate the problem and if it is the core
javascript engine, have to get in contact with the html unit guys. Have in mind
I am doing this in my sparetime.
was (Author: werpu):
Ok I made a test setup and a small fixup and the problem seems to be the
exmascript parser of html unit which chokes on prototypes, which means the
entire inheritance part we are based of is invalidated by it.
I will dig further into the issue, but I think the ecmascript parser of
htmlunit has a problem here, which the normal browsers do not have.
Not sure why htmlunit is able to cope with other libraries which do exactly the
same as we do, in the meanwhile I will commit the first small fixup before
going further.
This is a nasty problem.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyber
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876280#action_12876280
]
Werner Punz commented on MYFACES-2745:
--
Ok just to give a short update, it looks like we really trigger a bug in the
html unit script engine here, the good news is it is not the prototype
inheritance per se, which is present, but something else, which I have yet to
nail down.
>From what I can gather is, that I am loosing values at a return statement
>which I should not. I will try to isolate the problem further and keep you
>guys updated the following days.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876592#action_12876592
]
Werner Punz commented on MYFACES-2745:
--
Ok first thanks Leonardo for finding the root cause of this. HTMLUnit is at
fault here, it registers itself as ie and then forces the code to do a
window.eval, which in case of htmlunit returns a String with the value null
"null" instead of a real null or undefined.
This is fixable commit coming soon.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:360)
> at com.gargoylesoftware.htmluni
[jira] Resolved: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2745.
--
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
Ok bug is fixed now, looks good so far.
The html unit parts pass my simple unit tests.
The fix really was to check for "null" in window.execScript and then convert
that value to a real null value.
I hope this is the only case where htmlunit seriously breaks the browser
behavior.
My Dom routine tests so far have all passed which is a good sign that we wont
run into this problem again.
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
> Fix For: 2.0.1-SNAPSHOT
>
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient
[jira] Commented: (TRINIDAD-1825) PPR Broken in Windows Mobile 6
[ https://issues.apache.org/jira/browse/TRINIDAD-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876678#action_12876678 ] Werner Punz commented on TRINIDAD-1825: --- Hia would´t it be better to fix the jsf2 apis instead on both implementations? Windows mobile 6 is a problematic issue generally, due to the browser being somewhere on ie 5 level, but as far as I know the xhr Object is there, so it should be fixable by someone who has the resources to do the winmobile 6 testing. It probably just boils down to a few fixes and special hooks in the codebase to get it up and running. > PPR Broken in Windows Mobile 6 > -- > > Key: TRINIDAD-1825 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1825 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.0.0-alpha-2 > Environment: Windows Mobile 6 >Reporter: Mamallan Uthaman > > Currently, PPR in Windows Mobile 6 neither performs a partial submit nor a > full-page submit. I guess, for mobile browsers, we need to revert the PPR > handling to old legacy way than JSF2 APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-134) JSF2 Extensions and composite components - error
[
https://issues.apache.org/jira/browse/EXTSCRIPT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved EXTSCRIPT-134.
---
Resolution: Fixed
> JSF2 Extensions and composite components - error
>
>
> Key: EXTSCRIPT-134
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-134
> Project: MyFaces Extensions Scripting
> Issue Type: Bug
> Components: MyFaces 2.0 Extension
>Affects Versions: Beta-1
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> It seems that Ext-Scripting has not entirely nailed down the composite
> components
> brunos example application breaks on composite components with following error
> After phase: RENDER_RESPONSE(6)
> javax.el.PropertyNotFoundException:
> /resources/components/intact/collapsiblePanel.xhtml at line 44 and column 138
> value="#{cc.attrs.title}": The class
>
> 'org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver$CompositeComponentAttributesMapWrapper'
> does not have the property 'title'.
> at
> org.apache.myfaces.view.facelets.el.TagValueExpression.getValue(TagValueExpression.java:88)
> at
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:243)
> at javax.faces.component.UIOutput.getValue(UIOutput.java:71)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getValue(RendererUtils.java:349)
> at
> org.apache.myfaces.shared_impl.renderkit.RendererUtils.getStringValue(RendererUtils.java:301)
> at
> org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.renderOutput(HtmlTextRendererBase.java:92)
> at
> org.apache.myfaces.shared_impl.renderkit.html.HtmlTextRendererBase.encodeEnd(HtmlTextRendererBase.java:79)
> at
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:490)
> at
> org.primefaces.renderkit.CoreRenderer.renderChild(CoreRenderer.java:77)
> at
> org.primefaces.renderkit.CoreRenderer.renderChildren(CoreRenderer.java:61)
> at
> org.primefaces.component.outputpanel.OutputPanelRenderer.encodeEnd(OutputPanelRenderer.java:44)
> at
> javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:490)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:618)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
> at
> org.apache.myfaces.renderkit.html.HtmlCompositeComponentRenderer.encodeEnd(HtmlCompositeComponentRenderer.java:71)
> This is definitely ext-scripting related because without it, the example
> works without errors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2747) Auto attachment of debug version of jsf.js crashes the loading of a page under ie6
Auto attachment of debug version of jsf.js crashes the loading of a page under ie6 -- Key: MYFACES-2747 URL: https://issues.apache.org/jira/browse/MYFACES-2747 Project: MyFaces Core Issue Type: Bug Reporter: Werner Punz 2.0.1 introduce a auto attachment of jsf.js in the body if jsf.ajax.request is somewhere in an onEvent handler and no h:head is present. The problem is the scripts are imported without defer into the body. While this is perfectly viable and works on any decent browser, it causes problems on IE6 under certain conditions (aka open subtags beneath body) which is highly senstive to this while having open tags. There are several ways to fix this, first defer the script loading via defer, this is Microsofts recommended way to load scripts within the body tag in ie6 secondly, I have to evaluate if I simply change the debug eval code just for ie6 to global eval it might fix the issue, third, simply do not auto include jsf.js at all, but just issue a warning that jsf.js should be included under development mode, so that manual includes do not trigger this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1825) PPR Broken in Windows Mobile 6
[ https://issues.apache.org/jira/browse/TRINIDAD-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876990#action_12876990 ] Werner Punz commented on TRINIDAD-1825: --- I only can comment for Myfaces here. I am currently desting against IE6-8 (I wont go lower than that for the desktop browsers) Firefox 2+ Webkit based browsers (which should also cover the iphone and android browsers, which all run on a recent fairly webkit base) and Opera in the latest versions. I have to admit Mobile browsers were not really my target for now, because my personal guess was that WinMobile 6 is a swiftly dying platform and even there the browser is hardly used by most users (they use Opera instead) and the more important (for dynamic html platforms) browsers in the mobile land are mostly webkit based and are covered by the webkit testing base. (Not sure how Opera Mobile fares here, due to lack of devices, which still is the most popular browser under WinMobile and Nokia devices) Anyway if someone is willing to tackle the mobile task I am happy to assist for the myfaces codebase. I am not sure how Mojarra behaves regarding mobile browsers, but I assume desktop browsers and fairly recent webkit based mobile browsers are also their main target. I have to admit this is the first time I heard that someone wants to do dhtml on WinMobile 6, never had that before :-) > PPR Broken in Windows Mobile 6 > -- > > Key: TRINIDAD-1825 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1825 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.0.0-alpha-2 > Environment: Windows Mobile 6 >Reporter: Mamallan Uthaman > > Currently, PPR in Windows Mobile 6 neither performs a partial submit nor a > full-page submit. I guess, for mobile browsers, we need to revert the PPR > handling to old legacy way than JSF2 APIs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2747) Auto attachment of debug version of jsf.js crashes the loading of a page under ie6
[ https://issues.apache.org/jira/browse/MYFACES-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2747. -- Resolution: Fixed Ok the issue is an old well known ie6 (and maybe 7 bug) the new loading code should fix it and does it form me, it only does head attachements in case of ie6 and 7 while the rest does it depending on whether the browser reacts to head attachement (firefox ie8 in some situations, opera) or not (all webkit browsers) > Auto attachment of debug version of jsf.js crashes the loading of a page > under ie6 > -- > > Key: MYFACES-2747 > URL: https://issues.apache.org/jira/browse/MYFACES-2747 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz > > 2.0.1 introduce a auto attachment of jsf.js in the body if jsf.ajax.request > is somewhere in an onEvent handler and no h:head is present. > The problem is the scripts are imported without defer into the body. While > this is perfectly viable and works on any decent browser, it causes problems > on IE6 under certain conditions (aka open subtags beneath body) which is > highly senstive to this while having open tags. > There are several ways to fix this, > first defer the script loading via defer, this is Microsofts recommended way > to load scripts within the body tag in ie6 > secondly, I have to evaluate if I simply change the debug eval code just for > ie6 to global eval it might fix the issue, > third, simply do not auto include jsf.js at all, but just issue a warning > that jsf.js should be included under development mode, so that manual > includes do not trigger this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2745) Cannot set property "_mfProto" of null to "null" error with new javascript
[
https://issues.apache.org/jira/browse/MYFACES-2745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877104#action_12877104
]
Werner Punz commented on MYFACES-2745:
--
https://sourceforge.net/tracker/?func=detail&aid=3013799&group_id=47038&atid=448266
done...
> Cannot set property "_mfProto" of null to "null" error with new javascript
> --
>
> Key: MYFACES-2745
> URL: https://issues.apache.org/jira/browse/MYFACES-2745
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>Assignee: Leonardo Uribe
> Fix For: 2.0.1
>
>
> The javascript changes from 5/25 have caused a regression when using htmlunit
> against even the simplest JSF page as long as it loads the jsf.js script.
> The exception occurs simply executing getPage() on the webClient.
> WebClient webClient = new WebClient();
> HtmlPage page =
> webClient.getPage("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> It can be recreated by a page with nothing but this form in the body:
>
>
>
>
> Attached is the exception trace from a run this morning which includes
> Werner's changes from MYFACES-2742 this morning so we are up to date in our
> sandbox.
> === EXCEPTION START
> EcmaError: lineNumber=[51] column=[0] lineSource=[]
> name=[TypeError]
> sourceName=[http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces]
> message=[TypeError: Cannot set property "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)]
> com.gargoylesoftware.htmlunit.ScriptException: TypeError: Cannot set property
> "_mfProto" of null to "null"
> (http://localhost:8080/JSF20AJAXTag/javax.faces.resource/jsf.js.jsf?ln=javax.faces#51)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
> at
> net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
> at
> net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:538)
> at
> com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:425)
> at
> com.gargoylesoftware.htmlunit.html.HtmlPage.loadExternalJavaScriptFile(HtmlPage.java:980)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.executeScriptIfNeeded(HtmlScript.java:353)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript$1.execute(HtmlScript.java:215)
> at
> com.gargoylesoftware.htmlunit.html.HtmlScript.onAllChildrenAddedToPage(HtmlScript.java:235)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:718)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
> Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.endElement(HTMLParser.java:676)
> at
> org.cyberneko.html.HTMLTagBalancer.callEndElement(HTMLTagBalancer.java:1136)
> at
> org.cyberneko.html.HTMLTagBalancer.endElement(HTMLTagBalancer.java:1038)
> at
> org.cyberneko.html.filters.DefaultFilter.endElement(DefaultFilter.java:206)
> at
> org.cyberneko.html.filters.NamespaceBinder.endElement(NamespaceBinder.java:329)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scanEndElement(HTMLScanner.java:2999)
> at
> org.cyberneko.html.HTMLScanner$ContentScanner.scan(HTMLScanner.java:1991)
> at org.cyberneko.html.HTMLScanner.scanDocument(HTMLScanner.java:895)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:499)
> at
> org.cyberneko.html.HTMLConfiguration.parse(HTMLConfiguration.java:452)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser$HtmlUnitDOMBuilder.parse(HTMLParser.java:896)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:350)
> at
> com.gargoylesoftware.htmlunit.html.HTMLParser.parseHtml(HTMLParser.java:304)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:134)
> at
> com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
> at
> com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:420)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:303)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:360)
> at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:345)
> at com.ibm.mike.TestJS.homePage(TestJS.java:19)
> at sun.reflect.NativeMethodAccessorImpl.in
[jira] Commented: (MYFACES-2748) NPE in htmlunit when testing ajax rendering
[
https://issues.apache.org/jira/browse/MYFACES-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877108#action_12877108
]
Werner Punz commented on MYFACES-2748:
--
Ok this is an issue Leonardo discovered yesterday. The reason is, I slightly
changed the dom replacement code for 2.0.1 so that the lifecycle behavior is
absolutely identical over all browsers (before it was suboptimal in certainb
browsers by keeping the elements double)
The problem here is some IE6 fixup code which enforces that all script tags are
properly evaled (which ie swallows under certain conditions). The main issue
there is that HTMLUnit by maskint itself as IE runs into this fixup code for
IE6 which then returns a null element, and triggers this issue.
We will fix this issue probably tomorrow (given my workload and timeframe)
maybe earlier if Leonard is able to do a quick fix before me.
> NPE in htmlunit when testing ajax rendering
> ---
>
> Key: MYFACES-2748
> URL: https://issues.apache.org/jira/browse/MYFACES-2748
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
>Reporter: Michael Concini
>
> When attempting to run some simple ajax tests using htmlunit, we're seeing
> some NPEs when running in the default (IE) client mode. As before with
> MYFACES-2745 this looks like its a bug in htmlunit, however these test cases
> had been passing on the MyFaces 2.0.0 release so something that is going on
> with the new javascript must be triggering the bug. I've validated in IE8,
> Firefox 3.6 and Chrome that this is being rendered properly in a live browser
> session as well as that it works if you initialize the htmlunit with new
> WebClient(BrowserVersion.FIREFOX_3).
> Here's a simple example of a failing case. Its just executes an increment
> action on a counter var and uses f:ajax to re-render an outputText field.
>
>
>
> action="#{incrementdecrement.increment}" >
>
>
>
>
> After doing some debugging, htmlunit doesn't seem to be handling the partial
> page update. Instead of updating the span value for "out1", it is actually
> removing it from the idMap for the page. So if you try to validate the value
> of "out1" has been incremented, you'll get an NPE since the element is no
> longer on the idMap.
> WebClient webClient = new WebClient();
> HtmlPage page = (HtmlPage) webClient.getPage
> ("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> String buttonId = "button1";
> doClick(page,buttonId);
>
> Assert.assertEquals( "1", page.getElementById
> ("out1").getTextContent());
> The NPE is coming from trying to execute getTextContent() when
> page.getElementById("out1") is returning null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2748) NPE in htmlunit when testing ajax rendering
[
https://issues.apache.org/jira/browse/MYFACES-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877108#action_12877108
]
Werner Punz edited comment on MYFACES-2748 at 6/9/10 11:41 AM:
---
Ok this is an issue Leonardo discovered yesterday. The reason is, I slightly
changed the dom replacement code for 2.0.1 so that the lifecycle behavior is
absolutely identical over all browsers (before it was suboptimal in certainb
browsers by keeping the elements double)
The problem here is some IE6 fixup code which enforces that all script tags are
properly evaled (which ie6 swallows under certain tag combinations). The main
issue there is that HTMLUnit by masking itself as IE runs into this fixup code
for IE6 which then returns a null element, and triggers this issue.
We will fix this issue probably tomorrow (given my workload and timeframe)
maybe earlier if Leonard is able to do a quick fix before me.
was (Author: werpu):
Ok this is an issue Leonardo discovered yesterday. The reason is, I
slightly changed the dom replacement code for 2.0.1 so that the lifecycle
behavior is absolutely identical over all browsers (before it was suboptimal in
certainb browsers by keeping the elements double)
The problem here is some IE6 fixup code which enforces that all script tags are
properly evaled (which ie swallows under certain conditions). The main issue
there is that HTMLUnit by maskint itself as IE runs into this fixup code for
IE6 which then returns a null element, and triggers this issue.
We will fix this issue probably tomorrow (given my workload and timeframe)
maybe earlier if Leonard is able to do a quick fix before me.
> NPE in htmlunit when testing ajax rendering
> ---
>
> Key: MYFACES-2748
> URL: https://issues.apache.org/jira/browse/MYFACES-2748
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
>Reporter: Michael Concini
>
> When attempting to run some simple ajax tests using htmlunit, we're seeing
> some NPEs when running in the default (IE) client mode. As before with
> MYFACES-2745 this looks like its a bug in htmlunit, however these test cases
> had been passing on the MyFaces 2.0.0 release so something that is going on
> with the new javascript must be triggering the bug. I've validated in IE8,
> Firefox 3.6 and Chrome that this is being rendered properly in a live browser
> session as well as that it works if you initialize the htmlunit with new
> WebClient(BrowserVersion.FIREFOX_3).
> Here's a simple example of a failing case. Its just executes an increment
> action on a counter var and uses f:ajax to re-render an outputText field.
>
>
>
> action="#{incrementdecrement.increment}" >
>
>
>
>
> After doing some debugging, htmlunit doesn't seem to be handling the partial
> page update. Instead of updating the span value for "out1", it is actually
> removing it from the idMap for the page. So if you try to validate the value
> of "out1" has been incremented, you'll get an NPE since the element is no
> longer on the idMap.
> WebClient webClient = new WebClient();
> HtmlPage page = (HtmlPage) webClient.getPage
> ("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> String buttonId = "button1";
> doClick(page,buttonId);
>
> Assert.assertEquals( "1", page.getElementById
> ("out1").getTextContent());
> The NPE is coming from trying to execute getTextContent() when
> page.getElementById("out1") is returning null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2748) NPE in htmlunit when testing ajax rendering
[
https://issues.apache.org/jira/browse/MYFACES-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877368#action_12877368
]
Werner Punz commented on MYFACES-2748:
--
A last comment on this issue, this bug only affected IE and only did so for the
IE simulation of html unit.
The root cause of this bug was following IE bug
http://blogs.perl.org/users/clinton_gormley/2010/02/forcing-ie-to-accept-script-tags-in-innerhtml.html
This bug only can occur in certain corner cases and afair also 2.0.0 was
affected which did not use innerHTML but used fragments instead (I moved over
to innerHTML because it is well supported in IE and faster and provided a
lifecycle which was closer to the contextual ranges we have for more W3C
compliant browsers.
The reason why we did not stumble over it was simply that we had no testing
cases which triggered it, my cross form submit testing revealed it, because it
only happens in certain dom combinations which are relatively rare and probably
should not occur at existing usecases.
However the problem with the proposed approach from clinton_gormley is that the
wrapping in forms does not work out for certain corner cases which have forms
embedded so I moved over to a table based approach, which then broke in
htmlUnit (I have to investigate if the deep scan can be eliminited by adding
more elements, but that is not the scope of 2.0.1 anymore)
The good thing is since the entire operation of replacement is encapsulated
into a single outerHTML replacement method, we always can relatively swiftly
switch to a different approach.
(one of the advantages of the code cleanup I did of between 2.0.0 - 2.0.1 the
code is way more maintainable and structured)
> NPE in htmlunit when testing ajax rendering
> ---
>
> Key: MYFACES-2748
> URL: https://issues.apache.org/jira/browse/MYFACES-2748
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
>Reporter: Michael Concini
>Assignee: Leonardo Uribe
> Fix For: 2.0.1
>
>
> When attempting to run some simple ajax tests using htmlunit, we're seeing
> some NPEs when running in the default (IE) client mode. As before with
> MYFACES-2745 this looks like its a bug in htmlunit, however these test cases
> had been passing on the MyFaces 2.0.0 release so something that is going on
> with the new javascript must be triggering the bug. I've validated in IE8,
> Firefox 3.6 and Chrome that this is being rendered properly in a live browser
> session as well as that it works if you initialize the htmlunit with new
> WebClient(BrowserVersion.FIREFOX_3).
> Here's a simple example of a failing case. Its just executes an increment
> action on a counter var and uses f:ajax to re-render an outputText field.
>
>
>
> action="#{incrementdecrement.increment}" >
>
>
>
>
> After doing some debugging, htmlunit doesn't seem to be handling the partial
> page update. Instead of updating the span value for "out1", it is actually
> removing it from the idMap for the page. So if you try to validate the value
> of "out1" has been incremented, you'll get an NPE since the element is no
> longer on the idMap.
> WebClient webClient = new WebClient();
> HtmlPage page = (HtmlPage) webClient.getPage
> ("http://localhost:8080/JSF20AJAXTag/DisabledFalse.jsf";);
> String buttonId = "button1";
> doClick(page,buttonId);
>
> Assert.assertEquals( "1", page.getElementById
> ("out1").getTextContent());
> The NPE is coming from trying to execute getTextContent() when
> page.getElementById("out1") is returning null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)
[
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879332#action_12879332
]
Werner Punz commented on MYFACES-2755:
--
Ok this is serious, I am getting on it right away.
I hope we can get the fix in in 2.0.1
> this.id is undefined in jsf.ajax.request (regression from 2.0.0)
>
>
> Key: MYFACES-2755
> URL: https://issues.apache.org/jira/browse/MYFACES-2755
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> With the new javascript, we now wrapper calls into jsf.ajax.request with a
> function call. So for example this:
> onclick="jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;"
>actionListener="#{counter.increment}" />
> would be rendered as this:
> value="Increment"
> onclick="var cf = function(){jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;};var oamSF = function(){};return
> (cf()==false)? false : oamSF();" />
> The problem is that we've broken the reference to this.id as it is undefined
> at the function's scope. This works fine in both the 2.0.0 release as well as
> Mojarra.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)
[
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879335#action_12879335
]
Werner Punz commented on MYFACES-2755:
--
Ok this is not entirely javascript related at least not in my part of the code
is the problem here is following:
onclick = "jsf.ajax.request(this, event, { execute: this.id, render: 'counter'
}); return false;"
is mapped into
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf()==false)?
false : oamSF();
which reassigns the this scope (whoever has written that code did not take that
into consideration.
the problem then is that this is assigned to the function cf which then tries
to determine the original this.id id value.
But now that this points towards the function id is undefined.
A quick workaround to fix that problem would be to use one of our impl functions
the call would look like: cf myfaces._impl._util._Lang.hitch(this,
(){jsf.ajax.request(this, event, { execute: this.id, render: 'counter' });
return false;});
this would reassign the this to the original scope.
if you do not want to go for the helper in our impls Lang package then a
workaround would be to
go for following code:
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf.apply(this,
[])==false)? false : oamSF.apply(this, []);
This would drag the scope also in.
Cheers Werner
Leonardo or Jakob can you take over you probably know fastest where the related
code is.
> this.id is undefined in jsf.ajax.request (regression from 2.0.0)
>
>
> Key: MYFACES-2755
> URL: https://issues.apache.org/jira/browse/MYFACES-2755
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> With the new javascript, we now wrapper calls into jsf.ajax.request with a
> function call. So for example this:
> onclick="jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;"
>actionListener="#{counter.increment}" />
> would be rendered as this:
> value="Increment"
> onclick="var cf = function(){jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;};var oamSF = function(){};return
> (cf()==false)? false : oamSF();" />
> The problem is that we've broken the reference to this.id as it is undefined
> at the function's scope. This works fine in both the 2.0.0 release as well as
> Mojarra.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2755) this.id is undefined in jsf.ajax.request (regression from 2.0.0)
[
https://issues.apache.org/jira/browse/MYFACES-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12879335#action_12879335
]
Werner Punz edited comment on MYFACES-2755 at 6/16/10 9:38 AM:
---
Ok this is not entirely javascript related at least not in my part of the code
is the problem here is following:
onclick = "jsf.ajax.request(this, event, { execute: this.id, render: 'counter'
}); return false;"
is mapped into
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf()==false)?
false : oamSF();
which reassigns the this scope (whoever has written that code did not take that
into consideration.
the problem then is that this is assigned to the function cf which then tries
to determine the original this.id id value.
But now that this points towards the function id is undefined.
A quick workaround to fix that problem would be to use one of our impl functions
the call would look like: cf myfaces._impl._util._Lang.hitch(this,
(){jsf.ajax.request(this, event, { execute: this.id, render: 'counter' });
return false;});
this would reassign the this to the original scope.
if you do not want to go for the helper in our impls Lang package then a
workaround would be to
go for following code:
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf.apply(this,
[])==false)? false : oamSF.apply(this, []);
This would drag the scope also in.
Ok I tried to fix it here, but the checkstyle plugin download currently fails
on me, can anyone fix it, the affected files are:
org.apache.myfaces.shared.renderkit.html.HtmlButtonRendererBase
org.apache.myfaces.shared.renderkit.html.HtmlLinkRendererBase
org.apache.myfaces.shared_impl.renderkit.html.HtmlButtonRendererBase
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlButtonRendererBase
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlLinkRendererBase
My personal vote would be to go for the apply(this, []) method instead of
calling hitch.
was (Author: werpu):
Ok this is not entirely javascript related at least not in my part of the
code is the problem here is following:
onclick = "jsf.ajax.request(this, event, { execute: this.id, render: 'counter'
}); return false;"
is mapped into
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf()==false)?
false : oamSF();
which reassigns the this scope (whoever has written that code did not take that
into consideration.
the problem then is that this is assigned to the function cf which then tries
to determine the original this.id id value.
But now that this points towards the function id is undefined.
A quick workaround to fix that problem would be to use one of our impl functions
the call would look like: cf myfaces._impl._util._Lang.hitch(this,
(){jsf.ajax.request(this, event, { execute: this.id, render: 'counter' });
return false;});
this would reassign the this to the original scope.
if you do not want to go for the helper in our impls Lang package then a
workaround would be to
go for following code:
var cf = function(){jsf.ajax.request(this, event, { execute: this.id, render:
'counter' }); return false;};var oamSF = function(){};return (cf.apply(this,
[])==false)? false : oamSF.apply(this, []);
This would drag the scope also in.
Cheers Werner
Leonardo or Jakob can you take over you probably know fastest where the related
code is.
> this.id is undefined in jsf.ajax.request (regression from 2.0.0)
>
>
> Key: MYFACES-2755
> URL: https://issues.apache.org/jira/browse/MYFACES-2755
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1
>Reporter: Michael Concini
>
> With the new javascript, we now wrapper calls into jsf.ajax.request with a
> function call. So for example this:
> onclick="jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;"
>actionListener="#{counter.increment}" />
> would be rendered as this:
> value="Increment"
> onclick="var cf = function(){jsf.ajax.request(this, event, { execute:
> this.id, render: 'counter' }); return false;};var oamSF = function(){};return
> (cf()==false)? false : oamSF();" />
> The problem is that we've broken the reference to this.id as it is undefined
> at the function's scope. This works fine in both the 2.0.0 release as well as
> Mojarra.
--
This message is automatically generated by JIRA.
-
You can reply to thi
[jira] Commented: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880626#action_12880626
]
Werner Punz commented on MYFACES-2762:
--
We had another issue with lost viewstates even in the old codebase which was
fixed by the new javascripts, but it can be that this one is a new bug
introduced by the viewstate fixups.
Nevertheless the root cause of all this is mostly a spec leak
which mostly prevents cross form submits and generally multi form handling in a
clean manner,
which I already filed, but let me see if we can fix this issue as well. Cross
form submits and especially this case should work.
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880628#action_12880628
]
Werner Punz commented on MYFACES-2762:
--
Ok we have a bug hear, the fixup code which should fix the viewstate issue does
not seem to work in this case...
I want to determine first the reason why the code fails before checking the
patch.
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880628#action_12880628
]
Werner Punz edited comment on MYFACES-2762 at 6/20/10 9:05 AM:
---
Ok we have a bug hear, the fixup code which should fix the viewstate issue does
not seem to work in this case...
I want to determine first the reason why the code fails before checking the
patch.
Btw. just a short note, this is not a new bug by the javascripts, in fact the
new javascrips try to deal with that condition. If it worked in 2.0 then the
behavior of the server response has changed.
I want to give an example here: the Example introduces following response:
As you can see both forms are rendered without a viewstate element and the
viewstate is appended afterwards with the javax.faces.ViewState.
Now here things become difficult. The spec states that the viewState only can
be attached to the issuing form. Which is the fault I sent to the spec issue
tracker, but in fact all forms within the render or update cycle should have a
reattached viewstate.
Now things become even more difficult, because the old codebase did not even
have this fixup code, so I assume the rendering behavior must have been
different with the viewstate being embedded in 2.0.
(Btw. my testing revealed mojarra also does not deal with this problem in a
proper manner, they also have some fixup code but it also fails in certain
conditions)
In either way, the fixup code did not work out properly which I added in 2.0.1
to deal with exactly this issue. I missed your case, I will first check why it
fails, and then later check your patch to get to a correct solution there.
was (Author: werpu):
Ok we have a bug hear, the fixup code which should fix the viewstate issue
does not seem to work in this case...
I want to determine first the reason why the code fails before checking the
patch.
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880634#action_12880634
]
Werner Punz commented on MYFACES-2762:
--
Ok now to the patch, most of it definitely looks correct, the viewstate has to
be applied to all forms which have changes (also even outer forms) elements so
applying it only to elements which have a form embedded like I did before is
not entirely correct, in fact the change trace should step up until the parent
form if it does not embed one or more forms.
secondly:
if (!document.forms || !document.forms.length) {
return null;
-} else if (1 == document.forms.length) {
-return document.forms[0];
}
+// This will not work well on portlet case, because we cannot be sure
+// the returned form is right one.
+//else if (1 == document.forms.length) {
+//return document.forms[0];
+//}
if (!elem) {
return null;
}
This is only a fallback routine in case of an element cannot be traced back to
an original form, so your fix here, does not really solve a lot of things
because a cross portlet submit is not possible and we cannot issue a submit
unless we have a form issuing it.
As for the rest of the changes they make a lot of sense although I would not
use two data structures for the change trace, I would push it into one list.
One minor gripe, call me nitpicky, the last change to the delete, but I do not
want to have direct dom manipulating routines in the response, everything dom
manipulating has to go through dom hence I will rework the last change. This
costs a little bit of performance, but I prefer a structured separation of
concerns to the last inch of performance. So I will not really use that change.
Nevertheless I will apply all of the patches and rework from there a little
bit, thanks a lot you saved me a load of work here, you really found a huge
issue here and also added code from the portlet case handling.
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880634#action_12880634
]
Werner Punz edited comment on MYFACES-2762 at 6/20/10 9:57 AM:
---
Ok now to the patch, most of it definitely looks correct, the viewstate has to
be applied to all forms which have changes (also even outer forms) elements so
applying it only to elements which have a form embedded like I did before is
not entirely correct, in fact the change trace should step up until the parent
form if it does not embed one or more forms.
secondly:
if (!document.forms || !document.forms.length) {
return null;
-} else if (1 == document.forms.length) {
-return document.forms[0];
}
+// This will not work well on portlet case, because we cannot be sure
+// the returned form is right one.
+//else if (1 == document.forms.length) {
+//return document.forms[0];
+//}
if (!elem) {
return null;
}
This is only a fallback routine in case of an element cannot be traced back to
an original form, so your fix here, does not really solve a lot of things
because a cross portlet submit is not possible and we cannot issue a submit
unless we have a form issueing it.
I will make it differently here, I will make that one configurable, by pushing
a new optional environment variable:
myfaces_config.no_portlet_env
if this one is set to true we can use the code (it really helps in detachement
cases so it makes sense)
On a sidenote, since 90% of all cases are non portlet it should be vice versa,
but given how intrusive history of portlets I cannot really enforce that on
portlet users to set a special param to switch this off. Especially since
portlets should work without additional config params on code level.
I personally think that the portlet guys should fix their api also in regards
to javascript to allow a portlet detection within the javascripts. We should
definitely work towards such a case at least from the myfaces side. The reason
simply is, that portlets are an entirely different beast environmentally and we
should also have access to the viewroot identifier etc.. in case of a portlet
and should know that we are in a portlet environment everything else will end
up in hacks.
As for the rest of the changes they make a lot of sense and utilize the new
apis really well. Originally I wanted to push both change lists into one data
structure but now thinking about it it makes more sense to take the entire
patchset as it is.
One minor gripe, call me nitpicky, the last change to the delete, but I do not
want to have direct dom manipulating routines in the response, everything dom
manipulating has to go through dom hence I will rework the last change. This
costs a little bit of performance, but I prefer a structured separation of
concerns to the last inch of performance. So I will not really use that change.
The performance cost in that case is nullified by the browser optimizations we
have on the dom walking side.
Nevertheless I will apply all of the patches and rework from there a little
bit, thanks a lot you saved me a load of work here, you really found a huge
issue here and also added code from the portlet case handling.
was (Author: werpu):
Ok now to the patch, most of it definitely looks correct, the viewstate has
to be applied to all forms which have changes (also even outer forms) elements
so applying it only to elements which have a form embedded like I did before is
not entirely correct, in fact the change trace should step up until the parent
form if it does not embed one or more forms.
secondly:
if (!document.forms || !document.forms.length) {
return null;
-} else if (1 == document.forms.length) {
-return document.forms[0];
}
+// This will not work well on portlet case, because we cannot be sure
+// the returned form is right one.
+//else if (1 == document.forms.length) {
+//return document.forms[0];
+//}
if (!elem) {
return null;
}
This is only a fallback routine in case of an element cannot be traced back to
an original form, so your fix here, does not really solve a lot of things
because a cross portlet submit is not possible and we cannot issue a submit
unless we have a form issuing it.
As for the rest of the changes they make a lot of sense although I would not
use two data structures for the change trace, I would push it into one list.
One minor gripe, call me nitpicky, the last change to the delete, but I do not
want to have direct dom manipulating routines in the response, everything dom
manipulating has to go through dom hence I will rework the last change. This
costs a little bit of performanc
[jira] Commented: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880639#action_12880639
]
Werner Punz commented on MYFACES-2762:
--
Ok another issue, the example with the applied patches causes a white screen
without errors on IE6, I will still commit the fixes and then open another
issue for the new problem.
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2762) Handling mutiple h:form and AJAX is broken
[
https://issues.apache.org/jira/browse/MYFACES-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz updated MYFACES-2762:
-
Status: Resolved (was: Patch Available)
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
The patch is applied thank you for sending in the patch
> Handling mutiple h:form and AJAX is broken
> --
>
> Key: MYFACES-2762
> URL: https://issues.apache.org/jira/browse/MYFACES-2762
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: myfaces current trunk (19.6.2010)
>Reporter: Martin Kočí
>Priority: Critical
> Fix For: 2.0.1-SNAPSHOT
>
> Attachments: MYFACES-2762.patch
>
>
> Is seems that handling of
> http://www.mail-archive.com/jsr-314-o...@jcp.org/msg00043.html
> (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=790)
> is broken in current trunk. This example:
>
>
>
>
>
>
> target="#{viewScope.test}" />
>
>
>
> should produce output "true" with all clicks but it works only at first.
> Firebug shows that all javax.faces.ViewState elements are removed after first
> response. If I comment out first h:form it works as expected.
> Because this example works fine with 2.0.0 I think it a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2763) Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode
Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode --- Key: MYFACES-2763 URL: https://issues.apache.org/jira/browse/MYFACES-2763 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1-SNAPSHOT Environment: Javascript Reporter: Werner Punz Priority: Blocker See headline -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2763) Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode
[ https://issues.apache.org/jira/browse/MYFACES-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880641#action_12880641 ] Werner Punz edited comment on MYFACES-2763 at 6/20/10 10:44 AM: Ok the issue is our outerhtml routine, specifically parentNode = item.parentNode; item.parentNode.replaceChild(evalNode, item); problem here is we have multiple items (due to a body replacement, which defaults into subitem replacements), I am not sure if this causes the white screen but everything points towards it. Since it is sunday today I will fix that later tonight, once I have time. Werner was (Author: werpu): Ok the issue is our outerhtml routine, specifically parentNode = item.parentNode; item.parentNode.replaceChild(evalNode, item); problem here is we have multiple items, I am not sure if this causes the white screen but everything points towards it. > Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks > mode > --- > > Key: MYFACES-2763 > URL: https://issues.apache.org/jira/browse/MYFACES-2763 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Blocker > > See headline -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2763) Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode
[ https://issues.apache.org/jira/browse/MYFACES-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880641#action_12880641 ] Werner Punz commented on MYFACES-2763: -- Ok the issue is our outerhtml routine, specifically parentNode = item.parentNode; item.parentNode.replaceChild(evalNode, item); problem here is we have multiple items, I am not sure if this causes the white screen but everything points towards it. > Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks > mode > --- > > Key: MYFACES-2763 > URL: https://issues.apache.org/jira/browse/MYFACES-2763 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Blocker > > See headline -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2763) Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode
[ https://issues.apache.org/jira/browse/MYFACES-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2763. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed Ok we have the issue fixed the outerhtml indeed was buggy, the reason for the issue was that the outerhtml was triggered against code with multiple root elements, normally this does not happen bug in case of a full body replacement it can happen due to the replacement logic (which takes into consideration that chrome and others do not allow the replacement of a body tag just its content and attributes) > Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks > mode > --- > > Key: MYFACES-2763 > URL: https://issues.apache.org/jira/browse/MYFACES-2763 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Blocker > Fix For: 2.0.1-SNAPSHOT > > > See headline -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2763) Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks mode
[ https://issues.apache.org/jira/browse/MYFACES-2763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12880667#action_12880667 ] Werner Punz edited comment on MYFACES-2763 at 6/20/10 4:30 PM: --- Ok we have the issue fixed the outerhtml indeed was buggy, the reason for the issue was that the outerhtml was triggered against code with multiple root elements, normally this does not happen but in case of a full body replacement it can happen due to the replacement logic (which takes into consideration that chrome and others do not allow the replacement of a body tag just its content and attributes) was (Author: werpu): Ok we have the issue fixed the outerhtml indeed was buggy, the reason for the issue was that the outerhtml was triggered against code with multiple root elements, normally this does not happen bug in case of a full body replacement it can happen due to the replacement logic (which takes into consideration that chrome and others do not allow the replacement of a body tag just its content and attributes) > Example from MyFaces 2762 causes a white result page in ie6 and ie7 quirks > mode > --- > > Key: MYFACES-2763 > URL: https://issues.apache.org/jira/browse/MYFACES-2763 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Blocker > Fix For: 2.0.1-SNAPSHOT > > > See headline -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2765) Dom findById fails on firefox with javax.faces.ViewState
Dom findById fails on firefox with javax.faces.ViewState Key: MYFACES-2765 URL: https://issues.apache.org/jira/browse/MYFACES-2765 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz see topic -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2765) Dom findById fails on firefox with javax.faces.ViewState
[ https://issues.apache.org/jira/browse/MYFACES-2765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2765. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed The issue was a non escaping of . and : in the optimized query searches, I will revisit that codepart again to make it waterproof for now I added the escapes to the dom routines. > Dom findById fails on firefox with javax.faces.ViewState > > > Key: MYFACES-2765 > URL: https://issues.apache.org/jira/browse/MYFACES-2765 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz > Fix For: 2.0.1-SNAPSHOT > > > see topic -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2767) _AjaxRequest.js adds an extra ampersand in request
[ https://issues.apache.org/jira/browse/MYFACES-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881105#action_12881105 ] Werner Punz commented on MYFACES-2767: -- Hey Martin, thanks a lot for this bugreport, I will fix it sometime today. I agree it is not a showstopper but nevertheless annyoing. > _AjaxRequest.js adds an extra ampersand in request > -- > > Key: MYFACES-2767 > URL: https://issues.apache.org/jira/browse/MYFACES-2767 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces core trunk Tomcat 6.0.26 >Reporter: Martin Kočí >Priority: Minor > > _AjaxRequest.js line 96 and next add an extra ampersand in request , for > example: javax.faces.ViewState=yz...%3D%3D&&javax.faces.source=formId > It has no impact but Tomcat complains: > 21.6.2010 20:09:26 org.apache.tomcat.util.http.Parameters processParameters > WARNING: Parameters: Invalid chunk '' ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2767) _AjaxRequest.js adds an extra ampersand in request
[ https://issues.apache.org/jira/browse/MYFACES-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12881234#action_12881234 ] Werner Punz commented on MYFACES-2767: -- Ok I have to postpone the fix a few days, I am currently overloaded with project work for the company I work for. > _AjaxRequest.js adds an extra ampersand in request > -- > > Key: MYFACES-2767 > URL: https://issues.apache.org/jira/browse/MYFACES-2767 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces core trunk Tomcat 6.0.26 >Reporter: Martin Kočí >Priority: Minor > > _AjaxRequest.js line 96 and next add an extra ampersand in request , for > example: javax.faces.ViewState=yz...%3D%3D&&javax.faces.source=formId > It has no impact but Tomcat complains: > 21.6.2010 20:09:26 org.apache.tomcat.util.http.Parameters processParameters > WARNING: Parameters: Invalid chunk '' ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2768) jsf.js internal myfaces parameters do not work anymore
jsf.js internal myfaces parameters do not work anymore -- Key: MYFACES-2768 URL: https://issues.apache.org/jira/browse/MYFACES-2768 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz Priority: Minor The internal myfaces parameters have been broken by the refactoring: fails while This is not a showstopper since queue control and pps are not part of jsf 2.0 but are preparation code for 2.1 so I can live with not having them currently enabled. The fixup either will go into 2.0.1 or 2.0.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2767) _AjaxRequest.js adds an extra ampersand in request
[ https://issues.apache.org/jira/browse/MYFACES-2767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2767. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed Ok since my private life has not yet taken over I was able to do a quick fix of this issue. The attached ambersant is now removed. > _AjaxRequest.js adds an extra ampersand in request > -- > > Key: MYFACES-2767 > URL: https://issues.apache.org/jira/browse/MYFACES-2767 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces core trunk Tomcat 6.0.26 >Reporter: Martin Kočí >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > _AjaxRequest.js line 96 and next add an extra ampersand in request , for > example: javax.faces.ViewState=yz...%3D%3D&&javax.faces.source=formId > It has no impact but Tomcat complains: > 21.6.2010 20:09:26 org.apache.tomcat.util.http.Parameters processParameters > WARNING: Parameters: Invalid chunk '' ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2768) jsf.js internal myfaces parameters do not work anymore
[
https://issues.apache.org/jira/browse/MYFACES-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2768.
--
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
The issue was a small refactoring bug I introduce while I cleaned up the j4fry
pps code.
I accidentally forgot to rename one of the old variables in a newly introduced
closure which was supposed
to take over the old code by utilizing our dom functionality.
> jsf.js internal myfaces parameters do not work anymore
> --
>
> Key: MYFACES-2768
> URL: https://issues.apache.org/jira/browse/MYFACES-2768
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
>Reporter: Werner Punz
>Priority: Minor
> Fix For: 2.0.1-SNAPSHOT
>
>
> The internal myfaces parameters have been broken by the refactoring:
> "#{count.increment}" onclick = "jsf.ajax.request(this, event, {render:
> 'out1', execute: 'out1 button1',
> myfaces:{errorlevel:'ERROR', pps:true,
> queuesize:1}}); return false;" />
> fails while
> "#{count.increment}" onclick = "jsf.ajax.request(this, event, {render:
> 'out1', execute: 'out1 button1'}); return false;" />
> This is not a showstopper since queue control and pps are not part of jsf 2.0
> but are preparation code for
> 2.1 so I can live with not having them currently enabled. The fixup either
> will go into 2.0.1 or 2.0.2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2771) Javascript: Unit test for _Dom.findByStyleClass fails on IE8
Javascript: Unit test for _Dom.findByStyleClass fails on IE8
Key: MYFACES-2771
URL: https://issues.apache.org/jira/browse/MYFACES-2771
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Werner Punz
Some of the last changes broke the
results = Dom.findByStyleClass(Dom.byId("level1"), "level2", true);
UnitTest.assertTrue("three elements found due to deep scan being neglegted",
results.length > 2);
for IE8 the function is not used currently in the code but it needs to be
fixed, probably an escaping issue related to the recent escaping bug fixed in
the codebase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2771) Javascript: Unit test for _Dom.findByStyleClass fails on IE8
[
https://issues.apache.org/jira/browse/MYFACES-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2771.
--
Fix Version/s: 2.0.1
Resolution: Fixed
fixed, I also fortified the querySelector fallbacks so that another option is
chosen in case the selector fails
> Javascript: Unit test for _Dom.findByStyleClass fails on IE8
>
>
> Key: MYFACES-2771
> URL: https://issues.apache.org/jira/browse/MYFACES-2771
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.1-SNAPSHOT
>Reporter: Werner Punz
> Fix For: 2.0.1
>
>
> Some of the last changes broke the
> results = Dom.findByStyleClass(Dom.byId("level1"), "level2", true);
>UnitTest.assertTrue("three elements found due to deep scan being
> neglegted", results.length > 2);
>
> for IE8 the function is not used currently in the code but it needs to be
> fixed, probably an escaping issue related to the recent escaping bug fixed in
> the codebase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2772) Javascript: Improve the unit testing and logging facilities
Javascript: Improve the unit testing and logging facilities Key: MYFACES-2772 URL: https://issues.apache.org/jira/browse/MYFACES-2772 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz Our javascripts have logging facilities which route to output consoles if present (firebug, firebug lite chromium or an embedded div as fallback if present) currently we do not have a tracing info and due to the structure of the non intrusiveness a log entry cannot be traced directly from the firebug console for instance to its origin, also we do not have logging level control on code level only on console level if present. The patch will add a trace if tracing functionaltiy is present, and also will introduce log switches and trace switches. Note, the logging only is present for dev mode not for production mode, to keep the code size lean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2772) Javascript: Improve the unit testing and logging facilities
[ https://issues.apache.org/jira/browse/MYFACES-2772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2772. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed done > Javascript: Improve the unit testing and logging facilities > > > Key: MYFACES-2772 > URL: https://issues.apache.org/jira/browse/MYFACES-2772 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz > Fix For: 2.0.1-SNAPSHOT > > > Our javascripts have logging facilities which route to output consoles if > present (firebug, firebug lite chromium or an embedded div as fallback if > present) > currently we do not have a tracing info and due to the structure of the non > intrusiveness a log entry cannot be traced directly from the firebug console > for instance to its origin, also > we do not have logging level control on code level only on console level if > present. > The patch will add a trace if tracing functionaltiy is present, and also will > introduce log switches and trace switches. > Note, the logging only is present for dev mode not for production mode, to > keep the code size lean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2773) (JSF.js) Performance fixes
(JSF.js) Performance fixes -- Key: MYFACES-2773 URL: https://issues.apache.org/jira/browse/MYFACES-2773 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz Priority: Minor I did some profiling on our scripts today, and found two hotspots in the script include sections both for dev and for deployment project stage. For dev the jsf-uncompressed.js was constantly loaded if embedded in ppr (and to the worse the subsequent dynamic loads were triggered as well), the same issue except for the subsequent reloads also persists for production. I also added some forEach fallbacks for arrays on browsers which already have Array.prototype.forEach implemented. This is a minor improvement but helps with readability. The changes will be committed tomorrow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2773) (JSF.js) Performance fixes
[ https://issues.apache.org/jira/browse/MYFACES-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2773. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed > (JSF.js) Performance fixes > -- > > Key: MYFACES-2773 > URL: https://issues.apache.org/jira/browse/MYFACES-2773 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > I did some profiling on our scripts today, and found two hotspots in the > script include sections both for dev and for deployment project stage. > For dev the jsf-uncompressed.js was constantly loaded if embedded in ppr (and > to the worse > the subsequent dynamic loads were triggered as well), the same issue except > for the subsequent reloads > also persists for production. > I also added some forEach fallbacks for arrays on browsers which already have > Array.prototype.forEach implemented. > This is a minor improvement but helps with readability. > The changes will be committed tomorrow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-135) Changes in the myfaces initialisation between 2.0.0 and 2.0.1 broke the startup of ext-scripting
Changes in the myfaces initialisation between 2.0.0 and 2.0.1 broke the startup of ext-scripting Key: EXTSCRIPT-135 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-135 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Final Reporter: Werner Punz Assignee: Werner Punz There have been some variations in the startup behavior of myfaces 2.0.0 - > 2.0.1 which are perfectly valid but which broke our startup in ext-scripting. Ext-Scripting relies on an initial compile and scan before myfaces initialises its own artifacts but somehow the code already relies on an existing application object to work in this startup phase which is wrong. This has to be changed on the ext-scripting side. The assumption of the initial compile is correct but not the application access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-135) Changes in the myfaces initialisation between 2.0.0 and 2.0.1 broke the startup of ext-scripting
[ https://issues.apache.org/jira/browse/EXTSCRIPT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-135. --- Fix Version/s: 1.0-Final Resolution: Fixed > Changes in the myfaces initialisation between 2.0.0 and 2.0.1 broke the > startup of ext-scripting > > > Key: EXTSCRIPT-135 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-135 > Project: MyFaces Extensions Scripting > Issue Type: Bug > Components: MyFaces 2.0 Extension >Affects Versions: 1.0-Final >Reporter: Werner Punz >Assignee: Werner Punz > Fix For: 1.0-Final > > > There have been some variations in the startup behavior of myfaces 2.0.0 - > > 2.0.1 which are perfectly valid but which broke our startup in ext-scripting. > Ext-Scripting relies on an initial compile and scan before myfaces > initialises its own artifacts but somehow the code already relies on an > existing application object to work in this startup phase which is wrong. > This has to be changed on the ext-scripting side. > The assumption of the initial compile is correct but not the application > access. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-109) Improve the test coverage of the system
[ https://issues.apache.org/jira/browse/EXTSCRIPT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-109. --- Fix Version/s: 1.0-Final Resolution: Fixed > Improve the test coverage of the system > --- > > Key: EXTSCRIPT-109 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-109 > Project: MyFaces Extensions Scripting > Issue Type: Bug > Components: Core >Affects Versions: Beta-1 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > Fix For: 1.0-Final > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-109) Improve the test coverage of the system
[ https://issues.apache.org/jira/browse/EXTSCRIPT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883091#action_12883091 ] Werner Punz commented on EXTSCRIPT-109: --- Added a load of unit tests over easter > Improve the test coverage of the system > --- > > Key: EXTSCRIPT-109 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-109 > Project: MyFaces Extensions Scripting > Issue Type: Bug > Components: Core >Affects Versions: Beta-1 >Reporter: Werner Punz >Assignee: Werner Punz >Priority: Minor > Fix For: 1.0-Final > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-136) Adding an event system
Adding an event system -- Key: EXTSCRIPT-136 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-136 Project: MyFaces Extensions Scripting Issue Type: Improvement Components: MyFaces 2.0 Extension Reporter: Werner Punz Assignee: Werner Punz adding an internal event system to make extensions to the core easier, the core itself will not use it for now, but later also will be moved there -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-137) Prepare 1.1 SNAPSHOT
Prepare 1.1 SNAPSHOT Key: EXTSCRIPT-137 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-137 Project: MyFaces Extensions Scripting Issue Type: Improvement Affects Versions: 1.1-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Preparations have to be done for 1.1 snapshot like upping the version numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-137) Prepare 1.1 SNAPSHOT
[ https://issues.apache.org/jira/browse/EXTSCRIPT-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-137. --- Fix Version/s: 1.1-SNAPSHOT Resolution: Fixed > Prepare 1.1 SNAPSHOT > > > Key: EXTSCRIPT-137 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-137 > Project: MyFaces Extensions Scripting > Issue Type: Improvement >Affects Versions: 1.1-SNAPSHOT >Reporter: Werner Punz >Assignee: Werner Punz > Fix For: 1.1-SNAPSHOT > > > Preparations have to be done for 1.1 snapshot like upping the version numbers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-139) Add on demand compilation
[ https://issues.apache.org/jira/browse/EXTSCRIPT-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883127#action_12883127 ] Werner Punz commented on EXTSCRIPT-139: --- The 1.1 branch uses asynchnronous on demand/on change recompilation of changed files. This makes sense since we ran into troubles with our per request recompilation in having dynamic resource handlers. We will change that. The only downside is there will be no clear dedicated point of recompilation anymore, but ont the other hand other things will become simpler. > Add on demand compilation > - > > Key: EXTSCRIPT-139 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-139 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-138) Work the classloader from the 1.1 branch in
Work the classloader from the 1.1 branch in --- Key: EXTSCRIPT-138 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-138 Project: MyFaces Extensions Scripting Issue Type: Sub-task Reporter: Werner Punz Assignee: Werner Punz We did too many things way too complicated the 1.1 branch has a better classloader in this regard we will work the concepts and code in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-139) Add on demand compilation
Add on demand compilation - Key: EXTSCRIPT-139 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-139 Project: MyFaces Extensions Scripting Issue Type: Sub-task Reporter: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-140) Unify the scripting weaver
Unify the scripting weaver -- Key: EXTSCRIPT-140 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-140 Project: MyFaces Extensions Scripting Issue Type: Sub-task Reporter: Werner Punz -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTSCRIPT-140) Unify the scripting weaver
[ https://issues.apache.org/jira/browse/EXTSCRIPT-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883128#action_12883128 ] Werner Punz commented on EXTSCRIPT-140: --- The current scripting weaver relies on one class per scripting language, it probably can be simplified by unifying it, we will see > Unify the scripting weaver > -- > > Key: EXTSCRIPT-140 > URL: https://issues.apache.org/jira/browse/EXTSCRIPT-140 > Project: MyFaces Extensions Scripting > Issue Type: Sub-task >Reporter: Werner Punz > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2761) PartialViewContextImpl does not respect isRenderAll()
[ https://issues.apache.org/jira/browse/MYFACES-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883439#action_12883439 ] Werner Punz commented on MYFACES-2761: -- Just to comment something additional to this issue. During the script implementation it has shown that neither render all nor render head works out. The issue was that certain browsers based on the Webkit engine prohibit a replacement (body replacement works fine for certain conditions) On the script side, I discussed that with the mojarra people and we agreed not to implement render head for now and limit render all to the body only client side. (I have not checked if mojarra still behaves like that) In the end the spec leaves it up to the implementation what has to be done in that case, which was a last minute change to tackle the problem on the spec side. You can issue the full page however, we have a high performance ll parser which strips out the body in the render all case and only does body replacement. If you issue a render head on the client side the script will trigger a non supported error however, for now. So anything regarding render all on the server side is safe and only cause the body to be rendered, no matter if the entire html form is issued or just the body. (including the body tags, which are the only must) > PartialViewContextImpl does not respect isRenderAll() > - > > Key: MYFACES-2761 > URL: https://issues.apache.org/jira/browse/MYFACES-2761 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces current trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe > > This construct should lead to complete ajax re-render of whole view (works > with mojarra): > partialViewContext.setRenderAll(true); > but it seems that myfaces don't read property renderAll during rendering at > all. Probably > org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(UIViewRoot, > PhaseId) should respect this property somehow. Note: there is a possible > workaround: > partialViewContext.getRenderIds().add(javax.faces.context.PartialResponseWriter.RENDER_ALL_MARKER); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2778) jsf.js ajax response xml format exception broken on newer mozilla builds
jsf.js ajax response xml format exception broken on newer mozilla builds Key: MYFACES-2778 URL: https://issues.apache.org/jira/browse/MYFACES-2778 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz Priority: Minor The way the xml errors are handled is not standardized every browser rolls its own handling, mozilla has changed the way it handles the xml parsing errors slightly, I have to readjust so that it works again. Also additionally to that I am going to make the development stage configurable from the config items if no default one is given. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2761) PartialViewContextImpl does not respect isRenderAll()
[ https://issues.apache.org/jira/browse/MYFACES-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883720#action_12883720 ] Werner Punz commented on MYFACES-2761: -- Hia Leonardo, I would call UIViewRoot in render=all nevertheless, there are browsers where it works (Firefox) theoretically a render all replaces everything including head tags. That the scripts only rerender the body is a pure client side issue. That the client for now has to ignore it (unless I find a way around the head issues on webkit and co) should not affect the server code in that area. A user might implement his own solution if he knows which browsers he can limit his code. > PartialViewContextImpl does not respect isRenderAll() > - > > Key: MYFACES-2761 > URL: https://issues.apache.org/jira/browse/MYFACES-2761 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces current trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe > > This construct should lead to complete ajax re-render of whole view (works > with mojarra): > partialViewContext.setRenderAll(true); > but it seems that myfaces don't read property renderAll during rendering at > all. Probably > org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(UIViewRoot, > PhaseId) should respect this property somehow. Note: there is a possible > workaround: > partialViewContext.getRenderIds().add(javax.faces.context.PartialResponseWriter.RENDER_ALL_MARKER); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2761) PartialViewContextImpl does not respect isRenderAll()
[ https://issues.apache.org/jira/browse/MYFACES-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883798#action_12883798 ] Werner Punz commented on MYFACES-2761: -- Ok I will change our script behavior then regarding embedded scripts for render all... We should be identical to mojarra in the behavior. > PartialViewContextImpl does not respect isRenderAll() > - > > Key: MYFACES-2761 > URL: https://issues.apache.org/jira/browse/MYFACES-2761 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces current trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe > > This construct should lead to complete ajax re-render of whole view (works > with mojarra): > partialViewContext.setRenderAll(true); > but it seems that myfaces don't read property renderAll during rendering at > all. Probably > org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(UIViewRoot, > PhaseId) should respect this property somehow. Note: there is a possible > workaround: > partialViewContext.getRenderIds().add(javax.faces.context.PartialResponseWriter.RENDER_ALL_MARKER); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2776) ViewState is not updated with ajax
[ https://issues.apache.org/jira/browse/MYFACES-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2776. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Invalid This probably was a temporary issue with one of the trunk states, it is not reproducable anymore. I will contact the user over the mailinglist to give him notification. > ViewState is not updated with ajax > -- > > Key: MYFACES-2776 > URL: https://issues.apache.org/jira/browse/MYFACES-2776 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Marcus Büttner >Assignee: Werner Punz > Fix For: 2.0.1-SNAPSHOT > > > When using ajax requests on ViewScoped Beans always old ViewState (ViewState > of last normal page rendering) is restored. It looks like component > javax.faces.ViewState is not updated in html dom tree by ajax. > Issue create to post on user list: > http://markmail.org/message/jnm6jilnb3p2b5s3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2779) PartialResponse bogus response on render all because of falsely positioned development stage script tag
PartialResponse bogus response on render all because of falsely positioned development stage script tag --- Key: MYFACES-2779 URL: https://issues.apache.org/jira/browse/MYFACES-2779 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz Hello Everyone some changes in the latest codebase cause a bogus render all response: Here is the output I am getting: http://www.pastebin.org/368077 as you can see the development stage is rendered before the html definition, any proper html parsing on such an output has to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2761) PartialViewContextImpl does not respect isRenderAll()
[ https://issues.apache.org/jira/browse/MYFACES-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883948#action_12883948 ] Werner Punz commented on MYFACES-2761: -- Ok I am working on a solution, I am also going to drop the interpreter in favor of browser based parsing, which is a tad slower but easier to maintain. (The interpreter had a bug and it is hard to maintain anyway, so I am going to drop it) The crux of this is, I wont be able to finish it today. Maybe tomorrow I will check everything in. > PartialViewContextImpl does not respect isRenderAll() > - > > Key: MYFACES-2761 > URL: https://issues.apache.org/jira/browse/MYFACES-2761 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces current trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe > > This construct should lead to complete ajax re-render of whole view (works > with mojarra): > partialViewContext.setRenderAll(true); > but it seems that myfaces don't read property renderAll during rendering at > all. Probably > org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(UIViewRoot, > PhaseId) should respect this property somehow. Note: there is a possible > workaround: > partialViewContext.getRenderIds().add(javax.faces.context.PartialResponseWriter.RENDER_ALL_MARKER); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2761) PartialViewContextImpl does not respect isRenderAll()
[ https://issues.apache.org/jira/browse/MYFACES-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883948#action_12883948 ] Werner Punz edited comment on MYFACES-2761 at 6/30/10 4:43 PM: --- Ok I committed the changes, scripts are now properly evaled even if placed in the head. The downside is, the page must be properly xhtml that this works html 4.01 is out of the game now. (normal in - body ppr cases still should work on html 4.01 though) I personally think this is a minor downside since facelets enforces xhtml 1.0+ anyway. was (Author: werpu): Ok I am working on a solution, I am also going to drop the interpreter in favor of browser based parsing, which is a tad slower but easier to maintain. (The interpreter had a bug and it is hard to maintain anyway, so I am going to drop it) The crux of this is, I wont be able to finish it today. Maybe tomorrow I will check everything in. > PartialViewContextImpl does not respect isRenderAll() > - > > Key: MYFACES-2761 > URL: https://issues.apache.org/jira/browse/MYFACES-2761 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.2-SNAPSHOT > Environment: myfaces current trunk >Reporter: Martin Kočí >Assignee: Leonardo Uribe > > This construct should lead to complete ajax re-render of whole view (works > with mojarra): > partialViewContext.setRenderAll(true); > but it seems that myfaces don't read property renderAll during rendering at > all. Probably > org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(UIViewRoot, > PhaseId) should respect this property somehow. Note: there is a possible > workaround: > partialViewContext.getRenderIds().add(javax.faces.context.PartialResponseWriter.RENDER_ALL_MARKER); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2779) PartialResponse bogus response on render all because of falsely positioned development stage script tag
[ https://issues.apache.org/jira/browse/MYFACES-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884065#action_12884065 ] Werner Punz commented on MYFACES-2779: -- Ok I added a small fixup code in my latest javascript commits, to deal with this issue, but as soon as it is fixed I will revert the javascript error correction code (it is just there to enable testing) > PartialResponse bogus response on render all because of falsely positioned > development stage script tag > --- > > Key: MYFACES-2779 > URL: https://issues.apache.org/jira/browse/MYFACES-2779 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > > Hello Everyone some changes in the latest codebase cause a bogus render all > response: > Here is the output I am getting: > http://www.pastebin.org/368077 > as you can see the development stage is rendered before the html definition, > any proper html parsing on such an output has to fail. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2781) Facelets double commenting embedded javascripts
Facelets double commenting embedded javascripts --- Key: MYFACES-2781 URL: https://issues.apache.org/jira/browse/MYFACES-2781 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.1, 2.0.2-SNAPSHOT Reporter: Werner Punz While I was testing the new head functionality I recognized an error which has not influenced browsers but influences my parsing routines (which rely on valid xhtml/xml markup for the head processing) renders on the browser
[jira] Created: (MYFACES-2786) Fix foundation work for jsf 2.1 in the areas of pps, timeout, delay, queue control
Fix foundation work for jsf 2.1 in the areas of pps, timeout, delay, queue control -- Key: MYFACES-2786 URL: https://issues.apache.org/jira/browse/MYFACES-2786 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz Now that the the spec for 2.1 is starting we have to fixup our foundation work in the areas of pps, timeout, delay and queue control. We have had that code since the beginning due to having it inherited from j4fry but it never got a serious testing and fixup, I am currently fixing that code up, so that way get a discussion and prototyping base for jsf 2.1 from it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2786) Fix foundation work for jsf 2.1 in the areas of pps, timeout, delay, queue control
[ https://issues.apache.org/jira/browse/MYFACES-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2786. -- Fix Version/s: 2.0.2-SNAPSHOT Resolution: Fixed Done everything now works as expected > Fix foundation work for jsf 2.1 in the areas of pps, timeout, delay, queue > control > -- > > Key: MYFACES-2786 > URL: https://issues.apache.org/jira/browse/MYFACES-2786 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > Fix For: 2.0.2-SNAPSHOT > > > Now that the the spec for 2.1 is starting we have to fixup our foundation > work in the areas of pps, timeout, delay and queue control. We have had that > code since the beginning due to having it inherited from j4fry but it never > got a serious testing and fixup, I am currently fixing that code up, so that > way get a discussion and prototyping base for jsf 2.1 from it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2793) jsf.ajax.request source should accept form element
[
https://issues.apache.org/jira/browse/MYFACES-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886075#action_12886075
]
Werner Punz commented on MYFACES-2793:
--
Yes this is definitely a bug, I will commit the fix tomorrow, thanks for
reporting it.
PS: Since you are from the icefaces team, I would love to have some feedback on
what you could need for improvement. I have somewhat a lack of feedback from
the authors of the big complibs.
> jsf.ajax.request source should accept form element
> --
>
> Key: MYFACES-2793
> URL: https://issues.apache.org/jira/browse/MYFACES-2793
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: MyFaces 2.0.1-SNAPSHOT, ICEfaces 2.0
>Reporter: Ted Goddard
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In some cases it is useful to directly pass the form element as the "source"
> parameter for jsf.ajax.request(source, |event|, { |OPTIONS| });
> The following modification to _Dom.js provides this feature:
> fuzzyFormDetection : function(elem) {
> ...
> //before going into the more complicated stuff we try the simple
> approach
> if (!_Lang.isString(elem)) {
> if (_Lang.equalsIgnoreCase(elem.tagName, "form")) {
> return elem;
> }
> return this.getParent(elem, "form");
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2794) jsf.js: Replace some direct comparisons with equalsIgnoreCase
jsf.js: Replace some direct comparisons with equalsIgnoreCase - Key: MYFACES-2794 URL: https://issues.apache.org/jira/browse/MYFACES-2794 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.2-SNAPSHOT Environment: Javascript Reporter: Werner Punz Priority: Minor We have some direct comparisons with toLowerCase in the dom routines, those need replacements by the Lang.js function equalsIgnoreCase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2795) browser independend auto eval detection
browser independend auto eval detection --- Key: MYFACES-2795 URL: https://issues.apache.org/jira/browse/MYFACES-2795 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz Priority: Minor The auto eval detection currently works over user agents, this is not ideal because for every browser release it has to be rechecked. Now that firefox has turned off auto eval, it probably is a good idea to move to a dom based detection to fix that as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2794) jsf.js: Replace some direct comparisons with equalsIgnoreCase
[ https://issues.apache.org/jira/browse/MYFACES-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2794. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed > jsf.js: Replace some direct comparisons with equalsIgnoreCase > - > > Key: MYFACES-2794 > URL: https://issues.apache.org/jira/browse/MYFACES-2794 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.2-SNAPSHOT > Environment: Javascript >Reporter: Werner Punz >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > We have some direct comparisons with toLowerCase in the dom routines, those > need replacements by the Lang.js function equalsIgnoreCase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2795) jsf.js:browser independend auto eval detection
[ https://issues.apache.org/jira/browse/MYFACES-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2795. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed > jsf.js:browser independend auto eval detection > -- > > Key: MYFACES-2795 > URL: https://issues.apache.org/jira/browse/MYFACES-2795 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz >Priority: Minor > Fix For: 2.0.1-SNAPSHOT > > > The auto eval detection currently works over user agents, this is not ideal > because for every browser release it has to be rechecked. Now that firefox > has turned off auto eval, it probably is a good idea to move to a dom based > detection to fix that as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2793) jsf.ajax.request source should accept form element
[
https://issues.apache.org/jira/browse/MYFACES-2793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-2793.
--
Fix Version/s: 2.0.1-SNAPSHOT
Resolution: Fixed
Fixed, thank you again for sending the bugfix in.
> jsf.ajax.request source should accept form element
> --
>
> Key: MYFACES-2793
> URL: https://issues.apache.org/jira/browse/MYFACES-2793
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.0.1-SNAPSHOT
> Environment: MyFaces 2.0.1-SNAPSHOT, ICEfaces 2.0
>Reporter: Ted Goddard
> Fix For: 2.0.1-SNAPSHOT
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In some cases it is useful to directly pass the form element as the "source"
> parameter for jsf.ajax.request(source, |event|, { |OPTIONS| });
> The following modification to _Dom.js provides this feature:
> fuzzyFormDetection : function(elem) {
> ...
> //before going into the more complicated stuff we try the simple
> approach
> if (!_Lang.isString(elem)) {
> if (_Lang.equalsIgnoreCase(elem.tagName, "form")) {
> return elem;
> }
> return this.getParent(elem, "form");
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2797) jsf.js Performance improvement dom update area by moving over to immerHTML
jsf.js Performance improvement dom update area by moving over to immerHTML -- Key: MYFACES-2797 URL: https://issues.apache.org/jira/browse/MYFACES-2797 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Werner Punz I ran the performance testing again against the scripts and found following out, for ie we use innerHTML with some fixes for the rest contextual ranges, this works, but contextual range creation is way slower than using innerHTML, neither is W3C standard, but at least innerHTML is supported over all browsers (with some bugs in older ie versions where it stems from), but innerHTML will be part of the HTML5 spec, since I solved all ie6 related innerhtml problems for our usecase I guess it is save to move over to innerHTML, we are talking about a differentce of 42 miliseconds on firefox 3.6 between the two methods. Mojarra still is faster (but fails to run my performance test on chrome, while our scripts work), but this is definitely one performance bottleneck we can solve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2797) jsf.js Performance of raw updates could need improvement compared to mojarra
[ https://issues.apache.org/jira/browse/MYFACES-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2797. -- Resolution: Fixed resolved we gained about 30% of raw exection performance, for a simple often triggered update case we are about 10% slower than mojarra on the raw javascript execution, but our code works on absolutely all desktop browsers including ie6 while mojarra fails the testcase on opera and chrome (probably any webkit based browser) The bigger performance issues now are on the server > jsf.js Performance of raw updates could need improvement compared to mojarra > > > Key: MYFACES-2797 > URL: https://issues.apache.org/jira/browse/MYFACES-2797 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Werner Punz > Fix For: 2.0.1-SNAPSHOT > > > I ran the performance testing again against the scripts and found following > out, for ie we use innerHTML with some fixes > for the rest contextual ranges, this works, but contextual range creation is > way slower than using innerHTML, neither is W3C standard, but at least > innerHTML is supported over all browsers (with some bugs in older ie > versions where it stems from), but innerHTML will be part of the HTML5 spec, > since I solved all ie6 related innerhtml problems for our usecase I guess it > is save to move over to innerHTML, we are talking about a differentce of 42 > miliseconds on firefox 3.6 between the two methods. > Mojarra still is faster (but fails to run my performance test on chrome, > while our scripts work), > this is partially caused by MyFaces constantly sending oamSubmit for a form > refresh (we should move that code finally out into an external resource), but > also partially on the javascript side, one reason for the performance > bottleneck was the usage > of contextualRanges which are half as fast as innerHTML. > Another issue is our oo layer, eval is calls way too often globalEval, > introducing a namespace index should resolve this. > On dom level the heaviest operation is the replaceElements probably by some > inlining for the 95% simple cases we can resolve that one to mojarra levels. > Last but not least our exectScript also can be performance improved by simply > concatenating all scripts and then doing a single eval. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2799) jsf.js cross form viewstate update
jsf.js cross form viewstate update -- Key: MYFACES-2799 URL: https://issues.apache.org/jira/browse/MYFACES-2799 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2-SNAPSHOT Reporter: Werner Punz Only issuer form and render target forms currently are updated, execute forms should be as well. This entire update mess again is caused by portlets constraints theoretically all forms within the document should be updated with their viewstates on server side state saving, we cannot do that due to having also to be able to run in portlets , we need a reliable portlet detection to fix this issue properly. (Burgreport on the jsf side is filed) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2799) jsf.js cross form viewstate update
[ https://issues.apache.org/jira/browse/MYFACES-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886642#action_12886642 ] Werner Punz commented on MYFACES-2799: -- After sleeping over things, I do not want to doctor in this area anymore. I filed a bugreport regarding the problems a while ago on the JSF2.1 side and it should be resolved on protocol level by further extensions to our viewstate handling specification on the ppr protocol. (including client ids for the viewstate forms) > jsf.js cross form viewstate update > -- > > Key: MYFACES-2799 > URL: https://issues.apache.org/jira/browse/MYFACES-2799 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > > Only issuer form and render target forms currently are updated, execute forms > should be as well. > This entire update mess again is caused by portlets constraints > theoretically all forms within the document should be updated with their > viewstates on server side state saving, we cannot do that due to > having also to be able to run in portlets > , we need a reliable portlet detection to fix this issue properly. > (Burgreport on the jsf side is filed) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2799) JSF 2.1: jsf.js viewstate handling does not entirely work out (bug filed on the spec tracker
[ https://issues.apache.org/jira/browse/MYFACES-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12886642#action_12886642 ] Werner Punz edited comment on MYFACES-2799 at 7/9/10 4:36 AM: -- After sleeping over things, I do not want to doctor in this area anymore. I filed a bugreport regarding the problems a while ago on the JSF2.1 side and it should be resolved on protocol level by further extensions to our viewstate handling specification on the ppr protocol. (including client ids for the viewstate forms) I have to add, cross form submit are already properly resolved by resolving forms which are related to the render cycle, so we have a workaround (although incompatible to mojarra which has non working fixup code) to the problem. So any further work on this issue, without getting the spec changes needed to fix it once and forall is pointless. was (Author: werpu): After sleeping over things, I do not want to doctor in this area anymore. I filed a bugreport regarding the problems a while ago on the JSF2.1 side and it should be resolved on protocol level by further extensions to our viewstate handling specification on the ppr protocol. (including client ids for the viewstate forms) > JSF 2.1: jsf.js viewstate handling does not entirely work out (bug filed on > the spec tracker > > > Key: MYFACES-2799 > URL: https://issues.apache.org/jira/browse/MYFACES-2799 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.2-SNAPSHOT >Reporter: Werner Punz > > Only issuer form and render target forms currently are updated, execute forms > should be as well. > This entire update mess again is caused by portlets constraints > theoretically all forms within the document should be updated with their > viewstates on server side state saving, we cannot do that due to > having also to be able to run in portlets > , we need a reliable portlet detection to fix this issue properly. > (Burgreport on the jsf side is filed) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2803) jsf.js multipart form request, multi transport method support
jsf.js multipart form request, multi transport method support - Key: MYFACES-2803 URL: https://issues.apache.org/jira/browse/MYFACES-2803 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.0 Reporter: Werner Punz We need iframe support for multipart form request (aka fileupload handling), we also might have to deliver different transport mechanisms outside of the existing one - Already working on it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2808) jsf.js tagged response causes hanging queue
[ https://issues.apache.org/jira/browse/MYFACES-2808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2808. -- Fix Version/s: 2.0.1-SNAPSHOT Resolution: Fixed fixed > jsf.js tagged response causes hanging queue > --- > > Key: MYFACES-2808 > URL: https://issues.apache.org/jira/browse/MYFACES-2808 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.1-SNAPSHOT >Reporter: Werner Punz > Fix For: 2.0.1-SNAPSHOT > > > see topic -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2808) jsf.js tagged response causes hanging queue
jsf.js tagged response causes hanging queue --- Key: MYFACES-2808 URL: https://issues.apache.org/jira/browse/MYFACES-2808 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz see topic -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2809) Bug in navigation + ppr
Bug in navigation + ppr --- Key: MYFACES-2809 URL: https://issues.apache.org/jira/browse/MYFACES-2809 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.1-SNAPSHOT Reporter: Werner Punz Priority: Blocker Hello I found following erratic behavior: if I have following forms http://www.pastebin.org/390005 under the name pprNavCase1 and the subsequent form: http://www.pastebin.org/390009 under the name pprNavCase2 we get following results: Navigation from page1 to page2 returns a rerender viewroot. Which is absolutely correct A subsequent navigation from page2 to page1 returns in the content of page2 to be redrawn, which is incorrect. In Mojarra the code switches from page1 to page2 and returns back to page1. This is an absolute showstopper because it indicates an error in the navigation somewhere, ppr navigation is not an unusual usecase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
