JSF 2.2 - disableClientWindow fully implemented?
Hi, is disableClientWindow completely implemented? I can see the attribute in UIOutcomeTarget but i can't see (via file search) any code that calls the getter or do a #getAttribute(disableClientWindow). Regards, Thomas
Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Hi Leo, sounds fine! thanks :) 2013/12/9 Leonardo Uribe lu4...@gmail.com Hi I think we could add it as a parameter for f:view tag, for example call it oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some cases, but after doing some experiments (MYFACES-3831) I have found we need to change some parts of the algorithm. Specifically I have found that it is not really necessary the check to disable the pool when VariableMapper is used because with the code we have in place there is no way an EL expression should not be the same each time the view is built. A phaselistener is not necessary. I think the best place to set the param manually is ViewHandler.createView(...). regards, Leonardo Uribe
Re: JSF 2.2 - disableClientWindow fully implemented?
Hi It seems we forgot to include those lines. The fix should be done in org.apache.myfaces.shared.renderkit.html.util.OutcomeTargetUtils.getOutcomeTargetHref(...). Please create an issue for this one in jira. regards, Leonardo Uribe 2013/12/9 Thomas Andraschko andraschko.tho...@gmail.com Hi, is disableClientWindow completely implemented? I can see the attribute in UIOutcomeTarget but i can't see (via file search) any code that calls the getter or do a #getAttribute(disableClientWindow). Regards, Thomas
[jira] [Created] (MYFACES-3832) disableClientWindow is not fully implemented
Thomas Andraschko created MYFACES-3832: -- Summary: disableClientWindow is not fully implemented Key: MYFACES-3832 URL: https://issues.apache.org/jira/browse/MYFACES-3832 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.0-beta Reporter: Thomas Andraschko The OutcomeTargetUtils must consider the attribute when rendering the URL -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (MYFACES-3465) Provide stateless extension
[ https://issues.apache.org/jira/browse/MYFACES-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved MYFACES-3465. Resolution: Duplicate JSF 2.2 provides stateless views and MyFaces 2.2 AFAIK provide poolable views Provide stateless extension --- Key: MYFACES-3465 URL: https://issues.apache.org/jira/browse/MYFACES-3465 Project: MyFaces Core Issue Type: New Feature Reporter: Thomas Andraschko As discussed with Leonardo, i create an issue with the stateless jsf extension. The code: http://www.mediafire.com/?3wr72zlch7ly1wc (also prepared with myfaces namespace and checkstyle) This extension is based on: http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead/ (Thanks to Rudi!) I completely refactored the code and made it compatible with mojarra and myfaces (with extra modules). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Hi It seems we have an inconsistency between what was proposed to enable the view pool and the inclusion of the new parameter. At start we have this: org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the app, by default false) But if we use an attribute in f:view like oamEnableViewPool, aiming to select the views that will use the pool, the previous param does not look good because it overlaps the attribute. In this case, I think it is better to keep things simple and remove the web config param and let the pool to be enabled only through the attribute or the entry in faces-config-extension. I'll do that. regards, Leonardo Uribe 2013/12/9 Thomas Andraschko andraschko.tho...@gmail.com Hi Leo, sounds fine! thanks :) 2013/12/9 Leonardo Uribe lu4...@gmail.com Hi I think we could add it as a parameter for f:view tag, for example call it oamEnableViewPool. The patch proposed uses already an attribute for disable the pool in some cases, but after doing some experiments (MYFACES-3831) I have found we need to change some parts of the algorithm. Specifically I have found that it is not really necessary the check to disable the pool when VariableMapper is used because with the code we have in place there is no way an EL expression should not be the same each time the view is built. A phaselistener is not necessary. I think the best place to set the param manually is ViewHandler.createView(...). regards, Leonardo Uribe
