[JBoss JIRA] (RF-13035) Simpleapp Archetype: mobile version shows modal dialog
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13035?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13035:
-------------------------------
Fix Version/s: 5.0.0.Alpha2
> Simpleapp Archetype: mobile version shows modal dialog
> -------------------------------------------------------
>
> Key: RF-13035
> URL: https://issues.jboss.org/browse/RF-13035
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: archetype
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Jan Papousek
> Assignee: Brian Leathem
> Priority: Critical
> Fix For: 4.3.4, 5.0.0.Alpha2
>
> Attachments: modal-iphone.png, richfaces-simpleapp-jee6.war, simpleapp-modal.png
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> When the simpleapp archetype is built with "-Dmobile-optimized=true", the welcome page shows modal dialog (see screenshot).
--
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
11 years, 3 months
[JBoss JIRA] (RF-13035) Simpleapp Archetype: mobile version shows modal dialog
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13035?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13035.
--------------------------------
Labels: (was: regression)
Resolution: Done
Added the missing divs when mobile-optimized == true
> Simpleapp Archetype: mobile version shows modal dialog
> -------------------------------------------------------
>
> Key: RF-13035
> URL: https://issues.jboss.org/browse/RF-13035
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: archetype
> Affects Versions: 4.1.0.Final, 5.0.0.Alpha1
> Reporter: Jan Papousek
> Assignee: Brian Leathem
> Priority: Critical
> Fix For: 4.3.4
>
> Attachments: modal-iphone.png, richfaces-simpleapp-jee6.war, simpleapp-modal.png
>
> Original Estimate: 45 minutes
> Remaining Estimate: 45 minutes
>
> When the simpleapp archetype is built with "-Dmobile-optimized=true", the welcome page shows modal dialog (see screenshot).
--
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
11 years, 3 months
[JBoss JIRA] (RF-13107) rich:message is renderer even though it is in non-active switchable panel, causing JSF to fail with mallformedXML error
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13107?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13107:
-------------------------------
Assignee: (was: Brian Leathem)
> rich:message is renderer even though it is in non-active switchable panel, causing JSF to fail with mallformedXML error
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: RF-13107
> URL: https://issues.jboss.org/browse/RF-13107
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.2
> Reporter: Jonáš Trantina
> Fix For: 4.3.4
>
> Attachments: bug_reproducer.zip, reproducer_ajax.zip
>
> Original Estimate: 1 hour, 30 minutes
> Remaining Estimate: 1 hour, 30 minutes
>
> We have a form with a tabPanel component with two tabs A and B. In A there is an input and its rich:message in B the same plus a button that submits and re-renders B. When B is opened (thus A is not rendered) and the form is submitted and validation fails, then no message is shown.
> Note that:
> 1) switchType must be set to server to ensure the A's rich:message is really not on the page.
> 2) button in B must re-render only content of B
> This is only a specific scenario, the issue might occur also in other situations (e.g. global messages tag outside of tabPanel is not rendered).
> Please find the enclosed reproducer.
> Snipper:
> {code:xml}
> <h:form>
> <rich:tabPanel switchType="server">
> <rich:tab>
> <h:inputText id="surname" value="#{richBean.surname}">
> <f:validateLength minimum="10"/>
> </h:inputText>
> <rich:message for="surname"/>
> </rich:tab>
> <rich:tab>
> <h:panelGroup id="content">
> <h:inputText id="name" value="#{richBean.name}">
> <f:validateLength minimum="6"/>
> </h:inputText>
> <rich:message for="name"/>
> </h:panelGroup>
> <a4j:commandButton value="Submit" execute="content" render="content" />
> </rich:tab>
> </rich:tabPanel>
> </h:form>
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (RF-13116) Using filters with paging / default filter value in extendeddatatable
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13116?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13116 at 8/12/13 4:23 PM:
-------------------------------------------------------------
What's the scope of your _#\{tiltakFilter\}_ object?
was (Author: bleathem):
what's the scope of your #{tiltakFilter} object?
> Using filters with paging / default filter value in extendeddatatable
> ---------------------------------------------------------------------
>
> Key: RF-13116
> URL: https://issues.jboss.org/browse/RF-13116
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: John Strandmyr
> Priority: Critical
> Labels: datascroller, extendedDataTable, filter, waiting_on_user
>
> I've got an extededdatatable from richfaces and if i add a default value to the filter, so that some rows are excluded on first rendering, and then change the filter to show the rows that were hidden, I don't get any calls to the actionlisteners on the rows that were hidden at first.
> It works fine on those rows that was shown in the first page load, but not on those hidden.
> The same issue appears when i use paging, and some rows are on page two. if i use the filter to show some rows from another page, the actionlistener isnt triggered. I can still click on those rows that was apparent on the first page, but not on the other pages.
> If I don't have a default filter, or a pager, i can add and remove filtering and everything is fine.
> {code}
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:rich="http://richfaces.org/rich">
> <h:head>
> <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
> <h:outputScript name="jsf.js" library="javax.faces"/>
> </h:head>
> <h:body>
> <h:form>
> <rich:extendedDataTable value="#{tiltakServer.tiltak}" var="tiltak" id="tiltakTable">
> <rich:column filter="#{tiltakFilter.tittelImpl}">
> <f:facet name="header">
> <h:outputText value="Tittel" />
> <h:panelGroup styleClass="filter">
> <h:inputText value="#{tiltakFilter.tittelFilter}">
> <a4j:ajax event="keyup" render="tiltakTable@body" execute="@this"/>
> </h:inputText>
> </h:panelGroup>
> </f:facet>
> <h:outputText value="#{tiltak.tittel}"/>
> </rich:column>
> <rich:column>
> <f:facet name="header">
> Edit
> </f:facet>
> <h:commandLink value="Goto">
> <f:actionListener type="no.hmskontoret.hmskontoret.hendelsesregister.TiltakOnEditActionListener"/>
> </h:commandLink>
> </rich:column>
> </rich:extendedDataTable>
> </h:form>
> </h:body>
> </html>
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (RF-13116) Using filters with paging / default filter value in extendeddatatable
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13116?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13116:
------------------------------------
what's the scope of your #{tiltakFilter} object?
> Using filters with paging / default filter value in extendeddatatable
> ---------------------------------------------------------------------
>
> Key: RF-13116
> URL: https://issues.jboss.org/browse/RF-13116
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: John Strandmyr
> Priority: Critical
> Labels: datascroller, extendedDataTable, filter, waiting_on_user
>
> I've got an extededdatatable from richfaces and if i add a default value to the filter, so that some rows are excluded on first rendering, and then change the filter to show the rows that were hidden, I don't get any calls to the actionlisteners on the rows that were hidden at first.
> It works fine on those rows that was shown in the first page load, but not on those hidden.
> The same issue appears when i use paging, and some rows are on page two. if i use the filter to show some rows from another page, the actionlistener isnt triggered. I can still click on those rows that was apparent on the first page, but not on the other pages.
> If I don't have a default filter, or a pager, i can add and remove filtering and everything is fine.
> {code}
> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
> <html xmlns="http://www.w3.org/1999/xhtml"
> xmlns:h="http://java.sun.com/jsf/html"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:a4j="http://richfaces.org/a4j"
> xmlns:rich="http://richfaces.org/rich">
> <h:head>
> <meta http-equiv="content-type" content="text/html; charset=utf-8"/>
> <h:outputScript name="jsf.js" library="javax.faces"/>
> </h:head>
> <h:body>
> <h:form>
> <rich:extendedDataTable value="#{tiltakServer.tiltak}" var="tiltak" id="tiltakTable">
> <rich:column filter="#{tiltakFilter.tittelImpl}">
> <f:facet name="header">
> <h:outputText value="Tittel" />
> <h:panelGroup styleClass="filter">
> <h:inputText value="#{tiltakFilter.tittelFilter}">
> <a4j:ajax event="keyup" render="tiltakTable@body" execute="@this"/>
> </h:inputText>
> </h:panelGroup>
> </f:facet>
> <h:outputText value="#{tiltak.tittel}"/>
> </rich:column>
> <rich:column>
> <f:facet name="header">
> Edit
> </f:facet>
> <h:commandLink value="Goto">
> <f:actionListener type="no.hmskontoret.hmskontoret.hendelsesregister.TiltakOnEditActionListener"/>
> </h:commandLink>
> </rich:column>
> </rich:extendedDataTable>
> </h:form>
> </h:body>
> </html>
> {code}
--
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
11 years, 3 months
[JBoss JIRA] (RF-13095) extendedDataTable tableState setter not called on column resize/reorder
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13095?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13095:
-------------------------------
Fix Version/s: 4.3.4
(was: 5-Tracking)
> extendedDataTable tableState setter not called on column resize/reorder
> -----------------------------------------------------------------------
>
> Key: RF-13095
> URL: https://issues.jboss.org/browse/RF-13095
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23, tested on Firefox 22 and Chrome 28.
> Reporter: Salvo Isaja
> Fix For: 4.3.4
>
>
> Not sure if this qualifies as a bug or a feature request.
> I have an extendedDataTable with the tableState attribute bound to a String property of a backing bean (tried both a request scoped bean on a transient view and a session scoped bean on a stateful view).
> When resizing or reordering columns, an Ajax request is posted to the server, and I correctly see the new column layouts in the request, but the setter of the tableState property in the backing bean is not called. If I execute @form on a a4j:commandLink or commandButton, it is called instead.
> Thanks
--
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
11 years, 3 months
[JBoss JIRA] (RF-13126) ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13126?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13126:
-------------------------------
Labels: waiting_on_user (was: new_and_noteworthy)
> ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
> ----------------------------------------------------------------------------------------------------------
>
> Key: RF-13126
> URL: https://issues.jboss.org/browse/RF-13126
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 5.0.0.Alpha1
> Environment: Windows / Tomcat 7 / JDK 1.7 (Firefox & IE)
> Reporter: Steven W.
> Labels: waiting_on_user
>
> In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
> In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be RF-4855 + RF-13094 and RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
> I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
--
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
11 years, 3 months
[JBoss JIRA] (RF-13126) ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13126?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13126:
------------------------------------
Is this issue reporting a new issue not covered by RF-13094 and RF-13095? If so, please indicate what the new issue is, otherwise I will close this issue as a duplicate.
> ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
> ----------------------------------------------------------------------------------------------------------
>
> Key: RF-13126
> URL: https://issues.jboss.org/browse/RF-13126
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 5.0.0.Alpha1
> Environment: Windows / Tomcat 7 / JDK 1.7 (Firefox & IE)
> Reporter: Steven W.
> Labels: new_and_noteworthy
>
> In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
> In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be RF-4855 + RF-13094 and RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
> I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
--
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
11 years, 3 months
[JBoss JIRA] (RF-13126) ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13126?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13126:
-------------------------------
Description:
In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be RF-4855 + RF-13094 and RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
was:
In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be https://issues.jboss.org/browse/RF-4855 + https://issues.jboss.org/browse/RF-13094 and https://issues.jboss.org/browse/RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
> ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
> ----------------------------------------------------------------------------------------------------------
>
> Key: RF-13126
> URL: https://issues.jboss.org/browse/RF-13126
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 5.0.0.Alpha1
> Environment: Windows / Tomcat 7 / JDK 1.7 (Firefox & IE)
> Reporter: Steven W.
> Labels: new_and_noteworthy
>
> In prior 3.x release the ExtendedDataTable control supported TableState data for sizing of columns - this worked relatively well *however* there is/was a bug such that the columns headers above the table did *not* align properly with the data rows of the table below; this could be partially accommodated by specifying a size for the column (in the TableState data) that was wider than the longest string in the column data as he initial / minimum size.
> In subsequent release (in 4.x time frame I believe) the control was refactored and the TableState capability as a whole was lost - I saw this in another report on the forum or Jira though not the same but other related issues may be RF-4855 + RF-13094 and RF-13095 ; the report I remember reading, however, is that this TableState functionality was lost during the refactoring and was then said to be restored in a subsequent release.
> I am now using Version 5 of RichFaces to include the first milestone and latest (overnight) snapshot and am confirming this column header sizing AND/OR TableState table header sizing issue(s) still remain, regardless of prior attempts to include TableState data recognition and, if/as so, the widths of the column headers does not respect the TableState data nor do they conform to the column widths of the data in the rows below.
--
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
11 years, 3 months
[JBoss JIRA] (RF-13127) onvalid and oninvalide pass wrong element when using rich:element with String field
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13127?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13127:
------------------------------------
Please include a [Short, Self Contained, Correct, Example|http://sscce.org/]. Refer to the RichFaces wiki article on [Submitting Effective Issue Reports|https://community.jboss.org/wiki/SubmittingEffectiveIssueReports].
> onvalid and oninvalide pass wrong element when using rich:element with String field
> -----------------------------------------------------------------------------------
>
> Key: RF-13127
> URL: https://issues.jboss.org/browse/RF-13127
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.3.3
> Reporter: Louis Parisi
>
> I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but always returns the element from row zero when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field.
> {code}
> <h:inputText value="#\{myBean.myField}" id="myField">
> <rich:validator oninvalid="valueModifiedAndError(#\{rich:element('myField')})"
> onvalid="valueModified(#\{rich:element('myField')})"/>
> </h:inputText>
> {code}
> Some other tests I did while trying to debug are:
> * I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field.
> * The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field.
--
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
11 years, 3 months