[jira] [Updated] (TRINIDAD-2282) In validateLength, a default hintRange message is displayed instead of hintMaximum even when minimum value is not set
[
https://issues.apache.org/jira/browse/TRINIDAD-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshu Jain updated TRINIDAD-2282:
-
Status: Patch Available (was: Open)
> In validateLength, a default hintRange message is displayed instead of
> hintMaximum even when minimum value is not set
> -
>
> Key: TRINIDAD-2282
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2282
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.0.0-beta-2
> Environment: JDeveloper 11.1.2.0.0
>Reporter: Anshu Jain
>
> af:validateLength is used for a input text box. The maximum value is set and
> minimum value is not set. Which means by default minimum is 0.
> The hintMaximum is set to "{0} is maximum allowed" and hintRange is set to
> "{0} is minimum, {1} is maximum"
> When the user clicks on the the given text box, hintMaximum should be
> displayed.
> Instead a default message: "Enter between 0 and 3 characters." is displayed.
> hintMaximum should be displayed in this scenario.
--
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] [Updated] (TRINIDAD-2282) In validateLength, a default hintRange message is displayed instead of hintMaximum even when minimum value is not set
[
https://issues.apache.org/jira/browse/TRINIDAD-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshu Jain updated TRINIDAD-2282:
-
Status: Open (was: Patch Available)
> In validateLength, a default hintRange message is displayed instead of
> hintMaximum even when minimum value is not set
> -
>
> Key: TRINIDAD-2282
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2282
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 2.0.0-beta-2
> Environment: JDeveloper 11.1.2.0.0
>Reporter: Anshu Jain
>
> af:validateLength is used for a input text box. The maximum value is set and
> minimum value is not set. Which means by default minimum is 0.
> The hintMaximum is set to "{0} is maximum allowed" and hintRange is set to
> "{0} is minimum, {1} is maximum"
> When the user clicks on the the given text box, hintMaximum should be
> displayed.
> Instead a default message: "Enter between 0 and 3 characters." is displayed.
> hintMaximum should be displayed in this scenario.
--
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] [Created] (MYFACES-3577) Duplicate component Id Exception when binding variable in Session Scope
Kumar Ashish created MYFACES-3577: - Summary: Duplicate component Id Exception when binding variable in Session Scope Key: MYFACES-3577 URL: https://issues.apache.org/jira/browse/MYFACES-3577 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.1.5 Environment: Weblogic 10.3.4 server,Eclipse IDE,Windows xp,Java SE 6, Reporter: Kumar Ashish JSF specification JSF_20101108 mentions in its section 3.1.5 "It is strongly recommend that application developers place managed beans that are pointed at by component binding expressions in "request" scope, and not any other scope." My concerns are as follows:- 1) We are getting duplicate component id exception when using binding in a session scoped variable in myfaces 2.1.It is a well known issue. This is a "recommendation" for the developers but has been forced by the myfaces implementation. 2) JSF 1.2 and 1.1 implementations worked fine with the binding variables in session scope also. Please let me know if this issue will be taken up in future releases or myfaces is going to have the same implementaion from now on. -- 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-3577) Duplicate component Id Exception when binding variable in Session Scope
[
https://issues.apache.org/jira/browse/MYFACES-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403138#comment-13403138
]
Mike Kienenberger commented on MYFACES-3577:
I have received duplicate component id exceptions for this in Myfaces 1.1 or
1.2 when using facelets if I bind components to session-scoped beans, so this
is not a change in behavior.
Note that if you only need a reference to your bound components and not
dynamically create components, make sure you are returning "null" for the
binding getter.
public UIComponent getMyComponent() { return null; }
public void setMyComponent(UIComponent c) { this.mycomponent = c; }
If you are using this pattern, you should be able to bind components to
session-scoped beans without duplicate id warnings. This works in Myfaces
1.2. I will be testing in the next few days for 2.1 as I am starting a
conversion of a project that uses this pattern today.
You still have to understand the issue mentioned by Leonardo, and make sure you
are handling that situation.
> Duplicate component Id Exception when binding variable in Session Scope
> ---
>
> Key: MYFACES-3577
> URL: https://issues.apache.org/jira/browse/MYFACES-3577
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-314
>Affects Versions: 2.1.5
> Environment: Weblogic 10.3.4 server,Eclipse IDE,Windows xp,Java SE 6,
>Reporter: Kumar Ashish
>Assignee: Leonardo Uribe
>
> JSF specification JSF_20101108 mentions in its section 3.1.5 "It is strongly
> recommend that application developers place managed beans that are pointed at
> by component binding expressions in
> "request" scope, and not any other scope."
> My concerns are as follows:-
> 1) We are getting duplicate component id exception when using binding in a
> session scoped variable in myfaces 2.1.It is a well known issue.
> This is a "recommendation" for the developers but has been forced by the
> myfaces implementation.
> 2) JSF 1.2 and 1.1 implementations worked fine with the binding variables in
> session scope also.
> 3) The mojarra implementation does not enforces this.
> Please let me know if this issue will be taken up in future releases or
> myfaces is going to have the same implementaion from now on.
--
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-3575) Disable relative location caching in DefaultFaceletFactory
[ https://issues.apache.org/jira/browse/MYFACES-3575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13403164#comment-13403164 ] Leonardo Uribe commented on MYFACES-3575: - I have been thinking about this problem and the intention of _relativeLocations is prevent unnecessary calls to ExternalContext.getResource(). In theory a cache like this one should be inside ResourceResolver implementation, because that's the right location to do that caching. Also, that part is done there to prevent unnecessary URL parsing. The real problem is the whole hack proposed violates Partial State Saving (PSS) requeriments, because it allows to change the location of the templates for a given string pointing to a template. So, if there is a postback and something has changed the algorithm will fail. > Disable relative location caching in DefaultFaceletFactory > -- > > Key: MYFACES-3575 > URL: https://issues.apache.org/jira/browse/MYFACES-3575 > Project: MyFaces Core > Issue Type: Improvement > Components: Extension Feature >Affects Versions: 2.0.14, 2.1.8 > Environment: Linux >Reporter: Dmitry Kukushkin >Assignee: Leonardo Uribe >Priority: Minor > > In some circumstances the caching of the relative location in the public > Facelet getFacelet(String uri) in DefaultFaceletFactory is not desirable: > e.g. return the mobile and full content version for the same URI, if the user > changes the content type on the fly. Now this caching always causes the same > content to be returned. > Should it be possible to switch it off like it is done for other caches in > this class with needsToBeRefreshed check and NO_CACHE_DELAY configuration > parameter? -- 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] [Created] (EXTCDI-297) merge back DELTASPIKE-212
Gerhard Petracek created EXTCDI-297: --- Summary: merge back DELTASPIKE-212 Key: EXTCDI-297 URL: https://issues.apache.org/jira/browse/EXTCDI-297 Project: MyFaces CODI Issue Type: Task Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- 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
