[jira] Commented: (TRINIDAD-1689) New Trinidad Default Skin - Casablanca
[ https://issues.apache.org/jira/browse/TRINIDAD-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829002#action_12829002 ] Catalin Kormos commented on TRINIDAD-1689: -- There are still a few issues open with the new skin which need work, please report any you find in Jira. New Trinidad Default Skin - Casablanca -- Key: TRINIDAD-1689 URL: https://issues.apache.org/jira/browse/TRINIDAD-1689 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Affects Versions: 1.2.14-core Reporter: Adonis Raul Raduca Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: casablanca.zip, casablancaIntegration.patch, trinidadAdaptation.patch A new more modern skin with a nice-minimalist look. Also a simple and intuitive way to skin Trinidad components using Casablanca selectors stack. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2526) javax.faces.view.facelets.ResourceResolver support
[ https://issues.apache.org/jira/browse/MYFACES-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829012#action_12829012 ] Michael Kurz commented on MYFACES-2526: --- Please see additional patch for fixes. javax.faces.view.facelets.ResourceResolver support -- Key: MYFACES-2526 URL: https://issues.apache.org/jira/browse/MYFACES-2526 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: myfaces core trunk Reporter: Martin Koci Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MYFACES-2526-2.patch, patch.MYFACES-2526 Currently DefaultResourceResolver in myfaces implements a interface ResourceResolver from o.a.m.v.f.i (probably copy from old facelts 1.x). JSF 2.0 introduce javax.faces.view.facelets.ResourceResolver as base class for all ResourceResolvers. Specification 11.1.3 Application Configuration Parameters describes it. Make ResourceResolver from o.a.m.v.f.i deprecated (or delete it) and modify facelts stuff for using javax.faces ResourceResolver + add support for decorator pattern. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2526) javax.faces.view.facelets.ResourceResolver support
[ https://issues.apache.org/jira/browse/MYFACES-2526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829030#action_12829030 ] Martin Koci commented on MYFACES-2526: -- Oh, I didn't have src/test/java on build path (I don't really know why) so I omitted that. Sorry for the oversight. javax.faces.view.facelets.ResourceResolver support -- Key: MYFACES-2526 URL: https://issues.apache.org/jira/browse/MYFACES-2526 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: myfaces core trunk Reporter: Martin Koci Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MYFACES-2526-2.patch, patch.MYFACES-2526 Currently DefaultResourceResolver in myfaces implements a interface ResourceResolver from o.a.m.v.f.i (probably copy from old facelts 1.x). JSF 2.0 introduce javax.faces.view.facelets.ResourceResolver as base class for all ResourceResolvers. Specification 11.1.3 Application Configuration Parameters describes it. Make ResourceResolver from o.a.m.v.f.i deprecated (or delete it) and modify facelts stuff for using javax.faces ResourceResolver + add support for decorator pattern. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2529) use of view-param in faces-config causes a NoSuchMethodExcepion for addViewParam
use of view-param in faces-config causes a NoSuchMethodExcepion for addViewParam Key: MYFACES-2529 URL: https://issues.apache.org/jira/browse/MYFACES-2529 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.0-beta Reporter: Marcus Büttner use of view-param in faces-config causes a NoSuchMethodExcepion for addViewParam I think the error occurs because of config in DigesterFacesConfigUnmarshallerImpl.java at the following lines: digester.addObjectCreate(faces-config/navigation-rule/navigation-case/redirect, Redirect.class); digester.addSetNext(faces-config/navigation-rule/navigation-case/redirect, setRedirect); digester.addSetNext(faces-config/navigation-rule/navigation-case/redirect/view-param, addViewParam); digester.addCallMethod(faces-config/navigation-rule/navigation-case/redirect/include-view-params, setIncludeViewParams, 0); digester.addObjectCreate(faces-config/navigation-rule/navigation-case/redirect/view-param, ViewParam.class); digester.addSetNext(faces-config/navigation-rule/navigation-case/redirect/view-param, addViewParam); In my opionen the first addViewParam lines should be deleted and the ViewParam.class config should be before setIncludeViewParams. It could looks like this: digester.addObjectCreate(faces-config/navigation-rule/navigation-case/redirect, Redirect.class); digester.addSetNext(faces-config/navigation-rule/navigation-case/redirect, setRedirect); digester.addObjectCreate(faces-config/navigation-rule/navigation-case/redirect/view-param, ViewParam.class); digester.addCallMethod(faces-config/navigation-rule/navigation-case/redirect/include-view-params, setIncludeViewParams, 0); digester.addSetNext(faces-config/navigation-rule/navigation-case/redirect/view-param, addViewParam); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2508) Miscellaneous CTS fixes
[ https://issues.apache.org/jira/browse/MYFACES-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829045#action_12829045 ] Curtiss Howard commented on MYFACES-2508: - Fixed CTS testcase jsf/spec/resource/relocatable/URLClient_relocatableFormTest: Resource tags such as h:outputScript can target the head, form, or body. The code for head and body were there, but the form code was missing. Miscellaneous CTS fixes --- Key: MYFACES-2508 URL: https://issues.apache.org/jira/browse/MYFACES-2508 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Curtiss Howard This issue will be used to fix problems identified by CTS testing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1488) Convert example pages from JSP to Facelets
Convert example pages from JSP to Facelets -- Key: TOMAHAWK-1488 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1488 Project: MyFaces Tomahawk Issue Type: Task Components: Examples Affects Versions: 1.1.10-SNAPSHOT Reporter: Ingo Hofmann Attachments: Converted_JSPs_to_Facelets.patch Convert all JSP pages from new sub module myfaces-example-simple20 to Facelets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ExtVal] backward compatibility
hi @ all, the review phase for the next extval release (r3) has been started already. one important topic is backward compatibility. the 3rd release will be a major version. besides a lot of new features r3 will be the first version which offers bean-validation integration for all jsf versions. i created an upgrade guide [1] for collecting changes which aren't backward compatible. currently there are just very few changes in the property-validation module which are easy to fix. since r3 will be a major release and i know many people who started with the current milestone and not the previous version, i think we can take the chance for further restructurings in the validation modules. what's about the following suggestion? i would like to introduce a new package which is suggested for every validation module for shared/common stuff. the name is e.g. module and in case of the property-validation module it would be interesting to move some classes to this package. property-validation module: org.apache.myfaces.extensions.validator.module.property [new] |_ PropertyValidationModuleKey [new] |_ PropertyValidationSkipValidationEvaluator [new] |_ annotation ||_ JoinValidation [moved] ||_ SkipValidation [moved] ||_ SkipValidationSupport [moved] |__ initializer.component [new] ||_ HtmlCoreComponentsComponentInitializer [moved] |__ interceptor [new] | |_ PropertyValidationInterceptor [moved] |__ startup [new] | |_ PropertyValidationModuleStartupListener [moved] |__ storage [new] |__ mapper [new] ||__ PropertyValidationGroupStorageNameMapper [new] |__ JoinValidationMetaDataStorageFilter [new] most of the stuff is new or internal - so we don't really have an issue here. however, esp. JoinValidation, SkipValidation and SkipValidationSupport are not new and part of the api. if we move these annotations (because they are used in base- as well as in cross-validation), users have to fix some import statements. since these annotations aren't used extremely often it does not lead to a huge effort. to be consistent we would have the same package concept in the bean-validation module as well (org.apache.myfaces.extensions.validator.module.bean). in this case we don't have an issue because the module is completely new. since it is a major release (imo) the impact is minimal and should be ok. if there is no veto, i'll do the mentioned refactoring. (for sure - i'll also create a jira issue.) regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [ExtVal] backward compatibility
Hi Gerhard, As a user of libraries, I generally don't like refactorings. I do like it to upgrade to the last version by only dropping in a new Jar and not having to change any code. However, I do understand that refactorings are needed sometimes. And with a good IDE, changing the imports shouldn't be that hard. Having said that, I agree that it is a good idea to align the structure of the validation modules with the structure of the core. I also agree that now is a good time to make this change. Best regards, Bart Kummel On Wed, Feb 3, 2010 at 14:49, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi @ all, the review phase for the next extval release (r3) has been started already. one important topic is backward compatibility. the 3rd release will be a major version. besides a lot of new features r3 will be the first version which offers bean-validation integration for all jsf versions. i created an upgrade guide [1] for collecting changes which aren't backward compatible. currently there are just very few changes in the property-validation module which are easy to fix. since r3 will be a major release and i know many people who started with the current milestone and not the previous version, i think we can take the chance for further restructurings in the validation modules. what's about the following suggestion? i would like to introduce a new package which is suggested for every validation module for shared/common stuff. the name is e.g. module and in case of the property-validation module it would be interesting to move some classes to this package. property-validation module: org.apache.myfaces.extensions.validator.module.property [new] |_ PropertyValidationModuleKey [new] |_ PropertyValidationSkipValidationEvaluator [new] |_ annotation ||_ JoinValidation [moved] ||_ SkipValidation [moved] ||_ SkipValidationSupport [moved] |__ initializer.component [new] ||_ HtmlCoreComponentsComponentInitializer [moved] |__ interceptor [new] | |_ PropertyValidationInterceptor [moved] |__ startup [new] | |_ PropertyValidationModuleStartupListener [moved] |__ storage [new] |__ mapper [new] ||__ PropertyValidationGroupStorageNameMapper [new] |__ JoinValidationMetaDataStorageFilter [new] most of the stuff is new or internal - so we don't really have an issue here. however, esp. JoinValidation, SkipValidation and SkipValidationSupport are not new and part of the api. if we move these annotations (because they are used in base- as well as in cross-validation), users have to fix some import statements. since these annotations aren't used extremely often it does not lead to a huge effort. to be consistent we would have the same package concept in the bean-validation module as well (org.apache.myfaces.extensions.validator.module.bean). in this case we don't have an issue because the module is completely new. since it is a major release (imo) the impact is minimal and should be ok. if there is no veto, i'll do the mentioned refactoring. (for sure - i'll also create a jira issue.) regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [ExtVal] backward compatibility
Hi Gerhard, +1 but maybe a few remarks - When the refactorings are only cosmetic (like here, there is a better grouping of functional alike classes), the user of the library hasn't much benefit from it. And thus doesn't like it very much. - By moving the annotation (JoinValidation, SkipValidation), the strategy must be moved along, no ? - JoinValidationStrategy is marked deprecated, (commit related to EXTVAL-59 and EXTVAL-60, don't see the immediate link between the deprecated and the issue, but anyway) - So skipValidation is the only x.x.2 moved file, together with the CrossValidationStorageEntry indicated on the upgrade guide. - Moving classes between packages is seen during compile time of the project. So, although not pleasant for the user, it is more visible then the functional changes of the @Length and the @Pattern. So only one 'feature' skipValidation impacted and already done other similar things, so +1 regards, Rudy On 3 February 2010 14:49, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi @ all, the review phase for the next extval release (r3) has been started already. one important topic is backward compatibility. the 3rd release will be a major version. besides a lot of new features r3 will be the first version which offers bean-validation integration for all jsf versions. i created an upgrade guide [1] for collecting changes which aren't backward compatible. currently there are just very few changes in the property-validation module which are easy to fix. since r3 will be a major release and i know many people who started with the current milestone and not the previous version, i think we can take the chance for further restructurings in the validation modules. what's about the following suggestion? i would like to introduce a new package which is suggested for every validation module for shared/common stuff. the name is e.g. module and in case of the property-validation module it would be interesting to move some classes to this package. property-validation module: org.apache.myfaces.extensions.validator.module.property [new] |_ PropertyValidationModuleKey [new] |_ PropertyValidationSkipValidationEvaluator [new] |_ annotation ||_ JoinValidation [moved] ||_ SkipValidation [moved] ||_ SkipValidationSupport [moved] |__ initializer.component [new] ||_ HtmlCoreComponentsComponentInitializer [moved] |__ interceptor [new] | |_ PropertyValidationInterceptor [moved] |__ startup [new] | |_ PropertyValidationModuleStartupListener [moved] |__ storage [new] |__ mapper [new] ||__ PropertyValidationGroupStorageNameMapper [new] |__ JoinValidationMetaDataStorageFilter [new] most of the stuff is new or internal - so we don't really have an issue here. however, esp. JoinValidation, SkipValidation and SkipValidationSupport are not new and part of the api. if we move these annotations (because they are used in base- as well as in cross-validation), users have to fix some import statements. since these annotations aren't used extremely often it does not lead to a huge effort. to be consistent we would have the same package concept in the bean-validation module as well (org.apache.myfaces.extensions.validator.module.bean). in this case we don't have an issue because the module is completely new. since it is a major release (imo) the impact is minimal and should be ok. if there is no veto, i'll do the mentioned refactoring. (for sure - i'll also create a jira issue.) regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [ExtVal] backward compatibility
hi rudy, in case of SkipValidationStrategy you are right - it has to be moved as well. JoinValidationStrategy will be removed after some final tests. (it was replaced by JoinValidationMetaDataStorageFilter which is based on the new storage concept and offers a better performance.) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/2/3 Rudy De Busscher rdebussc...@gmail.com Hi Gerhard, +1 but maybe a few remarks - When the refactorings are only cosmetic (like here, there is a better grouping of functional alike classes), the user of the library hasn't much benefit from it. And thus doesn't like it very much. - By moving the annotation (JoinValidation, SkipValidation), the strategy must be moved along, no ? - JoinValidationStrategy is marked deprecated, (commit related to EXTVAL-59 and EXTVAL-60, don't see the immediate link between the deprecated and the issue, but anyway) - So skipValidation is the only x.x.2 moved file, together with the CrossValidationStorageEntry indicated on the upgrade guide. - Moving classes between packages is seen during compile time of the project. So, although not pleasant for the user, it is more visible then the functional changes of the @Length and the @Pattern. So only one 'feature' skipValidation impacted and already done other similar things, so +1 regards, Rudy On 3 February 2010 14:49, Gerhard Petracek gerhard.petra...@gmail.comwrote: hi @ all, the review phase for the next extval release (r3) has been started already. one important topic is backward compatibility. the 3rd release will be a major version. besides a lot of new features r3 will be the first version which offers bean-validation integration for all jsf versions. i created an upgrade guide [1] for collecting changes which aren't backward compatible. currently there are just very few changes in the property-validation module which are easy to fix. since r3 will be a major release and i know many people who started with the current milestone and not the previous version, i think we can take the chance for further restructurings in the validation modules. what's about the following suggestion? i would like to introduce a new package which is suggested for every validation module for shared/common stuff. the name is e.g. module and in case of the property-validation module it would be interesting to move some classes to this package. property-validation module: org.apache.myfaces.extensions.validator.module.property [new] |_ PropertyValidationModuleKey [new] |_ PropertyValidationSkipValidationEvaluator [new] |_ annotation ||_ JoinValidation [moved] ||_ SkipValidation [moved] ||_ SkipValidationSupport [moved] |__ initializer.component [new] ||_ HtmlCoreComponentsComponentInitializer [moved] |__ interceptor [new] | |_ PropertyValidationInterceptor [moved] |__ startup [new] | |_ PropertyValidationModuleStartupListener [moved] |__ storage [new] |__ mapper [new] ||__ PropertyValidationGroupStorageNameMapper [new] |__ JoinValidationMetaDataStorageFilter [new] most of the stuff is new or internal - so we don't really have an issue here. however, esp. JoinValidation, SkipValidation and SkipValidationSupport are not new and part of the api. if we move these annotations (because they are used in base- as well as in cross-validation), users have to fix some import statements. since these annotations aren't used extremely often it does not lead to a huge effort. to be consistent we would have the same package concept in the bean-validation module as well (org.apache.myfaces.extensions.validator.module.bean). in this case we don't have an issue because the module is completely new. since it is a major release (imo) the impact is minimal and should be ok. if there is no veto, i'll do the mentioned refactoring. (for sure - i'll also create a jira issue.) regards, gerhard [1] http://wiki.apache.org/myfaces/Extensions/Validator/Versions/Versions/UpgradeGuide http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-1705) Refactor Trinidad's JavaScript under a namespace and remove all global functions
Refactor Trinidad's JavaScript under a namespace and remove all global functions Key: TRINIDAD-1705 URL: https://issues.apache.org/jira/browse/TRINIDAD-1705 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.13-core Reporter: Andrew Robinson Trinidad's JavaScript is hard to work with, there are many global functions that could cause collisions with other javascript libraries and the files are not named in such a way that makes maintenance easy (finding where code can be found). It would be nice to have a global Trinadad object (or just Tr if we can get away with it) with all the objects under it much in the same way JSF 2 has done jsf and jsf.ajax. Just looking at Core.js one can see the vast number of global variables -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (EXTVAL-79) deactivate required initialization via web.xml context parameter
[ https://issues.apache.org/jira/browse/EXTVAL-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek reopened EXTVAL-79: Assignee: Gerhard Petracek deactivate required initialization via web.xml context parameter Key: EXTVAL-79 URL: https://issues.apache.org/jira/browse/EXTVAL-79 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Bean Validation, Core, Property Validation Affects Versions: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT Reporter: Gerhard Petracek Assignee: Gerhard Petracek Priority: Minor Fix For: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT required initialization is useful in case of component libs like trinidad. due to several dynamic features the next version of extval isn't compatible with the required attribute (within pages). if there is no benefit from using metadata based required initialization, it's possible to deactivate it to get back the compatibility with the required attribute within pages. web.xml: context-param param-nameorg.apache.myfaces.extensions.validator.DEACTIVATE_REQUIRED_INITIALIZATION/param-name param-valuetrue/param-value /context-param -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (EXTVAL-79) activate required initialization
[ https://issues.apache.org/jira/browse/EXTVAL-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTVAL-79. Resolution: Fixed activate required initialization Key: EXTVAL-79 URL: https://issues.apache.org/jira/browse/EXTVAL-79 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Bean Validation, Core, Property Validation Affects Versions: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT Reporter: Gerhard Petracek Assignee: Gerhard Petracek Priority: Minor Fix For: 1.2.3-SNAPSHOT, 2.0.3-SNAPSHOT, 1.1.3-SNAPSHOT required initialization is useful in case of component libs like trinidad. by default it's deactivated to avoid issues in combination with dynamic meta-data and severity aware validation. so it's required to activate it manually via web.xml: context-param param-nameorg.apache.myfaces.extensions.validator.ACTIVATE_REQUIRED_INITIALIZATION/param-name param-valuetrue/param-value /context-param or within an extval startup listener: ... ExtValContext.getContext().addGlobalProperty(init:required, Boolean.TRUE); ... *** with trinidad *** if you are using the trinidad support module it gets activated automatically. so the required attribute of input components (used within pages) will be ignored. if you don't need features like severity aware validation, you can re-introduce the support for the required attribute via: web.xml: context-param param-nameorg.apache.myfaces.extensions.validator.ACTIVATE_REQUIRED_INITIALIZATION/param-name param-valuefalse/param-value /context-param or a custom add-on -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2530) ActionSourceRule does not deal with jsf 1.1 ActionSouce instances
ActionSourceRule does not deal with jsf 1.1 ActionSouce instances - Key: MYFACES-2530 URL: https://issues.apache.org/jira/browse/MYFACES-2530 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe The code dealing with this was removed, but could be custom component instances extending from ActionSource instead ActionSource2, so to keep them compatible it is better to rollback the previous code (without the check el stuff). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2530) ActionSourceRule does not deal with jsf 1.1 ActionSouce instances
[ https://issues.apache.org/jira/browse/MYFACES-2530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2530. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 ActionSourceRule does not deal with jsf 1.1 ActionSouce instances - Key: MYFACES-2530 URL: https://issues.apache.org/jira/browse/MYFACES-2530 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 The code dealing with this was removed, but could be custom component instances extending from ActionSource instead ActionSource2, so to keep them compatible it is better to rollback the previous code (without the check el stuff). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1487) ClassCastException when rendering HtmlDataScroller with core 2.0
[ https://issues.apache.org/jira/browse/TOMAHAWK-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1487. -- Resolution: Fixed Fix Version/s: 1.1.10-SNAPSHOT Assignee: Leonardo Uribe I changed a little bit the solution, because action param is not used by the scroller. Thanks to Ingo Hofmann for provide this patch. ClassCastException when rendering HtmlDataScroller with core 2.0 Key: TOMAHAWK-1487 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1487 Project: MyFaces Tomahawk Issue Type: Bug Components: Data Scroller Affects Versions: 1.1.10-SNAPSHOT Reporter: Ingo Hofmann Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT Attachments: ActionSourceRule_should_deal_with_both_ActionSource_and_ActionSource2.patch, HtmlDataScroller_as_ActionSource2.patch Using tomahawk20's HtmlDataScroller produces following exception: java.lang.ClassCastException: org.apache.myfaces.custom.datascroller.HtmlDataScroller cannot be cast to javax.faces.component.ActionSource2 at org.apache.myfaces.view.facelets.tag.jsf.ActionSourceRule$ActionMapper2.applyMetadata(ActionSourceRule.java:55) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
[
https://issues.apache.org/jira/browse/TOMAHAWK-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1485.
--
Resolution: Not A Problem
Assignee: Leonardo Uribe
t:dataList iterate over a list without check for rendered property on the
component. The fact that the component is not rendered does not means that the
value is skipped. t:dataList works as expected.
t:dataList should not render li element when iterated element is not
rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9,
commons-el 1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging
1.1.1
Reporter: Bauke Scholtz
Assignee: Leonardo Uribe
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1706) Trinidad components showcase demo app doesn't include java sources in packaged war
[ https://issues.apache.org/jira/browse/TRINIDAD-1706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Catalin Kormos resolved TRINIDAD-1706. -- Resolution: Fixed Fix Version/s: 1.2.14-core Trinidad components showcase demo app doesn't include java sources in packaged war -- Key: TRINIDAD-1706 URL: https://issues.apache.org/jira/browse/TRINIDAD-1706 Project: MyFaces Trinidad Issue Type: Improvement Components: Build Affects Versions: 1.2.14-core Reporter: Catalin Kormos Assignee: Catalin Kormos Priority: Minor Fix For: 1.2.14-core Including the sources in the packaged war using dependency-maven-plugin doesn't work properly. Better to use the maven-war-plugin to add the additional src/main/java as a resources folder to be included under WEB-INF/src when packaging the final war file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1706) Trinidad components showcase demo app doesn't include java sources in packaged war
Trinidad components showcase demo app doesn't include java sources in packaged war -- Key: TRINIDAD-1706 URL: https://issues.apache.org/jira/browse/TRINIDAD-1706 Project: MyFaces Trinidad Issue Type: Improvement Components: Build Affects Versions: 1.2.14-core Reporter: Catalin Kormos Assignee: Catalin Kormos Priority: Minor Including the sources in the packaged war using dependency-maven-plugin doesn't work properly. Better to use the maven-war-plugin to add the additional src/main/java as a resources folder to be included under WEB-INF/src when packaging the final war file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2531) Support for name/library attributes with h:commandButton
Support for name/library attributes with h:commandButton
Key: MYFACES-2531
URL: https://issues.apache.org/jira/browse/MYFACES-2531
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces core trunk
Reporter: Martin Koci
Priority: Minor
JSF 2.0 specify new name/library attributes for h:graphicImage,
h:outputStylesheet and h:outputScript. But current JSF RI implementation
supports name/library even on h:commandButton (and maybe others - h:button for
example ?). That is very useful feature which allows complex EL like:
h:commandButton name=#{resourceBean.fileName}.#{extensions.extension}
library=#{otherBean.libraryName}/foo/bar/#{randomLibraryName}.
Supporting this hidden feature enables easy migration from RI to myfaces too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2531) Support for name/library attributes with h:commandButton
[
https://issues.apache.org/jira/browse/MYFACES-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Koci updated MYFACES-2531:
-
Status: Patch Available (was: Open)
Support for name/library attributes with h:commandButton
Key: MYFACES-2531
URL: https://issues.apache.org/jira/browse/MYFACES-2531
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces core trunk
Reporter: Martin Koci
Priority: Minor
JSF 2.0 specify new name/library attributes for h:graphicImage,
h:outputStylesheet and h:outputScript. But current JSF RI implementation
supports name/library even on h:commandButton (and maybe others - h:button
for example ?). That is very useful feature which allows complex EL like:
h:commandButton name=#{resourceBean.fileName}.#{extensions.extension}
library=#{otherBean.libraryName}/foo/bar/#{randomLibraryName}.
Supporting this hidden feature enables easy migration from RI to myfaces too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2531) Support for name/library attributes with h:commandButton
[
https://issues.apache.org/jira/browse/MYFACES-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829278#action_12829278
]
Martin Koci commented on MYFACES-2531:
--
Patch also switch order of rendering url and name/library. According to spec:
If the name attribute is present, execute algorithm Common Algorithm for
Obtaining A Resource to Render to obtain a Resource instance. Call
Resource.getRequestPath() and output the result as the value of the src
attribute on the rendered markup. Otherwise, if the url attribute is present
Previously HtmlImageRendererBase rendered name/library and url vice versa.
Support for name/library attributes with h:commandButton
Key: MYFACES-2531
URL: https://issues.apache.org/jira/browse/MYFACES-2531
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces core trunk
Reporter: Martin Koci
Priority: Minor
Attachments: MYFACES-2531.patch
JSF 2.0 specify new name/library attributes for h:graphicImage,
h:outputStylesheet and h:outputScript. But current JSF RI implementation
supports name/library even on h:commandButton (and maybe others - h:button
for example ?). That is very useful feature which allows complex EL like:
h:commandButton name=#{resourceBean.fileName}.#{extensions.extension}
library=#{otherBean.libraryName}/foo/bar/#{randomLibraryName}.
Supporting this hidden feature enables easy migration from RI to myfaces too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
Really?
I'd think if the direct child t:dataList isn't rendered, we probably
shouldn't output the tag.
But it's our own component, so we can make whatever rules we want.
On Wed, Feb 3, 2010 at 2:31 PM, Leonardo Uribe (JIRA)
dev@myfaces.apache.org wrote:
[
https://issues.apache.org/jira/browse/TOMAHAWK-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved TOMAHAWK-1485.
--
Resolution: Not A Problem
Assignee: Leonardo Uribe
t:dataList iterate over a list without check for rendered property on the
component. The fact that the component is not rendered does not means that
the value is skipped. t:dataList works as expected.
t:dataList should not render li element when iterated element is not
rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9,
commons-el 1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging
1.1.1
Reporter: Bauke Scholtz
Assignee: Leonardo Uribe
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
[
https://issues.apache.org/jira/browse/TOMAHAWK-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829294#action_12829294
]
Mike Kienenberger commented on TOMAHAWK-1485:
-
Note that you can workaround this behavior by using layout=simple and
generating your own li/li tags, rendered when you want them rendered, and
prefixing/suffixing the t:dataList with ul and /ul
t:dataList should not render li element when iterated element is not
rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9,
commons-el 1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging
1.1.1
Reporter: Bauke Scholtz
Assignee: Leonardo Uribe
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1485) t:dataList should not render li element when iterated element is not rendered
[
https://issues.apache.org/jira/browse/TOMAHAWK-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829299#action_12829299
]
Bauke Scholtz commented on TOMAHAWK-1485:
-
Well, I know that, that's also why I didn't report it as a bug. but as an
improvement. It could just check if none of its direct children are rendered.
t:dataList should not render li element when iterated element is not
rendered
---
Key: TOMAHAWK-1485
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1485
Project: MyFaces Tomahawk
Issue Type: Improvement
Components: Data List
Affects Versions: 1.1.9
Environment: Tomcat 6.0.20, Mojarra 1.2_14, Tomahawk 1.1.9,
commons-el 1.0, commons-fileupload 1.2.1, commons-io 1.4, commons-logging
1.1.1
Reporter: Bauke Scholtz
Assignee: Leonardo Uribe
The following code example:
%...@taglib uri=http://java.sun.com/jsf/core; prefix=f %
%...@taglib uri=http://myfaces.apache.org/tomahawk; prefix=t %
%
request.setAttribute(list, java.util.Arrays.asList(1, 2, 3, 4, 5));
%
f:view
!doctype html
html lang=en
head
titleTomahawk t:dataList demo/title
/head
body
t:dataList value=#{list} var=item layout=unorderedList
t:outputText value=#{item} rendered=#{item % 2 == 0} /
/t:dataList
/body
/html
/f:view
results in following:
*
* 2
*
* 4
*
while the following is expected:
* 2
* 4
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1484) t:inputCalendar as popup with forceId=false does not work
[ https://issues.apache.org/jira/browse/TOMAHAWK-1484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829330#action_12829330 ] Leonardo Uribe commented on TOMAHAWK-1484: -- The bug is not on the component, rather it is in core. It was a little bit tricky to track down. If you set partial state saving to false, the code works without problem. t:inputCalendar creates a transient component for the input text when renderAsPopup=true. This component is created on Render Response time, and the listener used to track changes on the component tree call getClientId(). This listener is activated by a PostAddToView event triggered by the addition of the component. The point is since parent component is not set yet, getClientId() does not take into account its future NamingContainer hierarchy, so the effect described happens. The algorithm for partial state saving must be fixed in two points: 1. It is only necessary to keep track of changes if the component added/removed is not transient. 2. Do not call getClientId() for PostAddToView, but do it for PreRemoveFromViewEvent. Instead, register the component to be added before saveView like we do for refreshTransientBuildOnPSS and preserve state option. I'll create another issue in myfaces core issue tracker. t:inputCalendar as popup with forceId=false does not work --- Key: TOMAHAWK-1484 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1484 Project: MyFaces Tomahawk Issue Type: Bug Components: Calendar Affects Versions: 1.1.10-SNAPSHOT Reporter: Ingo Hofmann A popup calender with forceId=true does not appear, but produces a JavaScript error when clicking on the button. The span element and JS code is rendered correctly, but the input element gets the wrong id (form ID missing). Simple Facelet page that reproduces this issue (first calender works fine, second doesn't): ?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:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:t=http://myfaces.apache.org/tomahawk; h:head meta HTTP-EQUIV=Content-Type CONTENT=text/html;charset=UTF-8 / titleCalender test/title /h:head h:body h:form id=calendarForm t:inputCalendar id=formWithForceIdTrue monthYearRowClass=yearMonthHeader weekRowClass=weekHeader popupButtonStyleClass=standard_bold currentDayCellClass=currentDayCell renderAsPopup=true popupDateFormat=MM/dd/ forceId=true/ t:inputCalendar id=formWithForceIdFalse monthYearRowClass=yearMonthHeader weekRowClass=weekHeader popupButtonStyleClass=standard_bold currentDayCellClass=currentDayCell renderAsPopup=true popupDateFormat=MM/dd/ forceId=false/ /h:form /h:body /html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2532) getClientId() should not be called from listener registering tree changes on DefaultFaceletsStateManagementStrategy and PostAddToViewEvent
getClientId() should not be called from listener registering tree changes on DefaultFaceletsStateManagementStrategy and PostAddToViewEvent -- Key: MYFACES-2532 URL: https://issues.apache.org/jira/browse/MYFACES-2532 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe see TOMAHAWK-1484 for details -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2532) getClientId() should not be called from listener registering tree changes on DefaultFaceletsStateManagementStrategy and PostAddToViewEvent
[ https://issues.apache.org/jira/browse/MYFACES-2532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2532. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 getClientId() should not be called from listener registering tree changes on DefaultFaceletsStateManagementStrategy and PostAddToViewEvent -- Key: MYFACES-2532 URL: https://issues.apache.org/jira/browse/MYFACES-2532 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 see TOMAHAWK-1484 for details -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1488) Convert example pages from JSP to Facelets
[ https://issues.apache.org/jira/browse/TOMAHAWK-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved TOMAHAWK-1488. -- Resolution: Fixed Fix Version/s: 1.1.10-SNAPSHOT Assignee: Leonardo Uribe Thanks to Ingo Hofmann for provide this ones. Really this examples are very useful testing myfaces core 2.0.x. Convert example pages from JSP to Facelets -- Key: TOMAHAWK-1488 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1488 Project: MyFaces Tomahawk Issue Type: Task Components: Examples Affects Versions: 1.1.10-SNAPSHOT Reporter: Ingo Hofmann Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT Attachments: Converted_JSPs_to_Facelets.patch Convert all JSP pages from new sub module myfaces-example-simple20 to Facelets. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1668) Speed up UIXComponent.getId()
[ https://issues.apache.org/jira/browse/TRINIDAD-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829388#action_12829388 ] Blake Sullivan commented on TRINIDAD-1668: -- There is a difference in behavior with the code--if the set of available keys is checked, the ID won't be in the set. I'll check in a fix Speed up UIXComponent.getId() - Key: TRINIDAD-1668 URL: https://issues.apache.org/jira/browse/TRINIDAD-1668 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-core Environment: All Reporter: Blake Sullivan Assignee: Blake Sullivan Fix For: 1.2.13-core Attachments: JIRA_1668_1_2_12_2.patch Original Estimate: 24h Remaining Estimate: 24h UIComponent.getId() is by far the most requested component attribute. There are a number of reasons for this: 1) The JSF RI has an issue in the JSP-JSF integration which causes getId() to be called n^2 times where n is the number of children a component has 2) getClientId() calls getId() 3) FindComponent calls getId() 4) The tree visiting code trades off calls to getClientId() for calls to getId() FacesBean optimizes attribute Map access at the expense of access directly through the component. The the extent that Renderers are Components are accessing the attributes through the attribute Map, this is fine, however even the Renderers access attributes common to all UIComponents such as id() through the component directly. Considering the huge number of times that the the id is accessed (for some renders, this was 8% of the rendering time), it makes sense to optimize this path. The proposal is to: 1) Store the id an an instance variable on the UIXComponent 2) Add a new capability flag to PropertyKey indicating that the property is actually stored elsewhere using a ValueExpression will be stored as the property's value in the PropertyMap. For access through the FacesBean, the ValueExpression will be evaluated to get/set the actual value 3) For state saving the ValueExpression is used to retrieve the actual value and for state restoration the ValueExpression (which has been rebootstrapped by the UIXComponent) is used to write the value back 4) Instead of setting the id attribute in the FacesBean, UIXComponent stores it locally and sets an ValueExpression implementation into the FacesBean that retrieves the value from the UIXComponent API Changes: PropertyKey: add /** * Capability indicating that values for this property should be * be stored and retrieved through a ValueExpression rather than on the * FacesBean itself */ static public final int CAP_VALUE_EXPRESSION_IMPLEMENTATION = 16; /** * Returns codetrue/code if property values for this key are set and get * using a ValueExpression rather than storing the value in the FacesBean. * @return codetrue/code if properties values for this key are retrieved * with a ValueExpression. */ public boolean usesValueExpressionAsImplementation() After this change id retrieval doesn't make the 1% YourKit profiler hot spot cut off -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2533) FaceletViewDeclarationLanguage call StateManager.saveView() before write document
FaceletViewDeclarationLanguage call StateManager.saveView() before write document - Key: MYFACES-2533 URL: https://issues.apache.org/jira/browse/MYFACES-2533 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe There are components that are added/removed on render response time that needs to be saved. I we call before render response, the result is this components are not saved on the tree and cause some components like t:tree not work correctly. It seems this was changed when we move the code from facelets, but the original implementation of FaceletViewHandler shows the place where this call should be done, so I'll just restore the code as originally was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2533) FaceletViewDeclarationLanguage call StateManager.saveView() before write document
[ https://issues.apache.org/jira/browse/MYFACES-2533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2533. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Thanks to Ingo Hofmann for fill TOMAHAWK-1486, so we can track this one on core. FaceletViewDeclarationLanguage call StateManager.saveView() before write document - Key: MYFACES-2533 URL: https://issues.apache.org/jira/browse/MYFACES-2533 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 There are components that are added/removed on render response time that needs to be saved. I we call before render response, the result is this components are not saved on the tree and cause some components like t:tree not work correctly. It seems this was changed when we move the code from facelets, but the original implementation of FaceletViewHandler shows the place where this call should be done, so I'll just restore the code as originally was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1486) Tree does not work any more with core 2.0
[
https://issues.apache.org/jira/browse/TOMAHAWK-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829398#action_12829398
]
Leonardo Uribe commented on TOMAHAWK-1486:
--
Solved the problem on MYFACES-2533 but now I have other different problem when
using t:tree2:
javax.faces.FacesException: java.lang.ClassCastException:
javax.faces.component.UIPanel
at
org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241)
at
org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:216)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Caused by: java.lang.ClassCastException: javax.faces.component.UIPanel
at
org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeNavigation(HtmlTreeRenderer.java:534)
at
org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeCurrentNode(HtmlTreeRenderer.java:366)
at
org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeTree(HtmlTreeRenderer.java:264)
at
org.apache.myfaces.custom.tree2.HtmlTreeRenderer.encodeChildren(HtmlTreeRenderer.java:233)
at
javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:464)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:603)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:608)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1051)
at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:231)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:107)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:201)
Tree does not work any more with core 2.0
-
Key: TOMAHAWK-1486
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1486
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Tree
Affects Versions: 1.1.10-SNAPSHOT
Reporter: Ingo Hofmann
A rendered t:tree tree can not be collapsed or opened any more (with core
2.0).
The nodes' command links seem to be rendered wrong.
Example from the examples module:
h:form id=treeform
t:tree id=tree1 value=#{tree1Backer.treeModel}
styleClass=tree
nodeClass=treenode
selectedNodeClass=treenodeSelected
expandRoot=true
/t:tree
/h:form
tree1Backer:
public class Tree1Backer {
private TreeModel treeModel;
public TreeModel getTreeModel() {
if (treeModel == null) {
DefaultMutableTreeNode root = new DefaultMutableTreeNode(XY);
DefaultMutableTreeNode a = new DefaultMutableTreeNode(A);
root.insert(a);
DefaultMutableTreeNode b = new
[jira] Created: (MYFACES-2534) ComponentSupport.addFacet adds a panel when there is only one component as a child
ComponentSupport.addFacet adds a panel when there is only one component as a child -- Key: MYFACES-2534 URL: https://issues.apache.org/jira/browse/MYFACES-2534 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Old behavior must be preserved, otherwise some components like t:tree2 will not work correctly. This fix the other problem in TOMAHAWK-1486 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2534) ComponentSupport.addFacet adds a panel when there is only one component as a child
[ https://issues.apache.org/jira/browse/MYFACES-2534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2534. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 ComponentSupport.addFacet adds a panel when there is only one component as a child -- Key: MYFACES-2534 URL: https://issues.apache.org/jira/browse/MYFACES-2534 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Old behavior must be preserved, otherwise some components like t:tree2 will not work correctly. This fix the other problem in TOMAHAWK-1486 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1679) Tag doc to list relationship between tags
[ https://issues.apache.org/jira/browse/TRINIDAD-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman resolved TRINIDAD-1679. -- Resolution: Fixed Fix Version/s: 1.2.12-plugins Tag doc to list relationship between tags - Key: TRINIDAD-1679 URL: https://issues.apache.org/jira/browse/TRINIDAD-1679 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Priority: Minor Fix For: 1.2.12-plugins Attachments: patchJIRA1679.patch, patchJIRA1679_2.patch The tag doc should list relationships between tags. For example, if a given facet of a component can only take a component of type X, that should be listed on the tag doc page, and a link to the tag doc for component X provided.This JIRA will supported parsing out the existing fmd:allowed-child-components and fmd:required-ancestor-contracts (from the namespace http://java.sun.com/xml/ns/javaee/faces/design-time-metadata) from the component XML files and converting that into relevant tag names, then adding that information into the generated tag doc pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1702) performance: decrease memory of FileSystemStyleCache by reusing CSSStyle objects.
[
https://issues.apache.org/jira/browse/TRINIDAD-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman resolved TRINIDAD-1702.
--
Resolution: Fixed
Fix Version/s: 1.2.14-core
performance: decrease memory of FileSystemStyleCache by reusing CSSStyle
objects.
-
Key: TRINIDAD-1702
URL: https://issues.apache.org/jira/browse/TRINIDAD-1702
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Skinning
Affects Versions: 1.2.13-core
Reporter: Jeanne Waldman
Assignee: Jeanne Waldman
Fix For: 1.2.14-core
Attachments: CSSStyleKeyPatch12122.patch
Our performance team gave me the following statistics:
Objects:
Shallow HeapRetained
Heap
SkinStyleProvider13 723B
540M
FileSystemStyleCache$Entry 71 1704B
536M
FileSystemStyleCache$StyleImpl 71 2272B533M
CSSStyle 315,431 7.5M
518M
The application they are testing has 13 skins, therefore there are 13
SkinStyleProvider objects.
Each css file has about 4500 selectors in this use case.
In FileSystemStyleCache's StyleImpl, we create a new CSSStyle object for
every selector, even though many of the selectors have the same css property
names/values. E.g., .af_inputText_xyz, .af_selectOneChoice_xyz,
.af_selectManyCheckbox_xyz {font-weight: bold; color: black}
To decrease the memory used, in StyleImpl we can reuse CSSStyle objects where
they have the same css property name and values. This small change saves 56%
of the memory used.
(Note: More memory should be saved in other ways, but this will be a
different JIRA issue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad][Skinning] Introduce include-Property in CSS
Hi,
I looked into the performance issues and they have nothing to do with
the new features we have been adding recently, so we are ok to add
patches.
I'll add this to my todo list, but if anyone else has some time in the
next couple of days, feel free to review the patch.
Jeanne
Jeanne Waldman wrote, On 1/21/2010 11:51 AM PT:
Ok. Our performance team has noticed the Skinning Framework is using
more memory than not that long ago, so I want to look into that before
we add anymore patches.
Jeanne
Marius Petoi wrote, On 1/19/2010 1:23 AM PT:
Hi Jeanne,
The new patch is ready.
Marius
On Tue, Jan 19, 2010 at 8:58 AM, Marius
Petoi marius.pe...@codebeat.ro
wrote:
Ok.
Then I shall adapt dealing with the aliases and I shall inform you when
the new patch is ready.
Marius
On Mon, Jan 18, 2010 at 11:16 PM, Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
I'm fine with your
syntax. I think it is clearer as well. I was just
giving an alternative option if people wanted to vote on it.
Marius Petoi wrote, On 1/15/2010 12:05 AM PT:
Yes, 'name' is an alias...I introduced
it
because I saw it
was done this way in the XSS. I will remove it. Are you saying I should
change the syntax? I personally think it is clearer this way.
Marius
On Fri, Jan 15, 2010 at 1:45 AM,
Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
What is 'name'? Is
that
an
alias? We distinguished between selector and
name in XSS but we don't in the CSS format. We still do in the code,
but the person working with the css shouldn't know the difference.
Yes, the con of my suggestion is that order matters and the user needs
to know what the order means .I can see them not knowing is color what
I'm setting or is color what I'm retrieving? That is what I think the
con is for the CSS syntax like padding: 0px 2px 3px 4px
Regarding your link, I haven't had time to look at that yet.
Jeanne
Marius Petoi wrote, On 1/12/2010 11:46 PM PT:
Hi Jeanne,
Thank you for the answer! Like in the situation of -tr-rule-ref, the
list of properties is comma separated. I don't understand what you mean
by camel-case...The name of the new property can be whatever the user
wishes for. Afterwards, it will be treated like all the other
properties in the CSS. Regarding the new syntax you suggested, first of
all, we may have a selector or a name, in which case "selector" is
replaced with "name". Also, another problem is the order in which they
appear; with this syntax it can be any order.
How about http://markmail.org/search/?q=skinning%20list%3Aorg.apache.myfaces.dev#query:skinning%20list%3Aorg.apache.myfaces.dev%20order%3Adate-backward+page:3+mid:3au5ilvrrpbxopgx+state:results
? Did you have the time to look over it too?
Regards,
Marius
On Tue, Jan 12, 2010 at 11:58
PM,
Jeanne
Waldman jeanne.wald...@oracle.com
wrote:
Another idea for the syntax comes from the rgb color syntax -
color: rgb(100%, 0%, 0%)
You could use this syntax, and not specify what each of the properties is for:
-tr-include-property:
property("af|foo", "color", "background-color")
or
property(af|foo, color, background-color)
I like this because it's shorter, but I don't like it since they will have to look up which is which, something I have to do when I use the border: 0px 3px 2px 1px syntax - which is right, left, top, bottom.
Jeanne
Jeanne Waldman wrote, On 1/12/2010 10:21 AM PT:
Hi,
Thanks for this patch.
I will have to look at the CSS spec to see if this syntax conforms to
other CSS syntaxes. This is what I usually do when I try to come up
with a new skinning api.
Like, is the comma standard, or should it be space-separated? Is the
camel-case standard, or should it be '-'s.
I think it looks good, but I'll have to look at it closer before I vote.
Jeanne
Marius Petoi wrote, On 1/11/2010 4:52 AM PT:
Is there anyone who has
already
reviewed
this or added
them on his/her TODO list? Thank you in advance!
Marius
On Fri, Jan 8, 2010 at
11:35
AM,
Marius
Petoi marius.pe...@codebeat.ro
wrote:
Hello,
I created a new JIRA task for this issue (https://issues.apache.org/jira/browse/TRINIDAD-1680)
and I added a patch for it.
I introduced a new -tr property: "-tr-include-property". The syntax of
this is:
-tr-include-property:
property(selector="af|foo",propertyName="color",
localPropertyName="background-color")
In
[jira] Updated: (MYFACES-2531) Support for name/library attributes with h:commandButton
[
https://issues.apache.org/jira/browse/MYFACES-2531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-2531:
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Assignee: Leonardo Uribe
Status: Resolved (was: Patch Available)
Thanks to Martin Koci for provide this patch
Support for name/library attributes with h:commandButton
Key: MYFACES-2531
URL: https://issues.apache.org/jira/browse/MYFACES-2531
Project: MyFaces Core
Issue Type: New Feature
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces core trunk
Reporter: Martin Koci
Assignee: Leonardo Uribe
Priority: Minor
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2531.patch
JSF 2.0 specify new name/library attributes for h:graphicImage,
h:outputStylesheet and h:outputScript. But current JSF RI implementation
supports name/library even on h:commandButton (and maybe others - h:button
for example ?). That is very useful feature which allows complex EL like:
h:commandButton name=#{resourceBean.fileName}.#{extensions.extension}
library=#{otherBean.libraryName}/foo/bar/#{randomLibraryName}.
Supporting this hidden feature enables easy migration from RI to myfaces too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2520) UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty
[ https://issues.apache.org/jira/browse/MYFACES-2520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12829469#action_12829469 ] Leonardo Uribe commented on MYFACES-2520: - I think the solution is change _SystemEventServletRequest and _SystemEventServletResponse with dummy methods (returning null, -1, false or empty arrays or collections) to all methods. For example, the code in trinidad check for null on getContentType, so we can return null safely. I remember this same problem with myfaces orchestra for jsf 2.0 and the solution was add dummy methods too. The problem is define what should we return for. UnsupportedOperationException when launching Trinidad 2 w/ MyFaces2 in Jetty Key: MYFACES-2520 URL: https://issues.apache.org/jira/browse/MYFACES-2520 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Matthias Weßendorf SEVERE: java.lang.UnsupportedOperationException: This request class is an empty placeholder at org.apache.myfaces.application._SystemEventServletRequest$1.invoke(_SystemEventServletRequest.java:56) at $Proxy0.getContentType(Unknown Source) at javax.servlet.ServletRequestWrapper.getContentType(ServletRequestWrapper.java:145) at org.apache.myfaces.context.servlet.ServletExternalContextImpl.getRequestContentType(ServletExternalContextImpl.java:322) at org.apache.myfaces.trinidad.util.ExternalContextUtils.getContentType(ExternalContextUtils.java:341) at org.apache.myfaces.trinidadinternal.share.util.MultipartFormHandler.isMultipartRequest(MultipartFormHandler.java:57) at org.apache.myfaces.trinidadinternal.config.upload.FileUploadConfiguratorImpl.beginRequest(FileUploadConfiguratorImpl.java:109) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._startConfiguratorServiceRequest(GlobalConfiguratorImpl.java:532) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.beginRequest(GlobalConfiguratorImpl.java:211) at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:327) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.init(FacesContextFactoryImpl.java:90) at org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:68) at org.apache.myfaces.webapp.AbstractFacesInitializer.dispatchInitDestroyEvent(AbstractFacesInitializer.java:140) at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:109) at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:155) at org.mortbay.jetty.handler.ContextHandler.startContext(ContextHandler.java:548) at org.mortbay.jetty.servlet.Context.startContext(Context.java:136) at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1250) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517) at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:467) at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:115) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132) at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:441) at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:383) at org.mortbay.jetty.plugin.AbstractJettyRunMojo.execute(AbstractJettyRunMojo.java:210) at org.mortbay.jetty.plugin.Jetty6RunMojo.execute(Jetty6RunMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at
Re: [Trinidad][Skinning] Introduce include-Property in CSS
Ok Jeanne. Thank you! One more question, in order to transform the XSS files in CSS files, in base-desktop.xss there are some styles which are mode-dependent. Should we add @mode in the CSS? Or do you have any other idea? Marius On Thu, Feb 4, 2010 at 7:17 AM, Jeanne Waldman jeanne.wald...@oracle.comwrote: Hi, I looked into the performance issues and they have nothing to do with the new features we have been adding recently, so we are ok to add patches. I'll add this to my todo list, but if anyone else has some time in the next couple of days, feel free to review the patch. Jeanne Jeanne Waldman wrote, On 1/21/2010 11:51 AM PT: Ok. Our performance team has noticed the Skinning Framework is using more memory than not that long ago, so I want to look into that before we add anymore patches. Jeanne Marius Petoi wrote, On 1/19/2010 1:23 AM PT: Hi Jeanne, The new patch is ready. Marius On Tue, Jan 19, 2010 at 8:58 AM, Marius Petoi marius.pe...@codebeat.rowrote: Ok. Then I shall adapt dealing with the aliases and I shall inform you when the new patch is ready. Marius On Mon, Jan 18, 2010 at 11:16 PM, Jeanne Waldman jeanne.wald...@oracle.com wrote: I'm fine with your syntax. I think it is clearer as well. I was just giving an alternative option if people wanted to vote on it. Marius Petoi wrote, On 1/15/2010 12:05 AM PT: Yes, 'name' is an alias...I introduced it because I saw it was done this way in the XSS. I will remove it. Are you saying I should change the syntax? I personally think it is clearer this way. Marius On Fri, Jan 15, 2010 at 1:45 AM, Jeanne Waldman jeanne.wald...@oracle.com wrote: What is 'name'? Is that an alias? We distinguished between selector and name in XSS but we don't in the CSS format. We still do in the code, but the person working with the css shouldn't know the difference. Yes, the con of my suggestion is that order matters and the user needs to know what the order means .I can see them not knowing is color what I'm setting or is color what I'm retrieving? That is what I think the con is for the CSS syntax like *padding: 0px 2px 3px 4px* Regarding your link, I haven't had time to look at that yet. Jeanne Marius Petoi wrote, On 1/12/2010 11:46 PM PT: Hi Jeanne, Thank you for the answer! Like in the situation of -tr-rule-ref, the list of properties is comma separated. I don't understand what you mean by camel-case...The name of the new property can be whatever the user wishes for. Afterwards, it will be treated like all the other properties in the CSS. Regarding the new syntax you suggested, first of all, we may have a selector or a name, in which case selector is replaced with name. Also, another problem is the order in which they appear; with this syntax it can be any order. How about http://markmail.org/search/?q=skinning%20list%3Aorg.apache.myfaces.dev#query:skinning%20list%3Aorg.apache.myfaces.dev%20order%3Adate-backward+page:3+mid:3au5ilvrrpbxopgx+state:results? Did you have the time to look over it too? Regards, Marius On Tue, Jan 12, 2010 at 11:58 PM, Jeanne Waldman jeanne.wald...@oracle.com wrote: Another idea for the syntax comes from the rgb color syntax - color: rgb(100%, 0%, 0%) You could use this syntax, and not specify what each of the properties is for:-tr-include-property: property(af|foo, color, background-color) or property(af|foo, color, background-color) I like this because it's shorter, but I don't like it since they will have to look up which is which, something I have to do when I use the border: 0px 3px 2px 1px syntax - which is right, left, top, bottom. Jeanne Jeanne Waldman wrote, On 1/12/2010 10:21 AM PT: Hi, Thanks for this patch. I will have to look at the CSS spec to see if this syntax conforms to other CSS syntaxes. This is what I usually do when I try to come up with a new skinning api. Like, is the comma standard, or should it be space-separated? Is the camel-case standard, or should it be '-'s. I think it looks good, but I'll have to look at it closer before I vote. Jeanne Marius Petoi wrote, On 1/11/2010 4:52 AM PT: Is there anyone who has already reviewed this or added them on his/her TODO list? Thank you in advance! Marius On Fri, Jan 8, 2010 at 11:35 AM, Marius Petoi marius.pe...@codebeat.ro wrote: Hello, I created a new JIRA task for this issue ( https://issues.apache.org/jira/browse/TRINIDAD-1680) and I added a patch for it. I introduced a new -tr property: -tr-include-property. The syntax of this is: -tr-include-property: property(selector=af|foo,propertyName=color, localPropertyName=background-color) In SkinStyleSheetParserUtils, when the selectors are parsed, similar to the -tr-rule-ref, I introduced a list of includedProperties. The rules defined with -tr-include-property are parsed and the list of includedProperties is filled up. In the end, when the StyleNode is created,
