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

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
>

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;
+    }
  }

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