[jira] [Created] (MYFACES-3547) Can't use expression for validator attributes
Deryk Sinotte created MYFACES-3547: -- Summary: Can't use expression for validator attributes Key: MYFACES-3547 URL: https://issues.apache.org/jira/browse/MYFACES-3547 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.1.7 Environment: validator ajax Reporter: Deryk Sinotte Attaching a test case that shows a problem when using an expression for an attribute in a validator. We have markup that looks like this: When the value of the maximum attribute is modified via Ajax from another input field, the value of the bean is properly set but the validator doesn't resolve appear to resolve the expression at the right time and the result is that validation occurs against the "old" values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3313) Calculation of redirect URL does not preserve the extension used in Faces Servlet mapping
[
https://issues.apache.org/jira/browse/MYFACES-3313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13109778#comment-13109778
]
Deryk Sinotte commented on MYFACES-3313:
The issue is consistent when using partial page rendering as well. The update
that returns from:
MyFaces:
Mojarra:
> Calculation of redirect URL does not preserve the extension used in Faces
> Servlet mapping
> -
>
> Key: MYFACES-3313
> URL: https://issues.apache.org/jira/browse/MYFACES-3313
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.1.2, 2.1.3
>Reporter: Deryk Sinotte
>
> I have a simple navigation test case that does a navigation between two
> pages. Both pages have the same simple markup:
>
> Page 01
>
> value="Nav"
>action="#{testBean.lastPage}" />
>
>
> The backing bean methods simply return the appropriate action outcome:
> public String lastPage(){
> return "lastPage";
> }
> And the faces-config file has the following navigation rules:
>
> *
>
> lastPage
> /page02.jsf
>
>
>
> firstPage
> /page01.jsf
>
>
>
> The web.xml has a servlet mapping for .jsf files:
>
> Faces Servlet
> *.jsf
>
> If I go to the page01.jsf, the page loads fine. When I click the "Nav"
> button, the navigation occurs but the URL is page02.xhtml rather than
> page02.jsf. Because the extension is not preserved and there is no mapping
> for .xhtml in this case, the page doesn't get handled by the Faces Servlet.
> The current version of Mojarra (2.1.3) does preserve the extension when the
> redirect URL is encoded.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3313) Calculation of redirect URL does not preserve the extension used in Faces Servlet mapping
Calculation of redirect URL does not preserve the extension used in Faces
Servlet mapping
-
Key: MYFACES-3313
URL: https://issues.apache.org/jira/browse/MYFACES-3313
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.1.3, 2.1.2
Reporter: Deryk Sinotte
I have a simple navigation test case that does a navigation between two pages.
Both pages have the same simple markup:
Page 01
The backing bean methods simply return the appropriate action outcome:
public String lastPage(){
return "lastPage";
}
And the faces-config file has the following navigation rules:
*
lastPage
/page02.jsf
firstPage
/page01.jsf
The web.xml has a servlet mapping for .jsf files:
Faces Servlet
*.jsf
If I go to the page01.jsf, the page loads fine. When I click the "Nav" button,
the navigation occurs but the URL is page02.xhtml rather than page02.jsf.
Because the extension is not preserved and there is no mapping for .xhtml in
this case, the page doesn't get handled by the Faces Servlet. The current
version of Mojarra (2.1.3) does preserve the extension when the redirect URL is
encoded.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3272) The h:message and h:messages renderers don't provide a consistent parent element for updates
The h:message and h:messages renderers don't provide a consistent parent element for updates - Key: MYFACES-3272 URL: https://issues.apache.org/jira/browse/MYFACES-3272 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Deryk Sinotte We've documented some of the analysis in our own tracking system: http://jira.icefaces.org/browse/ICE-6622 The issue is that, with both the h:message and h:messages tags, the rendered output is empty if an "id" attribute is not provided. When an Ajax request triggers a message, the resulting update needs to look for a parent element - like the form or even the entire body depending on where the h:message(s) tag is located. This can make the updates much larger than they need to be. By adding an "id" attribute, the renderer will ouput a containing element, regardless of whether are messages or not: h:message will render a h:messages will render a In the case of h:message, an update that actually contains the span will be replaced by a span - which is basically the behaviour we want. But with h:messages, the div is replaced by ul which is less desirable as the actual element type is changing. What we'd like to see is that the renderers provide consistent output at all times, whether there is a message or not. So that a span or div with a id (generated if necessary) is always present and this consistent parent element would allow updates to be smaller and more efficient. Note: The same problem exists with Mojarra and we submitted an issue awhile ago but it's still pending: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-931 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3179) Inconsistent behaviour implementing and registering SystemEventListeners for PostAddToViewEvents
Inconsistent behaviour implementing and registering SystemEventListeners for PostAddToViewEvents Key: MYFACES-3179 URL: https://issues.apache.org/jira/browse/MYFACES-3179 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.1, 2.1.0, 2.0.7 Environment: Tested on Tomcat 7 Reporter: Deryk Sinotte I've developed a test case (which will be attached) which is a simple JSF app that has 3 different methods of registering SystemEventListeners for PostAddToViewEvents: 1) via @ListenFor annotations 2) via definition in faces-config.xml 3) via programmatically adding the listener through an eagerly created application scoped bean Then I ran this tst case with the following JSF implemenations: * Mojarra 2.1 * MyFaces 2.0.7 * MyFaces 2.1.0 * MyFaces 2.1.1 The behaviour can be summarized as follows: Method 1 - Annotations All implementations: The listener instance is never constructed or used. (Perhaps it's a limitation of the annotation processing in Tomcat?) Method 2 - Defining in faces-config.xml Mojarra 2.1: An instance of the listener is created and used appropriately. MyFaces 2.*: An instance of the listener is created but the isListenerFor() and processEvent() methods are never called. Method 3 - Programmatic registration All implementations: An instance of the listener is created and used appropriately. So the question is why, when the listeners are defined in the faces-config file, are the listeners created but never called. Other MyFaces JIRAs that might have some relevance: https://issues.apache.org/jira/browse/MYFACES-2509 https://issues.apache.org/jira/browse/MYFACES-2638 Bottom line is that only the programmatic approach appears to be reliable across the 2 implementations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3178) Calling jsf.getViewState() with a direct reference to a form element throws an exception
[
https://issues.apache.org/jira/browse/MYFACES-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Deryk Sinotte updated MYFACES-3178:
---
Status: Patch Available (was: Open)
> Calling jsf.getViewState() with a direct reference to a form element throws
> an exception
>
>
> Key: MYFACES-3178
> URL: https://issues.apache.org/jira/browse/MYFACES-3178
> Project: MyFaces Core
> Issue Type: Bug
> Components: General, JSR-314
>Affects Versions: 2.1.0, 2.1.1
> Environment: Client
>Reporter: Deryk Sinotte
>
> The jsf.getViewState() function is a standard part of the JSF client API.
> Currently, if I call this function with a valid reference to a form object,
> an exception is thrown. Firefox 4 (with Firebug) reports it as:
> this._onException is not a function
> I believe the problem stems from the getViewState implementation itself in
> Impl.js:
> getViewState : function(form) {
> /**
> * typecheck assert!, we opt for strong typing here
> * because it makes it easier to detect bugs
> */
> if (form) {
> form = this._Lang.byId(form);
> }
> if (!form
> || !form.nodeName
> || form.nodeName.toLowerCase() != "form") {
> throw new Error(this._Lang.getMessage("ERR_VIEWSTATE"));
> }
> var ajaxUtils = new myfaces._impl.xhrCore._AjaxUtils(0);
> var ret = this._Lang.createFormDataDecorator([]);
> ajaxUtils.encodeSubmittableFields(ret, null, null, form, null);
> return ret.makeFinal();
> },
> In that function, some checking is done to ensure that the form is a valid
> reference, then a new AjaxUtils is created with no parameters. Typically
> these would be warning and exception handlers. Since these handlers are
> missing, when encodeSubmittable fields runs into a problem and tries to use
> the handler, the above noted exception occurs.
> When encodeSubmittableFields is called, the form reference is set as the
> parameter expected for an individual form item and the parentItem is null. I
> believe the form should be set as the parent item:
> ajaxUtils.encodeSubmittableFields(ret, null, null, null, form, null);
> By setting it as the parent item, the encoding logic should be able to handle
> it correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3178) Calling jsf.getViewState() with a direct reference to a form element throws an exception
Calling jsf.getViewState() with a direct reference to a form element throws an
exception
Key: MYFACES-3178
URL: https://issues.apache.org/jira/browse/MYFACES-3178
Project: MyFaces Core
Issue Type: Bug
Components: General, JSR-314
Affects Versions: 2.1.1, 2.1.0
Environment: Client
Reporter: Deryk Sinotte
The jsf.getViewState() function is a standard part of the JSF client API.
Currently, if I call this function with a valid reference to a form object, an
exception is thrown. Firefox 4 (with Firebug) reports it as:
this._onException is not a function
I believe the problem stems from the getViewState implementation itself in
Impl.js:
getViewState : function(form) {
/**
* typecheck assert!, we opt for strong typing here
* because it makes it easier to detect bugs
*/
if (form) {
form = this._Lang.byId(form);
}
if (!form
|| !form.nodeName
|| form.nodeName.toLowerCase() != "form") {
throw new Error(this._Lang.getMessage("ERR_VIEWSTATE"));
}
var ajaxUtils = new myfaces._impl.xhrCore._AjaxUtils(0);
var ret = this._Lang.createFormDataDecorator([]);
ajaxUtils.encodeSubmittableFields(ret, null, null, form, null);
return ret.makeFinal();
},
In that function, some checking is done to ensure that the form is a valid
reference, then a new AjaxUtils is created with no parameters. Typically these
would be warning and exception handlers. Since these handlers are missing,
when encodeSubmittable fields runs into a problem and tries to use the handler,
the above noted exception occurs.
When encodeSubmittableFields is called, the form reference is set as the
parameter expected for an individual form item and the parentItem is null. I
believe the form should be set as the parent item:
ajaxUtils.encodeSubmittableFields(ret, null, null, null, form, null);
By setting it as the parent item, the encoding logic should be able to handle
it correctly.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
