springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-473) Allow VLDockingApplicationPageFactory to reuse pages

[Geoffrey De S. (JIRA) <no...@at...>]

    [ http://opensource.atlassian.com/projects/spring/browse/RCP-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_23672 ] 

Geoffrey De Smet commented on RCP-473:
--------------------------------------

Blocks RCP-469

> Allow VLDockingApplicationPageFactory to reuse pages
> ----------------------------------------------------
>
>                 Key: RCP-473
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-473
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Helper Classes
>    Affects Versions: 0.3.0
>         Environment: Any
>            Reporter: Rogan Dawes
>            Assignee: Peter De Bruycker
>         Attachments: vldocking_page_reuse.patch
>
>
> One way of implementing User controllable perspectives is to make each perspective an ApplicationPage instance, and simply change between them as required. One downside of this approach is that the current VLDockingApplicationPageFactory simply recreates the pages on every switch, discarding any state that the child PageComponents may have had.
> The attached patch provides an option to allow pages to be cached and reused, thus preserving the state in those pages.
> Question:
> It seems that ApplicationPage.close() is not called when a new page is opened. Is this something that is wrong in my own code, or is this something that the framework should be doing for me?

-- 
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

        

[Springframework-rcp-dev] Support for buttons (actions) on forms

[Andy D. <an...@ma...>]

Has anyone given much thought to support for buttons or actions on 
forms?  When you think about it, Spring's Form framework is MVC, with 
the Form (and binding) being the controller.  With this in mind, I'd 
like to "bind" buttons on the form to actions.  Since the Form instance 
ends up being the closest thing to a Controller, it seems to me the best 
approach would be to register actions (ActionCommand, or 
ActionCommandExecutor?) with the Form.  Components in the view can then 
bind to these actions by name (ActionCommands have an 'id'), much in the 
same way components are bound to properties by name.
In our case, we use a UI designer, and then a custom FormUIProvider to 
load and bind the generated UI at runtime.  We use a convention where 
the UI designer names each component on the UI that can be bound (via 
Component's name property) with the name of the property to bind to + 
"_bound".  So, if I named a component "name_bound", then that component 
will be bound to the "name" property in the FormModel.  I'd like to do 
the same for a button.  If a button is bound, then it binds to the 
ActionCommand registered with the Form with the specified name.  This 
approach causes any "action" to be handled by the controller (Form 
instance), and avoids putting such code into the View or the backing 
bean.  With this approach, the MVC pattern is split up like so:

1. View = predesigned UI + FormUIProvider
2. Model = backing JavaBean + FormModel
3. Controller = Spring's Form + registered actions + Spring binding 
framework

Thoughts, suggestions?

  - Andy

Re: [Springframework-rcp-dev] Binder and Binding name confusing

[Jim M. <moo...@gm...>]

BindingFactory is a better/clearer name.  Fortunately, it's not something
used all over the place, so breakage should be minimal, even if it wasn't so
easy to do the search&replace.


On 5/4/07, Geoffrey De Smet <ge0...@gm...> wrote:
>
> I noticed that others, including myself at first, are confusing the
> concept of "Binder" and "Binding".
>
> Maybe we should consider renaming "Binder" to "BindingFactory" to make
> it a lot more self-explaining?
>
> Naming is very important to keep an API understandable. If we want to do
> this, we shouldn't put it off because it might break to many code -
> docced in upgrading.apt and a simple find and replace can tackle it.
> Larry's *Property to *Field method renames also turned out to make to
> API a lot more understandable.
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] Binder and Binding name confusing

[Geoffrey De S. <ge0...@gm...>]

I noticed that others, including myself at first, are confusing the
concept of "Binder" and "Binding".

Maybe we should consider renaming "Binder" to "BindingFactory" to make
it a lot more self-explaining?

Naming is very important to keep an API understandable. If we want to do
this, we shouldn't put it off because it might break to many code -
docced in upgrading.apt and a simple find and replace can tackle it.
Larry's *Property to *Field method renames also turned out to make to
API a lot more understandable.

-- 
With kind regards,
Geoffrey De Smet

Re: [Springframework-rcp-dev] DefaultFormModel eats exceptions in setValueSilently

[Jan H. <jh...@sc...>]

On Fri, 2007-05-04 at 09:25 +0200, Geoffrey De Smet wrote:
> Exceptions shouldn't be eaten, but DefaultFormModel does it on 
> setValueSilently.

I guess you are referring to DefaultFormModel.ValidatingFormValueModel,
the inner class that wraps valueModels.

> The method setValueSilently is used by comboboxbinders
> and in our use case sometimes contact the back-end.

This wrapper is used on all valueModels, not only in combination with
comboboxbindings (you probably meant the bindING, not the bindER, former
is the actual instance sitting between user input and valueModel while
the latter is the 'factory' for a type of binding).

> That back-end could throw an exception, which is currently eaten:
> 
> 
>          public void setValueSilently(Object value, 
> PropertyChangeListener listenerToSkip) {
>              try {
>                  ...
>                  super.setValueSilently(value, listenerToSkip);
>                  clearBindingError(this);
>              }
>              catch (Exception e) {
>                  logger.debug("Exception occurred setting value", e);
>                  raiseBindingError(this, value, e);
>              }
>          }
> 
> Is anyone relying on the fact that exceptions are eaten?

The implementation reflects a use-case: when the value is being written,
an exception is raised when the format/type/argument is incorrect this
exception will translate in a validation message to the user in order to
let him correct his input. I'm not sure how often this use-case pops up.

There is indeed a draw-back in this whole issue: all exceptions raised
during the setting of the value, including all exceptions raised in the
listeners, will result in this handling. The bindings are registered as
listeners and thus every exception raised is handled by this catch
routine. 

I'll see if I can change the behaviour of these listener-exceptions by
letting them fall through, while still allowing the binding-error
handling. Meanwhile, it's recommended that, when developing, you place a
debug-point at that catch block to see if it doesn't get triggered when
you're not expecting it to.

I don't know if this one is already raised as a jira issue, but it
definitely qualifies as one.

Gr-,
J.


 **** DISCLAIMER ****
 http://www.schaubroeck.be/maildisclaimer.htm

[Springframework-rcp-dev] DefaultFormModel eats exceptions in setValueSilently

[Geoffrey De S. <ge0...@gm...>]

Exceptions shouldn't be eaten, but DefaultFormModel does it on 
setValueSilently.
The method setValueSilently is used by comboboxbinders
and in our use case sometimes contact the back-end.
That back-end could throw an exception, which is currently eaten:


         public void setValueSilently(Object value, 
PropertyChangeListener listenerToSkip) {
             try {
                 ...
                 super.setValueSilently(value, listenerToSkip);
                 clearBindingError(this);
             }
             catch (Exception e) {
                 logger.debug("Exception occurred setting value", e);
                 raiseBindingError(this, value, e);
             }
         }

Is anyone relying on the fact that exceptions are eaten?

-- 
With kind regards,
Geoffrey De Smet

Re: [Springframework-rcp-dev] Changing ApplicationPage's

[Jonny W. <jwr...@gm...>]

Rogan,

some inline comments to your points. I have to admit I've not fleshed out my
perspective implementation as much as I'd like and there's aspects about it
I don't like, so this is useful for giving me some food for thought.



> Hi Jonny,
>
> Well, there was not really much infrastructure supporting changing pages
> until I added the various commands in a recent patch. I guess you could
> associate page change with workspace change, however, that seems to me
> to be more like a "reload context and start the app from scratch" event.


Yes, that is more or less what happens with the page switch in my JIDE based
implementation. I have to admit I don't really see many use cases for this,
I personally have never used it.

Your approach sounds superficially like a good idea, but it means that
> the PageDescriptor no longer corresponds to the ApplicationPage, which
> had a nice symmetry to it.


I guess I don't see this implication. In my approach each ApplicationPage
certainly has its own PageDescriptor, I don't see where the symmetry breaks
down. Can you elaborate?


I think that the approach I'm going to take is to just NOT close the
> pages when I switch to a new one, rather caching them for possible later
> use. This turns out to be rather easy to implement, and is restricted to
> 3 routines in the VLDockingApplicationPageFactory. However, it *DOES*
> mean that I end up with multiple instances of a View, for instance, if
> it is added to both Pages. This is probably a memory leak, which is why
> this behaviour is only enabled if the user specifically asks for it.


I'd agree this is another approach but in the end I think the only
difference between our approaches appears to be caching of already used
pages (in yours) or creating them, and closing the old, on page switch (in
mine). So, at that level our page concept is the same, just the side effects
of switching are different. The implications of these side effects are
reflected in how we chose to deal with perspectives.

You have equated that with a page whereas I have equated it with a specific
arrangement of views on a page. My approach results in another level of
organizational change in the application that, as you say, is more akin to
destroy and reload. This is well defined but I'm not sure how useful it is,
I've certainly never used it.

Any other users have input into what they consider a page vs a perspective
and how switching should behave?

Jonny

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-473) Allow VLDockingApplicationPageFactory to reuse pages

[Rogan D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rogan Dawes updated RCP-473:
----------------------------

    Attachment: vldocking_page_reuse.patch

> Allow VLDockingApplicationPageFactory to reuse pages
> ----------------------------------------------------
>
>                 Key: RCP-473
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-473
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Helper Classes
>    Affects Versions: 0.3.0
>         Environment: Any
>            Reporter: Rogan Dawes
>         Attachments: vldocking_page_reuse.patch
>
>
> One way of implementing User controllable perspectives is to make each perspective an ApplicationPage instance, and simply change between them as required. One downside of this approach is that the current VLDockingApplicationPageFactory simply recreates the pages on every switch, discarding any state that the child PageComponents may have had.
> The attached patch provides an option to allow pages to be cached and reused, thus preserving the state in those pages.
> Question:
> It seems that ApplicationPage.close() is not called when a new page is opened. Is this something that is wrong in my own code, or is this something that the framework should be doing for me?

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-473) Allow VLDockingApplicationPageFactory to reuse pages

[Rogan D. (JIRA) <no...@at...>]

Allow VLDockingApplicationPageFactory to reuse pages
----------------------------------------------------

                 Key: RCP-473
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-473
             Project: Spring Framework Rich Client Project
          Issue Type: New Feature
          Components: Helper Classes
    Affects Versions: 0.3.0
         Environment: Any
            Reporter: Rogan Dawes


One way of implementing User controllable perspectives is to make each perspective an ApplicationPage instance, and simply change between them as required. One downside of this approach is that the current VLDockingApplicationPageFactory simply recreates the pages on every switch, discarding any state that the child PageComponents may have had.

The attached patch provides an option to allow pages to be cached and reused, thus preserving the state in those pages.

Question:

It seems that ApplicationPage.close() is not called when a new page is opened. Is this something that is wrong in my own code, or is this something that the framework should be doing for me?

-- 
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

        

Re: [Springframework-rcp-dev] Changing ApplicationPage's

[Rogan D. <ro...@da...>]

Jonny Wray wrote:
> 
> Rogan,
> 
> I'm not sure what the expected behaviour is (that may have been long 
> lost) but I can tell you how I approached it when implementing the 
> multipage/multiview with the JIDE docking framework. I basically 
> considered a perspective as a specific arrangement (including visible or 
> not) of views. Thus when changing perspectives no views are created, 
> they are just moved, made visible or hidden.
> 
> The page change is different in that all current views are destroyed and 
> the new views created. This I thought was a different concept than a 
> perspective switch. Almost like the change in workspace switch vs a 
> perspective switch in Eclipse. I have to admit though, I have never 
> really used the page switch in a real application.
> 
> Jonny
> 

Hi Jonny,

Well, there was not really much infrastructure supporting changing pages 
until I added the various commands in a recent patch. I guess you could 
associate page change with workspace change, however, that seems to me 
to be more like a "reload context and start the app from scratch" event.

Your approach sounds superficially like a good idea, but it means that 
the PageDescriptor no longer corresponds to the ApplicationPage, which 
had a nice symmetry to it.

I think that the approach I'm going to take is to just NOT close the 
pages when I switch to a new one, rather caching them for possible later 
use. This turns out to be rather easy to implement, and is restricted to 
3 routines in the VLDockingApplicationPageFactory. However, it *DOES* 
mean that I end up with multiple instances of a View, for instance, if 
it is added to both Pages. This is probably a memory leak, which is why 
this behaviour is only enabled if the user specifically asks for it.

Thanks for your response.

Rogan

> On 4/19/07, *Rogan Dawes* <ro...@da... 
> <mailto:ro...@da...>> wrote:
> 
>     Hi folks,
> 
>     I have used ApplicationPage's to implement perspectives using the
>     VLDocking framework. It works very well to define multiple pages with
>     appropriate views and layouts, and to switch between them.
> 
>     One thing that does not work too well however, is that when switching
>     between perspectives/pages, the contents of the page are re-initalised
>     (or else created from scratch). E.g. if I have scrolled down a table of
>     items, or selected something, switch perspectives, then switch back, my
>     selection is gone, and the table is scrolled back to the top.
> 
>     I suppose that this is expected behaviour, and makes sense from the
>     perspective of not leaking memory. Would it make sense to have an
>     option
>     to not discard the contents of the page, on the premise that we are
>     likely to come back to it?
> 
>     Regards,
> 
>     Rogan

Badly wordwrapped patch follows. Thunderbird seems to ALWAYS wrap :-(

diff --git 
a/vldocking/src/main/java/org/springframework/richclient/application/vldocking/VLDockingApplicationPageFactory.java 
b/vldocking/src/main/java/org/springframework/richclient/application/vldocking/VLDockingApplicationPageFactory.java
index 45e307b..3fdbb94 100644
--- 
a/vldocking/src/main/java/org/springframework/richclient/application/vldocking/VLDockingApplicationPageFactory.java
+++ 
b/vldocking/src/main/java/org/springframework/richclient/application/vldocking/VLDockingApplicationPageFactory.java
@@ -15,6 +15,9 @@
   */
  package org.springframework.richclient.application.vldocking;

+import java.util.HashMap;
+import java.util.Map;
+
  import org.springframework.richclient.application.ApplicationPage;
  import org.springframework.richclient.application.ApplicationPageFactory;
  import org.springframework.richclient.application.ApplicationWindow;
@@ -25,12 +28,44 @@ import 
org.springframework.richclient.application.PageDescriptor;
   */
  public class VLDockingApplicationPageFactory implements 
ApplicationPageFactory {

+    private boolean reusePages = false;
+
+    private Map windowPages = new HashMap();
+
         /* (non-Javadoc)
          * @see 
org.springframework.richclient.application.ApplicationPageFactory#createApplicationPage(org.springframework.richclient.application.ApplicationWindow, 
org.springframework.richclient.application.PageDescriptor)
          */
         public ApplicationPage createApplicationPage(ApplicationWindow 
window, PageDescriptor descriptor) {
-               VLDockingApplicationPage page = new 
VLDockingApplicationPage(window, descriptor);
+        VLDockingApplicationPage page = null;
+        if (reusePages)
+            page = findPage(window, descriptor);
+        if (page != null) return page;
+        page = new VLDockingApplicationPage(window, descriptor);
+        if (reusePages)
+            cachePage(page);
          return page;
         }

+    protected VLDockingApplicationPage findPage(ApplicationWindow 
window, PageDescriptor descriptor) {
+        Map pages = (Map) windowPages.get(window);
+        if (pages == null) return null;
+        VLDockingApplicationPage page = (VLDockingApplicationPage) 
pages.get(descriptor.getId());
+        return page;
+    }
+
+    protected void cachePage(VLDockingApplicationPage page) {
+        Map pages = (Map) windowPages.get(page.getWindow());
+        if (pages == null) {
+            pages = new HashMap();
+            windowPages.put(page.getWindow(), pages);
+        }
+        pages.put(page.getId(), page);
+    }
+
+    /**
+     * @param reusePages the reusePages to set
+     */
+    public void setReusePages(boolean reusePages) {
+        this.reusePages = reusePages;
+    }
  }

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-472) Implement ExclusiveCommandGroup.createComboBox()

[Rogan D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rogan Dawes updated RCP-472:
----------------------------

    Attachment: combobox.patch

Sorry, previous patch excluded the imports.

> Implement ExclusiveCommandGroup.createComboBox()
> ------------------------------------------------
>
>                 Key: RCP-472
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-472
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Command System
>    Affects Versions: 0.3.0
>         Environment: Any
>            Reporter: Rogan Dawes
>         Attachments: combobox.patch, combobox.patch
>
>
> An ExclusiveCommandGroup can manifest as a series of RadioButtons, or a single selection Menu. Another way to present this (in the minimum space) is to use a JComboBox. The attached patch implements this idea.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-472) Implement ExclusiveCommandGroup.createComboBox()

[Rogan D. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rogan Dawes updated RCP-472:
----------------------------

    Attachment: combobox.patch

> Implement ExclusiveCommandGroup.createComboBox()
> ------------------------------------------------
>
>                 Key: RCP-472
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-472
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Command System
>    Affects Versions: 0.3.0
>         Environment: Any
>            Reporter: Rogan Dawes
>         Attachments: combobox.patch
>
>
> An ExclusiveCommandGroup can manifest as a series of RadioButtons, or a single selection Menu. Another way to present this (in the minimum space) is to use a JComboBox. The attached patch implements this idea.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-472) Implement ExclusiveCommandGroup.createComboBox()

[Rogan D. (JIRA) <no...@at...>]

Implement ExclusiveCommandGroup.createComboBox()
------------------------------------------------

                 Key: RCP-472
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-472
             Project: Spring Framework Rich Client Project
          Issue Type: New Feature
          Components: Command System
    Affects Versions: 0.3.0
         Environment: Any
            Reporter: Rogan Dawes
         Attachments: combobox.patch

An ExclusiveCommandGroup can manifest as a series of RadioButtons, or a single selection Menu. Another way to present this (in the minimum space) is to use a JComboBox. The attached patch implements this idea.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-471) objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class

[Jan H. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Hoskens closed RCP-471.
---------------------------

         Assignee: Jan Hoskens
       Resolution: Fixed
    Fix Version/s: 0.3.0

Patch applied:

http://svn.sourceforge.net/spring-rich-c/?rev=1749&view=rev

Thanks for reporting & providing a patch.

> objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-471
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-471
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1, 0.3.0
>         Environment: all
>            Reporter: Arne Limburg
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: LifecycleApplicationEvent.patch
>
>
> objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not of the same class as the source-object of the event. The call to isAssignableFrom must be the other way round.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-471) objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class

[Arne L. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arne Limburg updated RCP-471:
-----------------------------

    Attachment: LifecycleApplicationEvent.patch

Patch applied.

> objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-471
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-471
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>    Affects Versions: 0.1.0, 0.2.0, 0.2.1, 0.3.0
>         Environment: all
>            Reporter: Arne Limburg
>         Attachments: LifecycleApplicationEvent.patch
>
>
> objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not of the same class as the source-object of the event. The call to isAssignableFrom must be the other way round.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-471) objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class

[Arne L. (JIRA) <no...@at...>]

objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not same class
------------------------------------------------------------------------------------------

                 Key: RCP-471
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-471
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
          Components: Application Framework
    Affects Versions: 0.2.1, 0.2.0, 0.1.0, 0.3.0
         Environment: all
            Reporter: Arne Limburg
         Attachments: LifecycleApplicationEvent.patch

objectIs in LifecycleApplicationEvent returns wrong result, if parameter is not of the same class as the source-object of the event. The call to isAssignableFrom must be the other way round.

-- 
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

        

Re: [Springframework-rcp-dev] Changing ApplicationPage's

[Jonny W. <jwr...@gm...>]

Rogan,

I'm not sure what the expected behaviour is (that may have been long lost)
but I can tell you how I approached it when implementing the
multipage/multiview with the JIDE docking framework. I basically considered
a perspective as a specific arrangement (including visible or not) of views.
Thus when changing perspectives no views are created, they are just moved,
made visible or hidden.

The page change is different in that all current views are destroyed and the
new views created. This I thought was a different concept than a perspective
switch. Almost like the change in workspace switch vs a perspective switch
in Eclipse. I have to admit though, I have never really used the page switch
in a real application.

Jonny

On 4/19/07, Rogan Dawes <ro...@da...> wrote:
>
> Hi folks,
>
> I have used ApplicationPage's to implement perspectives using the
> VLDocking framework. It works very well to define multiple pages with
> appropriate views and layouts, and to switch between them.
>
> One thing that does not work too well however, is that when switching
> between perspectives/pages, the contents of the page are re-initalised
> (or else created from scratch). E.g. if I have scrolled down a table of
> items, or selected something, switch perspectives, then switch back, my
> selection is gone, and the table is scrolled back to the top.
>
> I suppose that this is expected behaviour, and makes sense from the
> perspective of not leaking memory. Would it make sense to have an option
> to not discard the contents of the page, on the premise that we are
> likely to come back to it?
>
> Regards,
>
> Rogan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] Changing ApplicationPage's

[Rogan D. <ro...@da...>]

Hi folks,

I have used ApplicationPage's to implement perspectives using the 
VLDocking framework. It works very well to define multiple pages with 
appropriate views and layouts, and to switch between them.

One thing that does not work too well however, is that when switching 
between perspectives/pages, the contents of the page are re-initalised 
(or else created from scratch). E.g. if I have scrolled down a table of 
items, or selected something, switch perspectives, then switch back, my 
selection is gone, and the table is scrolled back to the top.

I suppose that this is expected behaviour, and makes sense from the 
perspective of not leaking memory. Would it make sense to have an option 
to not discard the contents of the page, on the premise that we are 
likely to come back to it?

Regards,

Rogan

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-470) An exception handling ChainPurger should replace evaluatedChainedIndex

[Geoffrey De S. (JIRA) <no...@at...>]

An exception handling ChainPurger should replace evaluatedChainedIndex
----------------------------------------------------------------------

                 Key: RCP-470
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-470
             Project: Spring Framework Rich Client Project
          Issue Type: New Feature
          Components: Application Framework
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
             Fix For: 0.3.0


evaluatedChainedIndex only applies to MessagesDialogExceptionHandler, but it should also be useable on the delegating exception handler.

evaluatedChainedIndex is to clumsy in most circumstances as it's the type of the exceptions, instead of the level that decide if it should be evaluated.

ExceptionChainPurger to the rescue, pluggable into any ExceptionHandler.
It cuts the first part of an exception chain if needed.
It contains 2 properties:

- alwaysEvaluatePrioritizedList: List<Class<? extends Exception>>: for example it contains "SQL504Exception", then any chain which contains that type of exception will be evaluated as the SQL504Exception instance.

- alwaysTryToUnwrapList: List<Class<? extends Exception>>: for example it contains "WrappingServiceException", so it always tries to unwrap that.
TODO: find beter names, suggestions 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

        

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-469) Refactor spring-richclient-vldocking to spring-richclient-docking

[Geoffrey De S. (JIRA) <no...@at...>]

Refactor spring-richclient-vldocking to spring-richclient-docking
-----------------------------------------------------------------

                 Key: RCP-469
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-469
             Project: Spring Framework Rich Client Project
          Issue Type: Task
          Components: Build System
            Reporter: Geoffrey De Smet
            Assignee: Geoffrey De Smet
             Fix For: 0.3.0


as discussed on the list a couple of weeks ago.

I 'll do it in a weekend sooner or later, so make sure everything in that module is checked in.

-- 
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

        

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-466) spring-richclient-core's POM transitively brings in too much

[Geoffrey De S. (JIRA) <no...@at...>]

     [ http://opensource.atlassian.com/projects/spring/browse/RCP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet resolved RCP-466.
----------------------------------

      Assignee: Geoffrey De Smet  (was: Jim Moore)
    Resolution: Fixed

the logback/avalon etc jars could still leak out in other modules, but not they shouldn't no more.

> spring-richclient-core's POM transitively brings in too much
> ------------------------------------------------------------
>
>                 Key: RCP-466
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-466
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Application Framework
>    Affects Versions: 0.3.0
>            Reporter: Jim Moore
>            Assignee: Geoffrey De Smet
>            Priority: Minor
>             Fix For: 0.3.0
>
>
> The spring-core dependency transitively brings in the Avalon framework, LogKit, log4j, and the Servlet API.  There's no need for any of those to be brought over to everyone's project via Spring Rich.

-- 
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

        

[Springframework-rcp-dev] Change in behaviour of nested properties?

[Geoffrey De S. <ge0...@gm...>]

BeanPropertyAccessStrategyTests.testMetaData() fails
because it expects a NullValueInNestedPathException being thrown when 
accessing a property of a nested property.

Has this behavior changed and how does the test need to be fixed?

-- 
With kind regards,
Geoffrey De Smet

[Springframework-rcp-dev] Subversion Stats updated for Spring Rich Client.

[Benoit X. <bx...@ob...>]

Hi *,

=20

The statistics for Spring Rich Client have been updated on the demo site =
(as
of 22 March):

HYPERLINK
"http://www.statsvn.org/demo/index.html"http://www.statsvn.org/demo/index=
.ht
ml

=20

It also uses the new =91real name=92 feature, furthermore if you would =
like to
have your homepage, email or picture or avatar added to the site, simply
email me the details:

=20

All optional of course:

yourSfLoginId.url=3D<your homepage/blog/ url>

yourSfLoginId.email=3D<your email>

yourSfLoginId.image=3D<the url to your avatar>

=20

Here is an example (and not me!)

HYPERLINK
"http://www.statsvn.org/demo/qalab/user_davesag.html"http://www.statsvn.o=
rg/
demo/qalab/user_davesag.html

or HYPERLINK
"http://www.statsvn.org/demo/pebble/user_simon_g_brown.html"http://www.st=
ats
vn.org/demo/pebble/user_simon_g_brown.html

=20

Hope that you=92ll find the stats interesting=85 and if you do=85 do =
click on a
few ads! Thanks!

=20

Benoit.


--=20
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 269.0.0/752 - Release Date: =
08/04/2007
20:34
=20

[Springframework-rcp-dev] [Spring-JIRA] Created: (RCP-468) WindowMementoTests are failing

[Ben H. (JIRA) <no...@at...>]

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


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

        

[Springframework-rcp-dev] roadmap / new release / project orientations

[Christophe G. <gad...@wa...>]

Hello,

When will the 0.3.0 release be out ? (six months since 0.2.1).
It seems that there has been many updates since 0.2.1 :
- vldocking
- mdi support
- many refactorings and cleanups
- javadoc improvment
- ...

Is there a roadmap (I found none on the site) ?
It could be very interesting to have one. What do you think ?

IMHO Spring Rich could have a great potential (good ideas, good design, =
good team).=20
JSR 296 seems to be good for small applications; Netbeans / Eclipse =
Platform good for "IDE" oriented applications (I've found them too =
complex for my applications -financial applications-). So Spring Rich =
has a "real" place (who could say something else in this dev-list ;-) =
?). But when I read blogs or java desktop sites, Spring Rich doesn't =
appear most of the time (or has a minor place - ben galbraith'blog for =
example-).

Java desktop applications have taken a greater importance during the =
last months :
- swingx
- JSR 296 (application framework)
- JSR 295 (binding)
- JDK 6 / 7
- components libraries (jide...)
- Matisse GUI Builder
- stuffs done by people like Romain Guy, Chris Campbell, Chet Haase, =
Kirill, "Bug" (Bug's blog), and more...

I think it's a bit confusing (and not easy to locate Spring Rich in this =
"desktop world"). Things are changing fast (faster than the last years) =
and going in different ways (applications design, new rich =
components...).


Don't you think we could have a discussion on these subjects ?
- how to work with JSR
- documentation=20
- IDE integration
- redefining goals / roadmap for Spring rich.

Don't you think it could be a good idea to post on the forum (or in the =
mailing list) a topic to know :=20
- who is using Spring rich
- for what applications Spring Rich is used
- what modules are used (At this time, I only use the Binding module) or =
never used
- if users have implemented their own extensions to Spring Rich (I've =
added new Binders for example for Radio Button, Slider / ProgressBar, an =
easyest way to bind components with the Matisse Buider...)
- what new features users like to be in Spring Rich
- what features are hard and easy to use
- good experiences to share
- ...

That's all (folks) !

Regards,

Christophe

PS : sorry for my poor english