July 2012 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-12230) [CDK] c:foreach in a cast component will result on a List<Object> instead of List<UIComponent>

by Paul Dijou (JIRA)

Paul Dijou created RF-12230: ------------------------------- Summary: [CDK] c:foreach in a cast component will result on a List<Object> instead of List<UIComponent> Key: RF-12230 URL: https://issues.jboss.org/browse/RF-12230 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.1.Final Environment: All Reporter: Paul Dijou Look at the following code : {code:xml} <cdk:object type="javax.faces.component.UIComponent" name="prependFacet" value="#{component.getFacet('prepend')}"/> <c:choose> <c:when test="#{prependFacet.family eq 'javax.faces.Panel'}"> <c:forEach var="child" items="#{component.getFacet('prepend').getChildren()}"> {code} I'm using a {{<cdk:object>}} to assign my facet to a var. Then I make some test and finally, I want to iterate over the children of my facet. This will result on this Java code on the renderer : {code:java} UIComponent prependFacet = component.getFacet("prepend"); if (isEqual(prependFacet.getFamily(),"javax.faces.Panel")) { for (UIComponent child: component.getFacet("prepend").getChildren()) { {code} That's perfect! But now, since I have a var for my facet, why not using it in the {{<c:forEach>}}? Seems natural. So I change my code to : {code:xml} <cdk:object type="javax.faces.component.UIComponent" name="prependFacet" value="#{component.getFacet('prepend')}"/> <c:choose> <c:when test="#{prependFacet.family eq 'javax.faces.Panel'}"> <c:forEach var="child" items="#{prependFacet.getChildren()}"> {code} Only the last line is different from the previous one. What does the generated Java code looks like? That: {code:java} UIComponent prependFacet = component.getFacet("prepend"); if (isEqual(prependFacet.getFamily(),"javax.faces.Panel")) { for (Object child: prependFacet.getChildren()) { {code} Whaaaaat?! Why is it a "Object" in the "for" loop and not a "UIComponent" anymore? Of course, the component is now broken since I'm calling {{UIComponent}} methods inside the loop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
5
0 / 0

[JBoss JIRA] (RF-12231) [CDK] EL empty method doesn't work for Collection

by Paul Dijou (JIRA)

Paul Dijou created RF-12231: ------------------------------- Summary: [CDK] EL empty method doesn't work for Collection Key: RF-12231 URL: https://issues.jboss.org/browse/RF-12231 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.1.Final Environment: All Reporter: Paul Dijou Let's say I want to test if a component doesn't have any children. I write thise code : {code:xml} <c:if test="#{empty(component.getChildren())}">No children!</c:if> {code} Seems logic, right? If the List is empty, then it means there is no children. The generated Java code is the following : {code:java} if (isEmpty(component.getChildren())) { responseWriter.writeText("No children!",null); } {code} And the "isEmpty" method : {code:java} private static boolean isEmpty(Object object) { return object == null || object.toString().length() == 0; } {code} This method will *always* returns {{false}}, even if the list is empty. Why? Because the list will not be null and an empty list toString() renders "{{[]}}", so "{{object.toString().length()}}" will be eval to "2", which is different from "0". So based on these test, the component will *always* have children. The "isEmpty" method should adapt its test depending on the type of object. It's an instance of Collection, calling "isEmpty()" is probably better. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
5
0 / 0

[JBoss JIRA] (RF-12248) CDK: Auto-casting #{component} inside the encodeBegin / encodeEnd methods

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12248: ------------------------------- Summary: CDK: Auto-casting #{component} inside the encodeBegin / encodeEnd methods Key: RF-12248 URL: https://issues.jboss.org/browse/RF-12248 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.0.Final Reporter: Paul Dijou -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
10
0 / 0

[JBoss JIRA] (RF-12232) [CDK] Support "varStatus" attribute on c:forEach

by Paul Dijou (JIRA)

Paul Dijou created RF-12232: ------------------------------- Summary: [CDK] Support "varStatus" attribute on c:forEach Key: RF-12232 URL: https://issues.jboss.org/browse/RF-12232 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.1.Final Environment: All Reporter: Paul Dijou Right now, when using {{<c:forEach>}} tag on a CDK template.xml, you will have a "for" loop in Java code. There is no way to do simple logic in the template like knowing your current index inside the loop, etc... An idea would be to support the {{varStatus}} attribute from the original {{<c:forEach>}}. This attribute maps to the name of a bean which contains util methods and evolve at each iteration of the loop. Here is a sample: {code:xml} <c:forEach var="child" items="#{component.getChildren()}" varStatus="status"> // Inside code </c:forEach> {code} Would generate something like: {code:java} LoopTagStatus status = new LoopTagStatus(); for(UIComponent child : component.getChildren()) { // Inside code status.next(); } {code} The javadoc of the original {{LoopTagStatus}} from JSTL is [here|http://docs.oracle.com/javaee/5/jstl/1.1/docs/api/javax/servlet/jsp/...]. Our LoopTagStatus would have the method and one more : the {{next()}} method. This one would increment the current index of the LoopTagStatus in order to be updated for the next iteration. We could also add any other usefull methods to this bean. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
7
0 / 0

[JBoss JIRA] (RF-12249) CDK: generates both get* and is* methods for boolean/Boolean expressions

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12249: ------------------------------- Summary: CDK: generates both get* and is* methods for boolean/Boolean expressions Key: RF-12249 URL: https://issues.jboss.org/browse/RF-12249 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.0.Final Reporter: Paul Dijou Generate both "get..." and "is..." method for Boolean and boolean attributes If you have an attribute like : {code:java} @Attribute abstract public boolean isClosable(); {code} This will generate a "isClosable()" method of course. But, then, trying to access it in a template like : {code:xml} <c:if test="#{alert.closable}"> {code} Will crash since JSF try to call the "getClosable()" method. The workaround is to write : {code:xml} <c:if test="#{alert.isClosable()}"> {code} But it would be nicer if the "geClosable()" method was generated in the same time of the "isClosable()" method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
13
0 / 0

[JBoss JIRA] (RF-12260) Support for cdk:renderFacet

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12260: ------------------------------- Summary: Support for cdk:renderFacet Key: RF-12260 URL: https://issues.jboss.org/browse/RF-12260 Project: RichFaces Issue Type: Feature Request Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.0.Final Reporter: Brian Leathem Support to render the facet content directly, similarly to {{cdk:body}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
12
0 / 0

[JBoss JIRA] (RF-12261) CDK: fix scanning for interfaces

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12261: ------------------------------- Summary: CDK: fix scanning for interfaces Key: RF-12261 URL: https://issues.jboss.org/browse/RF-12261 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.0.Final Reporter: Lukáš Fryč All the component definitions should be possible by inheritance (instead of using properties files). That means use inheritance to bring all {{@Attribute}} definitions to components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
11
0 / 0

[JBoss JIRA] (RF-12266) progressBar: CSS contains text-color and color

by Christophe Roussy (JIRA)

Christophe Roussy created RF-12266: -------------------------------------- Summary: progressBar: CSS contains text-color and color Key: RF-12266 URL: https://issues.jboss.org/browse/RF-12266 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-misc Affects Versions: 4.2.1.Final Environment: Firefox, Windows Reporter: Christophe Roussy text-color in progressbar css, is this standard css ? *.rf-pb-rmng { height: 13px; white-space: nowrap; width: 200px; position: relative; border-width: 1px; border-style: solid; border-color: #C4C0B9; border-radius: 0px; overflow: hidden; color: #000000; font-family: Arial, Verdana, sans-serif ; font-size: 11px; font-weight: bold; text-color: #000000; background-color: #ffffff; padding: 0px; } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

4
6
0 / 0

[JBoss JIRA] (RF-12317) maven-cdk-plugin: two phase source compilation needed for consuming projects to determine types during CDK build

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12317: ------------------------------- Summary: maven-cdk-plugin: two phase source compilation needed for consuming projects to determine types during CDK build Key: RF-12317 URL: https://issues.jboss.org/browse/RF-12317 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Lukáš Fryč With current setup of UI builds, CDK features * {{component-base-class}} * {{<cdk:object />}} or {{<c:forEach />}} can't properly determine the type of component (if not explicitly defined), since the type is not known in the time of the CDK generation step. See following log: {code} ~/cdk/test-component$ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building RichFaces CDK: Test Component 4.3.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ ... [INFO] --- maven-cdk-plugin:4.3.0-SNAPSHOT:generate (cdk-generate-sources) @ cdk-test-component --- [WARNING] Could not determine if the renderer-base-class extends org.richfaces.renderkit.RendererBase: org.richfaces.renderkit.TestComponentRendererBase [INFO] Cannot determine the type of org.richfaces.cdk.templatecompiler.el.types.ReferencedType: org.richfaces.renderkit.TestComponentRendererBase, it will be treated as generic Object. [INFO] The <foreach> expression #{msgs} is not array, Iterable nor Iterator. It will be treated as single object. ... [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ cdk-test-component --- [INFO] Compiling 5 source files to /home/lfryc/workspaces/richfaces/cdk/test-component/target/classes ... {code} Give attention especially to following part: {code} [WARNING] Could not determine if the renderer-base-class extends org.richfaces.renderkit.RendererBase: org.richfaces.renderkit.TestComponentRendererBase [INFO] Cannot determine the type of org.richfaces.cdk.templatecompiler.el.types.ReferencedType: org.richfaces.renderkit.TestComponentRendererBase, it will be treated as generic Object. {code} It says {{TestComponentRendererBase}} type cannot be determined, which basically means {{Class.forName(...)}} fails even though the project's {{target/classes}} directory is on classpath. Then note the compilation of sources ({{maven-compiler-plugin}}) is done after the CDK generation, which is the root cause of this problem. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
5
0 / 0

[JBoss JIRA] (RF-12318) CDK Generator: can't determine return/parameter types of methods for "this" object

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12318: ------------------------------- Summary: CDK Generator: can't determine return/parameter types of methods for "this" object Key: RF-12318 URL: https://issues.jboss.org/browse/RF-12318 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.0.Final Reporter: Lukáš Fryč Assignee: Lukáš Fryč Fix For: 4.3.0.Milestone1 $SUBJ$, since class of "this" is unknown at the time of generation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues July 2012