Here is an updated version of the VLDocking support.

It now supports automatic persisting of the workspace to disk. I developed this against v 2.1.3, although it might work for earlier revisions.

The approach has not changed significantly:

In your richclient-application-context.xml:

Define the PageFactory:

<bean id="applicationPageFactory" depends-on="serviceLocator"
class="org.springframework.richclient.application.vldocking.VLDockingApplicationPageFactory" lazy-init="false">
</bean>

Define your views, using either the standard ViewDescriptors, or else VLDockingViewDescriptor, which allows you to specify docking properties such as closable, floatable, maximisable, etc.

<bean id="initialView"
class="org.springframework.richclient.application.vldocking.VLDockingViewDescriptor">
<property name="viewClass">
<value>my.view.class.name</value>
</property>
<property name="autoHideEnabled"><value>true</value></property>
<property name="closeEnabled"><value>true</value></property>
</bean>

Define your pages. You can either provide a list of Views which should be displayed, or else provide an XML layout file (or both). If the desktop contains 0 Views after being loaded, the list of Views will be opened.

<bean id="defaultDesktopPage"
class="org.springframework.richclient.application.vldocking.VLDockingPageDescriptor">
<property name="viewDescriptors">
<list>
<value>initialView</value>
<value>initialView-1</value>
<value>initialView-2</value>
</list>
</property>
<property name="initialLayout">
<bean class="org.springframework.core.io.ClassPathResource">
<constructor-arg type="java.lang.String">
<value>/ui/desktopLayout.xml</value>
</constructor-arg>
</bean>
</property>
</bean>

You can also specify a layoutManager (implements VLDockingLayoutManager) as a property of the page, which will be called to place the Dockable in a particular location in the DockingDesktop, or customize the desktop when Dockables are removed.

If the Resource you supply to the Page as the initialLayout refers to a writable file, the page will write out the current layout when the page is closed.

v2

v2

v2

v2

v2

Hi Rogan,

thanks for your contribution.

I did a look at that stuff and find it really good. So I added a vldocking module to spring rich and imported everything into that module. I also created a new simple sample application to make it easy for trying out vldocking support of spring rich. See samples/vldocking. Feel free to make that sample a better one. It is currently based on simple sample and don't uses much of vldocking. But you already manage views.

But IMO we also have to figure out if we can use vldocking without violating the CeCill licence (see http://www.cecill.info/index.en.html). I hope that it is not a problem if we have a copy of the vldocking.jar in our repository.

Hi Mathias,

Thanks for checking this in. Just one question:

You seem to have moved the package that this was in from richclient.application.vldocking (similar to richclient.application.flexdock) to just richclient.vldocking. Is there a specific reason for this? Do you plan to move the flexdock package as well to match?

I agree that there may be problems with distributing this from the Spring Rich repo. I think that I probably need to add some documentation to the supporting classes to make sure that people know that if they make use of vldocking in a commercial app, that they need to make sure that they are complying with the license.

Regards,

Rogan

I was a little bit confused by the package application. I should have had a better look at the sandbox package where everything about views is placed in that package. So now I think it is much better to place it again under the application package. I will do this shortly. But I'm still a little bit puzzled if the name application really fits to all that different view, page and docking implementations.

Does anyone have objections to me implementing the Page-level analog of ViewDescriptorRegistry? i.e PageDescriptorRegistry interface, BeanFactoryPageDescriptorRegistry implementation, and relevant ImplBuilder classes in DefaultApplicationServices. It would probably also need an extension to the PageDescriptor interface to include createShowPageCommand() and getShowPageCommandLabel()

The idea is that in a docking framework, the "perspectives", or dock layouts are represented by Page implementations which contain a number of Views. In order to switch between perspectives, one simply chooses a different Page to show. One could obviously implement ShowPageCommand manually for each PageDescriptor, but it seems to be something that would fit into the framework quite naturally.

Opinions?

Sounds good!

But try to use a new JIRA issue for that.