[JBoss JIRA] Created: (RF-8210) switchType=ajax on modalPanel
by Gonzalez Adrian (JIRA)
switchType=ajax on modalPanel
-----------------------------
Key: RF-8210
URL: https://jira.jboss.org/jira/browse/RF-8210
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Gonzalez Adrian
Lately, I'm mostly (80% of times) rendering my rich:modalPanels in ajax mode [1] :
- a4j:commandButton calls a backing bean method, and rerenders the a4j:outputPanel surrounding rich;modalPanel.
oncomplete js handler call Richfaces.showPanel.
- the rich:modalPanel is inside a a4j:outputPanel nd its rendered attribute points to a backing bean property.
This is because each modalPanels weights more or less 5 ko (I've seen 4 different application and it was always at least 5 ko).
This code is repetitive.
Could it be possible to add a switchType (or mode) attribute on rich:calendar, the meaning of which would be :
1. if switchType=client, behaviour unchanged.
2. if switchType=ajax, Richfaces.showModal would make an ajax call, rerender the rich:modalPanel (so rich:modalPanel would always be contained in an invisible <span> or shting like this) and show it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (RF-6026) PickList doesn't accept comma in string value of SelectItem
by Andrzej Haczewski (JIRA)
PickList doesn't accept comma in string value of SelectItem
-----------------------------------------------------------
Key: RF-6026
URL: https://jira.jboss.org/jira/browse/RF-6026
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.3.0
Environment: WebLogic 10, JSF 1.2, RichFaces 3.3.0, Hibernate JPA, Facelets 1.1.14
Reporter: Andrzej Haczewski
When you use a List<SelectItem> where SelectItems are created like this:
new SelectItem("SOME STRING,CONTAINING COMMA", "A nice string to show in list")
as a PickList <h:selectItems>, and use List<String> as PickList value, then PickList doesn't validate when you add that item to target list.
The reason is that UISelectMany is trying to validate values "SOME STRINGS" and "CONTAINING COMMA" with available items.
The exact point is the UISelectMany.matchValue() method, which returns false on validation of that PickList.
Sample code:
--- BackingBean.java
class BackingBean {
private List<SelectItem> picklistItems;
private List<String> result;
public BackingBean() {
picklistItems = new ArrayList<SelectItem>();
picklistItems.add(new SelectItem("SAMPLE,EXAMPLE", "Sample example"));
}
// then comes getters and setters for picklistItems and result
}
--- PickList.xhtml
<rich:pickList value="#{backingBean.result}">
<h:selectItems value="#{backingBean.picklistItems}">
</rich:pickList>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (RF-7351) Regression: "messages: globalOnly does not work properly"
by Joseph Miller (JIRA)
Regression: "messages: globalOnly does not work properly"
---------------------------------------------------------
Key: RF-7351
URL: https://jira.jboss.org/jira/browse/RF-7351
Project: RichFaces
Issue Type: Bug
Components: component, regression
Affects Versions: 3.3.1
Environment: Windows / JBoss 4.2.2.GA / Seam 2.1.1.GA / RichFaces 3.3.1.GA
Reporter: Joseph Miller
Looks like a regression of RF-615... I've upgraded my Seam project to sue RF 3.3.1, in order to fix a number of other bugs, but now messages intended for a single UI component (via the for= ) are appearing in the global messages list at the top of my page.
My page template has:
<rich:messages globalOnly="true" id="page-messages">
...
</rich:messages>
and the controls have:
<rich:message for="my-control-id" id="my-control-id-message">
...
</rich:message>
I can switch the rich:messages to h:messages, and it behaves as it should. Also reverting back to the RichFaces 3.2.2.SR1 jars makes the problem go away, but I get the other older bugs back :(
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (RF-9345) Richfaces HTTP Header Cache-Control settings, need 'public'
by igor regis (JIRA)
Richfaces HTTP Header Cache-Control settings, need 'public'
-----------------------------------------------------------
Key: RF-9345
URL: https://jira.jboss.org/browse/RF-9345
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: performance
Affects Versions: 3.3.3.Final, 3.3.3.CR1, 3.3.3.BETA1, 3.3.2.SR1, 3.3.2.GA, 3.3.2.CR1, 3.3.1
Environment: This issue affect any web browser according to w3c specification
Reporter: igor regis
If an application is running over https the web browser will only cache on disk, the Richfaces resources, if and only if, the Cache-control header (present on http header) has the value "public" on it. Otherwise the web browser will perform in memory cache, so when user restarts the browser the application will need to request all the resources again.
For applications running on corporative network, manipulating sensitive information, it's mandatory the use of a secure connection through https protocol, and form better performance is necessary for Richfaces to provide it's resources with this "public" mark on cache-control tag.
According the w3c specs (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1) Richfaces resources may be classified as public content with non individual information.
Here (https://community.jboss.org/thread/150732?tstart=0) there is a discussion about this issue, as well as the point on Richfaces source code that need to be changed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (RF-7955) ExtendedDataTable : Only first column correctly resize
by Nicolas Gaudin (JIRA)
ExtendedDataTable : Only first column correctly resize
------------------------------------------------------
Key: RF-7955
URL: https://jira.jboss.org/jira/browse/RF-7955
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.3.2.GA, 3.3.2.CR1
Environment: JSF RI 1.2_13
Facelets 1.1.14 (with .jspx files)
Glassfish
Jdk 1.6
Reporter: Nicolas Gaudin
Fix For: 3.3.2.GA
Hi,
During my test to deliver, I discovered that the columns of all my EDTs would not resize correctly.
More precisely, the first column resizes without any problem but the others resize WITHOUT resizing the header.
I must mention that my EDT use value binding for dynamic column creation.
My actions that generated this issue:
- moved from jsp to facelets (with jspx extension)
- upgraded to JSF 1.2_13
This affected 3.3.2.CR1, the version I was using.
I then upgraded to 3.3.2.GA to check if this would fix but no luck
Also, I thought that 3.3.2.GA would full scrolling support for EDT (horizontal mainly)
Is that the case?
Could you please confirm?
May thanks in advance
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months