springframework-rcp-dev

[Springframework-rcp-dev] Refactoring the docking code

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

Hi folks,

I am looking at refactoring the docking code to include some generic 
interfaces and supporting classes, along with specialised classes for 
the various docking frameworks.

I have come up with the following, from examining the JIDE docking and 
VLDocking support libs. Comments are welcome.

Create a package org.springframework.richclient.application.docking, 
under which common docking support interfaces and classes reside:

Each framework will have a custom implementation of DockingApplicationPage.

interface DockingApplicationPage extends ApplicationPage {

     public PerspectiveManager getPerspectiveManager();

     public void setPerspectiveManager(PerspectiveManager 
perspectiveManager);

}

PerspectiveManager will be responsible for organising the available 
Perspectives.

public interface PerspectiveManager {

     void setPerspectives(Perspective[] perspectives);

     void setDefaultPerspective(Perspective perspective);

     Perspective getDefaultPerspective();

     Perspective getCurrentPerspective();

     void setCurrentPerspective(Perspective perspective);

}

Perspective will be responsible for applying and saving itself on a 
particular DockingApplicationPage:

public interface Perspective extends BeanNameAware {

     String getId();

     void activate(DockingApplicationPage dockingPage);

     boolean saveLayout(DockingApplicationPage dockingPage);

}

Each framework will have a custom implementation of Perspective. 
Obviously, the custom versions will only be able to operate with the 
corresponding version of DockingApplicationPage.

I have also created a common implementation of DockingViewDescriptor, 
that adds "hideable", "closeable", "maximizeable", "floatable" 
attributes. These should be common to all docking frameworks.

Then implementations for specific frameworks would fall under the 
.docking package.

e.g. org.springframework.richclient.application.docking.vldocking

What do you think?

Rogan

Re: [Springframework-rcp-dev] Refactoring the docking code

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

Sounds good, though I haven't yet used a docking framework.

I guess a user can choose the needed framework and the dependencies are
listed optional (user has to choose one in its own dependencies)?

Thanks for looking at this. I hope I can find some time to finish some
of my rcp changes that I had to delay (yet again).

Regards,
Jan

On Wed, 2007-09-05 at 18:31 +0200, Rogan Dawes wrote:
> Hi folks,
> 
> I am looking at refactoring the docking code to include some generic 
> interfaces and supporting classes, along with specialised classes for 
> the various docking frameworks.
> 
> I have come up with the following, from examining the JIDE docking and 
> VLDocking support libs. Comments are welcome.
> 
> Create a package org.springframework.richclient.application.docking, 
> under which common docking support interfaces and classes reside:
> 
> Each framework will have a custom implementation of DockingApplicationPage.
> 
> interface DockingApplicationPage extends ApplicationPage {
> 
>      public PerspectiveManager getPerspectiveManager();
> 
>      public void setPerspectiveManager(PerspectiveManager 
> perspectiveManager);
> 
> }
> 
> PerspectiveManager will be responsible for organising the available 
> Perspectives.
> 
> public interface PerspectiveManager {
> 
>      void setPerspectives(Perspective[] perspectives);
> 
>      void setDefaultPerspective(Perspective perspective);
> 
>      Perspective getDefaultPerspective();
> 
>      Perspective getCurrentPerspective();
> 
>      void setCurrentPerspective(Perspective perspective);
> 
> }
> 
> Perspective will be responsible for applying and saving itself on a 
> particular DockingApplicationPage:
> 
> public interface Perspective extends BeanNameAware {
> 
>      String getId();
> 
>      void activate(DockingApplicationPage dockingPage);
> 
>      boolean saveLayout(DockingApplicationPage dockingPage);
> 
> }
> 
> Each framework will have a custom implementation of Perspective. 
> Obviously, the custom versions will only be able to operate with the 
> corresponding version of DockingApplicationPage.
> 
> I have also created a common implementation of DockingViewDescriptor, 
> that adds "hideable", "closeable", "maximizeable", "floatable" 
> attributes. These should be common to all docking frameworks.
> 
> Then implementations for specific frameworks would fall under the 
> .docking package.
> 
> e.g. org.springframework.richclient.application.docking.vldocking
> 
> What do you think?
> 
> Rogan
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev


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

Re: [Springframework-rcp-dev] Refactoring the docking code

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

Jan Hoskens wrote:
> Sounds good, though I haven't yet used a docking framework.
> 
> I guess a user can choose the needed framework and the dependencies are
> listed optional (user has to choose one in its own dependencies)?
> 
> Thanks for looking at this. I hope I can find some time to finish some
> of my rcp changes that I had to delay (yet again).
> 
> Regards,
> Jan

Yes, that would be the idea.

Rogan

> 
> On Wed, 2007-09-05 at 18:31 +0200, Rogan Dawes wrote:
>> Hi folks,
>>
>> I am looking at refactoring the docking code to include some generic 
>> interfaces and supporting classes, along with specialised classes for 
>> the various docking frameworks.
>>
>> I have come up with the following, from examining the JIDE docking and 
>> VLDocking support libs. Comments are welcome.
>>
>> Create a package org.springframework.richclient.application.docking, 
>> under which common docking support interfaces and classes reside:
>>
>> Each framework will have a custom implementation of DockingApplicationPage.
>>
>> interface DockingApplicationPage extends ApplicationPage {
>>
>>      public PerspectiveManager getPerspectiveManager();
>>
>>      public void setPerspectiveManager(PerspectiveManager 
>> perspectiveManager);
>>
>> }
>>
>> PerspectiveManager will be responsible for organising the available 
>> Perspectives.
>>
>> public interface PerspectiveManager {
>>
>>      void setPerspectives(Perspective[] perspectives);
>>
>>      void setDefaultPerspective(Perspective perspective);
>>
>>      Perspective getDefaultPerspective();
>>
>>      Perspective getCurrentPerspective();
>>
>>      void setCurrentPerspective(Perspective perspective);
>>
>> }
>>
>> Perspective will be responsible for applying and saving itself on a 
>> particular DockingApplicationPage:
>>
>> public interface Perspective extends BeanNameAware {
>>
>>      String getId();
>>
>>      void activate(DockingApplicationPage dockingPage);
>>
>>      boolean saveLayout(DockingApplicationPage dockingPage);
>>
>> }
>>
>> Each framework will have a custom implementation of Perspective. 
>> Obviously, the custom versions will only be able to operate with the 
>> corresponding version of DockingApplicationPage.
>>
>> I have also created a common implementation of DockingViewDescriptor, 
>> that adds "hideable", "closeable", "maximizeable", "floatable" 
>> attributes. These should be common to all docking frameworks.
>>
>> Then implementations for specific frameworks would fall under the 
>> .docking package.
>>
>> e.g. org.springframework.richclient.application.docking.vldocking
>>
>> What do you think?
>>
>> Rogan
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems?  Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >>  http://get.splunk.com/
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 

Re: [Springframework-rcp-dev] Refactoring the docking code

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

Rogan,

This is Jonny Wray, author of the JIDE docking integration.

I looked over your refactorings wrt the JIDE related code and it looks
great. Good to know there's common ground between the two frameworks that
can be abstracted out. The one difference I notice is that you are applying
perspectives on a page, whereas I apply then on a window, at least at the
API level. However, in my implementation it actually identifies the
perspective on a page by page basis, so the changes shouldn't be too hard to
make and the code should be cleaner.

One other addition might be useful, a 'change perspective' command that
allows configuration of the specific perspective within the application
context, and a  doExecuteCommand method that calls switch on that
perspective.

thanks
Jonny

Re: [Springframework-rcp-dev] Refactoring the docking code

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

Jonny Wray wrote:
> Rogan,
> 
> This is Jonny Wray, author of the JIDE docking integration.
> 
> I looked over your refactorings wrt the JIDE related code and it looks 
> great. Good to know there's common ground between the two frameworks 
> that can be abstracted out. The one difference I notice is that you are 
> applying perspectives on a page, whereas I apply then on a window, at 
> least at the API level. However, in my implementation it actually 
> identifies the perspective on a page by page basis, so the changes 
> shouldn't be too hard to make and the code should be cleaner.
> 
> One other addition might be useful, a 'change perspective' command that 
> allows configuration of the specific perspective within the application 
> context, and a  doExecuteCommand method that calls switch on that 
> perspective.
> 
> thanks
> Jonny

Hi Jonny,

Thanks for taking the time to take a look. I did consider your 
implementation of the JIDE docking code when doing the refactoring. The 
major difference that is not accounted for in the refactoring is the 
JideApplicationWindow code.

I must admit, I'm not entirely sure why this is needed. Any reason that 
this has to be different to the standard behaviour? Can the JIDE 
DockableHolder not be a property of the JideApplicationPage, rather?

I absolutely do plan to make a ChangePerspectiveCommand. You may have 
seen the PageDescriptorRegistry, ShowPageCommand and ShowPageMenu that I 
added at the beginning of the year. I was previously implementing 
Perspectives in their own Page. Unfortunately, this ends up requiring 
unclean changes to support persistence of Views across Perspective changes.

Rogan

Re: [Springframework-rcp-dev] Refactoring the docking code

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

Hi Rogan,

I appreciate your consideration of my code when doing this refactoring.
It'll make keeping the jide integration code in-sync with the main code-base
easier.

As for the need for the JideApplicationWindow, I'm not sure what you mean
about different from standard behaviour. When I implemented the docking code
there was no other example or standard, so I just did what made sense to me
at the time. It seems that we may have a different view on the relative
roles of application windows, application pages and perspectives. How do you
see the roles of application window, application page and perspectives with
respect to a docking implementation? I'll also look at the vldocking code
when I get the chance, as I think it's worthwhile to have the docking
implementation consistent in their concepts and the introduction of these
refactorings seems like a good time to do that.

Regarding the perspectives, the exposure of the JideApplicationWindow in the
API, I'd say this a leaking of the implementation details into the API and
so could be done better for sure, so I don't see a problem there.

Jonny

On 9/10/07, Rogan Dawes <ro...@da...> wrote:
>
>
> Hi Jonny,
>
> Thanks for taking the time to take a look. I did consider your
> implementation of the JIDE docking code when doing the refactoring. The
> major difference that is not accounted for in the refactoring is the
> JideApplicationWindow code.
>
> I must admit, I'm not entirely sure why this is needed. Any reason that
> this has to be different to the standard behaviour? Can the JIDE
> DockableHolder not be a property of the JideApplicationPage, rather?
>
> I absolutely do plan to make a ChangePerspectiveCommand. You may have
> seen the PageDescriptorRegistry, ShowPageCommand and ShowPageMenu that I
> added at the beginning of the year. I was previously implementing
> Perspectives in their own Page. Unfortunately, this ends up requiring
> unclean changes to support persistence of Views across Perspective
> changes.
>
> Rogan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>