[JBoss JIRA] (RF-13126) ExtendedDataTable Header Column Widths does not conform to Row Data Column Widths specified in TableState
by Steven W. (JIRA)
[ https://issues.jboss.org/browse/RF-13126?page=com.atlassian.jira.plugin.s... ]
Steven W. commented on RF-13126:
--------------------------------
Thanks!
> 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.
>
> 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
12 years, 7 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 updated RF-13035:
-------------------------------
Priority: Major (was: Critical)
> 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
> 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
12 years, 7 months
[JBoss JIRA] (RF-10442) extendedDataTable: add state saving functionality
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-10442?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-10442:
------------------------------------
[~tfburton] you cannot vote because this issue has been resolved. Upgrade your application to use RichFaces >= 4.3.0.Final to take advantage of this feature.
> extendedDataTable: add state saving functionality
> -------------------------------------------------
>
> Key: RF-10442
> URL: https://issues.jboss.org/browse/RF-10442
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.0.0.Milestone5
> Reporter: Ilya Shaikovsky
> Assignee: Brian Leathem
> Fix For: 4.3.0.M3
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> developer should be able to store column width'es, order and so on between requests.
> TO discuss: use tableState as before or maybe create set of specific attributes for every required properties set.
--
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
[JBoss JIRA] (RF-13098) Regression: mediaOutput broken for CDI MediaData beans
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13098?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reopened RF-13098:
--------------------------------
Assignee: Matej Novotny
[~manovotn] It seems in your reproducer you used a JSF @RequestScoped annotation, rather than a CDI one:
https://github.com/richfaces/richfaces-qa/commit/2aa0b238bfc4599d553c3181...
Can you please repeat your verification using a proper CDI bean?
> Regression: mediaOutput broken for CDI MediaData beans
> ------------------------------------------------------
>
> Key: RF-13098
> URL: https://issues.jboss.org/browse/RF-13098
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.3
> Reporter: Marek Schmidt
> Assignee: Matej Novotny
>
> https://issues.jboss.org/browse/RF-13089 introduced a regression for a4j:mediaOutput component
> Having a
> {code}
> <a4j:mediaOutput element="img" cacheable="true" session="true" createContent="#{mediaBean.paint}" value="#{mediaData}" mimeType="image/jpeg"/>
> {code}
> with mediaData being a CDI bean, e.g.
> {code}
> @javax.inject.Named("mediaData")
> @javax.enterprise.context.RequestScoped
> public class MediaData implements Serializable
> {code}
> the following exception occurs:
> {code}10:39:27,997 SEVERE [org.richfaces.log.Resource] (http-/127.0.0.1:8080-1) Input error for deserialize data : java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.bean.proxy.util.SerializableClientProxy
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:93) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342) [rt.jar:1.7.0_25]
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) [rt.jar:1.7.0_25]
> at org.richfaces.util.Util.decodeObjectData(Util.java:237) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156) [richfaces-core-impl-4.3.3.Final.jar:4.3.3.Final]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:591) [jboss-jsf-api_2.1_spec-2.1.19.1.Final-redhat-1.jar:2.1.19.1.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {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
12 years, 7 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 reassigned RF-13116:
----------------------------------
Assignee: Pavol Pitonak
QE, please verify this issue.
> 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
> Assignee: Pavol Pitonak
> Priority: Critical
> Labels: datascroller, extendedDataTable, filter
>
> 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
12 years, 7 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 updated RF-13116:
-------------------------------
Labels: datascroller extendedDataTable filter (was: datascroller extendedDataTable filter waiting_on_user)
> 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
>
> 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
12 years, 7 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 resolved RF-13126.
--------------------------------
Labels: (was: waiting_on_user)
Resolution: Duplicate Issue
There will be some overlap where we will dual-patch RF 4.3.x and RF 5.0.x - no need for separate issues for each branch.
> 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.
>
> 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
12 years, 7 months