Menu
▾
▴
springframework-rcp-dev — Spring Rich Client developer list
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
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Reporter <lug...@gm...> - 2010-04-26 15:59:37
|
O-la-la... huge or not? http://ho.io/hogeor |
|
From: Reporter <lug...@gm...> - 2010-04-24 09:49:28
|
Oh, its amazing. I have no words to describe http://cut.io/CEV4 |
|
From: Brucz S. <sul...@ho...> - 2010-04-23 08:11:11
|
; he was complaining of rheumatism--" "There are so many things to complain of in this household that it would never have occurred to me to complain of rheumatism," murmured Clovis. "He was complaining of rheumatism," continued Mrs. Momeby, trying to throw a chilling inflection into a voice that was already doing a good deal of sobbing and talking at high pressure as well. She was again interrupted. "There is no such thing as rheumatism," said Miss Gilpet. She said it with the conscious air of defiance that a waiter adopts in announcing that the cheapest-priced claret in the wine-list is no more. She did not proceed, however, to offer the alternative of some more expensive malady, |
|
From: Reporter <lug...@gm...> - 2010-04-22 02:55:39
|
O-ha-ha! Have You Seen? What are they doing? Extremely fun clip! http://cli.gs/Sb4JN2 |
|
From: Reporter <lug...@gm...> - 2010-04-19 19:29:57
|
Just take a look! We have found new young stars. Please rate their first erotic clip. http://afx.cc/angelina Thanks |
|
From: Anton A. (JIRA) <no...@sp...> - 2010-04-12 12:18:10
|
Potential LARGE memory leak in Spring RC
----------------------------------------
Key: RCP-632
URL: https://jira.springsource.org/browse/RCP-632
Project: Spring Rich Client Project
Issue Type: Bug
Affects Versions: 1.1.0
Reporter: Anton Antonov
Assignee: Lieven Doclo
Priority: Major
An instance of PropertyChangeListener is added to PageComponent (see DefaultPageComponentPane.java line 47), but never removed. For this reason PageComponent can never be collected by GC.
See more detailed description here: http://markmail.org/message/gna2g3nbaj6vivtt
Workaround.
I used SimplePageComponentPaneFactory instead of DefaultPageComponentPaneFactory (see part of context.xml below):
{code:xml}
<bean id="applicationServices"
class="org.springframework.richclient.application.support.DefaultApplicationServices"
...
<property name="pageComponentPaneFactory">
<bean class="org.springframework.richclient.application.support.SimplePageComponentPaneFactory"/>
</property>
</bean>
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Adam A. (JIRA) <no...@sp...> - 2010-04-09 02:41:05
|
[ https://jira.springsource.org/browse/RCP-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52805#action_52805 ]
Adam Armistead commented on RCP-626:
------------------------------------
Ok, this is still broken. If I open a view it gets created, if i close a view it goes away, but the Dockable is still registered with the DockingContext. If I open a it again, it gets recreated and a duplicate Dockable gets added to the DockingContext, etc. So if I open and close one dockable 10 times i have 10 registered with the DockingContext now.
First I tried to override the #findPageComponent(String) method. In order to attempt to get the dockable we are looking for from the DockingContext if it wasn't found with the superclass implementation. I could then #addPageComponent to add it to the list of page components for the page and #getLayoutManager().addDockable(desktop,getDockable(pageComponent)) to add the dockable to the desktop. This seemed to work, until I added an initialLayout file, then my views createControl() method doesn't get called, hrm.
In the process I found that the default layout manager is calling #desktop.remove(Dockable). This method doesn't unregister the dockable in the DockingContext, but close does. So I tried changing that to use the close method. That results in views being destroyed when closed and recreated when opened again, instead of just "hidden" when closed, and "visible" when opened again.
I also tried changing my VLDockingApplicationWindow to unregister dockables when a new page is shown.
Anyway, I haven't found the solution yet, things seem to work either when I'm not using initialLayout files, or when I am, and sometimes break when switching between application pages, and sometimes not. This became apparent when I wrote a more than trivial VLDockingLayoutManager as adding things to tabs and so on apparently works a bit differently than just throwing views on the desktop and it started throwing NPEs.
I'll keep working on it but if anyone gets sometime, help is always appreciated.
> VLDocking integration broken
> ----------------------------
>
> Key: RCP-626
> URL: https://jira.springsource.org/browse/RCP-626
> Project: Spring Rich Client Project
> Issue Type: Bug
> Reporter: Adam Armistead
> Assignee: Lieven Doclo
> Priority: Major
> Attachments: RCP-626.patch, RCP-626_1.patch
>
>
> In the VLDocking integrations each application page is its own DockingDesktop instance. Pages are not being saved and loaded correctly resulting in floating dockables remaining on screen after showing a new page that should not show the floating dockable as a view. Floating dockables are not positioned correctly when a page is shown, and when closing a page it is saved once for each page created, so if you create 5 application pages and close one of them it is saved 5 times in a row.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Lieven D. (JIRA) <no...@sp...> - 2010-04-08 19:52:01
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52791#action_52791 ]
Lieven Doclo commented on RCP-631:
----------------------------------
Matthieu,
I think the best solution in this case would be if the formmodel had a switch that enables this behavior. The default setting should produce the behavior as it is now, in the alternate setting it should assume that after setting a formobject the formmodel should never be dirty. Any thoughts on this?
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: <wp...@gm...> - 2010-04-07 12:17:01
|
<html><head><title>
TrueSwitch
</title><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta></head><style type="text/css"><!--
body {
margin-left: 0px;
margin-top: 0px;
margin-right: 0px;
margin-bottom: 0px;
}
.style1 {
font-size: small;
font-family: Arial, Helvetica, sans-serif;
font-weight: bold;
color: #0066FF;
}
.style5 {
color: #5294C8;
font-size: large;
font-family: Arial, Helvetica, sans-serif;
font-weight: bold;
}
.style9 {
font-size: x-large;
font-family: Arial, Helvetica, sans-serif;
font-weight: bold;
}
.style11 {font-size: x-small}
.style12 {font-family: Arial, Helvetica, sans-serif}
.style14 {font-size: 12px}
.style16 {color: #666666}
.style17 {font-size: 12px; font-family: Arial, Helvetica, sans-serif; color: #666666; }
.style18 {
font-size: medium;
font-family: Arial, Helvetica, sans-serif;
color: #009900;
font-weight: bold;
}
.style19 {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 14px; }
.style20 {font-size: large; font-family: Arial, Helvetica, sans-serif; color: #006600; font-weight: bold; }
.style21 {font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 14px; font-weight: bold; }
.style22 {font-size: medium; font-family: Arial, Helvetica, sans-serif; font-weight: bold; }
.style23 {color: #000000}
.style25 {font-family: Arial, Helvetica, sans-serif; font-size: small; }
.style26 {
font-family: Arial, Helvetica, sans-serif;
font-size: small;
}
.style27 {color: #0066FF}
--></style><div width="550"><h1>Hello, I have a new e-mail address</h1><p><strong>Instead of contacting me at wp...@gm... you can now reach me at my new Hotmail address. Please send all your future e-mail messages to me at wpc...@ho.... In fact, you can simply reply to this message to contact me.</strong></p><p></p><p><strong>Old E-mail Address: wp...@gm...</strong></p><p><strong>New E-mail Address: wpc...@ho...</strong></p><p></p><p><strong>Be sure to update your address book now.</strong></p><p></p><p><strong>Thank you!</strong></p></div></html>
|
|
From: Matthieu S. (JIRA) <no...@sp...> - 2010-04-07 07:44:34
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52723#action_52723 ]
Matthieu Steyt commented on RCP-631:
------------------------------------
Can we take a decision here? This is quite important for us...
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Reporter <lug...@gm...> - 2010-04-06 19:18:16
|
Hottest collection of amazing clips with celebrities. NAKED Jennifer! http://fwd4.me/KHS |
|
From: Reporter <lug...@gm...> - 2010-04-04 22:11:18
|
Wanna find a friend for chatting? For flirting? Or maybe for more? Millions boys and girls are waiting for You in online video chat! Join us now! http://go2.lv/webcam |
|
From: Reporter <lug...@gm...> - 2010-04-03 01:41:51
|
No panties subway ride - HAVE YOU SEEN THIS???! http://afx.cc/no-panties |
|
From: Matthieu S. (JIRA) <no...@sp...> - 2010-04-02 08:15:35
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52615#action_52615 ]
Matthieu Steyt commented on RCP-631:
------------------------------------
Reconsider the example with object X x1 = new X(id=1, A=a1(id=5), B=10) with A another domain object and you set this bean on a formmodel that sets the value of A to an instance a2 with id=5 (fresh from a db back-end) when B=10 (this is necessary for user interaction with the form) and of course a2.equals(a1). But as the value change detector checks on java instance equality (==) instead of using the equals() implementation our formmodel will be dirty after setting x1 on it. I don't think this is desired behaviour.
One could say, use a value change detector that uses equals(), but:
* does not work with referables/derived valuemodels (when you change a property on the referred entity, you expect the derived value model to change even if oldEntity.equals(newEntity))
* a considerable amount of bindings make intensive use of cloning to make a valuemodel clear that something has changed... which will break if you use a value change detector that uses equals()...
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Geoffrey De S. (JIRA) <no...@sp...> - 2010-04-01 07:28:35
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52592#action_52592 ]
Geoffrey De Smet commented on RCP-631:
--------------------------------------
I agree with these 3 arguments:
* Matthieu: 1) The current for loop is unstable because it is order dependend (and the order is undefined)
* Lieven, Jan: 2) After setting a formObject, the formObject can be dirty (due to listeners)
* ?: 3) The original author of boolean clearValueModels was fixing a problem, we have to make sure we don't regress that problem
Examples to prove some of those arguments
* 1) See Matthieu's patch which simply breaks on the order in which the user code calls listeners
* 2) A Contact (think Thunderbird) has a property firstName, lastName, displayName.
** if displayName is empty and firstName or lastName are changed, then displayName = firstName + " " + lastName
** if the db has a row: firstName = "Kabouter", lastName = "Plop", displayName = ""
*** then it will be shown to the user in the form as firstName = "Kabouter", lastName = "Plop", displayName = "Kabouter Plop"
*** In that case the save button should be enabled (so it should be dirty)
**** because otherwise if you send a mail to that contact, the display name of that contact is not the displayName shown in the unsaved form, "Kabouter Plop"
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Lieven D. (JIRA) <no...@sp...> - 2010-03-31 14:33:34
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52569#action_52569 ]
Lieven Doclo commented on RCP-631:
----------------------------------
_They really should enable comment editing again_
Depends on what you consider to be dirty.
So in your case, say you have a dummy object X(A=1, and B=2) and you set this bean on a formmodel that sets the value of B to 3 whenever A is changed through a valuechangelistener.
The following will fail:
{code}
X x = new X();
... // sets values of A=1 and B=2
formModel.setFormObject;
if(!formModel.isDirty) // formModel isn't dirty, so one would assume no values have been changed
{ assertEquals(x, formModel.getFormObject); // fails because B is 3 now, although the form model is not dirty } {code}
I would assume that when the formmodel isn't dirty, the object behind the formmodel hasn't been changed. With your changes, I can't be sure anymore, as listeners on the formmodel may have altered the object...
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Lieven D. (JIRA) <no...@sp...> - 2010-03-31 14:31:35
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52568#action_52568 ]
Lieven Doclo commented on RCP-631:
----------------------------------
Depends on what you consider to be dirty.
So in your case, say you have a dummy object X(A=1, and B=2) and you set this bean on a formmodel that sets the value of B to 3 whenever A is changed through a valuechangelistener.
The following will fail:
{code}
X x = new X();
... // sets values of A=1 and B=2
formModel.setFormObject(x);
if(!formModel.isDirty) // formModel isn't dirty, so one would assume no values have been changed
{
assertEquals(x, formModel.getFormObject); // fails because B is 3 now, although the form model is not dirty
}
{/code}
I would assume that when the formmodel isn't dirty, the object behind the formmodel hasn't been changed. With your changes, I can't be sure anymore, as listeners on the formmodel may have altered the object...
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Jan H. (JIRA) <no...@sp...> - 2010-03-31 14:18:35
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52567#action_52567 ]
Jan Hoskens commented on RCP-631:
---------------------------------
The same goes for the opposite: when setting a formobject, a propertyChangeListener updates some value which needs to be confirmed by the user. Hence expect the formModel to be dirty because of the property change listener.
Not sure which way to go yet.
Additionally I would expect a default object to be complete, hence if you set a formObject, it should contain all values. When property change listeners fire, it would only set the same default value and this won't trigger a dirty if done correctly. Or is this not the case?
This might need some more thought before a complete solution pops up...
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Matthieu S. (JIRA) <no...@sp...> - 2010-03-31 14:00:37
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthieu Steyt updated RCP-631:
-------------------------------
Attachment: AbstractFormModelTests.java.patch
It seems that this test case has been lucky for a long time...
After switching the role of the two properties in this test case, it fails. This because simpleProperty is always cleared after singleSelectListProperty (this as a side effect of the used Map implementation used to hold the mediatingValueModels). See attachment for a patch containing such a switch.
So, as it seems that the behaviour as tested in testSetFormObjectUpdatesDirtyState has never worked correctly, the question is : what should be the correct behaviour? The javadoc states "Disconnect view from data in MediatingValueModels, possibly clearing them afterwards.", so I expect all valuemodels to be cleared after calling this method with clearValueModels = 'true'
The use case is simple, after calling setFormObject() on the formmodel I expect the formmodel to be 'not dirty'.
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
> Attachments: AbstractFormModelTests.java.patch
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Lieven D. (JIRA) <no...@sp...> - 2010-03-31 13:19:36
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52563#action_52563 ]
Lieven Doclo commented on RCP-631:
----------------------------------
Can you comment a simple use case for this issue?
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Geoffrey De S. (JIRA) <no...@sp...> - 2010-03-31 12:45:34
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoffrey De Smet reopened RCP-631:
----------------------------------
reopened, Matthieu is looking at Lieven's comment before resolving
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Geoffrey De S. (JIRA) <no...@sp...> - 2010-03-31 12:43:34
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Geoffrey De Smet resolved RCP-631.
----------------------------------
Resolution: Complete
Fix Version/s: 1.1.1
Assignee: Geoffrey De Smet (was: Lieven Doclo)
fixed by Matthieu
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Geoffrey De Smet
> Priority: Major
> Fix For: 1.1.1
>
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Lieven D. (JIRA) <no...@sp...> - 2010-03-31 12:29:36
|
[ https://jira.springsource.org/browse/RCP-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52560#action_52560 ]
Lieven Doclo commented on RCP-631:
----------------------------------
After changing to the suggested solution, one of the tests is failing: testSetFormObjectUpdatesDirtyState on AbstractFormModelTests. This test actually mimics the behavior as shown, but revolves around the assumption that the object should be dirty: if the object composed by the valuemodels in a formmodel isn't the same as the object that was used to create said formmodel, it should be dirty.
[code]
fm.getValueModel("simpleProperty").addValueChangeListener(new PropertyChangeListener() {
public void propertyChange(PropertyChangeEvent evt) {
fm.getValueModel("singleSelectListProperty").setValue(null);
}
});
TestBean newBean = new TestBean();
newBean.setSimpleProperty("simpleProperty");
newBean.setSingleSelectListProperty("singleSelectListProperty");
fm.setFormObject(newBean);
assertEquals(null, fm.getValueModel("singleSelectListProperty").getValue());
assertTrue(fm.isDirty());
[/code]
When your solution would be used, the last statement would return false, while the valuemodel's value (null) isn't the same as the original value ("singleSelectListProperty") which means it should be dirty.
> Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: RCP-631
> URL: https://jira.springsource.org/browse/RCP-631
> Project: Spring Rich Client Project
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0
> Reporter: Matthieu Steyt
> Assignee: Lieven Doclo
> Priority: Major
>
> Consider the following example:
> A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
> 1. valueChangeEvents of A are delivered
> 2. A is cleared (dirty = false)
> 3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
> 4. B is cleared (dirty = false)
> Result:
> A is dirty, while it is the intention of the method that A is cleared.
> Solution:
> Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Matthieu S. (JIRA) <no...@sp...> - 2010-03-31 12:00:35
|
Clearing the valuemodels in AbstractFormModel#setDeliverValueChangeEvents(boolean,boolean) should occur after all ValueChangeEvents are delivered.
--------------------------------------------------------------------------------------------------------------------------------------------------
Key: RCP-631
URL: https://jira.springsource.org/browse/RCP-631
Project: Spring Rich Client Project
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0
Reporter: Matthieu Steyt
Assignee: Lieven Doclo
Priority: Major
Consider the following example:
A formmodel containing two valuemodels A and B. B has a changelistener registered in which A gets a new value. The current implementation of the setDeliverValueChangeEvents(boolean,boolean) method uses the following sequence:
1. valueChangeEvents of A are delivered
2. A is cleared (dirty = false)
3. valueChangeEvents of B are delivered, as a consequence A is adapted (back to dirty)
4. B is cleared (dirty = false)
Result:
A is dirty, while it is the intention of the method that A is cleared.
Solution:
Two for-loops instead of one. One for firing the events and one for clearing the value models.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.springsource.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
|
|
From: Reporter <lug...@gm...> - 2010-03-29 17:17:22
|
Who is this actor? im pretty sure hes famous but i need to know who he is? http://ho.io/whois |
406 messages has been excluded from this view by a project administrator.
