Performance issues

[julio.arguello]

I have detected and fixed some performance related issues when dealing with event lists.

See details here:
http://code.google.com/p/bluebell/issues/detail?id=31

Basically consists on reducing drastically the number of events been raised and also reduces the cost of cloning within <code>DeepCopyBufferedCollectionValueModel</code>.

[tamim]

I have detected and fixed some performance related issues when dealing with event lists.

See details here:
http://code.google.com/p/bluebell/issues/detail?id=31

Basically consists on reducing drastically the number of events been raised and also reduces the cost of cloning within <code>DeepCopyBufferedCollectionValueModel</code>.

There is another memory leak that you might want to fix as well. When using VLDocking, you'll see this in VLDockingApplicationPage class:

    private class DefaultLayoutManager implements VLDockingLayoutManager
    {
        /*
         * (non-Javadoc)
         * 
         * @seeorg.springframework.richclient.application.vldocking.
         * VLDockingLayoutManager
         * #addDockable(com.vlsolutions.swing.docking.DockingDesktop,
         * com.vlsolutions.swing.docking.Dockable)
         */
        public void addDockable(DockingDesktop desktop, Dockable dockable)
        {
            desktop.addDockable(dockable);
        }

        /*
         * (non-Javadoc)
         * 
         * @seeorg.springframework.richclient.application.vldocking.
         * VLDockingLayoutManager
         * #removeDockable(com.vlsolutions.swing.docking.DockingDesktop,
         * com.vlsolutions.swing.docking.Dockable)
         */
        public void removeDockable(DockingDesktop desktop, Dockable dockable)
        {
             desktop.remove(dockable);
        }

The problem with this piece of code is that if you close and reopen the same view multiple times, docking context ends up with a lot of stale docking state objects that have already been removed. The correct usage is:

        public void removeDockable(DockingDesktop desktop, Dockable dockable)
        {
             desktop.remove(dockable);
             desktop.unregisterDockable(dockable);
        }

[adamarmistead]

That works great, unless you want to do page caching. Still trying to figure out how to get that to work. As when switching application pages, it looks like you need to close page components to ensure floating dialogs get closed. And closing a page component calls removeDockable(). The caching could be done by NOT unregistering the dockable if page caching is turned on, but that requires you to look for dockables in the desktop and recreate their descriptors and add them back to the application page properly... Which I have yet to accomplish.

Mostly I would like this behavior as some of my dockables contain complex forms that display large data sets I needed to load from my application server. Even caching my data and recreating the forms can take a few seconds for some of the forms. If I figure it out I'll post the code.

[tamim]

That works great, unless you want to do page caching. Still trying to figure out how to get that to work. As when switching application pages, it looks like you need to close page components to ensure floating dialogs get closed. And closing a page component calls removeDockable(). The caching could be done by NOT unregistering the dockable if page caching is turned on, but that requires you to look for dockables in the desktop and recreate their descriptors and add them back to the application page properly... Which I have yet to accomplish.

Mostly I would like this behavior as some of my dockables contain complex forms that display large data sets I needed to load from my application server. Even caching my data and recreating the forms can take a few seconds for some of the forms. If I figure it out I'll post the code.

I don't use floating views. I found that the docking behaves much better when you turn it off. I haven't tried page caching and actually don't require it for my app. But would be interested to know how you do that.

[adamarmistead]

to cache pages you can just set the vldocking application page factory's reusePages property to true, like this:

<bean id="applicationPageFactory"
        depends-on="serviceLocator"
        class="org.springframework.richclient.application.docking.vldocking.VLDockingApplicationPageFactory">
    <property name="reusePages" value="true"/>
  </bean>

[tamim]

to cache pages you can just set the vldocking application page factory's reusePages property to true, like this:

<bean id="applicationPageFactory"
        depends-on="serviceLocator"
        class="org.springframework.richclient.application.docking.vldocking.VLDockingApplicationPageFactory">
    <property name="reusePages" value="true"/>
  </bean>

I'm aware of that ... but you mentioned that you haven't been able to make it work. I have a modified ShowViewMenu that retrieves the view descriptors from VLDockingPageDescriptor. It recreates the menu every time we switch pages. So, when we switch pages only the relevant views are made available.

[adamarmistead]

I have extended most of the VLDocking extension classes. The current ones don't load/save layouts correctly or create the docking desktop correctly. This is mostly likely why you are having problems with floating dialogs. This describes some of the issues. If your interested I can show you how to fix that one.

http://jira.springframework.org/browse/RCP-626

I still can't get it to work correctly with the page caching though. The idea I am working on is to fix the VLDockingApplicationPage class so that it unregisters dockables from the desktop if page caching is off like you have mentioned here in your layout manager. But if its on, to leave the dockable registered and look it back up in the when a page component is opened. I create a new descriptor for it but reuse the dockable that was left in the docking desktop instead of creating a new one, effectively making the docking desktop registry my page cache. I've only gotten it to work partially so far though. Keep running into problems when using a non-trivial layout manager, or switching between pages, or having some pages have a layout file and others not.

I have also added security controller stuff to my view descriptors and page descriptors. This allows me to just add a securityControllerId to views and pages and the view menu command and view page commands all get them added when they are created allowing me to filter out views/pages from my menus based on my security configuration. But I am quite liking your idea of a show view menu that filters views per application page as well. For some reason I hadn't thought of that. I will definitely have to code one of those up as well.

[julio.arguello]

Take a look to Bluebell aproach, I finally got to remove the memory leak.
http://saber.b2b2000.com/display/BLU...ng+memory+leak