You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(37) |
Jun
(141) |
Jul
(111) |
Aug
(91) |
Sep
(79) |
Oct
(151) |
Nov
(161) |
Dec
(93) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(40) |
Feb
(60) |
Mar
(43) |
Apr
(90) |
May
(31) |
Jun
(114) |
Jul
(35) |
Aug
(112) |
Sep
(305) |
Oct
(151) |
Nov
(122) |
Dec
(103) |
| 2006 |
Jan
(65) |
Feb
(57) |
Mar
(475) |
Apr
(276) |
May
(482) |
Jun
(134) |
Jul
(127) |
Aug
(188) |
Sep
(271) |
Oct
(220) |
Nov
(74) |
Dec
(41) |
| 2007 |
Jan
(121) |
Feb
(50) |
Mar
(36) |
Apr
(11) |
May
(31) |
Jun
(12) |
Jul
(73) |
Aug
(41) |
Sep
(59) |
Oct
(33) |
Nov
(60) |
Dec
(111) |
| 2008 |
Jan
(139) |
Feb
(49) |
Mar
(87) |
Apr
(43) |
May
(10) |
Jun
(25) |
Jul
(114) |
Aug
(17) |
Sep
(25) |
Oct
(199) |
Nov
(94) |
Dec
(45) |
| 2009 |
Jan
(36) |
Feb
(14) |
Mar
(29) |
Apr
(32) |
May
(49) |
Jun
(18) |
Jul
(68) |
Aug
(34) |
Sep
(34) |
Oct
(11) |
Nov
(10) |
Dec
(14) |
| 2010 |
Jan
(35) |
Feb
(12) |
Mar
(23) |
Apr
(17) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
(10) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2012 |
Jan
(2) |
Feb
(1) |
Mar
(8) |
Apr
(3) |
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(8) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
(1) |
May
(5) |
Jun
(1) |
Jul
(13) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(15) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 13:23:19
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker closed RCP-96.
--------------------------------
> Form reset problems with nested properties
> ------------------------------------------
>
> Key: RCP-96
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-96
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Juan Gil
> Assignee: Oliver Hutchison
> Priority: Minor
> Fix For: 1.0.0
>
>
> class Product {
> String code;
> Price price;
> ....
> }
> class Price {
> Double base;
> Double tax;
> ...
> }
> class ProductForm extends AbstractForm {
> ...
> protected JComponent createFormControl() {
> TableFormBuilder formBuilder = new TableFormBuilder(this.getFormModel());
>
> formBuilder.row();
> formBuilder.add("code");
> formBuilder.row();
> formBuilder.add("price.base");
> formBuilder.row();
> formBuilder.add("price.tax");
> return formBuilder.getForm();
> }
> ------------------------------------
> Then I use this form in a View, that needs to refresh the product information based on other view. I do productForm.reset and it throws a exception :
> java.lang.IllegalArgumentException: Held bean value cannot be null!
> It's due to the nested properties on the form, because I works with a form without them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 13:23:19
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-96.
----------------------------------
Resolution: Fixed
this has been fixed for some time now: look in the Simple App in the ContactForm: all properties of the address are nested.
> Form reset problems with nested properties
> ------------------------------------------
>
> Key: RCP-96
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-96
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Juan Gil
> Assignee: Oliver Hutchison
> Priority: Minor
> Fix For: 1.0.0
>
>
> class Product {
> String code;
> Price price;
> ....
> }
> class Price {
> Double base;
> Double tax;
> ...
> }
> class ProductForm extends AbstractForm {
> ...
> protected JComponent createFormControl() {
> TableFormBuilder formBuilder = new TableFormBuilder(this.getFormModel());
>
> formBuilder.row();
> formBuilder.add("code");
> formBuilder.row();
> formBuilder.add("price.base");
> formBuilder.row();
> formBuilder.add("price.tax");
> return formBuilder.getForm();
> }
> ------------------------------------
> Then I use this form in a View, that needs to refresh the product information based on other view. I do productForm.reset and it throws a exception :
> java.lang.IllegalArgumentException: Held bean value cannot be null!
> It's due to the nested properties on the form, because I works with a form without them.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 10:57:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-445?page=
=3Dcom.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-445.
-----------------------------------
Resolution: Fixed
> The messages typeMismatch and unknown don't show the cause of the error
> -----------------------------------------------------------------------
>
> Key: RCP-445
> URL: http://opensource.atlassian.com/projects/spring/brow=
se/RCP-445
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Binding System
> Affects Versions: 0.3.0
> Reporter: Aaron Digulla
> Assignee: Peter De Bruycker
>
> When validation for a text field fails because of a typeMismatch or an un=
known error, the source of the error is not display leaving the developer c=
lueless at what the problem might be.
> See DefaultBindingErrorMessageProvider.java:49
> To fix, add a {1} parameter to the properties (it's already filled by the=
code):
> message.properties:
> typeMismatch=3D{0} has an invalid format "{1}"
> unknown=3D{0} has an invalid format "{1}"
> messages_de.properties:
> typeMismatch=3D"{1}" ist ung=C3=BCltig f=C3=BCr {0}
> unknown=3D"{1}" ist ung=C3=BCltig f=C3=BCr {0}
--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 10:14:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27956 ]
Peter De Bruycker commented on RCP-390:
---------------------------------------
FormGuardTests now runs in headless mode
> make the tests run in headless environment
> ------------------------------------------
>
> Key: RCP-390
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-390
> Project: Spring Framework Rich Client Project
> Issue Type: Task
> Affects Versions: 0.1.0, 0.2.0
> Reporter: Mathias Broekelmann
> Priority: Minor
>
> some of the tests don't run in a headless environment. I identified these tests to fail:
> support:
> FormGuardTests
> InputApplicationDialogTests
> DirtyIndicatorInterceptorTests
> sandbox:
> WindowMementoTests
> If we going to use continuum on a linux box these tests will not run.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 09:35:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27955 ]
Peter De Bruycker commented on RCP-500:
---------------------------------------
fixed by adding a null check in AbstractFormBuilder
> NullPointerException in AbstractFormBuilder
> -------------------------------------------
>
> Key: RCP-500
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-500
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Arne Limburg
> Assignee: Peter De Bruycker
>
> The AbstractFormBuilder throws a NullPointerException when no FormComponentInterceptorFactory is configured, because it calls FormComponentInterceptor.processLabel in createLabel without checking the FormComponentInterceptor to be not null. A simple surrounding with interceptor != null would solve the problem.
> Another solution would be to make the FormComponentInterceptorFactories to never return null on getInterceptor.
> This should be fixed in the FormComponentInterceptorFactory returned by the formComponentInterceptorFactoryImplBuilder in DefaultApplicationServices. It could just return an anonymous implementation of AbstractFormComponentInterceptor.
> The ChainedInterceptorFactory will return null too, if no inner FormComponentInterceptorFactories are configured. It could return an interceptor with an empty list instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 09:33:17
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27954 ]
Peter De Bruycker commented on RCP-465:
---------------------------------------
I did an analysis of the memory usage in SimpleApp, and I didn't notice strange things.
After several invocations of the ContactPropertiesDialog, I see that the objects stay in memory, but after garbage collection, they disappear, meaning they're not a memory leak.
One could argue that the PropertiesExecutor in the ContactView could be refactored so it reuses the ContactPropertiesDialog instance, but that's another discussion.
> TextComponentPopup provokes memory leaks
> ----------------------------------------
>
> Key: RCP-465
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-465
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Command System
> Affects Versions: 0.3.0
> Reporter: Fausto Gamito
>
> TextComponentPopup provokes memory leaks.
> Using the SimpleApp, when the JMenuPopup (private method "maybeShowPopup") is created a big number of objects (ContactForm, ContactPropertiesDialog and many others) stay alive and grow on each ContactPropertiesDialog request.
> I think the problem is in the commands, but i don't find the solution.
> Any help is welcome!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 08:12:17
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker closed RCP-468.
---------------------------------
Assignee: Peter De Bruycker
Resolution: Duplicate
duplicate of RCP-390
> WindowMementoTests are failing
> ------------------------------
>
> Key: RCP-468
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-468
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Affects Versions: 0.3.0
> Environment: Linux with Xvfb
> Reporter: Ben Hale
> Assignee: Peter De Bruycker
>
> The WindowMementoTests class has two failing tests: testSaveMaximizedState and testRestoreMaximizedState. See Spring CI build for details: http://build.springframework.org:8085/bamboo/browse/RCP-NIGHTLY/latest
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-26 07:59:18
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-500.
-----------------------------------
Resolution: Fixed
> NullPointerException in AbstractFormBuilder
> -------------------------------------------
>
> Key: RCP-500
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-500
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Arne Limburg
> Assignee: Peter De Bruycker
>
> The AbstractFormBuilder throws a NullPointerException when no FormComponentInterceptorFactory is configured, because it calls FormComponentInterceptor.processLabel in createLabel without checking the FormComponentInterceptor to be not null. A simple surrounding with interceptor != null would solve the problem.
> Another solution would be to make the FormComponentInterceptorFactories to never return null on getInterceptor.
> This should be fixed in the FormComponentInterceptorFactory returned by the formComponentInterceptorFactoryImplBuilder in DefaultApplicationServices. It could just return an anonymous implementation of AbstractFormComponentInterceptor.
> The ChainedInterceptorFactory will return null too, if no inner FormComponentInterceptorFactories are configured. It could return an interceptor with an empty list instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Benoit X. <be...@ya...> - 2007-11-25 20:21:21
|
Hi *, On Friday, a bank in the City of London pointed to me that they would not recommend the use of Spring Rich Client due to a lack of activity. I'd say that there is still some activity but it is true that the last release is nearly 14m old... I therefore encourage you to consider a release soon... and why not 1.0 or close to 1.0; a version 0.3 does not reflect the maturity of this framework. Thanks! Benoit. ------------------------IMPORTANT NOTICE This communication contains information that is considered confidential and may also be privileged . It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender and delete the original. |
|
From: Arne L. (JIRA) <no...@at...> - 2007-11-25 13:37:17
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arne Limburg updated RCP-499:
-----------------------------
Attachment: ClassPropertyAccessStrategy.patch
This patch fixes two minor bugs of the first patch
> Provide a ClassPropertyAccessStrategy
> -------------------------------------
>
> Key: RCP-499
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-499
> Project: Spring Framework Rich Client Project
> Issue Type: New Feature
> Components: Binding System
> Reporter: Arne Limburg
> Attachments: ClassPropertyAccessStrategy.patch, ClassPropertyAccessStrategy.patch
>
>
> You discussed the creation of a ClassPropertyAccessStrategy some month ago. My implementation can detect property-types based on provided classes or interfaces even if some object in the property path is null. It can detect collection types if Java 5 Generics are available. Field-access can optionally switched on or off. Within this patch I have abstracted out an AbstractPropertyAccessStrategy. This base-class for BeanPropertyAccessStrategy and ClassPropertyAccessStrategy can easily to be used to implement further PropertyAccessStrategy.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Arne L. (JIRA) <no...@at...> - 2007-11-24 13:37:17
|
NullPointerException in AbstractFormBuilder
-------------------------------------------
Key: RCP-500
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-500
Project: Spring Framework Rich Client Project
Issue Type: Bug
Components: Binding System
Reporter: Arne Limburg
The AbstractFormBuilder throws a NullPointerException when no FormComponentInterceptorFactory is configured, because it calls FormComponentInterceptor.processLabel in createLabel without checking the FormComponentInterceptor to be not null. A simple surrounding with interceptor != null would solve the problem.
Another solution would be to make the FormComponentInterceptorFactories to never return null on getInterceptor.
This should be fixed in the FormComponentInterceptorFactory returned by the formComponentInterceptorFactoryImplBuilder in DefaultApplicationServices. It could just return an anonymous implementation of AbstractFormComponentInterceptor.
The ChainedInterceptorFactory will return null too, if no inner FormComponentInterceptorFactories are configured. It could return an interceptor with an empty list instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Arne L. (JIRA) <no...@at...> - 2007-11-23 22:37:16
|
Provide a ClassPropertyAccessStrategy
-------------------------------------
Key: RCP-499
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-499
Project: Spring Framework Rich Client Project
Issue Type: New Feature
Components: Binding System
Reporter: Arne Limburg
Attachments: ClassPropertyAccessStrategy.patch
You discussed the creation of a ClassPropertyAccessStrategy some month ago. My implementation can detect property-types based on provided classes or interfaces even if some object in the property path is null. It can detect collection types if Java 5 Generics are available. Field-access can optionally switched on or off. Within this patch I have abstracted out an AbstractPropertyAccessStrategy. This base-class for BeanPropertyAccessStrategy and ClassPropertyAccessStrategy can easily to be used to implement further PropertyAccessStrategy.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Arne L. (JIRA) <no...@at...> - 2007-11-23 22:37:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Arne Limburg updated RCP-499:
-----------------------------
Attachment: ClassPropertyAccessStrategy.patch
> Provide a ClassPropertyAccessStrategy
> -------------------------------------
>
> Key: RCP-499
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-499
> Project: Spring Framework Rich Client Project
> Issue Type: New Feature
> Components: Binding System
> Reporter: Arne Limburg
> Attachments: ClassPropertyAccessStrategy.patch
>
>
> You discussed the creation of a ClassPropertyAccessStrategy some month ago. My implementation can detect property-types based on provided classes or interfaces even if some object in the property path is null. It can detect collection types if Java 5 Generics are available. Field-access can optionally switched on or off. Within this patch I have abstracted out an AbstractPropertyAccessStrategy. This base-class for BeanPropertyAccessStrategy and ClassPropertyAccessStrategy can easily to be used to implement further PropertyAccessStrategy.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Luis S. (JIRA) <no...@at...> - 2007-11-23 17:18:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luis Santos updated RCP-498:
----------------------------
Attachment: attributesPatch.txt
A proposed patch to the issue
> The label does not get the correct attrbites
> --------------------------------------------
>
> Key: RCP-498
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-498
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Reporter: Luis Santos
> Priority: Critical
> Attachments: attributesPatch.txt
>
>
> when you add a property to a form in the form of
> formBuilder.add( propertyName, attributes)
> the jLabel is not afected by the attutes defined.
> More precisely, if an valign or rowspan attribute is specified it should also be applied to the label.
> _Proposal_ of a fix:
> replace the method in the class org.springframework.richclient.form.builder.TableFormBuilder
> public String getLabelAttributes() {
> return labelAttributes;
> }
> for an alternate implementation
> public String getLabelAttributes(String fieldProperties) {
> String theLabelAttributes = labelAttributes;
>
> int valignStartIndex = fieldProperties.indexOf(TableLayoutBuilder.VALIGN);
> if( valignStartIndex!=-1){
> int valignEndIndex = fieldProperties.indexOf(" ",valignStartIndex);
> theLabelAttributes += (" "+theLabelAttributes.substring(valignStartIndex, valignEndIndex));
> }
>
> int rowStartIndex = fieldProperties.indexOf(TableLayoutBuilder.ROWSPAN);
> if( rowStartIndex!=-1){
> int rowEndIndex = fieldProperties.indexOf(" ",valignStartIndex);
> theLabelAttributes += (" "+theLabelAttributes.substring(rowStartIndex, rowEndIndex));
> }
>
> return theLabelAttributes;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Luis S. (JIRA) <no...@at...> - 2007-11-23 16:31:17
|
The label does not get the correct attrbites
--------------------------------------------
Key: RCP-498
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-498
Project: Spring Framework Rich Client Project
Issue Type: Bug
Reporter: Luis Santos
Priority: Critical
when you add a property to a form in the form of
formBuilder.add( propertyName, attributes)
the jLabel is not afected by the attutes defined.
More precisely, if an valign or rowspan attribute is specified it should also be applied to the label.
_Proposal_ of a fix:
replace the method in the class org.springframework.richclient.form.builder.TableFormBuilder
public String getLabelAttributes() {
return labelAttributes;
}
for an alternate implementation
public String getLabelAttributes(String fieldProperties) {
String theLabelAttributes = labelAttributes;
int valignStartIndex = fieldProperties.indexOf(TableLayoutBuilder.VALIGN);
if( valignStartIndex!=-1){
int valignEndIndex = fieldProperties.indexOf(" ",valignStartIndex);
theLabelAttributes += (" "+theLabelAttributes.substring(valignStartIndex, valignEndIndex));
}
int rowStartIndex = fieldProperties.indexOf(TableLayoutBuilder.ROWSPAN);
if( rowStartIndex!=-1){
int rowEndIndex = fieldProperties.indexOf(" ",valignStartIndex);
theLabelAttributes += (" "+theLabelAttributes.substring(rowStartIndex, rowEndIndex));
}
return theLabelAttributes;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Christian H. (JIRA) <no...@at...> - 2007-11-23 15:07:16
|
OverlayHelper missing validate() in OverlayUpdater causes painting problem (overlay not shown)
----------------------------------------------------------------------------------------------
Key: RCP-497
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-497
Project: Spring Framework Rich Client Project
Issue Type: Bug
Components: Application Framework
Affects Versions: 0.3.0
Environment: Mac OS Leopard
Reporter: Christian Heilmann
Overlay is not shown.
Please add validate() in OverlayUpdater
...
if (layeredPane.isVisible() && layeredPane.isShowing()) {
putOverlay(layeredPane);
positionOverlay(layeredPane);
//ADDED
layeredPane.validate();
}
...
Please call updateOverlay() in attachOverlay(..)-Method the first time, so that i can use the OverlayHelper standalone.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Christian H. (JIRA) <no...@at...> - 2007-11-23 14:55:16
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27916 ]
Christian Heilmann commented on RCP-483:
----------------------------------------
Please put the following code in to fix it:
AbstractApplicationPage.close(PageComponent pageComponent) {
...
ApplicationEventMulticaster aem = getApplicationEventMulticaster();
if (aem != null && pageComponent instanceof ApplicationListener) {
aem.removeApplicationListener((ApplicationListener) pageComponent);
}
...
}
protected ApplicationEventMulticaster getApplicationEventMulticaster() {
if (getApplicationContext() != null) {
final String beanName = AbstractApplicationContext.APPLICATION_EVENT_MULTICASTER_BEAN_NAME;
if (getApplicationContext().containsBean(beanName)) {
return (ApplicationEventMulticaster) getApplicationContext().getBean(beanName);
}
}
return null;
}
> missing to remove view from ApplicationEventMulticaster when view is closed
> ---------------------------------------------------------------------------
>
> Key: RCP-483
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-483
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Application Framework
> Reporter: Christian Heilmann
> Priority: Critical
>
> In DefaultViewDescriptor.createView() the view is added to the ApplicationEventMulticaster (ApplicationEventMulticaster.addApplicationListener(view)) as Listener.
> But when closing the view, it is missing to remove the view from the ApplicationEventMulticaster (ApplicationEventMulticaster.removeApplicationListener(view)).
> Please remove the view from the ApplicationEventMulticaster when it is closed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-22 11:34:19
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27887 ]
Peter De Bruycker commented on RCP-488:
---------------------------------------
so now you can do the following:
<snip>
...
dia.setInputConstraint(new Constraint() {
public boolean test(Object argument) {
final String name = (String) argument;
boolean found = ... check if the name already exist
if (found) {
dia.setMessage(new DefaultMessage("not unique", Severity.ERROR));
}
return !found;
}
});
...
</snip>
> InputApplicationDialog.getValidationReporter() could be public
> --------------------------------------------------------------
>
> Key: RCP-488
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-488
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Helper Classes
> Reporter: Benoit Xhenseval
> Assignee: Peter De Bruycker
>
> I'm trying to use the InputApplicationDialog and I think that a private method should be made public: getValidationReporter().
> Some basic rules are created for string length for instance but I would like to validate the input once the user tries to press enter (e.g. check the DB/Server).
> I wanted to use the setInputConstraint(Constraint c) and it works fine, the server detects a duplicate and returns false so the dialog cannot be closed via OK, however how could I notify the user in the error reporting area?
> If the method getValidationReporter() was public, one could simply do it like this:
> final InputApplicationDialog dia = new InputApplicationDialog(nameModel, "name");
> dia.setTitle(getMessage("xxxx.title"));
> dia.setInputLabelMessage("Enter a query name");
> dia.setInputConstraint(new Constraint() {
> public boolean test(Object argument) {
> final String name = (String) argument;
> boolean found = ... check if the name already exist
> if (found) {
> dia.getValidationReporter().setMessage(
> new DefaultMessage("not unique", Severity.ERROR));
> }
> return !found;
> }
> });
> dia.showDialog();
>
> So, may I suggest that this method is made public?
> Of course, there may be a better way... could someone enlighten me?
> Thanks
> Benoit
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-22 11:34:19
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-488.
-----------------------------------
Resolution: Fixed
InputApplicationDialog now implements Messagable, so there is a public setMessage method that can be used.
> InputApplicationDialog.getValidationReporter() could be public
> --------------------------------------------------------------
>
> Key: RCP-488
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-488
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Helper Classes
> Reporter: Benoit Xhenseval
> Assignee: Peter De Bruycker
>
> I'm trying to use the InputApplicationDialog and I think that a private method should be made public: getValidationReporter().
> Some basic rules are created for string length for instance but I would like to validate the input once the user tries to press enter (e.g. check the DB/Server).
> I wanted to use the setInputConstraint(Constraint c) and it works fine, the server detects a duplicate and returns false so the dialog cannot be closed via OK, however how could I notify the user in the error reporting area?
> If the method getValidationReporter() was public, one could simply do it like this:
> final InputApplicationDialog dia = new InputApplicationDialog(nameModel, "name");
> dia.setTitle(getMessage("xxxx.title"));
> dia.setInputLabelMessage("Enter a query name");
> dia.setInputConstraint(new Constraint() {
> public boolean test(Object argument) {
> final String name = (String) argument;
> boolean found = ... check if the name already exist
> if (found) {
> dia.getValidationReporter().setMessage(
> new DefaultMessage("not unique", Severity.ERROR));
> }
> return !found;
> }
> });
> dia.showDialog();
>
> So, may I suggest that this method is made public?
> Of course, there may be a better way... could someone enlighten me?
> Thanks
> Benoit
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-22 10:32:17
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27885 ]
Peter De Bruycker commented on RCP-488:
---------------------------------------
if we let InputApplicationDialog implement the Messagable interface, the InputApplicationDialog gets a public setMessage method, that can be used to set messages (duh) on the dialog.
> InputApplicationDialog.getValidationReporter() could be public
> --------------------------------------------------------------
>
> Key: RCP-488
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-488
> Project: Spring Framework Rich Client Project
> Issue Type: Improvement
> Components: Helper Classes
> Reporter: Benoit Xhenseval
> Assignee: Peter De Bruycker
>
> I'm trying to use the InputApplicationDialog and I think that a private method should be made public: getValidationReporter().
> Some basic rules are created for string length for instance but I would like to validate the input once the user tries to press enter (e.g. check the DB/Server).
> I wanted to use the setInputConstraint(Constraint c) and it works fine, the server detects a duplicate and returns false so the dialog cannot be closed via OK, however how could I notify the user in the error reporting area?
> If the method getValidationReporter() was public, one could simply do it like this:
> final InputApplicationDialog dia = new InputApplicationDialog(nameModel, "name");
> dia.setTitle(getMessage("xxxx.title"));
> dia.setInputLabelMessage("Enter a query name");
> dia.setInputConstraint(new Constraint() {
> public boolean test(Object argument) {
> final String name = (String) argument;
> boolean found = ... check if the name already exist
> if (found) {
> dia.getValidationReporter().setMessage(
> new DefaultMessage("not unique", Severity.ERROR));
> }
> return !found;
> }
> });
> dia.showDialog();
>
> So, may I suggest that this method is made public?
> Of course, there may be a better way... could someone enlighten me?
> Thanks
> Benoit
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Quinten V. (JIRA) <no...@at...> - 2007-11-21 15:32:17
|
need for PartialLookupViewDescriptor ?
--------------------------------------
Key: RCP-496
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-496
Project: Spring Framework Rich Client Project
Issue Type: Improvement
Components: Application Framework
Affects Versions: 0.3.0
Environment: WinXp, JDK1.5_11
Reporter: Quinten Verheyen
Priority: Minor
I was asked to create a JRIA issue for this on the Spring forum.
I noticed the current view descriptors do not always suffice.
Currently you either have a choice between a) a new view instance with the same collaborator instances or b) a new view instance with all of it's collaborars being reinstantiated to.
The first option is by using DefaultViewDescriptor, passing through a "viewClass" and a "viewProperties".
However, I discovered this default approach can be problematic since multiple ApplicationWindow's reference different view instances (of the same view) that refer to the same collaborator instances underneath. This is ok when all of the collaborators are singleton services, but when you have a (statefull) prototype collaborator you can experience strange behaviour. I actually wanted two different instances for that specific collaborator (1 for each window), but that meant I should not provide it in "viewProperties" of a view descriptor. Also, marking any beans used underneath as prototype beans doesn't work since the view descriptor is a singleton, so your beans are only instantiated once, prototype or not.
The alternative option was to use LookupViewDescriptor, passing through a prototype bean, but that's not possible if you want some things to be statefull of course.
So the only thing I could think of was to write a custom ViewDescriptor that accepts a "reloadableViewProperties" and changes the mentioned properties in the already instantiated BeanWrapper underneath (that loaded the viewProperties first). The advantage is of course that the bean type (prototype or singleton) will be taken into account this time (since it is bean factory aware).
protected View createView() {
// ...
BeanWrapper wrapper = new BeanWrapperImpl(view);
if (viewProperties != null) {
wrapper.setPropertyValues(viewProperties);
}
if (reloadableViewProperties != null) {
MutablePropertyValues pvs = new MutablePropertyValues(reloadableViewProperties);
List propertyValues = pvs.getPropertyValueList();
for (Iterator it = propertyValues.iterator(); it.hasNext();) {
PropertyValue pv = (PropertyValue) it.next();
Object bean = getBeanFactory().getBean(pv.getName());
wrapper.setPropertyValue(pv.getName(), bean);
}
}
(btw, sadly I had to duplicate the code from DefaultViewDescriptor it isn't designed with extensibility in mind ?)
So the approach solved my problem, but I cannot imagine I'm the first one encountering this "multiple window" impact on view descriptors. So I'm wondering if there are better solutions ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-21 13:33:20
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27868 ]
Peter De Bruycker commented on RCP-495:
---------------------------------------
ToolTipInterceptor + Factory checked in.
usage:
in your app context : formComponentInterceptorFactory bean:
add
<bean class="org.springframework.richclient.form.builder.support.ToolTipInterceptorFactory">
<property name="processComponent" value="true|false"/>
<property name="processLabel" value="true|false"/>
</bean>
the properties processComponent en processLabel are true by default, and control whether the component and/or the label should have their tooltip text set with the caption of the property.
> Provide tooltip feature for form components
> -------------------------------------------
>
> Key: RCP-495
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-495
> Project: Spring Framework Rich Client Project
> Issue Type: New Feature
> Components: Binding System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
>
> from forum (http://forum.springframework.org/showthread.php?t=46130):
> is there a way to define and use tooltips for components like JTextField (not just buttons) etc. which are defined in the property files like:
> # Contact form
> address.address1.label=Address 1
> address.address1.tooltip=This is the private address information
> address.address2.label=Address 2
> address.address2.tooltip=This is the business address information
> address.address3.label=Address 3
> address.address3.tooltip=Here you will be reached durring the holidays
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-21 13:33:20
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-495.
-----------------------------------
Resolution: Fixed
> Provide tooltip feature for form components
> -------------------------------------------
>
> Key: RCP-495
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-495
> Project: Spring Framework Rich Client Project
> Issue Type: New Feature
> Components: Binding System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
>
> from forum (http://forum.springframework.org/showthread.php?t=46130):
> is there a way to define and use tooltips for components like JTextField (not just buttons) etc. which are defined in the property files like:
> # Contact form
> address.address1.label=Address 1
> address.address1.tooltip=This is the private address information
> address.address2.label=Address 2
> address.address2.tooltip=This is the business address information
> address.address3.label=Address 3
> address.address3.tooltip=Here you will be reached durring the holidays
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-21 13:29:17
|
[ http://opensource.atlassian.com/projects/spring/browse/RCP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter De Bruycker resolved RCP-494.
-----------------------------------
Resolution: Fixed
> FormComponentInterceptor.processLabel is never called
> -----------------------------------------------------
>
> Key: RCP-494
> URL: http://opensource.atlassian.com/projects/spring/browse/RCP-494
> Project: Spring Framework Rich Client Project
> Issue Type: Bug
> Components: Binding System
> Reporter: Peter De Bruycker
> Assignee: Peter De Bruycker
>
> FormComponentInterceptor.processLabel is never called
> should be called from AbstractFormBuilder.createLabelFor method
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Peter De B. (JIRA) <no...@at...> - 2007-11-21 13:24:15
|
Provide tooltip feature for form components
-------------------------------------------
Key: RCP-495
URL: http://opensource.atlassian.com/projects/spring/browse/RCP-495
Project: Spring Framework Rich Client Project
Issue Type: New Feature
Components: Binding System
Reporter: Peter De Bruycker
Assignee: Peter De Bruycker
from forum (http://forum.springframework.org/showthread.php?t=46130):
is there a way to define and use tooltips for components like JTextField (not just buttons) etc. which are defined in the property files like:
# Contact form
address.address1.label=Address 1
address.address1.tooltip=This is the private address information
address.address2.label=Address 2
address.address2.tooltip=This is the business address information
address.address3.label=Address 3
address.address3.tooltip=Here you will be reached durring the holidays
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/spring/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|