[jira] [Resolved] (TOBAGO-2287) Avoid error msg when using cc:clientBehavior with target attribute and f:ajax and @this
[
https://issues.apache.org/jira/browse/TOBAGO-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2287.
---
Resolution: Fixed
> Avoid error msg when using cc:clientBehavior with target attribute and f:ajax
> and @this
> ---
>
> Key: TOBAGO-2287
> URL: https://issues.apache.org/jira/browse/TOBAGO-2287
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.2.0
>Reporter: Bernd Bohmann
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 5.11.0, 6.3.0
>
>
> Error:
> {code:java}
> o.a.myfaces.tobago.util.ComponentUtils : No component found for
> id='@this:selected-values', search base component is
> 'page:filter-roles:selected-values' {code}
> in composite component:
> {code:java}
> targets="selected-values"/> {code}
>
> Code in org.apache.myfaces.view.facelets.tag.faces.core.AjaxHandler there is
> something like this
> {code:java}
> // execute is required
> Collection execute = ajaxBehavior.getExecute();
> if (execute.isEmpty() || execute.contains("@this"))
> {
> Collection newExecute = new ArrayList<>(execute);
> newExecute.remove("@this");
> for (String target : targetsArray)
> {
> newExecute.add("@this" + separatorChar + target);
> }
> ajaxBehavior.setExecute(newExecute);
> }
> // render is optional
> Collection render = ajaxBehavior.getRender();
> if (render.contains("@this"))
> {
> Collection newRender = new ArrayList<>(render);
> newRender.remove("@this");
> for (String target : targetsArray)
> {
> newRender.add("@this" + separatorChar + target);
> }
> ajaxBehavior.setRender(newRender);
> } {code}
>
>
> We need to handle _@this:_ in ComponentUtils. Still I think the myfaces
> core code is wrong the '@this' should be enough
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2277) Support for PassThroughAttributes in Tobago
[ https://issues.apache.org/jira/browse/TOBAGO-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2277. --- Resolution: Fixed > Support for PassThroughAttributes in Tobago > --- > > Key: TOBAGO-2277 > URL: https://issues.apache.org/jira/browse/TOBAGO-2277 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.11.0, 6.3.0 > > > Implemented in TobagoResponseWriter and in tc:in, tc:textarea, tc:out, > tc:image, tc:button and tc:link -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2291) Allow Jakarta Faces HTML tags in segment layout
[ https://issues.apache.org/jira/browse/TOBAGO-2291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2291. --- Resolution: Fixed > Allow Jakarta Faces HTML tags in segment layout > --- > > Key: TOBAGO-2291 > URL: https://issues.apache.org/jira/browse/TOBAGO-2291 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.10.0, 6.2.0 >Reporter: Henning Nöth >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 5.11.0, 6.3.0 > > > The current workaround is, to wrap a with a . -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2289) Invalid warning message from TobagoConfigParser for some tags
[
https://issues.apache.org/jira/browse/TOBAGO-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2289.
---
Resolution: Fixed
> Invalid warning message from TobagoConfigParser for some tags
> -
>
> Key: TOBAGO-2289
> URL: https://issues.apache.org/jira/browse/TOBAGO-2289
> Project: MyFaces Tobago
> Issue Type: Improvement
> Components: Core
>Affects Versions: 5.10.0, 6.2.0
>Reporter: Bernd Bohmann
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 5.11.0, 6.3.0
>
>
>
> {code:java}
> o.a.m.t.i.config.TobagoConfigParser : Ignoring unknown start tag
> with hashCode=1967055403
> o.a.m.t.i.config.TobagoConfigParser : Ignoring unknown start tag
> with hashCode=-1764519240
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-1982) Composite components in segment layout not rendered correctly
[
https://issues.apache.org/jira/browse/TOBAGO-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-1982.
---
Resolution: Fixed
> Composite components in segment layout not rendered correctly
> -
>
> Key: TOBAGO-1982
> URL: https://issues.apache.org/jira/browse/TOBAGO-1982
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.3.2
>Reporter: Henning Nöth
>Assignee: Bernd Bohmann
>Priority: Minor
> Fix For: 5.11.0, 6.3.0
>
>
> Imagine a composite component for a text, where the attribute "asText" decide
> if a tc:in or a tc:out is used.
> {code:xml}
>
>
>
>
>
>
>
> {code}
> Without a layout manager the component show either the tc:in or the tc:out as
> expected.
> Within a segment layout the component use two segments. One for the tc:in
> and the second for the tc:out.
> If "asText=true" the first segment is empty and the second segment shows the
> tc:out.
> If "asText=false" the first segment shows the tc:in and the second segment is
> empty.
> This might be not the expected behavior, which I think is that the composite
> component uses only one segment.
> As a workaround you can wrap the tc:in/tc:out with a panel:
> {code:xml}
>
>
>
>
>
> {code}
>
> (!) And the 'rendered' attribute on the composite component container doesn't
> work within a segment layout which should be definitely fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2290) Allow style tag in segment layout
[ https://issues.apache.org/jira/browse/TOBAGO-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2290. --- Resolution: Fixed > Allow style tag in segment layout > - > > Key: TOBAGO-2290 > URL: https://issues.apache.org/jira/browse/TOBAGO-2290 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.10.0, 6.2.0 >Reporter: Henning Nöth >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 5.11.0, 6.3.0 > > > Currently a within a is ignored. It would be an > easy way to set for example a maximum width on the segment layout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (TOBAGO-2277) Support for PassThroughAttributes in Tobago
[ https://issues.apache.org/jira/browse/TOBAGO-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann reopened TOBAGO-2277: --- button and link are missing > Support for PassThroughAttributes in Tobago > --- > > Key: TOBAGO-2277 > URL: https://issues.apache.org/jira/browse/TOBAGO-2277 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.11.0, 6.3.0 > > > Implemented in TobagoResponseWriter and in tc:in, tc:textarea, tc:out and > tc:image -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2289) Invalid warning message from TobagoConfigParser for some tags
Bernd Bohmann created TOBAGO-2289: - Summary: Invalid warning message from TobagoConfigParser for some tags Key: TOBAGO-2289 URL: https://issues.apache.org/jira/browse/TOBAGO-2289 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.2.0, 5.10.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann o.a.m.t.i.config.TobagoConfigParser : Ignoring unknown start tag with hashCode=1967055403 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (TOBAGO-1982) Composite components in segment layout not rendered correctly
[
https://issues.apache.org/jira/browse/TOBAGO-1982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann reopened TOBAGO-1982:
---
Assignee: Bernd Bohmann (was: Henning Nöth)
> Composite components in segment layout not rendered correctly
> -
>
> Key: TOBAGO-1982
> URL: https://issues.apache.org/jira/browse/TOBAGO-1982
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.3.2
>Reporter: Henning Nöth
>Assignee: Bernd Bohmann
>Priority: Minor
>
> Imagine a composite component for a text, where the attribute "asText" decide
> if a tc:in or a tc:out is used.
> {code:xml}
>
>
>
>
>
>
>
> {code}
> Without a layout manager the component show either the tc:in or the tc:out as
> expected.
> Within a segment layout the component use two segments. One for the tc:in
> and the second for the tc:out.
> If "asText=true" the first segment is empty and the second segment shows the
> tc:out.
> If "asText=false" the first segment shows the tc:in and the second segment is
> empty.
> This might be not the expected behavior, which I think is that the composite
> component uses only one segment.
> As a workaround you can wrap the tc:in/tc:out with a panel:
> {code:xml}
>
>
>
>
>
> {code}
>
> (!) And the 'rendered' attribute on the composite component container doesn't
> work within a segment layout which should be definitely fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2287) Error 'No component found for id='@this:xys'.. with composite component and clientBehavoir with target attribute
Bernd Bohmann created TOBAGO-2287:
-
Summary: Error 'No component found for id='@this:xys'.. with
composite component and clientBehavoir with target attribute
Key: TOBAGO-2287
URL: https://issues.apache.org/jira/browse/TOBAGO-2287
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 6.2.0
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
{code:java}
o.a.myfaces.tobago.util.ComponentUtils : No component found for
id='@this:selected-values', search base component is
'page:filter-roles:selected-values' {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2277) Support for PassThroughAttributes in Tobago
[ https://issues.apache.org/jira/browse/TOBAGO-2277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2277. --- Resolution: Fixed > Support for PassThroughAttributes in Tobago > --- > > Key: TOBAGO-2277 > URL: https://issues.apache.org/jira/browse/TOBAGO-2277 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.10.1, 6.2.1 > > > Implemented in TobagoResponseWriter and in tc:in, tc:textarea, tc:out and > tc:image -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2277) Support for PassthroughAttributes in Tobago
Bernd Bohmann created TOBAGO-2277: - Summary: Support for PassthroughAttributes in Tobago Key: TOBAGO-2277 URL: https://issues.apache.org/jira/browse/TOBAGO-2277 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.1.0, 5.9.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2273) Avoid warning log message for required|converter|validatorMessage attribute
[ https://issues.apache.org/jira/browse/TOBAGO-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2273. --- Resolution: Fixed > Avoid warning log message for required|converter|validatorMessage attribute > --- > > Key: TOBAGO-2273 > URL: https://issues.apache.org/jira/browse/TOBAGO-2273 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.1, 6.1.1 > > > Can't find enum for Attributes with name 'requiredMessage' > I think the warning is useless. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2276) Allow selectionMode only for columnSelector
[ https://issues.apache.org/jira/browse/TOBAGO-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2276. --- Resolution: Fixed > Allow selectionMode only for columnSelector > --- > > Key: TOBAGO-2276 > URL: https://issues.apache.org/jira/browse/TOBAGO-2276 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.1, 6.1.1 > > > You can configure selectionMode none for the sheet and define a selectionMode > for the columnSelector only. Use case is rowSelection for show details and > columnSelector for executing action on rows. Selection will change with a > click inside the columnSelector column only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2276) Allow selectionMode only for columnSelector
Bernd Bohmann created TOBAGO-2276: - Summary: Allow selectionMode only for columnSelector Key: TOBAGO-2276 URL: https://issues.apache.org/jira/browse/TOBAGO-2276 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.1.0, 5.9.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann You can configure selectionMode none for the sheet and onlti selectionMode for the columnSelector. Use case is rowSelection for show details and columnSelector for executing action on items. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2273) Avoid warning log message for required/converter/validatorMessage attribute
Bernd Bohmann created TOBAGO-2273: - Summary: Avoid warning log message for required/converter/validatorMessage attribute Key: TOBAGO-2273 URL: https://issues.apache.org/jira/browse/TOBAGO-2273 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.1.0, 5.9.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Can't find enum for Attributes with name 'requiredMessage' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2267) Ajax request outside sheet breaks lazy loading within sheet
[ https://issues.apache.org/jira/browse/TOBAGO-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2267. --- Fix Version/s: 5.9.1 6.1.1 Resolution: Fixed > Ajax request outside sheet breaks lazy loading within sheet > --- > > Key: TOBAGO-2267 > URL: https://issues.apache.org/jira/browse/TOBAGO-2267 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Marcus Kroeger >Assignee: Henning Nöth >Priority: Major > Fix For: 5.9.1, 6.1.1 > > > When e.g. > * searching using a tc:in outside the sheet which triggers a reload of the > sheet the values get shown correctly. When emtying the search the lazy loaded > sheet does not show all values anymore. > * clicking a button within a sheet column which rerenders the sheet, not all > values are shown anymore -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2272) Support for delay attribute in f:ajax
[ https://issues.apache.org/jira/browse/TOBAGO-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2272. --- Fix Version/s: 5.9.1 6.1.1 Resolution: Fixed > Support for delay attribute in f:ajax > - > > Key: TOBAGO-2272 > URL: https://issues.apache.org/jira/browse/TOBAGO-2272 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.9.0, 6.1.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.1, 6.1.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2271) Error for lazy tc:sheet with only one row
[
https://issues.apache.org/jira/browse/TOBAGO-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2271.
---
Resolution: Fixed
> Error for lazy tc:sheet with only one row
> -
>
> Key: TOBAGO-2271
> URL: https://issues.apache.org/jira/browse/TOBAGO-2271
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: JavaScript
>Affects Versions: 5.9.0
>Reporter: Verena Schreyer
>Assignee: Bernd Bohmann
>Priority: Major
> Labels: sheet
> Fix For: 5.9.1, 6.1.1
>
> Attachments: error.PNG
>
>
> If the property "lazy" for tc:sheet is set to "true" and there is only one
> row in the sheet the following error occurs:
>
> {color:#ff}Uncaught TypeError: Cannot read properties of undefined
> (reading 'offsetTop'){color}
> {color:#ff} at get firstVisibleRowIndex [as firstVisibleRowIndex]
> (tobago-sheet.ts:345:33){color}
> {color:#ff} at HTMLElement.nextLazyLoad (tobago-sheet.ts:404:39){color}
> {color:#ff} at HTMLElement.lazyCheck (tobago-sheet.ts:389:23){color}
> {color:#ff} at HTMLElement.connectedCallback
> (tobago-sheet.ts:248:12){color}
> {color:#ff} at HTMLDocument. (tobago-sheet.ts:970:27){color}
> {color:#ff} at tobago-all.ts:65:12{color}
> {color:#ff} at tobago.js:1:62{color}
> {color:#ff} at tobago.js:1:66{color}
>
> {color:#ff}!error.PNG|height=250,width=600!{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2271) Error for lazy tc:sheet with only one row
[
https://issues.apache.org/jira/browse/TOBAGO-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17795900#comment-17795900
]
Bernd Bohmann commented on TOBAGO-2271:
---
There is a composite component? Can you provide some example code?
> Error for lazy tc:sheet with only one row
> -
>
> Key: TOBAGO-2271
> URL: https://issues.apache.org/jira/browse/TOBAGO-2271
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: JavaScript
>Affects Versions: 5.9.0
>Reporter: Verena Schreyer
>Assignee: Henning Nöth
>Priority: Major
> Labels: sheet
> Attachments: error.PNG
>
>
> If the property "lazy" for tc:sheet is set to "true" and there is only one
> row in the sheet the following error occurs:
>
> {color:#ff}Uncaught TypeError: Cannot read properties of undefined
> (reading 'offsetTop'){color}
> {color:#ff} at get firstVisibleRowIndex [as firstVisibleRowIndex]
> (tobago-sheet.ts:345:33){color}
> {color:#ff} at HTMLElement.nextLazyLoad (tobago-sheet.ts:404:39){color}
> {color:#ff} at HTMLElement.lazyCheck (tobago-sheet.ts:389:23){color}
> {color:#ff} at HTMLElement.connectedCallback
> (tobago-sheet.ts:248:12){color}
> {color:#ff} at HTMLDocument. (tobago-sheet.ts:970:27){color}
> {color:#ff} at tobago-all.ts:65:12{color}
> {color:#ff} at tobago.js:1:62{color}
> {color:#ff} at tobago.js:1:66{color}
>
> {color:#ff}!error.PNG|height=250,width=600!{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2272) Support for delay attribute in f:ajax
Bernd Bohmann created TOBAGO-2272: - Summary: Support for delay attribute in f:ajax Key: TOBAGO-2272 URL: https://issues.apache.org/jira/browse/TOBAGO-2272 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 6.1.0, 5.9.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2263) f:ajax should stop event propagation
Bernd Bohmann created TOBAGO-2263: - Summary: f:ajax should stop event propagation Key: TOBAGO-2263 URL: https://issues.apache.org/jira/browse/TOBAGO-2263 Project: MyFaces Tobago Issue Type: Bug Components: JavaScript Affects Versions: 6.0.0, 5.8.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Using a button inside a sheet is causing changing the selection because the click event is captured by the button ajax handler and the row sheet selection handler. Ajax calls should call _stopPropagation()_ on the event. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2239) Add custom event support for sheet row selection
[ https://issues.apache.org/jira/browse/TOBAGO-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2239. --- Resolution: Fixed > Add custom event support for sheet row selection > > > Key: TOBAGO-2239 > URL: https://issues.apache.org/jira/browse/TOBAGO-2239 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Affects Versions: 5.8.0 >Reporter: Carsten Dimmek >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.0, 6.1.0 > > > It might be better to add support for a Custom Selection Event. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2257) Support for noSelectionOptionAttribute of selectItem
[ https://issues.apache.org/jira/browse/TOBAGO-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2257. --- Resolution: Fixed > Support for noSelectionOptionAttribute of selectItem > > > Key: TOBAGO-2257 > URL: https://issues.apache.org/jira/browse/TOBAGO-2257 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.7.2 >Reporter: Carsten Dimmek >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.0, 6.1.0 > > > Compare to noSelectionOption from f:selectItem -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2256) Missing itemLabel on noSelectionOption throws NullPointerException
[
https://issues.apache.org/jira/browse/TOBAGO-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2256.
---
Resolution: Fixed
> Missing itemLabel on noSelectionOption throws NullPointerException
> --
>
> Key: TOBAGO-2256
> URL: https://issues.apache.org/jira/browse/TOBAGO-2256
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.7.2
>Reporter: Carsten Dimmek
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 5.9.0, 6.1.0
>
>
> {code:java}
>
>
> {code}
> I haven't tested any other components yet, but tc:selectOneList with a
> noSelectionOption
> throws a NullPointerException
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2259) Support for f:ajax resetValues=true
[ https://issues.apache.org/jira/browse/TOBAGO-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2259. --- Resolution: Fixed > Support for f:ajax resetValues=true > --- > > Key: TOBAGO-2259 > URL: https://issues.apache.org/jira/browse/TOBAGO-2259 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.8.0, 6.0.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.9.0, 6.1.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2259) Support for f:ajax resetValues=true
Bernd Bohmann created TOBAGO-2259: - Summary: Support for f:ajax resetValues=true Key: TOBAGO-2259 URL: https://issues.apache.org/jira/browse/TOBAGO-2259 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 6.0.0, 5.8.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2258) SelectItemGroup support for Select(One|Many)List
[ https://issues.apache.org/jira/browse/TOBAGO-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2258. --- Resolution: Fixed > SelectItemGroup support for Select(One|Many)List > > > Key: TOBAGO-2258 > URL: https://issues.apache.org/jira/browse/TOBAGO-2258 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 5.8.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.8.1, 6.0.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2258) SelectItemGroup support
Bernd Bohmann created TOBAGO-2258: - Summary: SelectItemGroup support Key: TOBAGO-2258 URL: https://issues.apache.org/jira/browse/TOBAGO-2258 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 5.8.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2254) Selector All Checkbox is not synchronized with selector Checkbox in each row after ajax request
Bernd Bohmann created TOBAGO-2254: - Summary: Selector All Checkbox is not synchronized with selector Checkbox in each row after ajax request Key: TOBAGO-2254 URL: https://issues.apache.org/jira/browse/TOBAGO-2254 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 6.0.0-beta-1, 5.7.2 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2253) Npm build is not working under windows
Bernd Bohmann created TOBAGO-2253: - Summary: Npm build is not working under windows Key: TOBAGO-2253 URL: https://issues.apache.org/jira/browse/TOBAGO-2253 Project: MyFaces Tobago Issue Type: Bug Components: JavaScript Affects Versions: 6.0.0-beta-1, 5.7.2 Environment: Windows Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2244) Possible NullpointerException in HtmlRendererUtils.writeDataAttributes with SegmentLayout and composite components
Bernd Bohmann created TOBAGO-2244:
-
Summary: Possible NullpointerException in
HtmlRendererUtils.writeDataAttributes with SegmentLayout and composite
components
Key: TOBAGO-2244
URL: https://issues.apache.org/jira/browse/TOBAGO-2244
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 5.7.2
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
{code}
java.lang.NullPointerException: Cannot invoke "Object.toString()" because the
return value of "javax.el.ValueExpression.getValue(javax.el.ELContext)" is null
at
org.apache.myfaces.tobago.internal.util.HtmlRendererUtils.writeDataAttributes(HtmlRendererUtils.java:169)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.InRenderer.encodeBeginField(InRenderer.java:111)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.InRenderer.encodeBeginField(InRenderer.java:47)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.DecorationPositionRendererBase.encodeBeginMessageField(DecorationPositionRendererBase.java:130)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.LabelLayoutRendererBase.encodeBeginInternal(LabelLayoutRendererBase.java:67)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.DecorationPositionRendererBase.encodeBeginInternal(DecorationPositionRendererBase.java:60)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.InRenderer.encodeBeginInternal(InRenderer.java:64)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.InRenderer.encodeBeginInternal(InRenderer.java:47)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeBegin(RendererBase.java:87)
~[tobago-core-5.7.2.jar:5.7.2]
at
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:597)
~[myfaces-api-2.3.9.jar:2.3.9]
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:527)
~[myfaces-api-2.3.9.jar:2.3.9]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.SegmentLayoutRenderer.encodeDiv(SegmentLayoutRenderer.java:115)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.SegmentLayoutRenderer.encodeChild(SegmentLayoutRenderer.java:104)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.SegmentLayoutRenderer.encodeChildrenInternal(SegmentLayoutRenderer.java:78)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.SegmentLayoutRenderer.encodeChildrenInternal(SegmentLayoutRenderer.java:42)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeChildren(RendererBase.java:96)
~[tobago-core-5.7.2.jar:5.7.2]
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:644)
~[myfaces-api-2.3.9.jar:2.3.9]
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:542)
~[myfaces-api-2.3.9.jar:2.3.9]
at javax.faces.render.Renderer.encodeChildren(Renderer.java:95)
~[myfaces-api-2.3.9.jar:2.3.9]
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeChildrenInternal(RendererBase.java:100)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeChildren(RendererBase.java:96)
~[tobago-core-5.7.2.jar:5.7.2]
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:644)
~[myfaces-api-2.3.9.jar:2.3.9]
at
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:542)
~[myfaces-api-2.3.9.jar:2.3.9]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.TabGroupRenderer.encodeContent(TabGroupRenderer.java:345)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.TabGroupRenderer.encodeEndInternal(TabGroupRenderer.java:168)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.internal.renderkit.renderer.TabGroupRenderer.encodeEndInternal(TabGroupRenderer.java:68)
~[tobago-core-5.7.2.jar:5.7.2]
at
org.apache.myfaces.tobago.renderkit.RendererBase.encodeEnd(RendererBase.java:105)
~[tobago-core-5.7.2.jar:5.7.2]
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:675)
~[myfaces-api-2.3.9.jar:2.3.9]
at
[jira] [Created] (TOBAGO-2233) Broken layout for Select(One|Many)List with long option labels
Bernd Bohmann created TOBAGO-2233: - Summary: Broken layout for Select(One|Many)List with long option labels Key: TOBAGO-2233 URL: https://issues.apache.org/jira/browse/TOBAGO-2233 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 5.7.1 Reporter: Bernd Bohmann Long option label values are causing broken layout in Select(One|Many)List components -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2219) Custom component inside a dropdown menu is not displayed correctly
[
https://issues.apache.org/jira/browse/TOBAGO-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2219.
---
Resolution: Fixed
> Custom component inside a dropdown menu is not displayed correctly
> --
>
> Key: TOBAGO-2219
> URL: https://issues.apache.org/jira/browse/TOBAGO-2219
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.7.0
>Reporter: Henning Nöth
>Assignee: Bernd Bohmann
>Priority: Minor
> Fix For: 5.8.0
>
>
> In the following example a custom component is inserted into a dropdown menu.
> The result is not a sub menu but a panel with a second top level dropdown
> menu.
> The dummy custom component:
> {code:xml}
> PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
> http://xmlns.jcp.org/jsf/composite;
> xmlns:tc="http://myfaces.apache.org/tobago/component;>
>
>
>
>
>
>
>
>
>
>
> {code}
> Dropdown menu with dummy custom component inside:
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2217) Support for ajax onchange in Select(One|Many)List
[
https://issues.apache.org/jira/browse/TOBAGO-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2217.
---
Resolution: Fixed
> Support for ajax onchange in Select(One|Many)List
> -
>
> Key: TOBAGO-2217
> URL: https://issues.apache.org/jira/browse/TOBAGO-2217
> Project: MyFaces Tobago
> Issue Type: Bug
>Affects Versions: 5.7.0
>Reporter: Bernd Bohmann
>Assignee: Bernd Bohmann
>Priority: Minor
> Fix For: 5.8.0
>
>
> The following example doesn't work!
> {code:xml}
>
> itemLabel="#{mountain.label}"
> itemValue="#{mountain.value}"/>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2217) Support for ajax onchange in Select(One|Many)List
Bernd Bohmann created TOBAGO-2217: - Summary: Support for ajax onchange in Select(One|Many)List Key: TOBAGO-2217 URL: https://issues.apache.org/jira/browse/TOBAGO-2217 Project: MyFaces Tobago Issue Type: Bug Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2213) Filtering in SelectOne|ManyList should use itemLabel instead of itemValue
[ https://issues.apache.org/jira/browse/TOBAGO-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2213. --- Resolution: Fixed > Filtering in SelectOne|ManyList should use itemLabel instead of itemValue > - > > Key: TOBAGO-2213 > URL: https://issues.apache.org/jira/browse/TOBAGO-2213 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.6.1 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2214) Avoid no overlay warning for faces hidden fields
[
https://issues.apache.org/jira/browse/TOBAGO-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-2214.
---
Resolution: Fixed
> Avoid no overlay warning for faces hidden fields
>
>
> Key: TOBAGO-2214
> URL: https://issues.apache.org/jira/browse/TOBAGO-2214
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.6.1
>Reporter: Bernd Bohmann
>Assignee: Bernd Bohmann
>Priority: Trivial
> Fix For: 5.7.0
>
>
> {code:java}
> Didn't found overlay for id j_id__v_0:javax.faces.ViewState:1
> Didn't found overlay for id j_id__v_0:javax.faces.ClientWindow:1{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2214) Avoid no overlay warning for faces hidden fields
Bernd Bohmann created TOBAGO-2214:
-
Summary: Avoid no overlay warning for faces hidden fields
Key: TOBAGO-2214
URL: https://issues.apache.org/jira/browse/TOBAGO-2214
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 5.6.1
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
{code:java}
Didn't found overlay for id j_id__v_0:javax.faces.ViewState:1
Didn't found overlay for id j_id__v_0:javax.faces.ClientWindow:1{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TOBAGO-2213) Filtering in SelectOne|ManyList should use itemLabel instead of itemValue
Bernd Bohmann created TOBAGO-2213: - Summary: Filtering in SelectOne|ManyList should use itemLabel instead of itemValue Key: TOBAGO-2213 URL: https://issues.apache.org/jira/browse/TOBAGO-2213 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 5.6.1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2212) selectOneList should show itemLabel for selected Value
[ https://issues.apache.org/jira/browse/TOBAGO-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2212. --- Resolution: Fixed > selectOneList should show itemLabel for selected Value > > > Key: TOBAGO-2212 > URL: https://issues.apache.org/jira/browse/TOBAGO-2212 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.6.1 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.7.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2212) selectOneList should show itemLabel for selected Value
Bernd Bohmann created TOBAGO-2212: - Summary: selectOneList should show itemLabel for selected Value Key: TOBAGO-2212 URL: https://issues.apache.org/jira/browse/TOBAGO-2212 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 5.6.1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2209) Wrong java.lang.Number declaration in StyleTagDeclaration in flexGrow and flexShrink attribute
[ https://issues.apache.org/jira/browse/TOBAGO-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2209. --- Resolution: Fixed > Wrong java.lang.Number declaration in StyleTagDeclaration in flexGrow and > flexShrink attribute > -- > > Key: TOBAGO-2209 > URL: https://issues.apache.org/jira/browse/TOBAGO-2209 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.6.0 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 5.7.0 > > > is causing > javax.el.ELException: Cannot convert [0] of type [class java.lang.String] to > [class java.lang.Number] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TOBAGO-2209) Wrong java.lang.Number declaration in StyleTagDeclaration
Bernd Bohmann created TOBAGO-2209: - Summary: Wrong java.lang.Number declaration in StyleTagDeclaration Key: TOBAGO-2209 URL: https://issues.apache.org/jira/browse/TOBAGO-2209 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 5.6.0 Reporter: Bernd Bohmann Assignee: Bernd Bohmann is causing javax.el.ELException: Cannot convert [0] of type [class java.lang.String] to [class java.lang.Number] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4560) Faces Issue #1791 SelectItems rendering
[
https://issues.apache.org/jira/browse/MYFACES-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688597#comment-17688597
]
Bernd Bohmann edited comment on MYFACES-4560 at 2/14/23 7:55 PM:
-
I have a simple test to verify the wrong behavior
{code:java}
@Test
public void testSelectListAsValue()
{
List values = new ArrayList<>();
values.add(new SelectItem("#1", "D1"));
values.add(new SelectItem("#2", "D2"));
values.add(new SelectItem("#3", "D3"));
UISelectItems selectItems = new UISelectItems();
selectItems.setValue(values);
selectItems.getAttributes().put("var", "item");
ValueExpression itemValue = new MockValueExpression("#{item.label}",
Object.class);
ValueExpression itemLabel = new MockValueExpression("#{item.value}",
Object.class);
ValueExpression itemDescription = new MockValueExpression("#{item.value}",
Object.class);
selectItems.setValueExpression("itemValue", itemValue);
selectItems.setValueExpression("itemLabel", itemLabel);
selectItems.setValueExpression("itemDescription", itemLabel);
UISelectOne selectOne = new UISelectOne();
selectOne.getChildren().add(selectItems);
SelectItemsIterator iter = new SelectItemsIterator(selectOne, facesContext);
List options = new ArrayList<>();
List labels = new ArrayList<>();
List descriptions = new ArrayList<>();
while (iter.hasNext())
{
SelectItem next = iter.next();
options.add((String) next.getValue());
labels.add(next.getLabel());
descriptions.add(next.getDescription());
}
Assertions.assertAll(
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getLabel).collect(Collectors.toList()),
options),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
labels),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
descriptions));
}{code}
was (Author: bommel):
I have a simple test to verify the wrong behavior
{code:java}
@Test
public void testSelectListAsValue()
{
List values = new ArrayList<>();
values.add(new SelectItem("#1", "D1"));
values.add(new SelectItem("#2", "D2"));
values.add(new SelectItem("#3", "D3"));
UISelectItems selectItems = new UISelectItems();
selectItems.setValue(values);
selectItems.getAttributes().put("var", "item");
ValueExpression itemValue = new MockValueExpression("#{item.label}",
Object.class);
ValueExpression itemLabel = new MockValueExpression("#{item.key}",
Object.class);
ValueExpression itemDescription = new MockValueExpression("#{item.key}",
Object.class);
selectItems.setValueExpression("itemValue", itemValue);
selectItems.setValueExpression("itemLabel", itemLabel);
selectItems.setValueExpression("itemDescription", itemLabel);
UISelectOne selectOne = new UISelectOne();
selectOne.getChildren().add(selectItems);
SelectItemsIterator iter = new SelectItemsIterator(selectOne, facesContext);
List options = new ArrayList<>();
List labels = new ArrayList<>();
List descriptions = new ArrayList<>();
while (iter.hasNext())
{
SelectItem next = iter.next();
options.add((String) next.getValue());
labels.add(next.getLabel());
descriptions.add(next.getDescription());
}
Assertions.assertAll(
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getLabel).collect(Collectors.toList()),
options),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
labels),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
descriptions));
}{code}
> Faces Issue #1791 SelectItems rendering
> ---
>
> Key: MYFACES-4560
> URL: https://issues.apache.org/jira/browse/MYFACES-4560
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 2.3-next-M7, 3.0.2, 4.0.0-RC4
>Reporter: Melloware
>Priority: Major
>
> See; [https://github.com/jakartaee/faces/issues/1791]
>
> The component should render the itemLabel as instructed by the provided EL,
> even if the backed data type is SelectItem. The default rendering should only
> be done when the attribute is missing.
> Example:
> {code:java}
>
>
> itemValue="#{i.value}" itemLabel="#{i.value} - #{i.label}" />
>
>
> itemValue="#{i.key}" itemLabel="#{i.key} - #{i.value}" />
>
>
>
>
>
>
>
> {code}
> The issue is `id="test1"` the user is
[jira] [Commented] (MYFACES-4560) Faces Issue #1791 SelectItems rendering
[
https://issues.apache.org/jira/browse/MYFACES-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688597#comment-17688597
]
Bernd Bohmann commented on MYFACES-4560:
I have a simple test to verify the wrong behavior
{code:java}
@Test
public void testSelectListAsValue()
{
List values = new ArrayList<>();
values.add(new SelectItem("#1", "D1"));
values.add(new SelectItem("#2", "D2"));
values.add(new SelectItem("#3", "D3"));
UISelectItems selectItems = new UISelectItems();
selectItems.setValue(values);
selectItems.getAttributes().put("var", "item");
ValueExpression itemValue = new MockValueExpression("#{item.label}",
Object.class);
ValueExpression itemLabel = new MockValueExpression("#{item.key}",
Object.class);
ValueExpression itemDescription = new MockValueExpression("#{item.key}",
Object.class);
selectItems.setValueExpression("itemValue", itemValue);
selectItems.setValueExpression("itemLabel", itemLabel);
selectItems.setValueExpression("itemDescription", itemLabel);
UISelectOne selectOne = new UISelectOne();
selectOne.getChildren().add(selectItems);
SelectItemsIterator iter = new SelectItemsIterator(selectOne, facesContext);
List options = new ArrayList<>();
List labels = new ArrayList<>();
List descriptions = new ArrayList<>();
while (iter.hasNext())
{
SelectItem next = iter.next();
options.add((String) next.getValue());
labels.add(next.getLabel());
descriptions.add(next.getDescription());
}
Assertions.assertAll(
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getLabel).collect(Collectors.toList()),
options),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
labels),
() ->
Assertions.assertEquals(values.stream().map(SelectItem::getValue).collect(Collectors.toList()),
descriptions));
}{code}
> Faces Issue #1791 SelectItems rendering
> ---
>
> Key: MYFACES-4560
> URL: https://issues.apache.org/jira/browse/MYFACES-4560
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 2.3-next-M7, 3.0.2, 4.0.0-RC4
>Reporter: Melloware
>Priority: Major
>
> See; [https://github.com/jakartaee/faces/issues/1791]
>
> The component should render the itemLabel as instructed by the provided EL,
> even if the backed data type is SelectItem. The default rendering should only
> be done when the attribute is missing.
> Example:
> {code:java}
>
>
> itemValue="#{i.value}" itemLabel="#{i.value} - #{i.label}" />
>
>
> itemValue="#{i.key}" itemLabel="#{i.key} - #{i.value}" />
>
>
>
>
>
>
>
> {code}
> The issue is `id="test1"` the user is expecting it to render
> `itemLabel="#\{i.key} - #\{i.value}"` but it is ignored and just the
> underlying Java SelectItem value is rendered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4560) Faces Issue #1791 SelectItems rendering
[
https://issues.apache.org/jira/browse/MYFACES-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688582#comment-17688582
]
Bernd Bohmann commented on MYFACES-4560:
I think the description is not correct itemLabel for id="test1" is
{code:java}
itemLabel="#{i.value} - #{i.label}"
{code}
> Faces Issue #1791 SelectItems rendering
> ---
>
> Key: MYFACES-4560
> URL: https://issues.apache.org/jira/browse/MYFACES-4560
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 2.3-next-M7, 3.0.2, 4.0.0-RC4
>Reporter: Melloware
>Priority: Major
>
> See; [https://github.com/jakartaee/faces/issues/1791]
>
> The component should render the itemLabel as instructed by the provided EL,
> even if the backed data type is SelectItem. The default rendering should only
> be done when the attribute is missing.
> Example:
> {code:java}
>
>
> itemValue="#{i.value}" itemLabel="#{i.value} - #{i.label}" />
>
>
> itemValue="#{i.key}" itemLabel="#{i.key} - #{i.value}" />
>
>
>
>
>
>
>
> {code}
> The issue is `id="test1"` the user is expecting it to render
> `itemLabel="#\{i.key} - #\{i.value}"` but it is ignored and just the
> underlying Java SelectItem value is rendered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4560) Faces Issue #1791 SelectItems rendering
[
https://issues.apache.org/jira/browse/MYFACES-4560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17688554#comment-17688554
]
Bernd Bohmann commented on MYFACES-4560:
Is this a myfaces problem?
> Faces Issue #1791 SelectItems rendering
> ---
>
> Key: MYFACES-4560
> URL: https://issues.apache.org/jira/browse/MYFACES-4560
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.3.10, 2.3-next-M7, 3.0.2, 4.0.0-RC4
>Reporter: Melloware
>Priority: Major
>
> See; [https://github.com/jakartaee/faces/issues/1791]
>
> The component should render the itemLabel as instructed by the provided EL,
> even if the backed data type is SelectItem. The default rendering should only
> be done when the attribute is missing.
> Example:
> {code:java}
>
>
> itemValue="#{i.value}" itemLabel="#{i.value} - #{i.label}" />
>
>
> itemValue="#{i.key}" itemLabel="#{i.key} - #{i.value}" />
>
>
>
>
>
>
>
> {code}
> The issue is `id="test1"` the user is expecting it to render
> `itemLabel="#\{i.key} - #\{i.value}"` but it is ignored and just the
> underlying Java SelectItem value is rendered.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2051) Allow HTML content in FacesMessage
[ https://issues.apache.org/jira/browse/TOBAGO-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17656643#comment-17656643 ] Bernd Bohmann commented on TOBAGO-2051: --- [~crusadah] without usecase and a working example it's hard to implement because it can cause security issues > Allow HTML content in FacesMessage > -- > > Key: TOBAGO-2051 > URL: https://issues.apache.org/jira/browse/TOBAGO-2051 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Reporter: Carsten Dimmek >Priority: Major > Fix For: 5.x > > > At the moment any html content in the faces message is escaped. It would be > nice to have the possibility to add html content to the message that gets > rendered -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TOBAGO-2185) tc:dataAttribute doesn't work with tc:badge
[ https://issues.apache.org/jira/browse/TOBAGO-2185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-2185. --- Resolution: Fixed > tc:dataAttribute doesn't work with tc:badge > > > Key: TOBAGO-2185 > URL: https://issues.apache.org/jira/browse/TOBAGO-2185 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 5.4.0 >Reporter: Carsten Dimmek >Assignee: Bernd Bohmann >Priority: Major > Fix For: 5.4.1 > > > tc:dataAttribute is not rendererd when used with tc:badge -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4392) Update to quarkus 1.13.0.Final
Bernd Bohmann created MYFACES-4392: -- Summary: Update to quarkus 1.13.0.Final Key: MYFACES-4392 URL: https://issues.apache.org/jira/browse/MYFACES-4392 Project: MyFaces Core Issue Type: Task Affects Versions: 2.3-next-M5 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TOBAGO-2070) Broken links to sources and examples
[ https://issues.apache.org/jira/browse/TOBAGO-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17303212#comment-17303212 ] Bernd Bohmann commented on TOBAGO-2070: --- Links should be fixed/removed in repo, now. > Broken links to sources and examples > > > Key: TOBAGO-2070 > URL: https://issues.apache.org/jira/browse/TOBAGO-2070 > Project: MyFaces Tobago > Issue Type: Bug >Reporter: Sebb >Assignee: Bernd Bohmann >Priority: Major > > The download page for tobago [1] has several broken links: > http://www.apache.org/dyn/closer.lua/myfaces/binaries/myfaces-tobago-4.5.3-source-release.zip > This should be > http://www.apache.org/dyn/closer.lua/myfaces/source/myfaces-tobago-4.5.3-source-release.zip > Similarly, 'binaries' needs to be changed to 'source' in: > http://www.apache.org/dyn/closer.lua/myfaces/binaries/myfaces-tobago-3.1.1-source-release.zip > and > http://www.apache.org/dyn/closer.lua/myfaces/binaries/myfaces-tobago-2.4.4-source-release.zip > Several of the sig and has links are also wrong: > https://www.apache.org/source-release/myfaces/binaries/myfaces-tobago-4.5.3-source-release.zip.sha256 > https://www.apache.org/source-release/myfaces/binaries/myfaces-tobago-4.5.3-source-release.zip.asc > https://www.apache.org/example/myfaces/binaries/myfaces-tobago-4.5.3-example.tar.gz.sha256 > https://www.apache.org/example/myfaces/binaries/myfaces-tobago-4.5.3-example.tar.gz.asc > https://www.apache.org/example/myfaces/binaries/myfaces-tobago-4.5.3-example.zip.sha256 > https://www.apache.org/example/myfaces/binaries/myfaces-tobago-4.5.3-example.zip.asc > These need to be replaced with > https://downloads.apache.org/myfaces/source/myfaces-tobago-4.5.3-source-release.zip.sha256 > https://downloads.apache.org/myfaces/source/myfaces-tobago-4.5.3-source-release.zip.asc > https://downloads.apache.org/myfaces/binaries/myfaces-tobago-4.5.3-example.tar.gz.sha256 > https://downloads.apache.org/myfaces/binaries/myfaces-tobago-4.5.3-example.tar.gz.asc > https://downloads.apache.org/myfaces/binaries/myfaces-tobago-4.5.3-example.zip.sha256 > https://downloads.apache.org/myfaces/binaries/myfaces-tobago-4.5.3-example.zip.asc > Similarly for versions 3.1.1 and 2.4.4. > [1] http://tobago-vm.apache.org/download.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MYFACES-4377) Disable the parsing of external general entities and external parameter entities in XML parsing code
Bernd Bohmann created MYFACES-4377: -- Summary: Disable the parsing of external general entities and external parameter entities in XML parsing code Key: MYFACES-4377 URL: https://issues.apache.org/jira/browse/MYFACES-4377 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 4.0.0-RC1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MYFACES-4376) Update Cryptographic algorithm in StateUtils to a stronger version
Bernd Bohmann created MYFACES-4376: -- Summary: Update Cryptographic algorithm in StateUtils to a stronger version Key: MYFACES-4376 URL: https://issues.apache.org/jira/browse/MYFACES-4376 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 4.0.0-RC1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MYFACES-4266) Ajax update fails due to invalid characters in response XML (DoS)
[
https://issues.apache.org/jira/browse/MYFACES-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698645#comment-16698645
]
Bernd Bohmann commented on MYFACES-4266:
Did someone test the performance impact of this new String?
> Ajax update fails due to invalid characters in response XML (DoS)
> -
>
> Key: MYFACES-4266
> URL: https://issues.apache.org/jira/browse/MYFACES-4266
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: jetty 9.4.14.v20181114
> JDK 10
>Reporter: cnsgithub
>Priority: Major
> Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.3, 3.0.0-SNAPSHOT
>
>
> I noticed that the {{}} update fails when the updated form contains
> unicode characters, which are not allowed in the [XML 1.0
> spec|https://www.w3.org/TR/REC-xml/#charsets].
> h2. Expected Behaviour
> If the update response contains characters that are not allowed in XML, they
> should be filtered by MyFaces before writing the response.
> h2. Actual Behaviour
> Some illegal XML characters are not filtered and therefore the browser fails
> to parse the response.
> h2. Steps to reproduce
> I created a small github project to reproduce this behaviour:
> [https://github.com/cnsgithub/mojarra-ajax/tree/myfaces] (branch myfaces)
> To reproduce:
> - {{git clone [https://github.com/cnsgithub/mojarra-ajax]}}
> - {{git checkout myfaces}}
> - run {{mvn clean package jetty:run}}
> - after the server has started, open [http://localhost:8080/index.xhtml]
> - Click the button, the error should occur
> The issue also occurs with user supplied inputs:
> - open [http://localhost:8080/input.xhtml]
> - Paste the characters from the {{illegal-xml-chars.txt}} file into the
> input field
> - Click the button
> This issue should be addressed with high priority since it is security
> related (might be exploited for Denial of Service).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MYFACES-4266) Ajax update fails due to invalid characters in response XML (DoS)
[
https://issues.apache.org/jira/browse/MYFACES-4266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698646#comment-16698646
]
Bernd Bohmann commented on MYFACES-4266:
This is a really critical part.
> Ajax update fails due to invalid characters in response XML (DoS)
> -
>
> Key: MYFACES-4266
> URL: https://issues.apache.org/jira/browse/MYFACES-4266
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: jetty 9.4.14.v20181114
> JDK 10
>Reporter: cnsgithub
>Priority: Major
> Fix For: 2.0.25, 2.1.19, 2.2.13, 2.3.3, 3.0.0-SNAPSHOT
>
>
> I noticed that the {{}} update fails when the updated form contains
> unicode characters, which are not allowed in the [XML 1.0
> spec|https://www.w3.org/TR/REC-xml/#charsets].
> h2. Expected Behaviour
> If the update response contains characters that are not allowed in XML, they
> should be filtered by MyFaces before writing the response.
> h2. Actual Behaviour
> Some illegal XML characters are not filtered and therefore the browser fails
> to parse the response.
> h2. Steps to reproduce
> I created a small github project to reproduce this behaviour:
> [https://github.com/cnsgithub/mojarra-ajax/tree/myfaces] (branch myfaces)
> To reproduce:
> - {{git clone [https://github.com/cnsgithub/mojarra-ajax]}}
> - {{git checkout myfaces}}
> - run {{mvn clean package jetty:run}}
> - after the server has started, open [http://localhost:8080/index.xhtml]
> - Click the button, the error should occur
> The issue also occurs with user supplied inputs:
> - open [http://localhost:8080/input.xhtml]
> - Paste the characters from the {{illegal-xml-chars.txt}} file into the
> input field
> - Click the button
> This issue should be addressed with high priority since it is security
> related (might be exploited for Denial of Service).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOBAGO-1878) Duplicated IDs for tc:tree inside tc:flexLayout with mojarra
[ https://issues.apache.org/jira/browse/TOBAGO-1878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406283#comment-16406283 ] Bernd Bohmann commented on TOBAGO-1878: --- Please add the full exception > Duplicated IDs for tc:tree inside tc:flexLayout with mojarra > > > Key: TOBAGO-1878 > URL: https://issues.apache.org/jira/browse/TOBAGO-1878 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core >Reporter: Henning Noeth >Priority: Major > Fix For: 4.2.1 > > > Tested with Mojarra 2.0, 2.1, 2.3 > The bug appears if columns attribute have the value '1fr'. > The duplicated IDs are from
[jira] [Commented] (TOBAGO-1870) The file attribute of tc:style is not rendered after a submit.
[
https://issues.apache.org/jira/browse/TOBAGO-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406018#comment-16406018
]
Bernd Bohmann commented on TOBAGO-1870:
---
It looks like webspere v8.5.5.9 is still using this in
ApplicationImpl#publishEvent
from myfaces 2.0.2
{code:java}
UIViewRoot uiViewRoot = facesContext.getViewRoot();
if (uiViewRoot != null)
{
//Call listeners on view level
event =
_traverseListenerList(uiViewRoot.getViewListenersForEventClass(systemEventClass),
systemEventClass, source, event);
}
{code}
instead of this since myfaces 2.0.3
{code:java}
UIViewRoot uiViewRoot = facesContext.getViewRoot();
if (uiViewRoot != null)
{
//Call listeners on view level
event =
_traverseListenerListWithCopy(uiViewRoot.getViewListenersForEventClass(systemEventClass),
systemEventClass, source, event);
}
{code}
> The file attribute of tc:style is not rendered after a submit.
> --
>
> Key: TOBAGO-1870
> URL: https://issues.apache.org/jira/browse/TOBAGO-1870
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.1.0
>Reporter: Henning Noeth
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 4.2.1
>
>
> An example could be found in the v4.2.0-SNAPSHOT demo:
>
> [http://localhost:8080/content/40-test/6000-event/event.xhtml|http://localhost:8080/content/40-test/6000-event/event-1870.xhtml]
> After clicking on "reload", the link to "demo.css" file is not rendered
> inside the tag.
> The problem only occures with .
> The problem NOT occures with , but the EL
> should resolve to excactly the same string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TOBAGO-1870) The file attribute of tc:style is not rendered after a submit.
[
https://issues.apache.org/jira/browse/TOBAGO-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406003#comment-16406003
]
Bernd Bohmann edited comment on TOBAGO-1870 at 3/20/18 9:27 AM:
this is the exception
{code}
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:912)
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1053)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2213)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:561)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:591)
at
org.apache.webbeans.jsf.OwbApplication.publishEvent(OwbApplication.java:484)
at
javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335)
at
javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335)
at
org.apache.deltaspike.jsf.impl.injection.InjectionAwareApplicationWrapper.publishEvent(InjectionAwareApplicationWrapper.java:148)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:72)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:240)
at
org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1233)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:782)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:481)
at
com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
{code}
was (Author: bommel):
this is the exception
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:912)
at java.util.ArrayList$Itr.next(ArrayList.java:862)
at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1053)
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2213)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:561)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:591)
at
org.apache.webbeans.jsf.OwbApplication.publishEvent(OwbApplication.java:484)
at
javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335)
at
javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335)
at
org.apache.deltaspike.jsf.impl.injection.InjectionAwareApplicationWrapper.publishEvent(InjectionAwareApplicationWrapper.java:148)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:72)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:240)
at
org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1233)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:782)
at
com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:481)
at
com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at
com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
> The file attribute of tc:style is not rendered after a submit.
> --
>
> Key: TOBAGO-1870
> URL: https://issues.apache.org/jira/browse/TOBAGO-1870
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.1.0
>Reporter: Henning Noeth
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 4.2.1
>
>
> An example could be found in the v4.2.0-SNAPSHOT demo:
>
> [http://localhost:8080/content/40-test/6000-event/event.xhtml|http://localhost:8080/content/40-test/6000-event/event-1870.xhtml]
> After clicking on "reload", the link to "demo.css" file is not rendered
> inside the tag.
> The problem only occures with .
> The problem NOT occures with , but the EL
> should resolve to excactly the same string.
--
This message was sent by Atlassian JIRA
[jira] [Commented] (TOBAGO-1870) The file attribute of tc:style is not rendered after a submit.
[ https://issues.apache.org/jira/browse/TOBAGO-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406003#comment-16406003 ] Bernd Bohmann commented on TOBAGO-1870: --- this is the exception at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:912) at java.util.ArrayList$Itr.next(ArrayList.java:862) at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1053) at org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2213) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:561) at org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:591) at org.apache.webbeans.jsf.OwbApplication.publishEvent(OwbApplication.java:484) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335) at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:335) at org.apache.deltaspike.jsf.impl.injection.InjectionAwareApplicationWrapper.publishEvent(InjectionAwareApplicationWrapper.java:148) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:72) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:240) at org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.render(DeltaSpikeLifecycleWrapper.java:111) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1233) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:782) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:481) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136) at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97) > The file attribute of tc:style is not rendered after a submit. > -- > > Key: TOBAGO-1870 > URL: https://issues.apache.org/jira/browse/TOBAGO-1870 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core >Affects Versions: 4.1.0 >Reporter: Henning Noeth >Assignee: Bernd Bohmann >Priority: Major > Fix For: 4.2.1 > > > An example could be found in the v4.2.0-SNAPSHOT demo: > > [http://localhost:8080/content/40-test/6000-event/event.xhtml|http://localhost:8080/content/40-test/6000-event/event-1870.xhtml] > After clicking on "reload", the link to "demo.css" file is not rendered > inside the tag. > The problem only occures with . > The problem NOT occures with , but the EL > should resolve to excactly the same string. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOBAGO-1589) Sorting in sheet work not with Mojarra
[ https://issues.apache.org/jira/browse/TOBAGO-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-1589. --- Resolution: Fixed Should work in mojarra 2.1-2.3. In mojarra 2.0 is still some bug. > Sorting in sheet work not with Mojarra > -- > > Key: TOBAGO-1589 > URL: https://issues.apache.org/jira/browse/TOBAGO-1589 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 2.0.9, 3.0.0-alpha-4 >Reporter: Udo Schnurpfeil >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 4.2.0 > > > There is still a problem with Mojarra 2.0. > With Mojarra 2.1 this is fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOBAGO-1589) Sorting in sheet work not with Mojarra 2.0
[ https://issues.apache.org/jira/browse/TOBAGO-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379956#comment-16379956 ] Bernd Bohmann commented on TOBAGO-1589: --- It's looks like components are not being created correctly while rendering. > Sorting in sheet work not with Mojarra 2.0 > -- > > Key: TOBAGO-1589 > URL: https://issues.apache.org/jira/browse/TOBAGO-1589 > Project: MyFaces Tobago > Issue Type: Bug > Components: Themes >Affects Versions: 2.0.9, 3.0.0-alpha-4 >Reporter: Udo Schnurpfeil >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 4.1.1 > > > There is still a problem with Mojarra 2.0. > With Mojarra 2.1 this is fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TRINIDAD-2560) nationalizations for built in buttons in trinidad tabel
[ https://issues.apache.org/jira/browse/TRINIDAD-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16169375#comment-16169375 ] Bernd Bohmann commented on TRINIDAD-2560: - Can you provide a CoreBundle_mn.xrts please use this as a base: https://github.com/apache/myfaces-trinidad/tree/master/trinidad-impl/src/main/xrts/org/apache/myfaces/trinidadinternal/renderkit/core/resource/CoreBundle.xrts you can attach the file to this issue or fork the project and submit a pull request > nationalizations for built in buttons in trinidad tabel > > > Key: TRINIDAD-2560 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2560 > Project: MyFaces Trinidad > Issue Type: Wish > Components: Components >Affects Versions: 1.2.10-core > Environment: windows 10, jdk 1.6, jsf 1.2.10, tomcat server >Reporter: RAVI PATEL G Y >Assignee: Bernd Bohmann >Priority: Minor > Attachments: M.png > > Original Estimate: 48h > Remaining Estimate: 48h > > Hello team, > when we use this Trinidad component in other languages application > EX: if we use tr:Tabel, it will give navigation buttons NEXT and PREVIOUS, > but these buttons appear in English languages, > so how to change the label of these navigation Buttons. > I have created a project in Magnolia language, but labels are appearing in > English, please see the attachment -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165285#comment-16165285
]
Bernd Bohmann commented on MYFACES-3525:
I don't agree and we should not discuss this in jira. It should be clear this
EMPTY_VALUES_AS_NULL_CLEAR_INPUT_PARAM_NAME parameter should be removed before
we are creating a new release. I'm writing code to show there is a better
alternative instead of this EMPTY_VALUES_AS_NULL_CLEAR_INPUT_PARAM_NAME
parameter. I think this clear input is dangerous.
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch,
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TRINIDAD-2560) nationalizations for built in buttons in trinidad tabel
[ https://issues.apache.org/jira/browse/TRINIDAD-2560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160887#comment-16160887 ] Bernd Bohmann commented on TRINIDAD-2560: - What is the iso code for magnolia language? If the resource file are not available for this language i assume the default is English (en). > nationalizations for built in buttons in trinidad tabel > > > Key: TRINIDAD-2560 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2560 > Project: MyFaces Trinidad > Issue Type: Wish > Components: Components >Affects Versions: 1.2.10-core > Environment: windows 10, jdk 1.6, jsf 1.2.10, tomcat server >Reporter: RAVI PATEL G Y >Priority: Critical > Attachments: M.png > > Original Estimate: 48h > Remaining Estimate: 48h > > Hello team, > when we use this Trinidad component in other languages application > EX: if we use tr:Tabel, it will give navigation buttons NEXT and PREVIOUS, > but these buttons appear in English languages, > so how to change the label of these navigation Buttons. > I have created a project in Magnolia language, but labels are appearing in > English, please see the attachment -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (MYFACES-4147) Remove CDI_MANAGED_CONVERTERS_ENABLED and CDI_MANAGED_VALIDATORS_ENABLED
[ https://issues.apache.org/jira/browse/MYFACES-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann reopened MYFACES-4147: You can not removed a released option/configuration without any notice. Please keep this option and at least print out a deprecation warning and describe the alternative. > Remove CDI_MANAGED_CONVERTERS_ENABLED and CDI_MANAGED_VALIDATORS_ENABLED > > > Key: MYFACES-4147 > URL: https://issues.apache.org/jira/browse/MYFACES-4147 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko > Fix For: 2.3.0 > > > it's supported native in JSF 2.3 via @FacesConverter(managed=true) and > @FacesValidator(managed=true) > As it's not portable either, we can just remove it instead of deprecation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4130) CDI @ManagedProperty does not work with all types
[
https://issues.apache.org/jira/browse/MYFACES-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116610#comment-16116610
]
Bernd Bohmann commented on MYFACES-4130:
ok
> CDI @ManagedProperty does not work with all types
> -
>
> Key: MYFACES-4130
> URL: https://issues.apache.org/jira/browse/MYFACES-4130
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>Assignee: Paul Nicolucci
> Attachments: MYFACES-4130.patch, MYFACES-4130-with-test.patch
>
>
> CDI Replacement for @ManagedProperty does not work with primitives,
> ParameterizedType or arrays.
> For example:
> @Inject
> @ManagedProperty("#{testBean.list}")
> private List listManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException:
> java.util.List
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.number}")
> private int numberManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException: int
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.stringArray}")
> private String[] stringArrayManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException:
> java.lang.String[]
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> I've attached a patch. If no objections by Wednesday close of business I'll
> commit it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working
[
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116611#comment-16116611
]
Bernd Bohmann commented on MYFACES-4131:
ok
> begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch, MYFACES-4131-WITH-TEST.patch
>
>
> I started to test the constraint feature of JSF 2.3 and it does
> not look to function on MyFaces.
> The changes required are for the following JSF 2.3 spec issue :
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the tag will now have begin and end
> attributes. For instance:
>
> #{x}
>
> In the above example if testList had 10 items in it each entry containing a
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
>
> #{x}
>
> We would expect the following output:
> 56789
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4131) begin and end do not look to be implemented / working
[
https://issues.apache.org/jira/browse/MYFACES-4131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116080#comment-16116080
]
Bernd Bohmann commented on MYFACES-4131:
What is the difference between offset and begin?
> begin and end do not look to be implemented / working
> --
>
> Key: MYFACES-4131
> URL: https://issues.apache.org/jira/browse/MYFACES-4131
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
> Attachments: MYFACES-4131.patch
>
>
> I started to test the constraint feature of JSF 2.3 and it does
> not look to function on MyFaces.
> The changes required are for the following JSF 2.3 spec issue :
> https://github.com/javaee/javaserverfaces-spec/issues/1102
> According to the spec the tag will now have begin and end
> attributes. For instance:
>
> #{x}
>
> In the above example if testList had 10 items in it each entry containing a
> number 0-9 then we would expect the following output:
> 0123456789
> If we changed it to:
>
> #{x}
>
> We would expect the following output:
> 56789
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-4130) CDI @ManagedProperty does not work with all types
[
https://issues.apache.org/jira/browse/MYFACES-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16108687#comment-16108687
]
Bernd Bohmann commented on MYFACES-4130:
A unit test would be nice as well. But the patch looks good :-)
> CDI @ManagedProperty does not work with all types
> -
>
> Key: MYFACES-4130
> URL: https://issues.apache.org/jira/browse/MYFACES-4130
> Project: MyFaces Core
> Issue Type: Bug
> Components: JSR-372
>Affects Versions: 2.3.0-beta
>Reporter: Paul Nicolucci
>Assignee: Paul Nicolucci
> Attachments: MYFACES-4130.patch
>
>
> CDI Replacement for @ManagedProperty does not work with primitives,
> ParameterizedType or arrays.
> For example:
> @Inject
> @ManagedProperty("#{testBean.list}")
> private List listManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException:
> java.util.List
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.number}")
> private int numberManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException: int
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> @Inject
> @ManagedProperty("#{testBean.stringArray}")
> private String[] stringArrayManagedProperty;
> javax.faces.FacesException: java.lang.ClassNotFoundException:
> java.lang.String[]
> at
> org.apache.myfaces.shared.util.ClassUtils.simpleClassForName(ClassUtils.java:218)
> at
> org.apache.myfaces.cdi.bean.DynamicManagedPropertyProducer.(DynamicManagedPropertyProducer.java:58)
> at
> org.apache.myfaces.cdi.bean.ManagedPropertyExtension.afterBean(ManagedPropertyExtension.java:62)
> I've attached a patch. If no objections by Wednesday close of business I'll
> commit it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (MYFACES-4128) pushComponentToEL should be called before isVisitable is called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat
[ https://issues.apache.org/jira/browse/MYFACES-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved MYFACES-4128. Resolution: Fixed Fix Version/s: 2.3.0 2.2.13 2.1.19 2.0.25 2.0.25-SNAPSHOT > pushComponentToEL should be called before isVisitable is called in visitTree > of UIData, UIForm, UINamingContainer and UIRepeat > -- > > Key: MYFACES-4128 > URL: https://issues.apache.org/jira/browse/MYFACES-4128 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.0-beta >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.0.25-SNAPSHOT, 2.0.25, 2.1.19, 2.2.13, 2.3.0 > > Attachments: MYFACES-4128.patch > > > The implementation of UIComponent.visitTree is correct but pushComponentToEL > in UIData, UIForm, UINamingContainer and UIRepeat is called too late. > 'component' expressions will fail in these components. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-4128) pushComponentToEL should be called before isVisitable is called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat
[ https://issues.apache.org/jira/browse/MYFACES-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16107315#comment-16107315 ] Bernd Bohmann commented on MYFACES-4128: patch applied to all branches >= 2.0.x and trunk > pushComponentToEL should be called before isVisitable is called in visitTree > of UIData, UIForm, UINamingContainer and UIRepeat > -- > > Key: MYFACES-4128 > URL: https://issues.apache.org/jira/browse/MYFACES-4128 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.0.24, 2.1.18, 2.2.12, 2.3.0-beta >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Attachments: MYFACES-4128.patch > > > The implementation of UIComponent.visitTree is correct but pushComponentToEL > in UIData, UIForm, UINamingContainer and UIRepeat is called too late. > 'component' expressions will fail in these components. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106680#comment-16106680
]
Bernd Bohmann commented on MYFACES-3525:
Sorry we are not following mojarra (I didn't take a look at the mojarry code
this is not allowed for us)
The information i have is from the spec issue tracker.
We (me and matthias) raised this question several years ago. The javadoc about
setting setSubmittedValue to null only is rubbish. There are two options
1. don't set submitted value to null only call validate with the null value
or
2. reset the submitted value to the old value if it's invalid
That's all it's already triggered many years ago. But with no real answer
before 2016
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12, 2.1.18, 2.2.12, 2.3.0-beta
>Reporter: VS
>Assignee: Leonardo Uribe
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch,
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYFACES-4128) pushComponentToEL should be called before isVisitable is called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat
[ https://issues.apache.org/jira/browse/MYFACES-4128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann updated MYFACES-4128: --- Status: Patch Available (was: Open) > pushComponentToEL should be called before isVisitable is called in visitTree > of UIData, UIForm, UINamingContainer and UIRepeat > -- > > Key: MYFACES-4128 > URL: https://issues.apache.org/jira/browse/MYFACES-4128 > Project: MyFaces Core > Issue Type: Bug >Reporter: Bernd Bohmann > > The implementation of UIComponent.visitTree is correct but pushComponentToEL > in UIData, UIForm, UINamingContainer and UIRepeat is called too late. > 'component' expressions will fail in these components. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101954#comment-16101954
]
Bernd Bohmann commented on MYFACES-3525:
If you read the comment from the spec lead in
https://github.com/javaee/javaserverfaces-spec/issues/671 the submitted value
should be restored to the original submitted value if the UIInput is not valid.
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch,
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101589#comment-16101589
]
Bernd Bohmann commented on MYFACES-3525:
I will not apply exactly the patch because I should cleanup the code as well.
But the patch shows the idea behind it
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch,
> MYFACES-3525-setsubmittedValueagain.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann updated MYFACES-3525:
---
Status: Patch Available (was: Reopened)
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann reopened MYFACES-3525:
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100638#comment-16100638
]
Bernd Bohmann commented on MYFACES-3525:
Ok, I can do it but not today. I will prepare a patch for better understanding
tomorrow.
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100598#comment-16100598
]
Bernd Bohmann commented on MYFACES-3525:
I can change the behavior to the suggestion in
https://github.com/javaee/javaserverfaces-spec/issues/671
and remove the INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL_CLEAR_INPUT
workaround
any complains?
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100523#comment-16100523
]
Bernd Bohmann commented on MYFACES-3525:
The suggested fix in https://github.com/javaee/javaserverfaces-spec/issues/671
is much better. It's setting the submitted Value to the old value if it's
invalid
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MYFACES-4128) pushComponentToEL should be called before isVisitable is called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat
Bernd Bohmann created MYFACES-4128: -- Summary: pushComponentToEL should be called before isVisitable is called in visitTree of UIData, UIForm, UINamingContainer and UIRepeat Key: MYFACES-4128 URL: https://issues.apache.org/jira/browse/MYFACES-4128 Project: MyFaces Core Issue Type: Bug Reporter: Bernd Bohmann The implementation of UIComponent.visitTree is correct but pushComponentToEL in UIData, UIForm, UINamingContainer and UIRepeat is called too late. 'component' expressions will fail in these components. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16100298#comment-16100298
]
Bernd Bohmann commented on MYFACES-3525:
In this case the description of the spec is wrong.
Compare to the local Value (local Value has two methods set/getLocalValue and
set/isLocalValueSet) unfortunately submitted Value has not a
set/isSubmittedValueSet method. Set submitted to null means there was no value
submitted. In this case if there is an conversion error or something else it
will render the old value instead of render the empty String.
javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL means during
validation an empty value should be interpreted as a null value only. This
should be the correct behavior. We raised a spec issue about this years ago but
the project has moved to github and I can not find the original issue:
// -= matzew = setSubmittedValue(null) is wrong, see:
// https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=671
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2554) Avoid duplicated trinidad-assembly artifacts
[ https://issues.apache.org/jira/browse/TRINIDAD-2554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2554. - Resolution: Fixed > Avoid duplicated trinidad-assembly artifacts > > > Key: TRINIDAD-2554 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2554 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Build >Affects Versions: 2.2.0-core >Reporter: Dennis Kieselhorst >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 2.1.4-core, 2.2.1-core > > > trinidad-assembly contains duplicated artifacts (with and without -dist). No > need to upload them twice. According to download page -dist is expected. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2558) NPE with partialStateSaving off and viewCache off and myface core in restore View
[ https://issues.apache.org/jira/browse/TRINIDAD-2558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2558. - Resolution: Fixed > NPE with partialStateSaving off and viewCache off and myface core in restore > View > - > > Key: TRINIDAD-2558 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2558 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.3-core, 2.2.0-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.1.4-core, 2.2.1-core > > > Caused by: java.lang.NullPointerException > at > javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:1335) > at > javax.faces.component.UIComponent$EventListenerWrapper.restoreState(UIComponent.java:1699) > at > javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1916) > at > javax.faces.component._DeltaList.restoreState(_DeltaList.java:252) > at > javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1916) > at > javax.faces.component.UIComponentBase.restoreFullSystemEventListenerClassMap(UIComponentBase.java:2292) > at > javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:2145) > at javax.faces.component.UIOutput.restoreState(UIOutput.java:241) > at > javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1631) > at > javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1675) > at > javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1646) > at > javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:884) > at > org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:840) > at > javax.faces.application.StateManagerWrapper.restoreView(StateManagerWrapper.java:84) > at > org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:104) > at > org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2140) > at > org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.restoreView(ViewDeclarationLanguageWrapper.java:74) > at > org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:336) > at > javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:82) > at > org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:247) > at > javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:82) > Reported in > http://mail-archives.apache.org/mod_mbox/myfaces-users/201112.mbox/%3C4EDFB3F6.7020306%40mayet.ca%3E > as well -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2557) writeDoctype is not implemented in PPRResponseWriter
[ https://issues.apache.org/jira/browse/TRINIDAD-2557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2557. - Resolution: Fixed > writeDoctype is not implemented in PPRResponseWriter > > > Key: TRINIDAD-2557 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2557 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.2.0-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.2.1-core > > > In jsf 2.2 responseWriter has the method writeDoctype. It should be skipped > for PPR Responses. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2556) UIXComponentBase|UIXEditableValue#processValidators|Decodes|Updates, CoreRenderer#encodeAllChildren and UIXComponent#visitTree doesn't support component expression i
[ https://issues.apache.org/jira/browse/TRINIDAD-2556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2556. - Resolution: Fixed > UIXComponentBase|UIXEditableValue#processValidators|Decodes|Updates, > CoreRenderer#encodeAllChildren and UIXComponent#visitTree doesn't support > component expression in rendered attribute > -- > > Key: TRINIDAD-2556 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2556 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.3-core, 2.2.0-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.1.4-core, 2.2.1-core > > > In some cases the call to pushComponentToEL is to late the rendered attribute > will be evaluated before the push. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRINIDAD-2558) NPE with partialStateSaving off and viewCache off and myface core in restore View
Bernd Bohmann created TRINIDAD-2558: --- Summary: NPE with partialStateSaving off and viewCache off and myface core in restore View Key: TRINIDAD-2558 URL: https://issues.apache.org/jira/browse/TRINIDAD-2558 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.2.0-core Reporter: Bernd Bohmann Assignee: Bernd Bohmann Caused by: java.lang.NullPointerException at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:1335) at javax.faces.component.UIComponent$EventListenerWrapper.restoreState(UIComponent.java:1699) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1916) at javax.faces.component._DeltaList.restoreState(_DeltaList.java:252) at javax.faces.component.UIComponentBase.restoreAttachedState(UIComponentBase.java:1916) at javax.faces.component.UIComponentBase.restoreFullSystemEventListenerClassMap(UIComponentBase.java:2292) at javax.faces.component.UIComponentBase.restoreState(UIComponentBase.java:2145) at javax.faces.component.UIOutput.restoreState(UIOutput.java:241) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1631) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1675) at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1646) at javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:884) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:840) at javax.faces.application.StateManagerWrapper.restoreView(StateManagerWrapper.java:84) at org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:104) at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2140) at org.apache.myfaces.trinidad.view.ViewDeclarationLanguageWrapper.restoreView(ViewDeclarationLanguageWrapper.java:74) at org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:336) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:82) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:247) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:82) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRINIDAD-2557) writeDoctype is not implemented in PPRResponseWriter
Bernd Bohmann created TRINIDAD-2557: --- Summary: writeDoctype is not implemented in PPRResponseWriter Key: TRINIDAD-2557 URL: https://issues.apache.org/jira/browse/TRINIDAD-2557 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.2.0-core Reporter: Bernd Bohmann Assignee: Bernd Bohmann In jsf 2.2 responseWriter has the method writeDoctype. It should be skipped for PPR Responses. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2550) Create a Trinidad 2.2.x version with more jsf 2.2 features
[ https://issues.apache.org/jira/browse/TRINIDAD-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2550. - Resolution: Fixed > Create a Trinidad 2.2.x version with more jsf 2.2 features > -- > > Key: TRINIDAD-2550 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2550 > Project: MyFaces Trinidad > Issue Type: Improvement > Components: Components >Affects Versions: 2.1.3-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.2.0-core > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2551) Add Pass-through attributes support
[ https://issues.apache.org/jira/browse/TRINIDAD-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2551. - Resolution: Fixed > Add Pass-through attributes support > --- > > Key: TRINIDAD-2551 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2551 > Project: MyFaces Trinidad > Issue Type: Sub-task > Components: Components >Affects Versions: 2.2.0-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.2.0-core > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRINIDAD-2556) processValidators|Decodes|Updates doesn't support component expression in rendered attribute
Bernd Bohmann created TRINIDAD-2556: --- Summary: processValidators|Decodes|Updates doesn't support component expression in rendered attribute Key: TRINIDAD-2556 URL: https://issues.apache.org/jira/browse/TRINIDAD-2556 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.3-core, 2.2.0-core Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRINIDAD-2555) java.lang.NullPointerException in SimpleSelectOneRenderer with javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL enabled
[ https://issues.apache.org/jira/browse/TRINIDAD-2555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TRINIDAD-2555. - Resolution: Fixed > java.lang.NullPointerException in SimpleSelectOneRenderer with > javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL enabled > -- > > Key: TRINIDAD-2555 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2555 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.3-core, 2.2.0-core >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 2.1.4-core, 2.2.1-core > > > Caused by: java.lang.NullPointerException > at > org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.__getIndex(SimpleSelectOneRenderer.java:421) > at > org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer._convertIndexedSubmittedValue(SimpleSelectOneRenderer.java:215) > at > org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.getConvertedValue(SimpleSelectOneRenderer.java:182) > at .. > at > org.apache.myfaces.trinidad.component.UIXEditableValue.getConvertedValue(UIXEditableValue.java:531) > at > org.apache.myfaces.trinidad.component.UIXEditableValue.validate(UIXEditableValue.java:201) > at > org.apache.myfaces.trinidad.component.UIXEditableValue._executeValidate(UIXEditableValue.java:763) > at > org.apache.myfaces.trinidad.component.UIXEditableValue.processValidators(UIXEditableValue.java:349) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) > at > javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) > at > javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) > at > javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) > at > javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) > at > javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) > at > org.apache.myfaces.trinidad.component.UIXForm.processValidators(UIXForm.java:82) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MYFACES-3525) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects display behavior for required fields
[
https://issues.apache.org/jira/browse/MYFACES-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049211#comment-16049211
]
Bernd Bohmann commented on MYFACES-3525:
I think the fix is wrong.
setSubmittedValue(null) should not called. Instead every getSubmittedValue call
should use INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL if it should
interpret the submitted empty value as null.
Then if the validation fails the empty submitted will be rendered
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL value affects
> display behavior for required fields
> --
>
> Key: MYFACES-3525
> URL: https://issues.apache.org/jira/browse/MYFACES-3525
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.0.12
>Reporter: VS
>Assignee: Bill Lucy
> Fix For: 2.0.25-SNAPSHOT, 2.1.19-SNAPSHOT, 2.2.13-SNAPSHOT
>
> Attachments: MYFACES-3525.patch
>
>
> Inconsistent behavior for required field validation when
> javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is set to true
> versus false
> To observe behavior:
> 1. Set javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to true in
> web.xml
> 2. Create JSF Page:
>
>
> required="true"
> requiredMessage="You must enter a first name"/>
>
>
> 3. Create Managed Bean:
> @ManagedBean
> public class Page1Controller
> {
> public String getFirstName()
> { return "Default Value"; }
> public void setFirstName(String value)
> { // no-op (for example purposes only) }
> 4. Load JSF page, blank out value in the input field and click Submit
> 5. Error message is displayed, however the value in the input field (which
> you formerly blanked out) is now reset back to its original value.
> 6. Change the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL
> setting to false and re-run the test.
> 7. Note that the value in the input field remains blank.
> Behavior is inconsistent and should be fixed
> (javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL setting of true
> or false should not result in inconsistent behavior with required fields)
>
> To state in a different way:
> When INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is TRUE, and you blank
> out a value for a required field that had previously been populated by the
> model, submit the form, you will see the OLD data from the model in the
> field. However, if that field had had a format validation applied to it and
> the user submits the form with a format validation error, the OLD data is NOT
> shown in the field (instead, the submitted/invalid data is shown). The same
> should happen for required field validation errors. The field should show the
> "blank" data and not the original model data. In order to get the correct
> behavior, the developer has to currently set
> INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL to false. But they should not
> have to do this... whether INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is
> true or false, the behavior of showing the blank field that the user
> submitted should be the same.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TRINIDAD-2555) java.lang.NullPointerException in SimpleSelectOneRenderer with javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL enabled
Bernd Bohmann created TRINIDAD-2555: --- Summary: java.lang.NullPointerException in SimpleSelectOneRenderer with javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL enabled Key: TRINIDAD-2555 URL: https://issues.apache.org/jira/browse/TRINIDAD-2555 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.3-core, 2.2.0-core Reporter: Bernd Bohmann Assignee: Bernd Bohmann Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.__getIndex(SimpleSelectOneRenderer.java:421) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer._convertIndexedSubmittedValue(SimpleSelectOneRenderer.java:215) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneRenderer.getConvertedValue(SimpleSelectOneRenderer.java:182) at .. at org.apache.myfaces.trinidad.component.UIXEditableValue.getConvertedValue(UIXEditableValue.java:531) at org.apache.myfaces.trinidad.component.UIXEditableValue.validate(UIXEditableValue.java:201) at org.apache.myfaces.trinidad.component.UIXEditableValue._executeValidate(UIXEditableValue.java:763) at org.apache.myfaces.trinidad.component.UIXEditableValue.processValidators(UIXEditableValue.java:349) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) at org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1261) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) at org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) at org.apache.myfaces.trinidad.component.UIXForm.processValidators(UIXForm.java:82) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildrenImpl(UIXComponentBase.java:1574) at org.apache.myfaces.trinidad.component.UIXComponentBase.validateChildren(UIXComponentBase.java:1559) at org.apache.myfaces.trinidad.component.UIXComponentBase.processValidators(UIXComponentBase.java:1316) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TOBAGO-1743) placeholder support for tc:textarea
[ https://issues.apache.org/jira/browse/TOBAGO-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-1743. --- Resolution: Fixed > placeholder support for tc:textarea > --- > > Key: TOBAGO-1743 > URL: https://issues.apache.org/jira/browse/TOBAGO-1743 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.4 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 3.1.0 > > Original Estimate: 2h > Remaining Estimate: 2h > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOBAGO-1743) placeholder support for tc:textarea
Bernd Bohmann created TOBAGO-1743: - Summary: placeholder support for tc:textarea Key: TOBAGO-1743 URL: https://issues.apache.org/jira/browse/TOBAGO-1743 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 3.0.4 Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOBAGO-1742) html5 minlength and pattern attribute support for tc:in and tc:textarea
[ https://issues.apache.org/jira/browse/TOBAGO-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Bohmann resolved TOBAGO-1742. --- Resolution: Fixed > html5 minlength and pattern attribute support for tc:in and tc:textarea > --- > > Key: TOBAGO-1742 > URL: https://issues.apache.org/jira/browse/TOBAGO-1742 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Core >Affects Versions: 3.0.4 >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann >Priority: Minor > Fix For: 3.1.0 > > Original Estimate: 4h > Remaining Estimate: 4h > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOBAGO-1692) Regex validation doesn't work
[
https://issues.apache.org/jira/browse/TOBAGO-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bernd Bohmann resolved TOBAGO-1692.
---
Resolution: Fixed
fixed in demo
> Regex validation doesn't work
> -
>
> Key: TOBAGO-1692
> URL: https://issues.apache.org/jira/browse/TOBAGO-1692
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.0.2
>Reporter: Dennis Kieselhorst
>Assignee: Bernd Bohmann
> Fix For: 3.1.0
>
>
> Check sample in content-validation.xhtml, regardless of the given value there
> is always a validation error after submit.
> Logfile warning
> {noformat}
> javax.faces.validator.BeanValidator validate
> WARNUNG: cannot validate component with empty value:
> page:mainForm:regexValidation:in
> {noformat}
> Moreover in TextareaRenderer and InRenderer code with RegexValidator is
> commented out, if it's no longer needed writeAttribute for pattern should be
> removed as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOBAGO-1742) html5 minlength and pattern attribute support for tc:in and tc:textarea
Bernd Bohmann created TOBAGO-1742: - Summary: html5 minlength and pattern attribute support for tc:in and tc:textarea Key: TOBAGO-1742 URL: https://issues.apache.org/jira/browse/TOBAGO-1742 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 3.0.4 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.15#6346)
