August 2013 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13052) popupPanel: @visualOptions does not work

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13052?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13052: --------------------------------- I propose to remove @visualOptions attribute as it does not serve any value anymore. > popupPanel: @visualOptions does not work > ---------------------------------------- > > Key: RF-13052 > URL: https://issues.jboss.org/browse/RF-13052 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 5.0.0.Alpha1 > Environment: RichFaces 5.0.0-SNAPSHOT > Reporter: Jiří Štefek > Assignee: Lukáš Fryč > Fix For: 4.3.4, 5-Tracking > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Setting @visualOptions doesn't work. Tried both settings from https://issues.jboss.org/browse/RF-2464 or https://issues.jboss.org/browse/RF-5239 > e.g.: 'left:1px' > OR > Is this attribute a leftover from older versions of RF (RF-3) and was replaced by attributes @*width, @*height and @style* ? > ALSO UPDATE VDL-DOC in both cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13052) popupPanel: @visualOptions does not work

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13052?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13052: --------------------------------- The attribute was evidently introduced in RF3 in RF-2464: http://www.docjar.com/html/api/org/richfaces/component/UIModalPanel.java.... As it seems, it should serve for setting a map of visual options like left/top coordinates and width/height. These attributes can be setup using attributes left/top and width/height in rich:popupPanel together with the min/max values. These options are discussed here: http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html... And further documented in VDL DOC: http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/popupPanel.html > popupPanel: @visualOptions does not work > ---------------------------------------- > > Key: RF-13052 > URL: https://issues.jboss.org/browse/RF-13052 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 5.0.0.Alpha1 > Environment: RichFaces 5.0.0-SNAPSHOT > Reporter: Jiří Štefek > Assignee: Lukáš Fryč > Fix For: 4.3.4, 5-Tracking > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Setting @visualOptions doesn't work. Tried both settings from https://issues.jboss.org/browse/RF-2464 or https://issues.jboss.org/browse/RF-5239 > e.g.: 'left:1px' > OR > Is this attribute a leftover from older versions of RF (RF-3) and was replaced by attributes @*width, @*height and @style* ? > ALSO UPDATE VDL-DOC in both cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13131) Upgrade to Arquillian Warp Beta1 / Core 1.0.4 / Graphene Beta1

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13131?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13131: --------------------------------- Nope, we don't have to - Warp Alpha3 brought critical issue which our tests suffers from. I wouldn't upgrade RF4 unless it'll be critical needed. > Upgrade to Arquillian Warp Beta1 / Core 1.0.4 / Graphene Beta1 > -------------------------------------------------------------- > > Key: RF-13131 > URL: https://issues.jboss.org/browse/RF-13131 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: build/distribution > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13131) Upgrade to Arquillian Warp Beta1 / Core 1.0.4 / Graphene Beta1

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13131?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13131 at 8/14/13 12:34 PM: ----------------------------------------------------------- Nope, we don't have to - Warp Alpha3 brought critical issue which our tests suffers from. I wouldn't upgrade RF4 unless it'll be critically needed. was (Author: lfryc): Nope, we don't have to - Warp Alpha3 brought critical issue which our tests suffers from. I wouldn't upgrade RF4 unless it'll be critical needed. > Upgrade to Arquillian Warp Beta1 / Core 1.0.4 / Graphene Beta1 > -------------------------------------------------------------- > > Key: RF-13131 > URL: https://issues.jboss.org/browse/RF-13131 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: build/distribution > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13130) Add Hamcrest for BDD-style assertions

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13130?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13130: --------------------------------- The difference is perceivable here: https://gist.github.com/lfryc/6232827 > Add Hamcrest for BDD-style assertions > ------------------------------------- > > Key: RF-13130 > URL: https://issues.jboss.org/browse/RF-13130 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - unit > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > https://code.google.com/p/hamcrest/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13130) Add Hamcrest for BDD-style assertions

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13130?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13130 at 8/14/13 12:32 PM: ----------------------------------------------------------- Hamcrest-style API provides more readable tests, but more importantly readable results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} * it fails with: {{AssertionError}}: ---- {code} Assert.assertTrue("list should be empty", list.isEmpty()); {code} * it fails with: {{list should be empty}}: ---- {code} Assert.assertThat(list, is(empty()); {code} * it fails with: {code} Expected: is an empty collection but: <[a, b, c]> {code} ---- The {{assertThat}} option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} was (Author: lfryc): Hamcrest-style API provides more readable tests, but more importantly readable results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} * it fails with: {{AssertionError}}: {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} * it fails with: {{list is empty}}: {code} Assert.assertThat(list, is(empty()); {code} * it fails with: {code} Expected: is an empty collection but: <[a, b, c]> {code} ---- The {{assertThat}} option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} > Add Hamcrest for BDD-style assertions > ------------------------------------- > > Key: RF-13130 > URL: https://issues.jboss.org/browse/RF-13130 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - unit > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > https://code.google.com/p/hamcrest/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13130) Add Hamcrest for BDD-style assertions

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13130?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13130 at 8/14/13 12:29 PM: ----------------------------------------------------------- Hamcrest-style API provides more readable tests, but more importantly readable results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} * it fails with: {{AssertionError}}: {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} * it fails with: {{list is empty}}: {code} Assert.assertThat(list, is(empty()); {code} * it fails with: {code} Expected: is an empty collection but: <[a, b, c]> {code} ---- The {{assertThat}} option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} was (Author: lfryc): Hamcrest-style API provides more readable tests, but more importantly readable results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} Fails with: {{AssertionError}} {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} Fails with: {{list is empty}} {code} Assert.assertThat(list, is(empty()); {code} Fails with: {{The 'list' is expected to be empty, but it was: ...}} ---- The second option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} > Add Hamcrest for BDD-style assertions > ------------------------------------- > > Key: RF-13130 > URL: https://issues.jboss.org/browse/RF-13130 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - unit > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > https://code.google.com/p/hamcrest/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13130) Add Hamcrest for BDD-style assertions

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13130?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč edited comment on RF-13130 at 8/14/13 12:23 PM: ----------------------------------------------------------- Hamcrest-style API provides more readable tests, but more importantly readable results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} Fails with: {{AssertionError}} {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} Fails with: {{list is empty}} {code} Assert.assertThat(list, is(empty()); {code} Fails with: {{The 'list' is expected to be empty, but it was: ...}} ---- The second option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} was (Author: lfryc): Hamcrest-style API provides more readable tests, but more importantly results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} Fails with: {{AssertionError}} {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} Fails with: {{list is empty}} {code} Assert.assertThat(list, is(empty()); {code} Fails with: {{The 'list' is expected to be empty, but it was: ...}} ---- The second option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} > Add Hamcrest for BDD-style assertions > ------------------------------------- > > Key: RF-13130 > URL: https://issues.jboss.org/browse/RF-13130 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - unit > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > https://code.google.com/p/hamcrest/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13130) Add Hamcrest for BDD-style assertions

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13130?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13130: --------------------------------- Hamcrest-style API provides more readable tests, but more importantly results - compare: {code} Assert.assertTrue(list.isEmpty()); {code} Fails with: {{AssertionError}} {code} Assert.assertTrue("list is empty", list.isEmpty()); {code} Fails with: {{list is empty}} {code} Assert.assertThat(list, is(empty()); {code} Fails with: {{The 'list' is expected to be empty, but it was: ...}} ---- The second option is refactoring proof, as it does not have to bear any message in order to understand what assertion has been made. Both APIs are part of JUnit, since JUnit transitionally depends on Hamcrest Core, however in Hamcrest Core are just simple matchers, e.g. it misses: {code} Assert.assertThat(someString, containsString("foo")); {code} > Add Hamcrest for BDD-style assertions > ------------------------------------- > > Key: RF-13130 > URL: https://issues.jboss.org/browse/RF-13130 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: tests - unit > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > https://code.google.com/p/hamcrest/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-12891) Datatable with ExtendedDataModel ajax call

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-12891?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-12891: ------------------------------------ The ExtendedDataModel is _working as designed_. We will keep this issue open to track the idea of optimizing that model to minimize iterations. > Datatable with ExtendedDataModel ajax call > ------------------------------------------ > > Key: RF-12891 > URL: https://issues.jboss.org/browse/RF-12891 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.3.1 > Environment: apache-tomcat-7.0.34, servlet-weld 1.1.11. > Reporter: tehackio teha > Labels: ExtendedDataModel, UIDataAdaptor, a4j:commandLink, datatable > Fix For: 5-Tracking > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > If one ajax call inside column of datatable(org.ajax4jsf.model.ExtendedDataModel) to render outside, method walk is called many times; > On org.richfaces.component.UIDataAdaptor.requiresRowIteration(VisitContext context), context.getFacesContext().getAttributes().get("javax.faces.visit.SKIP_ITERATION") returns "null", therefore "false". -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues August 2013