[JBoss JIRA] (RF-13587) rich:autocomplete - suggestion box doesn't show up at all
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13587?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13587:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
(was: 4.3.5)
> rich:autocomplete - suggestion box doesn't show up at all
> ---------------------------------------------------------
>
> Key: RF-13587
> URL: https://issues.jboss.org/browse/RF-13587
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.5
> Environment: Implementation: JSF-2.2.6 mojarra, Mojarra 2.2.5
> Server: WebLogic 12.1.2.1, WildFly 8.0.0.Final
> Browser: Chrome 33, Firefox 27
> Java: 1.7
> Reporter: Amit Tikoo
> Assignee: Brian Leathem
> Labels: richfaces
> Fix For: 4.5.0.Alpha3
>
>
> I am using a <rich:autocomplete> component but the suggestion box just doesn't show up. Here is a simple case I'm trying:
> XHTML:
> {code}
> <h:form id="amit" prependId="false">
> <rich:autocomplete mode="ajax" minChars="1" autofill="true" var="station" autocompleteMethod="#{segmentationBean.autocomplete1}" >
> <rich:column styleClass="sexy">
> <b>#{station}</b>
> </rich:column>
> </rich:autocomplete>
> </h:form>
> {code}
> JAVA:
> {code}
> public List<String> autocomplete1(String request){
> List<String> suggestions = new ArrayList<String>();
> suggestions.add("test 1");
> suggestions.add("test 2");
> suggestions.add("test 3");
> suggestions.add("test 4");
> return suggestions;
> }
> {code}
> This shows up in logging (using <a4j:log/>)
> {code}
> error[14:47:03.644]: Received 'error@malformedXML' event from <span id=j_idt5 class=rf-au ...>
> error[14:47:03.644]: [status=200] During update: javax.faces.ViewState not found
> {code}
> Also i can see the suggestion if i switch the mode to "Client"
--
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
10 years, 2 months
[JBoss JIRA] (RF-13534) a4j:mediaOutput on GF4: "Unauthorized deserialisation attempt"
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13534?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13534:
-------------------------------
Labels: glassfish (was: )
> a4j:mediaOutput on GF4: "Unauthorized deserialisation attempt"
> --------------------------------------------------------------
>
> Key: RF-13534
> URL: https://issues.jboss.org/browse/RF-13534
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.5
> Environment: Glassfish 4.0, Mac OS X 10.9.1, Java(TM) SE Runtime Environment (build 1.7.0_21-b12), Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
> Reporter: Daniele Benegiamo
> Labels: glassfish
> Fix For: 5-Tracking
>
> Attachments: MediaOutput.zip
>
>
> On GF4.0 any attempt to use {{<a4j:mediaOutput>}} raises the same exception ("{{java.io.InvalidClassException: Unauthorized deserialisation attempt}}"). Everything works nicely with the old RichFaces 4.1.0.
> Below you can find a stack trace, a sample page and a sample managed bean as minimum reproducible test case.
> To keep the test case short, the sample doesn't uses the {{value}} attribute, but exceptions are raised also when using it (e.g. passing a simple {{java.lang.String}}).
> From a first quick analysis seems that:
> * basic types (as {{java.lang.String}}) are not properly detected as "de-serializable";
> * types implementing {{Serializable}} or {{SerializableResource}} interfaces are impossible to instantiate by {{LookAheadObjectInputStream}} (row 118 - {{Class.forName()}} call in {{isClassValid()}} method - raises a {{ClassNotFoundException}} exception).
> {code:title=Exception}
> SEVERE: Input error for deserialize data
> java.io.InvalidClassException: Unauthorized deserialization attempt; org.jboss.weld.util.el.ForwardingMethodExpression
> at org.richfaces.util.LookAheadObjectInputStream.resolveClass(LookAheadObjectInputStream.java:105)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1610)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
> at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1620)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1515)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1769)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at com.sun.faces.facelets.el.TagMethodExpression.readExternal(TagMethodExpression.java:158)
> at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1835)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1794)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1989)
> at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1913)
> at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1796)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1348)
> at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1704)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1342)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at org.richfaces.util.Util.decodeObjectData(Util.java:237)
> at org.richfaces.resource.DefaultCodecResourceRequestData.getData(DefaultCodecResourceRequestData.java:97)
> at org.richfaces.resource.ResourceFactoryImpl.createResource(ResourceFactoryImpl.java:337)
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:156)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
> at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
> at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
> at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
> at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
> at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
> at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
> at java.lang.Thread.run(Thread.java:722)
> WARNING: StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet Faces Servlet threw exception
> java.lang.NullPointerException
> at org.richfaces.resource.MediaOutputResource.encode(MediaOutputResource.java:62)
> at org.richfaces.resource.UserResourceWrapperImpl.encode(UserResourceWrapperImpl.java:188)
> at org.richfaces.resource.ResourceHandlerImpl.handleResourceRequest(ResourceHandlerImpl.java:229)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:643)
> at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:318)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
> at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:357)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:260)
> at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:188)
> at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:191)
> at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:168)
> at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:189)
> at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:288)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:206)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:136)
> at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:114)
> at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
> at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:838)
> at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:113)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
> at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:564)
> at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:544)
> at java.lang.Thread.run(Thread.java:722)
> {code}
> {code:xml|title=index.xhtml}
> <?xml version='1.0' encoding='UTF-8' ?>
> <!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://xmlns.jcp.org/jsf/html"
> xmlns:a4j="http://richfaces.org/a4j">
> <h:head>
> <title>Page title</title>
> </h:head>
> <h:body>
> <a4j:mediaOutput element="img" createContent="#{myBean.myCreateContent}"/>
> </h:body>
> </html>
> {code}
> {code:java|title=MyBean.java}
> package org.example;
> import java.awt.Color;
> import java.awt.Font;
> import java.awt.Graphics2D;
> import java.awt.image.BufferedImage;
> import java.io.IOException;
> import javax.enterprise.context.RequestScoped;
> import javax.imageio.ImageIO;
> import javax.inject.Named;
> @Named
> @RequestScoped
> public class MyBean
> {
> public void myCreateContent (java.io.OutputStream output, java.lang.Object input)
> throws IOException
> {
> BufferedImage img = new BufferedImage (400, 200, BufferedImage.TYPE_INT_RGB);
> Graphics2D graphics2D = img.createGraphics ();
> graphics2D.setBackground (Color.BLACK);
> graphics2D.setColor (Color.WHITE);
> graphics2D.clearRect (0, 0, img.getWidth (), img.getHeight ());
> graphics2D.setFont (new Font ("Arial", Font.PLAIN, 12));
> graphics2D.drawString ("String", 20, 35);
> ImageIO.write (img, "png", output);
> }
> }
> {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
10 years, 2 months
[JBoss JIRA] (RF-13356) DataTable: row height strechted to 100% of the table height
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13356?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13356:
-------------------------------
Assignee: (was: Brian Leathem)
> DataTable: row height strechted to 100% of the table height
> -----------------------------------------------------------
>
> Key: RF-13356
> URL: https://issues.jboss.org/browse/RF-13356
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.3, 5.0.0.Alpha1
> Reporter: Anton Bogoslavskyi
> Fix For: 5-Tracking
>
> Attachments: edt.png, extended-screen1.png, extended-screen2.png, screen1.png, screen2.png
>
>
> The same as in the parent issue:
> Instead of having fixed row height and blank space if not enough rows to fill the entire table height, the rows are stretched to fill the entire table height. For instance with an extended data table of 500px height and 2 rows, each row is approximately 250px height (minus the height of the header, borders and cell spacing).
--
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
10 years, 2 months
[JBoss JIRA] (RF-13356) DataTable: row height strechted to 100% of the table height
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13356?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13356:
------------------------------------
Thanks [~ppitonak]
> DataTable: row height strechted to 100% of the table height
> -----------------------------------------------------------
>
> Key: RF-13356
> URL: https://issues.jboss.org/browse/RF-13356
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.3, 5.0.0.Alpha1
> Reporter: Anton Bogoslavskyi
> Fix For: 5-Tracking
>
> Attachments: edt.png, extended-screen1.png, extended-screen2.png, screen1.png, screen2.png
>
>
> The same as in the parent issue:
> Instead of having fixed row height and blank space if not enough rows to fill the entire table height, the rows are stretched to fill the entire table height. For instance with an extended data table of 500px height and 2 rows, each row is approximately 250px height (minus the height of the header, borders and cell spacing).
--
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
10 years, 2 months
[JBoss JIRA] (RF-12289) rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12289?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12289:
-------------------------------
Description:
Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
Basically, what I have is:
{code}
<h:selectOneMenu value="#{myBean.batchRows}">
<f:selectItem itemLabel="10" itemValue="10"/>
<f:selectItem itemLabel="20" itemValue="20"/>
<f:ajax render="table table-ds" />
</h:selectOneMenu>
...
<h:panelGroup>
<rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
...
</rich:dataTable>
</h:panelGroup>
<rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
...
</rich:dataScroller>
{code}
And the behaviour with 21 elements:
- on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
- rows: 10 (correct)
- first: 20 (weird)
Following calls to this method is setting those properties to:
- rows: 10 (correct)
- first: 10 (correct)
was:
Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
Basically, what I have is:
<h:selectOneMenu value="#{myBean.batchRows}">
<f:selectItem itemLabel="10" itemValue="10"/>
<f:selectItem itemLabel="20" itemValue="20"/>
<f:ajax render="table table-ds" />
</h:selectOneMenu>
...
<h:panelGroup>
<rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
...
</rich:dataTable>
</h:panelGroup>
<rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
...
</rich:dataScroller>
And the behaviour with 21 elements:
- on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
- rows: 10 (correct)
- first: 20 (weird)
Following calls to this method is setting those properties to:
- rows: 10 (correct)
- first: 10 (correct)
> rich:dataTable and rich:dataScroller inside h:panelGroup - doesn't display the correct number of rows when number of rows is updated
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RF-12289
> URL: https://issues.jboss.org/browse/RF-12289
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.2.1.Final, 4.2.2.Final, 4.3.5
> Reporter: Nicolas Daniels
> Fix For: 5-Tracking
>
> Attachments: another-reproducer.zip, richfaces-sandbox.zip, rich_dataTable-rows.png, test.jspx, TestFace.java
>
>
> Trying to have datascroller with dynamic rows number, but it works only if dataScroller is above the table.
> Basically, what I have is:
> {code}
> <h:selectOneMenu value="#{myBean.batchRows}">
> <f:selectItem itemLabel="10" itemValue="10"/>
> <f:selectItem itemLabel="20" itemValue="20"/>
> <f:ajax render="table table-ds" />
> </h:selectOneMenu>
> ...
> <h:panelGroup>
> <rich:dataTable id="table" rows="#{myBean.batchRows}" value="#{myBean.dataModel}" var="var">
> ...
> </rich:dataTable>
> </h:panelGroup>
> <rich:dataScroller id="table-ds" page="#{myBean.batchPage}" for="table" renderIfSinglePage="false" boundaryControls="hide" fastControls="hide">
> ...
> </rich:dataScroller>
> {code}
>
> And the behaviour with 21 elements:
> - on page 2 displaying 20 element (so only 1 is visible), if I switch to 10, I stay on page 2 but I still have only 1 element visible.
>
> If my datascroller is above my table it works fine. If the table is not wrapped within a panelGroup, it works as well.
>
> Debugging a bit, it seems that when UIDataAdaptor.walk method is 1st called, getComponentState() is updating the state rows and first properties with values:
> - rows: 10 (correct)
> - first: 20 (weird)
>
> Following calls to this method is setting those properties to:
> - rows: 10 (correct)
> - first: 10 (correct)
>
--
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
10 years, 2 months
[JBoss JIRA] (RF-12031) rich:validator does not work after re render (ajax)
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12031?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12031:
------------------------------------
[~michaelb80] would you please file a new issue for this? We'll have our QE team investigate and determine if this indeed a regression.
> rich:validator does not work after re render (ajax)
> ---------------------------------------------------
>
> Key: RF-12031
> URL: https://issues.jboss.org/browse/RF-12031
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.2.0.Final
> Environment: browsers: Firefox, Chrome
> Reporter: Andries Ehlers
> Assignee: Lukáš Fryč
> Priority: Minor
>
> When you have a simple inputText component with rich:validator inside, validation works perfectly when you move focus away from the component - validation messages display, e.g:
> {code:xml|borderStyle=solid}
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/>
> </h:inputText>
> <rich:message for="mytest1"/>
> {code}
> If the above code resides in a panel, which is conditionally rendered, then <rich:validator> ceases to function when you re-render the panel with ajax, eg:
> {code:xml|borderStyle=solid}
> <h:form id="dummyForm" prependId="false">
> <h:commandButton value="Toggle" actionListener="#{profileBean.toggleRender}">
> <f:ajax execute="@form" render="@form"/>
> </h:commandButton>
> <!--This will toggle on/off as you click the button above-->
> <h:panelGroup layout="block" rendered="#{profileBean.mustRenderThePanel}">
> <br/>
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/> <!--this fails to work when you move focus away -->
> </h:inputText>
> <rich:message for="mytest1"/>
> </h:panelGroup>
> </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
10 years, 2 months
[JBoss JIRA] (RF-12031) rich:validator does not work after re render (ajax)
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12031?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-12031 at 3/31/14 8:01 PM:
-------------------------------------------------------------
Currently we are facing the same issue using RF 4.3.5.
We tried the workaround as described here, but have a few problems we'd like to share.
For inputText adding:
{code}
<a4j:ajax event="blur" render="<input-id>" />
{code}
seems to work at first, but has some backdraws.
Adding this seems to produce 2 JS handlers to execute.The first one (onchange) fails due to the missing JS-function "av_....", while the other performs the validation correctly. (This can be verified when looking at the output of firebug for example.)
A bit ugly but somewhat OK. - However combining this workaround with <rich:focus preserve="true" /> inside the form leads to a validation error message showing for a moment and then disappearing again directly after. The validation message will only remain visible when defining the workaround with the additional limitRender="true" attribute and also adding the id of the message for this field to the render attribute.
Another problem is, that this workaround is only valid for inputText fields. Currently we are facing the same problem for example with the rich:calendar component having a rich:validator.
This is reproducable with the same configuration as shown in the description of this JIRA. - After the page was loaded via ajax re-render, perform a click on the select date button. Try to select a day. Normally the selected date is validated, the selector pop-up closes and the value is applied to the input field of the calendar. In this case the selector pop-up is not closed automatically. Again this problem is due to the missing JS-function "av_...." as can be seen also in firebug.
We've tried several of the ajax event handlers of the calendar component to find a similar workaround like the one for inputText, but with no success so far.
We still have to check that assumption, but I guess the same problem will occur for other field types like rich:select as well...
Our current project heavily relies on ajax re-rendering and using the rich:validator as bridge for client side validation and thus this issue is becoming a show-stopper for us.
Therefore, please re-open this issue! Any hint for finding a suitable workaround for other components besides inputText would also be greatly appreciated!
Update:
After a little more research I found an old JIRA from 2011
https://issues.jboss.org/browse/RF-10940
... as well as a discussion about what seems to be the problem
https://community.jboss.org/thread/171420
Since it looks as if the problem was fixed back then (?!) could this be re-appearing in RF 4.3.5 for some reason?
was (Author: michaelb80):
Currently we are facing the same issue using RF 4.3.5.
We tried the workaround as described here, but have a few problems we'd like to share.
For inputText adding
<a4j:ajax event="blur" render="<input-id>" />
seems to work at first, but has some backdraws.
Adding this seems to produce 2 JS handlers to execute.The first one (onchange) fails due to the missing JS-function "av_....", while the other performs the validation correctly. (This can be verified when looking at the output of firebug for example.)
A bit ugly but somewhat OK. - However combining this workaround with <rich:focus preserve="true" /> inside the form leads to a validation error message showing for a moment and then disappearing again directly after. The validation message will only remain visible when defining the workaround with the additional limitRender="true" attribute and also adding the id of the message for this field to the render attribute.
Another problem is, that this workaround is only valid for inputText fields. Currently we are facing the same problem for example with the rich:calendar component having a rich:validator.
This is reproducable with the same configuration as shown in the description of this JIRA. - After the page was loaded via ajax re-render, perform a click on the select date button. Try to select a day. Normally the selected date is validated, the selector pop-up closes and the value is applied to the input field of the calendar. In this case the selector pop-up is not closed automatically. Again this problem is due to the missing JS-function "av_...." as can be seen also in firebug.
We've tried several of the ajax event handlers of the calendar component to find a similar workaround like the one for inputText, but with no success so far.
We still have to check that assumption, but I guess the same problem will occur for other field types like rich:select as well...
Our current project heavily relies on ajax re-rendering and using the rich:validator as bridge for client side validation and thus this issue is becoming a show-stopper for us.
Therefore, please re-open this issue! Any hint for finding a suitable workaround for other components besides inputText would also be greatly appreciated!
Update:
After a little more research I found an old JIRA from 2011
https://issues.jboss.org/browse/RF-10940
... as well as a discussion about what seems to be the problem
https://community.jboss.org/thread/171420
Since it looks as if the problem was fixed back then (?!) could this be re-appearing in RF 4.3.5 for some reason?
> rich:validator does not work after re render (ajax)
> ---------------------------------------------------
>
> Key: RF-12031
> URL: https://issues.jboss.org/browse/RF-12031
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-validators
> Affects Versions: 4.2.0.Final
> Environment: browsers: Firefox, Chrome
> Reporter: Andries Ehlers
> Assignee: Lukáš Fryč
> Priority: Minor
>
> When you have a simple inputText component with rich:validator inside, validation works perfectly when you move focus away from the component - validation messages display, e.g:
> {code:xml|borderStyle=solid}
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/>
> </h:inputText>
> <rich:message for="mytest1"/>
> {code}
> If the above code resides in a panel, which is conditionally rendered, then <rich:validator> ceases to function when you re-render the panel with ajax, eg:
> {code:xml|borderStyle=solid}
> <h:form id="dummyForm" prependId="false">
> <h:commandButton value="Toggle" actionListener="#{profileBean.toggleRender}">
> <f:ajax execute="@form" render="@form"/>
> </h:commandButton>
> <!--This will toggle on/off as you click the button above-->
> <h:panelGroup layout="block" rendered="#{profileBean.mustRenderThePanel}">
> <br/>
> <h:inputText id="mytest1" value="#{profileBean.profileUser.firstName}">
> <rich:validator/> <!--this fails to work when you move focus away -->
> </h:inputText>
> <rich:message for="mytest1"/>
> </h:panelGroup>
> </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
10 years, 2 months