Re: [VOTE] Release Tobago 1.0.25
Here is my +1 Regards Bernd On Mon, Apr 19, 2010 at 11:09 AM, Udo Schnurpfeil u...@schnurpfeil.de wrote: +1 Am 19.04.10 07:01, schrieb Matthias Wessendorf: +1 Sent from my iPod. On 18.04.2010, at 16:34, Werner Punz werner.p...@gmail.com wrote: +1 Am 18.04.10 12:22, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.25. For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12314527 The version is available at the staging location and the revision number of the release is 935243 and tagged as tobago-1.0.25. Staging distribution: http://people.apache.org/~bommel/repo Staging repository: http://people.apache.org/~bommel/repo The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1
Re: [Trinidad 2] AJAX branch ready for testing
can you file a jira issue ? On Mon, Apr 19, 2010 at 7:37 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: _ajaxOldDomElements is code in Page.js, this looks like a bug in Trinidad that needs to be fixed On Fri, Apr 9, 2010 at 8:52 AM, Matthias Wessendorf mat...@apache.org wrote: looks like the 2.0.1 are just labeled as Mojarra 2.0.2 (SNAPSHOT 20091204) I now updated the pom to 2.0.2 and got this log: INFO: Initializing Mojarra 2.0.2 (FCS b10) But the error is the same on the clientBehaviorHolder.xhtml page -Matthias On Fri, Apr 9, 2010 at 4:33 PM, Matthias Wessendorf mat...@apache.org wrote: eh, funny. the pom is actually configured with 2.0.1. Something is going wrong here :-) On Fri, Apr 9, 2010 at 4:15 PM, Max Starets max.star...@oracle.com wrote: Matthias, Are you getting the same results with Mojarra 2.0.1? Max Matthias Wessendorf wrote: hi, I gave it a quick try. Here are my results: Page: http://localhost:8080/trinidad-demo/faces/demos/clientBehaviorHolder.xhtml JSF_RI (Mojarra 2.0.2 (SNAPSHOT 20091204)) results: I entered some text and clicked submit via JSF Ajax Got this (in an alert JS box): httpError: The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons. second click on the same button I got this JS error. mojarra is not defined [Break on this error] var func = new Function(event, handler); === the submit button works. MyFaces 2.0.0-SNAPHOT results: (using snapshot since the ViewExpiredException is gone in latest snapshot ) * submit button gives me this ALERT() box: TypeError: this._ajaxOldDomElements is null followed by this: malformedXML-- * Submit via JSF Ajax: I get this alert() BOX: httpError-httpError-Request failed Are there any other pages where I can test the new functionality ? -Matthias On Wed, Apr 7, 2010 at 4:33 PM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Btw. thanks guys for the effort, I think the tests also were a good indicator about the state of our javascripts. Which looked quite good btw. The main issues I have seen so far were on the spec level. We really need a queue control mechanism on the spec level and a timeout as well, hanging xhr cores should be terminated within an adjustable timeframe, and a load of inputs should not fill up the queue. Most of this is resolvable one way or the other outside, but it needs to be addressed on spec level. Werner Am 19.04.10 23:58, schrieb Andrew Robinson: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew
Re: [Trinidad 2] AJAX branch ready for testing
Sorry - all PPR stuff does a full page-refresh wasn´t that a caching issue on the browsers side, because I was investigating that problem and could not reproduce it. Werner Am 20.04.10 09:26, schrieb Matthias Wessendorf: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (EXTVAL-92) Ext-Script+Ext-Val Validation list changes, do not refresh while constraint validation changes are refreshed
[
https://issues.apache.org/jira/browse/EXTVAL-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved EXTVAL-92.
---
Resolution: Fixed
I added the cache clearing code on the ext-script side, for now I hacked it in
because I am missing framework events which will be added post 1.0 for spring
etc...
Good enough for now, but will be cleared up.
Ext-Val now is hopefully fully supported by Ext-Scripting.
Ext-Script+Ext-Val Validation list changes, do not refresh while constraint
validation changes are refreshed
Key: EXTVAL-92
URL: https://issues.apache.org/jira/browse/EXTVAL-92
Project: MyFaces Extensions Validator
Issue Type: Bug
Components: Core
Affects Versions: 2.0.3
Environment: OSX 10.6
Reporter: Werner Punz
Priority: Minor
I am currently integrating Ext-Scripting and Ext-Val, so that both frameworks
work together as expected.
So far things look good, but the issue I face is that while the Constraint
changes are picked up following is not
@BeanValidation.List({
@BeanValidation(useGroups = Default.class),
@BeanValidation(viewIds = /beanValidation.xhtml, useGroups =
User.class),
@BeanValidation(viewIds = /groupValidation02.jsp, useGroups =
Admin.class),
@BeanValidation(viewIds = /modelValidation01.jsp, useGroups =
Admin.class),
@BeanValidation(viewIds = /modelValidation01.jsp, useGroups =
Name.class,
modelValidation = @ModelValidation(isActive = true))
})
private Person person = new Person();
when I change anything in the ValidationList nothing changes, as it seems the
Validation list is cached overaggressively, so that on object reloads
it is not udpated.
There are two solutions to the problem
a) Either provide me a cache clear callback interface which I can trigger via
reflection from the core (and later from my event system)
b) Disable the cache in development mode so that no caching happens at all
Thanks Gerhard for providing me the feedback, I am just filing this issue so
that it does not get lost
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-119) Improve the Ext-Val integration
Improve the Ext-Val integration --- Key: EXTSCRIPT-119 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-119 Project: MyFaces Extensions Scripting Issue Type: Improvement Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz Ext-Val does some aggressive caching which has to be cleared, Gerhard Petracek gave me indications on what to do to clear up the caching. We will hack it in and post 1.0 once the event system is in place we will refactor it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-119) Improve the Ext-Val integration
[ https://issues.apache.org/jira/browse/EXTSCRIPT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-119. --- Fix Version/s: 1.0-Beta-2 Resolution: Fixed done works Improve the Ext-Val integration --- Key: EXTSCRIPT-119 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-119 Project: MyFaces Extensions Scripting Issue Type: Improvement Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz Fix For: 1.0-Beta-2 Ext-Val does some aggressive caching which has to be cleared, Gerhard Petracek gave me indications on what to do to clear up the caching. We will hack it in and post 1.0 once the event system is in place we will refactor it out. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-120) Performance bug,
Performance bug, Key: EXTSCRIPT-120 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-120 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz The scanner is triggered in the el resolver if a property could not be resolved, this is most likely old code which was using a two phased scan (one for delete the other one for add if an artifact is deleted annotationwise) Since we have been on a single phase scan for some while now this code should not be needed anymore it drags performance down, that is all it does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-121) removing an annotated managed property causes an error
removing an annotated managed property causes an error -- Key: EXTSCRIPT-121 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-121 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz The removal of an annotated managed property causes following error (see below) I assume the reason for this is a bug in the annotation scanner which does not seem to remove managed properties currently if they are not present anymore. Caused by: javax.el.PropertyNotFoundException: The class 'org.apache.myfaces.javaloader.test.TestBean2' does not have the property 'bean4'. at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) at javax.el.BeanELResolver.setValue(BeanELResolver.java:360) at javax.el.CompositeELResolver.setValue(CompositeELResolver.java:283) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:180) at org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.ELResolverProxy.setValue(ELResolverProxy.java:118) at org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:349) at org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:169) at org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:303) at org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:266) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.ELResolverProxy.getValue(ELResolverProxy.java:49) at org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1789) maven-tagdoc-plugin POM fails on Maven 3
maven-tagdoc-plugin POM fails on Maven 3 Key: TRINIDAD-1789 URL: https://issues.apache.org/jira/browse/TRINIDAD-1789 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.2-plugins Environment: Maven 3 JRE 1.6 Reporter: Ali Ok [ERROR] The project org.apache.myfaces.trinidadbuild:maven-tagdoc-plugin:2.0.2-SNAPSHOT (C:\Users\aok\Desktop\MyFacesWorkspace\maven-plugin-parent-BRANCH-2-0-x\maven-tagdoc-plugin\pom.xml) has 1 error [ERROR] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.maven:maven-project:jar - version 2.0 vs 2.0.1 There is 2 dependency version definitons for org.apache.maven:maven-project: 2.0 and 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1789) maven-tagdoc-plugin POM fails on Maven 3
[ https://issues.apache.org/jira/browse/TRINIDAD-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ali Ok updated TRINIDAD-1789: - Status: Patch Available (was: Open) maven-tagdoc-plugin POM fails on Maven 3 Key: TRINIDAD-1789 URL: https://issues.apache.org/jira/browse/TRINIDAD-1789 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Affects Versions: 2.0.2-plugins Environment: Maven 3 JRE 1.6 Reporter: Ali Ok Attachments: TRINIDAD-1789.patch Original Estimate: 0.02h Remaining Estimate: 0.02h [ERROR] The project org.apache.myfaces.trinidadbuild:maven-tagdoc-plugin:2.0.2-SNAPSHOT (C:\Users\aok\Desktop\MyFacesWorkspace\maven-plugin-parent-BRANCH-2-0-x\maven-tagdoc-plugin\pom.xml) has 1 error [ERROR] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.apache.maven:maven-project:jar - version 2.0 vs 2.0.1 There is 2 dependency version definitons for org.apache.maven:maven-project: 2.0 and 2.0.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-120) Performance bug,
[ https://issues.apache.org/jira/browse/EXTSCRIPT-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-120. --- Fix Version/s: 1.0-Beta-2 Resolution: Fixed done Performance bug, Key: EXTSCRIPT-120 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-120 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz Fix For: 1.0-Beta-2 The scanner is triggered in the el resolver if a property could not be resolved, this is most likely old code which was using a two phased scan (one for delete the other one for add if an artifact is deleted annotationwise) Since we have been on a single phase scan for some while now this code should not be needed anymore it drags performance down, that is all it does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-121) removing an annotated managed property causes an error
[ https://issues.apache.org/jira/browse/EXTSCRIPT-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-121. --- Fix Version/s: 1.0-Beta-2 Resolution: Fixed done you now can add and pull managed props on the fly removing an annotated managed property causes an error -- Key: EXTSCRIPT-121 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-121 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: 1.0-Beta-2 Reporter: Werner Punz Assignee: Werner Punz Fix For: 1.0-Beta-2 The removal of an annotated managed property causes following error (see below) I assume the reason for this is a bug in the annotation scanner which does not seem to remove managed properties currently if they are not present anymore. Caused by: javax.el.PropertyNotFoundException: The class 'org.apache.myfaces.javaloader.test.TestBean2' does not have the property 'bean4'. at javax.el.BeanELResolver.getBeanProperty(BeanELResolver.java:574) at javax.el.BeanELResolver.setValue(BeanELResolver.java:360) at javax.el.CompositeELResolver.setValue(CompositeELResolver.java:283) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.setValue(FacesCompositeELResolver.java:180) at org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.ELResolverProxy.setValue(ELResolverProxy.java:118) at org.apache.myfaces.config.ManagedBeanBuilder.initializeProperties(ManagedBeanBuilder.java:349) at org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:169) at org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:303) at org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:266) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:140) at org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.ELResolverProxy.getValue(ELResolverProxy.java:49) at org.apache.myfaces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:64) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-122) Initial compile and scan triggered twice in a jsf2 environment
Initial compile and scan triggered twice in a jsf2 environment -- Key: EXTSCRIPT-122 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-122 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: Beta-1 Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Due to having offloaded the initial compile and scan to a system event it is triggered twice in a jsf2 environment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2] AJAX branch ready for testing
Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/ Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2663) NPE in UIParameter when value resolves to null
[
https://issues.apache.org/jira/browse/MYFACES-2663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858886#action_12858886
]
Jakob Korherr commented on MYFACES-2663:
While looking through the code that uses UIParameter I found out that nearly
every method uses a different way to get its UIParameter children, which is
very inconsistent. So I introduced
HtmlRendererUtils.getValidUIParameterChildren() with a few parameters to
indicate whether or not to include null-values. This method is now used across
the code base to get all valid UIParameters, so ugly NPEs like this one should
not happen anymore.
However I will leave the issue open until the tests are committed.
NPE in UIParameter when value resolves to null
--
Key: MYFACES-2663
URL: https://issues.apache.org/jira/browse/MYFACES-2663
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jan-Kees van Andel
Assignee: Jakob Korherr
Attachments: MYFACES-2663-tests.patch
When I have a null value in an f:param
value=#{expr.that.evaluates.to.null} / tag, I get the following NPE when
rendering:
java.lang.NullPointerException
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.getOutcomeTargetLinkHref(HtmlRendererUtils.java:1883)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.renderOutcomeLinkStart(HtmlLinkRendererBase.java:742)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlLinkRendererBase.encodeBegin(HtmlLinkRendererBase.java:123)
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:430)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:605)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:614)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1117)
at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:231)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:122)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:207)
at
org.apache.myfaces.extensions.scripting.jsf.dynamicdecorators.implemetations.LifefcycleProxy.render(LifefcycleProxy.java:74)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
I don't know what the spec says or what Mojarra does, but I think we should
at least do better than a NPE, for example appending an empty string to the
parameter list...
Any ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTSCRIPT-122) Initial compile and scan triggered twice in a jsf2 environment
[ https://issues.apache.org/jira/browse/EXTSCRIPT-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved EXTSCRIPT-122. --- Fix Version/s: 1.0-Beta-2 Resolution: Fixed done, the dual init trigger now is deactivated Initial compile and scan triggered twice in a jsf2 environment -- Key: EXTSCRIPT-122 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-122 Project: MyFaces Extensions Scripting Issue Type: Bug Components: MyFaces 2.0 Extension Affects Versions: Beta-1 Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 1.0-Beta-2 Due to having offloaded the initial compile and scan to a system event it is triggered twice in a jsf2 environment -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2] AJAX branch ready for testing
on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1745) Introduce @mode in CSS files
[ https://issues.apache.org/jira/browse/TRINIDAD-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marius Petoi updated TRINIDAD-1745: --- Status: Patch Available (was: Open) Introduce @mode in CSS files Key: TRINIDAD-1745 URL: https://issues.apache.org/jira/browse/TRINIDAD-1745 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.2.13-core Reporter: Marius Petoi Priority: Minor In order to transform the old XSS files in CSS files, @mode should be supported in CSS -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad][Skinning] Introduce @mode in CSS files
Hello, In the XSS files there are some styles which are mode-dependent, such as: styleSheet platforms=windows ppc browsers=ie versions=6 mode=quirks //. These are styles defined only for quirks mode. In CSS this feature is not implemented and it is needed in order to port the old XSS files into CSS. I attached a patch to the JIRA ticket: https://issues.apache.org/jira/browse/TRINIDAD-1745. Please have a look over it and see if it is ok. Thank you! Marius
[jira] Commented: (MYFACES-2665) Legacy ViewHandler doesn't work in back compatibility mode for JSP pages
[ https://issues.apache.org/jira/browse/MYFACES-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858921#action_12858921 ] Jakob Korherr commented on MYFACES-2665: The problem here originates from the fact that the code that builds the whole component tree was moved from ViewHandler.renderView() to ViewDeclarationLanguage.buildView() in JSF 2.0. This is a problem for the legacy ViewHandler, because it returns null for getViewDeclarationLanguage() and thus VDL.buildView() is never called. To solve this problem we have to memorize if VDL.buildView() was already called for the current UIViewRoot in VDL.renderView(), and if not, we have to call it from there. Legacy ViewHandler doesn't work in back compatibility mode for JSP pages Key: MYFACES-2665 URL: https://issues.apache.org/jira/browse/MYFACES-2665 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Nick Belaevski Assignee: Jakob Korherr Attachments: myfaces-2665.zip Attached demo project shows ViewHandler wrapper based on JSF 1.2 that prevents JSP pages rendering in back-compatibility mode. View structure is just not being built, because calls to VDL doesn't happen. Mojarra works (activate jsfri Maven profile to check). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Ext-Scripting Final Logo
Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner
Re: Ext-Scripting Final Logo
It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.pnghttp://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Ext-Scripting Final Logo
Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.pnghttp://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Ext-Scripting Final Logo
Btw. guys I would need a favor, can anyone have a quick look over the documentation, if the information is enough to get people started? I am very nitpicky regarding having good documentation, but I am sort of blind regarding my own stuff. Werner Am 20.04.10 17:04, schrieb Bruno Aranda: Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png http://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [Trinidad 2] AJAX branch ready for testing
Also, are you using JSF RI? MyFaces is known to be bad with Ajax. On 04/20/2010 08:50 AM, Max Starets wrote: Hey Matthias, This works for me: http://adc2100180.us.oracle.com:7101/trinidad-demo-context-root/faces/demos/pprDemos.jspx Are you seeing any errors? Is request showing up in Firebug console? Thanks, Max Matthias Wessendorf wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Matthias Wessendorf blog:http://matthiaswessendorf.wordpress.com/ sessions:http://www.slideshare.net/mwessendorf twitter:http://twitter.com/mwessendorf -- Andrew Robinson | Principal Software Engineer Phone: +1 303 334 5027 Oracle
Re: [Trinidad 2] AJAX branch ready for testing
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of hours
to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the Ajax
part (which caused your conclusion), please post them to the jira under
our impl section, so that we can fix it :-), just saying bad with ajax
is no help here :-), we would like to have the best ajax implementation
of both implementations (better than the RI, so any bugreport is
welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Message true
_noJavaScript false
event autosub
itxtChange this text
j_id1078059021_4041e82d
javax.faces.ViewState !h19u5lcmm
javax.faces.ViewState !h19u5lcmm
javax.faces.partial.ajaxtrue
javax.faces.partial.event click
javax.faces.partial.execu...null
javax.faces.source null
org.apache.myfaces.trinid...j_id1078059021_4041e08f
partial true
selOne 0
source j_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Ok I did a testing on the RI the links do not work as well, but wont
even go into the xhr part (I will add a fix here to be coherent to the
RI in our scripts)
what happens is that the links trigger an error
jsf.ajax.request: source not set
throw new Error(jsf.ajax.request: source not set);
Due to a missing source element on trinidads side
(I am more lenient regarding the source, because I also handle detached
objects which some frameworks like dojo or jquery can produce,
but I obviously missed the case of source being null or undefined,
having to throw an explicit error, which is not directly in the spec
afair, but nevertheless I will change that tomorrow if the spec does not
state otherwise)
the original request as posted below
issues:
javax.faces.source null
in our case it just performs an empty roundtrip in case of the ri it
bombs out due to constraints on the javascripts side.
Werner
Am 20.04.10 17:37, schrieb Werner Punz:
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of hours
to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the Ajax
part (which caused your conclusion), please post them to the jira under
our impl section, so that we can fix it :-), just saying bad with ajax
is no help here :-), we would like to have the best ajax implementation
of both implementations (better than the RI, so any bugreport is
welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Message true
_noJavaScript false
event autosub
itxt Change this text
j_id1078059021_4041e82d
javax.faces.ViewState !h19u5lcmm
javax.faces.ViewState !h19u5lcmm
javax.faces.partial.ajax true
javax.faces.partial.event click
javax.faces.partial.execu... null
javax.faces.source null
org.apache.myfaces.trinid... j_id1078059021_4041e08f
partial true
selOne 0
source j_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Hello Andrew, on my tryouts I used both, see here: http://markmail.org/message/onwsrqwfhu7ai67e -Matthias On Tue, Apr 20, 2010 at 5:00 PM, Andrew Robinson andrew.robin...@oracle.com wrote: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. On 04/20/2010 08:50 AM, Max Starets wrote: Hey Matthias, This works for me: http://adc2100180.us.oracle.com:7101/trinidad-demo-context-root/faces/demos/pprDemos.jspx Are you seeing any errors? Is request showing up in Firebug console? Thanks, Max Matthias Wessendorf wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions:
Re: [Trinidad 2] AJAX branch ready for testing
Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help of some others). Actually if you have run into any errors or problems regarding the Ajax part (which caused your conclusion), please post them to the jira under our impl section, so that we can fix it :-), just saying bad with ajax is no help here :-), we would like to have the best ajax implementation of both implementations (better than the RI, so any bugreport is welcome). But no offence taken, back to the topic. But back to the original problem, the first link (Go to Trinidad demos home page.) issue following xhr post: Tr-PPR-Message true _noJavaScript false event autosub itxt Change this text
Re: [Trinidad 2] AJAX branch ready for testing
I can see this page failing with JS errors in chrome. I'll have a look On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Hello Andrew, the problem below is already fixed in the up-coming release, which I used to verify this. Let's merge your branch to trunk and work on it to get these other (minor) things fixed. On Tue, Apr 20, 2010 at 6:09 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help of some others). Actually if you have run into any errors or problems regarding the Ajax part (which caused your conclusion), please post them to the jira under our impl section, so that we can fix it :-), just saying bad with ajax is no help here :-), we would like to have the best ajax
[jira] Created: (PORTLETBRIDGE-140) Ensure invocation of buildView() in PortletJspViewDeclarationLanguageImpl
Ensure invocation of buildView() in PortletJspViewDeclarationLanguageImpl - Key: PORTLETBRIDGE-140 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-140 Project: MyFaces Portlet Bridge Issue Type: Task Components: Impl Environment: sobryan_portlet-bridge-3.0.0 branch Reporter: Jakob Korherr Assignee: Scott O'Bryan On MYFACES-2665 we got an error report that JSPs are not working with legacy ViewHandler implementations. After some digging on the issue I found out that VDL.buildView() is never called, because getViewDeclarationLanguage() returns null on a legacy ViewHandler. However this has to be called in order to work properly, so I committed a solution that memorizes if VDL.buildView() has been called and if not, it calls it from VDL.renderView() before the real rendering happens (see [1] for details). This solves the problem. However some code I had to change is from shared and is also used by the Portlet Bridge (JspViewDeclarationLanguageBase). So in order to work properly, PortletJspViewDeclarationLanguageImpl has to call super.buildView() in its buildView() method to do the memorizing (just as JspViewDeclarationLanguage does). Otherwise buildView() will be called twice on PortletJspViewDeclarationLanguageImpl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (PORTLETBRIDGE-140) Ensure invocation of buildView() in PortletJspViewDeclarationLanguageImpl
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated PORTLETBRIDGE-140: Status: Patch Available (was: Open) Ensure invocation of buildView() in PortletJspViewDeclarationLanguageImpl - Key: PORTLETBRIDGE-140 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-140 Project: MyFaces Portlet Bridge Issue Type: Task Components: Impl Environment: sobryan_portlet-bridge-3.0.0 branch Reporter: Jakob Korherr Assignee: Scott O'Bryan Attachments: PORTLETBRIDGE-140.patch On MYFACES-2665 we got an error report that JSPs are not working with legacy ViewHandler implementations. After some digging on the issue I found out that VDL.buildView() is never called, because getViewDeclarationLanguage() returns null on a legacy ViewHandler. However this has to be called in order to work properly, so I committed a solution that memorizes if VDL.buildView() has been called and if not, it calls it from VDL.renderView() before the real rendering happens (see [1] for details). This solves the problem. However some code I had to change is from shared and is also used by the Portlet Bridge (JspViewDeclarationLanguageBase). So in order to work properly, PortletJspViewDeclarationLanguageImpl has to call super.buildView() in its buildView() method to do the memorizing (just as JspViewDeclarationLanguage does). Otherwise buildView() will be called twice on PortletJspViewDeclarationLanguageImpl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2665) Legacy ViewHandler doesn't work in back compatibility mode for JSP pages
[ https://issues.apache.org/jira/browse/MYFACES-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12858956#action_12858956 ] Jakob Korherr commented on MYFACES-2665: This works now, but I will leave the issue open, because I want to provide a test case for it. Legacy ViewHandler doesn't work in back compatibility mode for JSP pages Key: MYFACES-2665 URL: https://issues.apache.org/jira/browse/MYFACES-2665 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Nick Belaevski Assignee: Jakob Korherr Attachments: myfaces-2665.zip Attached demo project shows ViewHandler wrapper based on JSF 1.2 that prevents JSP pages rendering in back-compatibility mode. View structure is just not being built, because calls to VDL doesn't happen. Mojarra works (activate jsfri Maven profile to check). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2] AJAX branch ready for testing
Hi Andrew, here is the ticket: https://issues.apache.org/jira/browse/MYFACES-2641 Looks like just a ticket for the _ajaxOldDomElements is missing, right ? http://markmail.org/message/tcoi36bneeultdx2 -Matthias On Tue, Apr 20, 2010 at 6:16 PM, Matthias Wessendorf mat...@apache.org wrote: Hello Andrew, the problem below is already fixed in the up-coming release, which I used to verify this. Let's merge your branch to trunk and work on it to get these other (minor) things fixed. On Tue, Apr 20, 2010 at 6:09 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: Werner, sorry for the short reply on that email, the tone probably sounded bad. There are state saving problems when using MyFaces. Unfortunately it is bad enough to make it completely non-functional as all PPR post backs fail to restore the state from what I have seen. We have no such errors when using Mojarra. @Matthias or Max: did one of you guys already file a bug on the MyFaces Core for this or do we still need to? To reproduce: 1) Get a working copy of the jsf2_ajax.3 Trinidad Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 2) Run the demo project using Jetty (mvn jetty:run -PjettyConfig) 3) Hit the page: http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml 4) Click on one of the buttons at the top (Full Submit button is fine) This error results: SEVERE: An exception occurred javax.faces.application.ViewExpiredException: /demos/ajaxPPRDemos.xhtmlNo saved view state could be found for the view identifier: /demos/ajaxPPRDemos.xhtml at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:114) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:138) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:88) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:189) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:536) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:930) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:747) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:405) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Form Data sent: itxt1:Change this text2 sf20%3Aitxt2:Change this text2 it1: org.apache.myfaces.trinidad.faces.FORM:j_id933005119_379c87b2 _noJavaScript:false javax.faces.ViewState:!yabr3gltb : javax.faces.behavior.event:action javax.faces.partial.event:click javax.faces.source:axBtn2 javax.faces.partial.ajax:true javax.faces.partial.execute:axBtn2 javax.faces.partial.render:btnTarget Request Headers: Content-Type:application/x-www-form-urlencoded Faces-Request:partial/ajax Origin:http://localhost:8080 Referer:http://localhost:8080/trinidad-demo/faces/demos/ajaxPPRDemos.xhtml User-Agent:Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/533.2 (KHTML, like Gecko) Chrome/5.0.342.9 Safari/533.2 On Tue, Apr 20, 2010 at 9:37 AM, Werner Punz werner.p...@gmail.com wrote: Am 20.04.10 17:00, schrieb Andrew Robinson: Also, are you using JSF RI? MyFaces is known to be bad with Ajax. Ouch that hit me personally, because I and others spent a load of hours to make the our javascripts as good as possible as the spec allowed (with the help
Re: [Trinidad 2] AJAX branch ready for testing
On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorf mat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Starets max.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorf mat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorf mat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorf mat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Starets max.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Ext-Scripting Final Logo
I used the docs last Sunday to get going, but I of course already knew a thing or two about the framework. Besides some small things that I have already fixed on the Wiki, I think the docs are good. But again, the opinion of someone who hasn't used Ext-Scripting before would be useful. Oh, btw. nice logo! /JK 2010/4/20 Werner Punz werner.p...@gmail.com Btw. guys I would need a favor, can anyone have a quick look over the documentation, if the information is enough to get people started? I am very nitpicky regarding having good documentation, but I am sort of blind regarding my own stuff. Werner Am 20.04.10 17:04, schrieb Bruno Aranda: Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png http://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [Trinidad 2] AJAX branch ready for testing
Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter:
Re: [Trinidad 2] AJAX branch ready for testing
Werner,
__handlePprResponseAction() is meant to update the action URL on the form
(this is what old Trinidad PPR always did). It's not supposed to do
navigation.
Max
Werner Punz wrote:
Am 20.04.10 17:00, schrieb Andrew Robinson:
Also, are you using JSF RI? MyFaces is known to be bad with Ajax.
Ouch that hit me personally, because I and others spent a load of
hours to make
the our javascripts as good as possible as the spec allowed (with the
help of some others).
Actually if you have run into any errors or problems regarding the
Ajax part (which caused your conclusion), please post them to the jira
under our impl section, so that we can fix it :-), just saying bad
with ajax is no help here :-), we would like to have the best ajax
implementation of both implementations (better than the RI, so any
bugreport is welcome). But no offence taken, back to the topic.
But back to the original problem, the first link (Go to Trinidad demos
home page.) issue following xhr post:
Tr-PPR-Messagetrue
_noJavaScriptfalse
eventautosub
itxtChange this text
j_id1078059021_4041e82d
javax.faces.ViewState!h19u5lcmm
javax.faces.ViewState!h19u5lcmm
javax.faces.partial.ajaxtrue
javax.faces.partial.eventclick
javax.faces.partial.execu...null
javax.faces.sourcenull
org.apache.myfaces.trinid...j_id1078059021_4041e08f
partialtrue
selOne0
sourcej_id1078059021_4041e6c3
and the response is following:
?xml version=1.0 ?
partial-responsechangesupdate
id=tr_j_id1078059021_4041e08f_Postscript![CDATA[span
id=tr_j_id1078059021_4041e08f_Postscriptinput type=hidden
name=sourcescript
type=text/javascriptTrPage.getInstance()._addResetFields('j_id1078059021_4041e08f',[source]);/scriptscript
type=text/javascriptvar
j_id1078059021_4041e08f_SF={};/script/span]]/updateupdate
id=javax.faces.ViewState![CDATA[!h19u5lcmm]]/updateeval![CDATA[TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');]]/eval/changes/partial-response
Not sure what the eval
TrPage.getInstance().__handlePprResponseAction('/trinidad-demo/faces/demos/pprDemos.jspx');
in this case triggers, it should trigger a go to the homepage.
Werner
Re: [Trinidad 2] AJAX branch ready for testing
Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter:
Re: [Trinidad 2] AJAX branch ready for testing
Werner, With the latest build, I can see the navigation happening with no issues when you choose Go to Trinidad demos home page on pprDemos.jspx. The response contains the following: ?xml version=1.0 encoding=utf-8? partial-responseredirect url=/trinidad-demo-context-root/faces/index.jspx/redirect/partial-response Max Max Starets wrote: Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and client behaviors, JSF2 submission working along side of partialSubmit=true and auto PPR. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions:
Re: [Trinidad 2] AJAX branch ready for testing
Ajax branch has been merged into the trunk. We'll keep hammering away on the problems that were found (most JSF2, not AJAX related) so we can hopefully stabilize the code for a release in the not too distant future.
[jira] Created: (TRINIDAD-1790) Trinidad 2: Component Bindings are not executed during postback
Trinidad 2: Component Bindings are not executed during postback --- Key: TRINIDAD-1790 URL: https://issues.apache.org/jira/browse/TRINIDAD-1790 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets To reproduce, run testRelativePartialTriggers.jspx an click the first Make table Pink button. Note that the table component is being PPR-ed, but the inline style remains the same. This happens because 'table1' in the backing bean is null. The setter method never gets called. The most likely cause is the fact that JSF RI moved the code for binding execution out of the lifecycle implementation into the PostRestoreViewState event processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad 2] AJAX branch ready for testing
Ok then the issue is fixed, the redirect response looks ok to me. I will update tomorrow and will fix the missing no source error on my side so that we get the same behavior on both mojarra and myfaces regarding null sources. Werner Am 20.04.10 20:42, schrieb Max Starets: Werner, With the latest build, I can see the navigation happening with no issues when you choose Go to Trinidad demos home page on pprDemos.jspx. The response contains the following: ?xml version=1.0 encoding=utf-8? partial-responseredirect url=/trinidad-demo-context-root/faces/index.jspx/redirect/partial-response Max Max Starets wrote: Werner, I will look into the navigation issue. The expected behavior with Trinidad in this case is a redirect. Max Werner Punz wrote: Actually Command components with partialSubmit works for me on both implementations. What does not work for me on both implementations is Command components with partialSubmit going to another page. Werner Am 20.04.10 18:40, schrieb Andrew Robinson: On Tue, Apr 20, 2010 at 7:59 AM, Matthias Wessendorfmat...@apache.org wrote: on the pprDemos.jspx stuff, there is a bunch of tests for PPR, one of the has the header Command components with partialSubmit, which does not work (in the trinidad demo) Works fine for me using -Djsf=ri2 except for the selectManyListbox once I did a rebuild and refresh. File (in SVN) is located there: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx On Tue, Apr 20, 2010 at 6:37 AM, Max Staretsmax.star...@oracle.com wrote: Matthias, What do you mean when you say 'command components with partialSubmit do not work'? Thanks, Max On Apr 20, 2010, at 3:26 AM, Matthias Wessendorfmat...@apache.org wrote: Checked Mojarra 2.0.1 and MyFaces 2.0.0 (out soon) - both have the NPE filed in TRINIDAD-1786 * Mojarra: -PPR on select* works (exception see above) - Command components with partialSubmit does _not_ work * MyFaces: - all PPR stuff does a full page-refresh I am fine in merging these bits to trunk, but before we acutally do a release, we should check what's going wrong in MyFaces/Trinidad ;-) (I think it must be an issue in MyFaces, so once I have some more time, I will file a bug against that, with a little better description) -Matthias On Tue, Apr 20, 2010 at 9:09 AM, Matthias Wessendorfmat...@apache.org wrote: Ok, looks like you are talking about JSF2's JS/Ajax stuff. The term mojarra is slightly confusing, since I understand it as a specific dependency to that particular implementation. But looks like we do not have that, for the ajax stuff, which is great. -Matthias On Tue, Apr 20, 2010 at 9:05 AM, Matthias Wessendorfmat...@apache.org wrote: On Mon, Apr 19, 2010 at 11:58 PM, Andrew Robinson andrew.rw.robin...@gmail.com wrote: The branch is ready and the issues that were brought up in this thread as well as other issues have been resolved. Unless there are any objections, I will merge the changes into the trunk tomorrow. fine here. Note that Max added a switch to be able to turn off PPR through JSF at the agent level so that mobile browsers that fail with the mojarra JavaScript can go back to the legacy code. not sure I understand: why is that switch mojarra specific ? Or are you just saying that it's a fallback to JSF2 ? -Matthias -Andrew On Wed, Apr 7, 2010 at 8:33 AM, Max Staretsmax.star...@oracle.com wrote: Just a few minor additions - - PartialViewContext.isAjaxRequest() will be returning true for the requests sent with jsf ajax as well as the legacy partialSubmit=true requests. - Trinidad's partial triggers will be honored for the jsf ajax requests. However, this will currently work only with execute=@all. Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. Max Andrew Robinson wrote: Well after a bit of work, the JSF2 AJAX branch is ready for testing to see if we want to merge it into the trunk. Branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/jsf2_ajax.3 Details: - jsf.ajax.request used to submit PPR requests from the request queue - server serves JSF2 payload, differing if an IFRAME submission is detected for Trinidad to send down script libraries - iframe processing through legacy code, but updated to use a valid JSF2 payload - iframe still sends Tr-XHR-Message to let the server know its a legacy request - legacy request supports DOM replacement but none of the new functionality of JSF2 (attribute updates for example) - TrPage integrated with JSF2 events to correctly broadcast DOM change notifications and restore focus - If users find errors in the jsf.js libraries, setting the _useJsfBuiltInAjaxForXhr property of the request queue to false will bypass usage of jsf.ajax. We can add support for a public way of doing this later if necessary. - Server side integration with the JSF2 APIs and
[Trinidad 2] Announcement: JSF 2 ajax support has been added to the trunk
As of SVN revision 936035, the Trinidad trunk now supports the built in AJAX of JSF2. Details: - Requests through f:ajax supported with Trinidad components - jsf.ajax.request used to submit PPR requests from the Trinidad request queue - Server delivers JSF2 payload, with special handling for Trinidad IFRAME requests to send down script libraries - IFrame processing still possible by bypassing the jsf.ajax code which has yet to be made compatible with file uploads in either Mojarra or MyFaces - Note that there is a limitation that iframe processing only supports the legacy PPR of Trinidad (replacement only, no support for the new insert, delete, attribute change functionality of the JSF2 partial response writer) - Trinidad still supports broadcasting of DOM changes and restores focus by leveraging JSF AJAX events - Agent specific flag to disable AJAX through jsf.ajax to handle use cases where mobile platforms do not function using the Mojarra or MyFaces JavaScript - Integration on the server between JSF 2 rendered IDs and Trinidad partial triggers - Partial submit and client behavior support - Trinidad's partial triggers will be honored for the jsf ajax requests. - However, this will currently work only with execute=@all or if the execute attribute is pointed to each component that is listed as a partial trigger. - Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. We welcome your assistance to test your applications on the current Trunk and report your findings and file issues when found. Thank you, Andrew
Re: Ext-Scripting Final Logo
Am 20.04.10 19:37, schrieb Jan-Kees van Andel: I used the docs last Sunday to get going, but I of course already knew a thing or two about the framework. Besides some small things that I have already fixed on the Wiki, I think the docs are good. But again, the opinion of someone who hasn't used Ext-Scripting before would be useful. Ok before I have to dig through the wiki history, since the pages are mostly legacy now (I have not yet deleted them) do you know what you fixed so that I can add it to the docs? (PS feel free to fix it directly in the docs, since you have committer rights anway) Werner Oh, btw. nice logo! /JK 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Btw. guys I would need a favor, can anyone have a quick look over the documentation, if the information is enough to get people started? I am very nitpicky regarding having good documentation, but I am sort of blind regarding my own stuff. Werner Am 20.04.10 17:04, schrieb Bruno Aranda: Great job! I like it, Cheers, Bruno On 20 April 2010 16:01, Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com wrote: It looks _very_ great and, of course, totally fits into the myfaces design. Regards, Jakob 2010/4/20 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com mailto:werner.p...@gmail.com mailto:werner.p...@gmail.com Hello everyone, Adonis (who designed the other Logos) has given me a final logo it looks now like following: http://people.apache.org/~werpu/ext-script-site/images/extscriptlogo.png http://people.apache.org/%7Ewerpu/ext-script-site/images/extscriptlogo.png respectively in conjunction with the documentation: http://people.apache.org/~werpu/ext-script-site/ http://people.apache.org/%7Ewerpu/ext-script-site/ I think the logo is more than perfect and fits into our design. Werner -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [Trinidad 2] Announcement: JSF 2 ajax support has been added to the trunk
great news! -Matthias On Tue, Apr 20, 2010 at 9:33 PM, Andrew Robinson arobinso...@apache.org wrote: As of SVN revision 936035, the Trinidad trunk now supports the built in AJAX of JSF2. Details: - Requests through f:ajax supported with Trinidad components - jsf.ajax.request used to submit PPR requests from the Trinidad request queue - Server delivers JSF2 payload, with special handling for Trinidad IFRAME requests to send down script libraries - IFrame processing still possible by bypassing the jsf.ajax code which has yet to be made compatible with file uploads in either Mojarra or MyFaces - Note that there is a limitation that iframe processing only supports the legacy PPR of Trinidad (replacement only, no support for the new insert, delete, attribute change functionality of the JSF2 partial response writer) - Trinidad still supports broadcasting of DOM changes and restores focus by leveraging JSF AJAX events - Agent specific flag to disable AJAX through jsf.ajax to handle use cases where mobile platforms do not function using the Mojarra or MyFaces JavaScript - Integration on the server between JSF 2 rendered IDs and Trinidad partial triggers - Partial submit and client behavior support - Trinidad's partial triggers will be honored for the jsf ajax requests. - However, this will currently work only with execute=@all or if the execute attribute is pointed to each component that is listed as a partial trigger. - Once we start adding trigger listeners during the PostRestoreView event processing, instead of decode, this limitation will go away. We welcome your assistance to test your applications on the current Trunk and report your findings and file issues when found. Thank you, Andrew -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] AJAX branch ready for testing
Am 20.04.10 21:22, schrieb Andrew Robinson: Ajax branch has been merged into the trunk. We'll keep hammering away on the problems that were found (most JSF2, not AJAX related) so we can hopefully stabilize the code for a release in the not too distant future. Hey Andrew sounds good, and feel free to open a jira issue if you run into issues on our sides, we will be happy to fix them for you guys. (and sorry for my reaction before) Werner
[jira] Commented: (TRINIDAD-1790) Trinidad 2: Component Bindings are not executed during postback
[ https://issues.apache.org/jira/browse/TRINIDAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12859045#action_12859045 ] Max Starets commented on TRINIDAD-1790: --- The issue only shows up if Trinidad view root caching is enabled. Trinidad 2: Component Bindings are not executed during postback --- Key: TRINIDAD-1790 URL: https://issues.apache.org/jira/browse/TRINIDAD-1790 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0.3-core Reporter: Max Starets To reproduce, run testRelativePartialTriggers.jspx an click the first Make table Pink button. Note that the table component is being PPR-ed, but the inline style remains the same. This happens because 'table1' in the backing bean is null. The setter method never gets called. The most likely cause is the fact that JSF RI moved the code for binding execution out of the lifecycle implementation into the PostRestoreViewState event processing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1715) Client behaviors are not decoded by UIXComponentBase
[ https://issues.apache.org/jira/browse/TRINIDAD-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1715. --- Fix Version/s: 2.0.0.3-core Resolution: Fixed Forgot to mark this as fixed Client behaviors are not decoded by UIXComponentBase Key: TRINIDAD-1715 URL: https://issues.apache.org/jira/browse/TRINIDAD-1715 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.0.3-core Forgot to add the client behavior decoding support to UIXComponentBase when I implemented the client behavior support -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
