springframework-rcp-dev — Spring Rich Client developer list

Re: [Springframework-rcp-dev] Position of caret for readonly fields

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

If this is a Swing "feature", then I'm not aware of a simple setting 
somewhere (maybe someone else knows of one?).  I do know that 
DefaultCaret has a setUpdatePolicy method.  You would have to get the 
Caret from the JTextField, make sure it is a DefaultCaret, cast it to 
DefaultCaret, and invoke setUpdatePolicy(DefaultCaret.NEVER_UPDATE).  
Even then, I haven't tested this, so I'm not sure if it would have the 
desired effect.  Another approach would be to implement a 
FormComponentInterceptor that automatically handles any JTextField that 
is not enabled so that the caret it always placed at the beginning of 
the field.  See SelectAllFormComponentInterceptorFactory for an example 
of what an interceptor looks like.

  - Andy

Benoit Xhenseval wrote:
>
> Hi *,
>
>  
>
> Sorry to disturb.
>
>  
>
> I have a form that displays fields from a model. I have some text 
> components that are readonly 
> (formModel.getFieldMetaData().setReadOnly(true);
>
>  
>
> Sometimes the text MAY be too long for the field, and that is ok, the 
> user could scroll.  The problem is that the caret seems always to be 
> positioned at the end of the text, like this:
>
>  
>
>  
>
> This is ok when one types some text.
>
>  
>
> But, since the text is readonly true, I would like, by default, the 
> caret to be place at position 0, like this:
>
>  
>
>  
>
> Is there a way (i.e. a setting? Or where to changed this…) to achieve 
> this by default for all fields with READONLY metadata set to true?
>
>  
>
> Suggestions would be greatly welcomed!
>
>  
>
> many thanks,
>
>  
>
> regards from London
>
>  
>
> Benoit
>
>  
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.485 / Virus Database: 269.13.6/991 - Release Date: 
> 05/09/2007 14:55
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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

[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

[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

[Springframework-rcp-dev] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

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

Jan Hoskens commented on RCP-165:
---------------------------------

I'm sorry, I was involved in other stuff lately. Thanks for the poking though, I've scheduled some rcp time this afternoon and will review your latest patch.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

-- 
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] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

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

Arne Limburg commented on RCP-165:
----------------------------------

Are you still not happy with my patch?

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

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

[Springframework-rcp-dev] Heads up on validation overlay patch

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

This is just a heads up to let everyone know I've committed a fix to 
OverlayHelper concerning JScrollPane + JTable support (see issue 
RCP-484: http://opensource.atlassian.com/projects/spring/browse/RCP-484 
).  If I did my job right, you should see no difference in the 
validation overlay support. :)  However, I encourage everyone who is 
able to test this change in their own app to do so, as I have partially 
redesigned the internal mechanics of how overlays are placed.  In 
particular, I removed the sort-of-hacky approach of interposing a new 
JLayeredPane between a JScrollPane's view and view component and 
replaced it with a new approach that does everything from the root 
JLayeredPane (which requires robust calculation of component location 
and visible rect clipping to handle overlays being scrolled within a 
scrollpane).
If you run into any problems, let me know or open a new issue and point 
me to it.

Thanks,
  Andy

[Springframework-rcp-dev] [Spring-JIRA] Resolved: (RCP-484) OverlayHelper removes table header if a form is contained in a JTable

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

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

Andy DePue resolved RCP-484.
----------------------------

    Resolution: Fixed

Fix committed as SVN revision #1799.


> OverlayHelper removes table header if a form is contained in a JTable
> ---------------------------------------------------------------------
>
>                 Key: RCP-484
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-484
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Binding System
>    Affects Versions: 0.3.0
>            Reporter: Andy DePue
>            Assignee: Andy DePue
>             Fix For: 0.3.0
>
>
> I have a modified JTable that creates a Spring Rich form for each row.  This allows us to develop a table row using a UI designer, then have this modified table instantiate it for each row.  Each row's form is then added to the enclosing parent form in order to support validation.  This all works fine now, except that when a row form is bound, the table header is removed!  After tracking this down, I've determined the culprit is OverlayHelper.  In order to support JScrollPanes (which this table happens to be in), OverlayHelper will remove the view component from a JScrollPane, add it to a JLayeredPane, then add that JLayeredPane to the JScrollPane.  This has the effect of removing the table's header from the JScrollPane, and since JLayeredPane knows nothing of table headers, the table header is never seen again.  OverlayHelper wants the JLayeredPane to be scrolled in order to avoid having to calculate scroll offsets and clipping boundaries for the overlay icons.
> I've created a preliminary fix by redesigning how OverlayHelper works.  The whole idea of replacing a JScrollPane's view component with a JLayeredPane is prone to many issues (this isn't the first bug to result from this approach).  The real fix is to figure out how to calculate overlay offsets and clipping boundaries on a component, whether it is in a scrollpane or not, and then handle the placement of the overlay in the rootpane's layered pane.  This would completely eliminate the need for OverlayHelper to ever instantiate a custom JLayeredPane, let alone replace a view component.
> I will be checking in the changes to OverlayHelper (and the unit tests) soon, and I encourage everyone to stress test this to make sure I didn't miss any corner cases.
> BTW, OverlayHelper uses components for the overlay as opposed to a custom "painter" (which is good), but it makes clipping a little tricky.  Since OverlayHelper uses the rootpane's layered pane exclusively now, clipping is very important so that an overlay within a JScrollPane is not painted outside the boundaries of the scrollpane when it is scrolled out of view (or even partially out of view).  My quick and dirty approach is to enclose the overlay component into a JPanel, then when clipping is required, I size the JPanel to the clip bounds, and adjust the position of the overlay component within the JPanel appropriately.

-- 
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-484) OverlayHelper removes table header if a form is contained in a JTable

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

OverlayHelper removes table header if a form is contained in a JTable
---------------------------------------------------------------------

                 Key: RCP-484
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-484
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
          Components: Binding System
    Affects Versions: 0.3.0
            Reporter: Andy DePue
            Assignee: Andy DePue
             Fix For: 0.3.0


I have a modified JTable that creates a Spring Rich form for each row.  This allows us to develop a table row using a UI designer, then have this modified table instantiate it for each row.  Each row's form is then added to the enclosing parent form in order to support validation.  This all works fine now, except that when a row form is bound, the table header is removed!  After tracking this down, I've determined the culprit is OverlayHelper.  In order to support JScrollPanes (which this table happens to be in), OverlayHelper will remove the view component from a JScrollPane, add it to a JLayeredPane, then add that JLayeredPane to the JScrollPane.  This has the effect of removing the table's header from the JScrollPane, and since JLayeredPane knows nothing of table headers, the table header is never seen again.  OverlayHelper wants the JLayeredPane to be scrolled in order to avoid having to calculate scroll offsets and clipping boundaries for the overlay icons.
I've created a preliminary fix by redesigning how OverlayHelper works.  The whole idea of replacing a JScrollPane's view component with a JLayeredPane is prone to many issues (this isn't the first bug to result from this approach).  The real fix is to figure out how to calculate overlay offsets and clipping boundaries on a component, whether it is in a scrollpane or not, and then handle the placement of the overlay in the rootpane's layered pane.  This would completely eliminate the need for OverlayHelper to ever instantiate a custom JLayeredPane, let alone replace a view component.
I will be checking in the changes to OverlayHelper (and the unit tests) soon, and I encourage everyone to stress test this to make sure I didn't miss any corner cases.
BTW, OverlayHelper uses components for the overlay as opposed to a custom "painter" (which is good), but it makes clipping a little tricky.  Since OverlayHelper uses the rootpane's layered pane exclusively now, clipping is very important so that an overlay within a JScrollPane is not painted outside the boundaries of the scrollpane when it is scrolled out of view (or even partially out of view).  My quick and dirty approach is to enclose the overlay component into a JPanel, then when clipping is required, I size the JPanel to the clip bounds, and adjust the position of the overlay component within the JPanel appropriately.

-- 
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-483) missing to remove view from ApplicationEventMulticaster when view is closed

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

missing to remove view from ApplicationEventMulticaster when view is closed
---------------------------------------------------------------------------

                 Key: RCP-483
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-483
             Project: Spring Framework Rich Client Project
          Issue Type: Bug
          Components: Application Framework
            Reporter: Christian Heilmann
            Priority: Critical


In DefaultViewDescriptor.createView() the view is added to the ApplicationEventMulticaster (ApplicationEventMulticaster.addApplicationListener(view)) as Listener.
But when closing the view, it is missing to remove the view from the ApplicationEventMulticaster (ApplicationEventMulticaster.removeApplicationListener(view)).

Please remove the view from the ApplicationEventMulticaster when it is closed.

-- 
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] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. <A.L...@ad...>]

Hi Jan,

I knew about the postprocessor, but I didn't think about multiple 
windows. So one solutionis the the special beanfactory, but what about 
declaring all commands as prototypes in the same beanfactory as the 
advisor. The ApplicationWindowPostprocessor could check this constraint 
and throw an Exception otherwise. We then could inject the toolBar and 
menuBar into the command-manager (this can also be done in the current 
configuration) and looking for the command-manager by type in the 
advisor. Then no special bean name is needed, no special beanfactory for 
commands and we can have multiple windows with multiple commands.

Kind regards,
Arne

Jan Hoskens schrieb:
> There is already a postprocessor that does this. But additionally the
> commands are processed by a different beanfactory as well (on which the
> postprocessor is installed). The commands that are
> ApplicationWindowAware need to be initialized per window. So when
> opening, the commands-context is created, AppWindowAware commands are
> postprocessed. Then when you open a new window (eg through the new
> window command that is provided) the advisor will create a new
> commands-context and all commmands are initialized anew. This ensures
> that per window the AppWindowAware commands will receive the correct
> window.
> 
> Say that you have a command that will provide a new view in your window,
> then that will probably have a reference to its AppWindow. When opening
> a new window, that command needs to be recreated and injected with the
> new window to work on.
> 
> Kind Regards,
> Jan
> 
> On Sat, 2007-08-11 at 10:53 +0200, Arne Limburg wrote:
> 
>>Hi Jan,
>>
>>what is the problem with the ApplicationWindowAware-ness? Couldn't the 
>>lifecycle-advisor act as a bean-postprocessor to inject the application 
>>window to all ApplicationWindowAware beans? The only thing we would have 
>>to do is to open the window during the initialization of the 
>>lifecycle-advisor or the application. I have had a short try on this. I 
>>moved the application.start() code into afterPropertiesSet() of 
>>Application. Everything worked fine. setOpeningWindow of 
>>ApplicationLifecycleAdvisor was called before afterPropertiesSet() of a 
>>command that I defined in the application-context. Is there another problem?
>>
>>Regards,
>>Arne
>>
>>Jan Hoskens (JIRA) schrieb:
>>
>>>    [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25315 ] 
>>>
>>>Jan Hoskens commented on RCP-165:
>>>---------------------------------
>>>
>>>3) thanks
>>>
>>>4) as I mentioned, it can be used for prototyping or new projects if we provide it in the archetype. You start off by creating a new project (mvn archetype stuff) and then you get a structure to start from which includes a basic project-rcp.xml and commands.xml (like the one you provided). All your cases would then apply to that setup. I still don't think we need this in the support jar.
>>>
>>>As for the beanNames, I call them magic because you don't need to inject them. There's no other connection between the advisor and the menuBeanId than in code. I would prefer to remove the in-code defaultIds and let them be injected in the code. This is more transparant in my opinion.
>>>
>>>Concerning the last remark: I think commands should be reusable anywhere, as is the case now. You shouldn't need to define if it may end up in the menu/toolbar etc... It's just another component to represent the same command. The only issue that is surfacing here is the separate commands context. It would be better to just have the commands added to the context (or preferably by importing the current commands.xml instead of providing the url to the advisor for special handling). The problem here is that there should be a way to fix the ApplicationWindowAware-ness of the commands, which is why there is a separate handling currently. Not yet sure how to do this, but I've posted this issue on the dev list as well to discuss it with the other developers.
>>>
>>>
>>>
>>>>Eliminate need for special bean names when configuring Application and ApplicationServices
>>>>------------------------------------------------------------------------------------------
>>>>
>>>>               Key: RCP-165
>>>>               URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>>>>           Project: Spring Framework Rich Client Project
>>>>        Issue Type: Improvement
>>>>          Reporter: Oliver Hutchison
>>>>          Assignee: Jan Hoskens
>>>>           Fix For: 0.3.0
>>>>
>>>>       Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>>>>
>>>>
>>>>We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.
>>>
>>>
>>
>>-------------------------------------------------------------------------
>>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] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

There is already a postprocessor that does this. But additionally the
commands are processed by a different beanfactory as well (on which the
postprocessor is installed). The commands that are
ApplicationWindowAware need to be initialized per window. So when
opening, the commands-context is created, AppWindowAware commands are
postprocessed. Then when you open a new window (eg through the new
window command that is provided) the advisor will create a new
commands-context and all commmands are initialized anew. This ensures
that per window the AppWindowAware commands will receive the correct
window.

Say that you have a command that will provide a new view in your window,
then that will probably have a reference to its AppWindow. When opening
a new window, that command needs to be recreated and injected with the
new window to work on.

Kind Regards,
Jan

On Sat, 2007-08-11 at 10:53 +0200, Arne Limburg wrote:
> Hi Jan,
> 
> what is the problem with the ApplicationWindowAware-ness? Couldn't the 
> lifecycle-advisor act as a bean-postprocessor to inject the application 
> window to all ApplicationWindowAware beans? The only thing we would have 
> to do is to open the window during the initialization of the 
> lifecycle-advisor or the application. I have had a short try on this. I 
> moved the application.start() code into afterPropertiesSet() of 
> Application. Everything worked fine. setOpeningWindow of 
> ApplicationLifecycleAdvisor was called before afterPropertiesSet() of a 
> command that I defined in the application-context. Is there another problem?
> 
> Regards,
> Arne
> 
> Jan Hoskens (JIRA) schrieb:
> >     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25315 ] 
> > 
> > Jan Hoskens commented on RCP-165:
> > ---------------------------------
> > 
> > 3) thanks
> > 
> > 4) as I mentioned, it can be used for prototyping or new projects if we provide it in the archetype. You start off by creating a new project (mvn archetype stuff) and then you get a structure to start from which includes a basic project-rcp.xml and commands.xml (like the one you provided). All your cases would then apply to that setup. I still don't think we need this in the support jar.
> > 
> > As for the beanNames, I call them magic because you don't need to inject them. There's no other connection between the advisor and the menuBeanId than in code. I would prefer to remove the in-code defaultIds and let them be injected in the code. This is more transparant in my opinion.
> > 
> > Concerning the last remark: I think commands should be reusable anywhere, as is the case now. You shouldn't need to define if it may end up in the menu/toolbar etc... It's just another component to represent the same command. The only issue that is surfacing here is the separate commands context. It would be better to just have the commands added to the context (or preferably by importing the current commands.xml instead of providing the url to the advisor for special handling). The problem here is that there should be a way to fix the ApplicationWindowAware-ness of the commands, which is why there is a separate handling currently. Not yet sure how to do this, but I've posted this issue on the dev list as well to discuss it with the other developers.
> > 
> > 
> >>Eliminate need for special bean names when configuring Application and ApplicationServices
> >>------------------------------------------------------------------------------------------
> >>
> >>                Key: RCP-165
> >>                URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
> >>            Project: Spring Framework Rich Client Project
> >>         Issue Type: Improvement
> >>           Reporter: Oliver Hutchison
> >>           Assignee: Jan Hoskens
> >>            Fix For: 0.3.0
> >>
> >>        Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
> >>
> >>
> >>We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.
> > 
> > 
> 
> 
> -------------------------------------------------------------------------
> 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

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

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

Arne Limburg updated RCP-165:
-----------------------------

    Attachment: RCP-165.patch

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

-- 
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] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

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

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

Arne Limburg commented on RCP-165:
----------------------------------

Besides the issue to remove the commands-context.xml completely from the advisor, I would like to have a nice default for the menubar and toolbar. But I see that my default-commands-context.xml does no good step in that direction. What about a DefaultMenuBarCommandGroup that is created in getMenuBarCommandGroup if no commands-context is set or if the menuBarBeanName is not set. Same could go with the toolBar. We then could remove your magic bean names. I will create a patch with an empty CommandGroup in that case. If you agree, I would implement the DefaultMenuBarCommandGroup and DefaultToolBarCommandGroup.

> Eliminate need for special bean names when configuring Application and ApplicationServices
> ------------------------------------------------------------------------------------------
>
>                 Key: RCP-165
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Oliver Hutchison
>            Assignee: Jan Hoskens
>             Fix For: 0.3.0
>
>         Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>
>
> We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.

-- 
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] [Spring-JIRA] Commented: (RCP-165) Eliminate need for special bean names when configuring Application and ApplicationServices

[Arne L. <A.L...@ad...>]

Hi Jan,

what is the problem with the ApplicationWindowAware-ness? Couldn't the 
lifecycle-advisor act as a bean-postprocessor to inject the application 
window to all ApplicationWindowAware beans? The only thing we would have 
to do is to open the window during the initialization of the 
lifecycle-advisor or the application. I have had a short try on this. I 
moved the application.start() code into afterPropertiesSet() of 
Application. Everything worked fine. setOpeningWindow of 
ApplicationLifecycleAdvisor was called before afterPropertiesSet() of a 
command that I defined in the application-context. Is there another problem?

Regards,
Arne

Jan Hoskens (JIRA) schrieb:
>     [ http://opensource.atlassian.com/projects/spring/browse/RCP-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_25315 ] 
> 
> Jan Hoskens commented on RCP-165:
> ---------------------------------
> 
> 3) thanks
> 
> 4) as I mentioned, it can be used for prototyping or new projects if we provide it in the archetype. You start off by creating a new project (mvn archetype stuff) and then you get a structure to start from which includes a basic project-rcp.xml and commands.xml (like the one you provided). All your cases would then apply to that setup. I still don't think we need this in the support jar.
> 
> As for the beanNames, I call them magic because you don't need to inject them. There's no other connection between the advisor and the menuBeanId than in code. I would prefer to remove the in-code defaultIds and let them be injected in the code. This is more transparant in my opinion.
> 
> Concerning the last remark: I think commands should be reusable anywhere, as is the case now. You shouldn't need to define if it may end up in the menu/toolbar etc... It's just another component to represent the same command. The only issue that is surfacing here is the separate commands context. It would be better to just have the commands added to the context (or preferably by importing the current commands.xml instead of providing the url to the advisor for special handling). The problem here is that there should be a way to fix the ApplicationWindowAware-ness of the commands, which is why there is a separate handling currently. Not yet sure how to do this, but I've posted this issue on the dev list as well to discuss it with the other developers.
> 
> 
>>Eliminate need for special bean names when configuring Application and ApplicationServices
>>------------------------------------------------------------------------------------------
>>
>>                Key: RCP-165
>>                URL: http://opensource.atlassian.com/projects/spring/browse/RCP-165
>>            Project: Spring Framework Rich Client Project
>>         Issue Type: Improvement
>>           Reporter: Oliver Hutchison
>>           Assignee: Jan Hoskens
>>            Fix For: 0.3.0
>>
>>        Attachments: Application.java.patch, RCP-165.patch, RCP-165.patch
>>
>>
>>We should totally eliminate the special bean names that are required when configuring the Application and ApplicationServices singletons. Both these classes should be configurable using DI.
> 
> 

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-107) The method to show/hide the status bar is not working propertly

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

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

Keith Donald updated RCP-107:
-----------------------------

    Assignee:     (was: Keith Donald)

> The method to show/hide the status bar is not working propertly
> ---------------------------------------------------------------
>
>                 Key: RCP-107
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-107
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>            Reporter: Robert Delahoz
>            Priority: Minor
>         Attachments: StatusBarCommandGroupTests.java
>
>
> configurer.setShowMenuBar(false); this works
> configurer.setShowStatusBar(false); this is not working
> configurer.setShowToolBar(false); this works

-- 
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-10) Add ProviderRegistry for ViewContext

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

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

Keith Donald updated RCP-10:
----------------------------

    Assignee:     (was: Keith Donald)

> Add ProviderRegistry for ViewContext
> ------------------------------------
>
>                 Key: RCP-10
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-10
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: besbello
>            Priority: Minor
>         Attachments: EntornoVista.java, RegistroFuentes.java
>
>
> Extent ViewContext to
> public interface ViewContext {
>   ...
>   public ProviderRegistry getProvider(Class typeOfProvider);
> }
> public interface ProviderRegistry{
>   public Object getProvider(Object bean, String property);
>   public Ojbect getProvider(Class clazz);
> }
> It could let registry provider of objects  (Example TableCellRenderes, TreeNodes, PropertyEditors)

-- 
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-3) Multiple views of the same type per application should be supported.

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

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

Keith Donald updated RCP-3:
---------------------------

    Assignee:     (was: Keith Donald)

> Multiple views of the same type per application should be supported.
> --------------------------------------------------------------------
>
>                 Key: RCP-3
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-3
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Ronald Haring
>            Priority: Minor
>         Attachments: spring-rcp.diff
>
>
> It should be possible for the application, to change its complete appearance. Not only should the views be changed, but also the menu bar and toolbar should be changed.
> Currently a given view can only be displayed on a single application window; it should be possible to have the same view active on multiple windows.

-- 
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-60) FileChooser - Utils with accessory component

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

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

Keith Donald updated RCP-60:
----------------------------

       Assignee:     (was: Keith Donald)
    Description:=20
FileChooser allows the addition of an accessory component.
I created a simple patch and a more comlicated one which allows
this for FileChooserUtils.
I removed the static JFileChooser member (since an added
accessory component would have been there even if you
wouldn't want it).

--simple
=C2=A0import java.awt.Component;
=C2=A0import java.io.File;

+import javax.swing.JComponent;
=C2=A0import javax.swing.JFileChooser;

=C2=A0/**
@@ -27,20 +28,34 @@
=C2=A0 * @author Keith Donald
=C2=A0 */
=C2=A0public class FileChooserUtils {
- =C2=A0 =C2=A0private static JFileChooser fileChooser;

=C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, St=
ring=20
defaultExtension, String approveButtonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription)=
 {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChooser=
();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D new JFileChooser(=
);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(paren=
t, approveButtonName);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OPTI=
ON) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelectedFi=
le();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0}
+
+ =C2=A0 =C2=A0public static File showFileChooser(Component parent, String=
=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser =C2=A0fileChooser =3D new JFileCh=
ooser();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultF=
ileFilter();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription=
);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setAccessory(accessory);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(=
parent, approveButtonName);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE=
_OPTION) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelec=
tedFile();
@@ -49,4 +64,9 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
+
+
+
+
+
=C2=A0}
\ No newline at end of file

--complicated
Index: FileChooserUtils.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file:=20
/cvsroot/spring-rich-c/spring-richclient/src/org/springframework/richclient=
/filechooser/FileChooserUtils.java,v
retrieving revision 1.5
diff -u -r1.5 FileChooserUtils.java
--- FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A031 Oct 2=
004 18:58:46 -0000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01.5
+++ FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03 Dec 20=
04 13:35:07 -0000
@@ -18,6 +18,7 @@
=C2=A0import java.awt.Component;
=C2=A0import java.io.File;
=C2=A0
+import javax.swing.JComponent;
=C2=A0import javax.swing.JFileChooser;
=C2=A0
=C2=A0/**
@@ -27,20 +28,26 @@
=C2=A0 * @author Keith Donald
=C2=A0 */
=C2=A0public class FileChooserUtils {
- =C2=A0 =C2=A0private static JFileChooser fileChooser;
-
+=20
0; =C2=A0
=C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
=C2=A0 =C2=A0 =C2=A0}
=C2=A0
=C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, St=
ring=20
defaultExtension, String approveButtonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription)=
 {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChooser=
();
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D createFileCho=
oser(parent,defaultExtension,=20
approveButtonName, fileTypeDescription, null );
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0int returnVal =3D fileChooser.showDialog(p=
arent, approveButtonName);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OPTI=
ON) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelectedFi=
le();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
- =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
- =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0
+ =C2=A0 =C2=A0
+ =C2=A0 =C2=A0public static File showFileChooser(Component parent, String=
=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D createFileChooser=
(parent,defaultExtension,=20
approveButtonName, fileTypeDescription, accessory );
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(=
parent, approveButtonName);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE=
_OPTION) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelec=
tedFile();
@@ -49,4 +56,17 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0static JFileChooser createFileChooser( Component parent, Str=
ing=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ){
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D new JFileChoo=
ser();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if( accessory !=3D null ){
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file=
Chooser.setAccessory(accessory);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+=20
0; =C2=A0 =C2=A0 =C2=A0return fileChooser; =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
+ =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0
=C2=A0}
\ No newline at end of file


  was:
FileChooser allows the addition of an accessory component.
I created a simple patch and a more comlicated one which allows
this for FileChooserUtils.
I removed the static JFileChooser member (since an added
accessory component would have been there even if you
wouldn't want it).

--simple
=C2=A0import java.awt.Component;
=C2=A0import java.io.File;

+import javax.swing.JComponent;
=C2=A0import javax.swing.JFileChooser;

=C2=A0/**
@@ -27,20 +28,34 @@
=C2=A0 * @author Keith Donald
=C2=A0 */
=C2=A0public class FileChooserUtils {
- =C2=A0 =C2=A0private static JFileChooser fileChooser;

=C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, St=
ring=20
defaultExtension, String approveButtonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription)=
 {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChooser=
();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D new JFileChooser(=
);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(paren=
t, approveButtonName);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OPTI=
ON) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelectedFi=
le();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0}
+
+ =C2=A0 =C2=A0public static File showFileChooser(Component parent, String=
=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser =C2=A0fileChooser =3D new JFileCh=
ooser();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultF=
ileFilter();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription=
);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setAccessory(accessory);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(=
parent, approveButtonName);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE=
_OPTION) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelec=
tedFile();
@@ -49,4 +64,9 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
+
+
+
+
+
=C2=A0}
\ No newline at end of file

--complicated
Index: FileChooserUtils.java
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file:=20
/cvsroot/spring-rich-c/spring-richclient/src/org/springframework/richclient=
/filechooser/FileChooserUtils.java,v
retrieving revision 1.5
diff -u -r1.5 FileChooserUtils.java
--- FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A031 Oct 2=
004 18:58:46 -0000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01.5
+++ FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03 Dec 20=
04 13:35:07 -0000
@@ -18,6 +18,7 @@
=C2=A0import java.awt.Component;
=C2=A0import java.io.File;
=C2=A0
+import javax.swing.JComponent;
=C2=A0import javax.swing.JFileChooser;
=C2=A0
=C2=A0/**
@@ -27,20 +28,26 @@
=C2=A0 * @author Keith Donald
=C2=A0 */
=C2=A0public class FileChooserUtils {
- =C2=A0 =C2=A0private static JFileChooser fileChooser;
-
+ =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
=C2=A0 =C2=A0 =C2=A0}
=C2=A0
=C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, St=
ring=20
defaultExtension, String approveButtonName,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription)=
 {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChooser=
();
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D createFileCho=
oser(parent,defaultExtension,=20
approveButtonName, fileTypeDescription, null );
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0int returnVal =3D fileChooser.showDialog(p=
arent, approveButtonName);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OPTI=
ON) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelectedFi=
le();
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
- =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
- =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
- =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0
+ =C2=A0 =C2=A0
+ =C2=A0 =C2=A0public static File showFileChooser(Component parent, String=
=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ) {
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D createFileChooser=
(parent,defaultExtension,=20
approveButtonName, fileTypeDescription, accessory );
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(=
parent, approveButtonName);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE=
_OPTION) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelec=
tedFile();
@@ -49,4 +56,17 @@
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0static JFileChooser createFileChooser( Component parent, Str=
ing=20
defaultExtension, String approveButtonName,
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JCom=
ponent accessory ){
+ =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D new JFileChoo=
ser();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFileFi=
lter();
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0if( accessory !=3D null ){
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0file=
Chooser.setAccessory(accessory);
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser; =C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
+ =C2=A0 =C2=A0}
+ =C2=A0 =C2=A0
=C2=A0}
\ No newline at end of file



> FileChooser - Utils with accessory component
> --------------------------------------------
>
>                 Key: RCP-60
>                 URL: http://opensource.atlassian.com/projects/spring/brow=
se/RCP-60
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: springtester
>            Priority: Minor
>
> FileChooser allows the addition of an accessory component.
> I created a simple patch and a more comlicated one which allows
> this for FileChooserUtils.
> I removed the static JFileChooser member (since an added
> accessory component would have been there even if you
> wouldn't want it).
> --simple
> =C2=A0import java.awt.Component;
> =C2=A0import java.io.File;
> +import javax.swing.JComponent;
> =C2=A0import javax.swing.JFileChooser;
> =C2=A0/**
> @@ -27,20 +28,34 @@
> =C2=A0 * @author Keith Donald
> =C2=A0 */
> =C2=A0public class FileChooserUtils {
> - =C2=A0 =C2=A0private static JFileChooser fileChooser;
> =C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
> =C2=A0 =C2=A0 =C2=A0}
> =C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, =
String=20
> defaultExtension, String approveButtonName,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescriptio=
n) {
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChoos=
er();
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D new JFileChoose=
r();
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFile=
Filter();
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialog(par=
ent, approveButtonName);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OP=
TION) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelected=
File();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0}
> +
> + =C2=A0 =C2=A0public static File showFileChooser(Component parent, Strin=
g=20
> defaultExtension, String approveButtonName,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JC=
omponent accessory ) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser =C2=A0fileChooser =3D new JFile=
Chooser();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new Defaul=
tFileFilter();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescripti=
on);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setAccessory(accessory);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialo=
g(parent, approveButtonName);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPRO=
VE_OPTION) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSel=
ectedFile();
> @@ -49,4 +64,9 @@
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> =C2=A0 =C2=A0 =C2=A0}
> +
> +
> +
> +
> +
> =C2=A0}
> \ No newline at end of file
> --complicated
> Index: FileChooserUtils.java
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file:=20
> /cvsroot/spring-rich-c/spring-richclient/src/org/springframework/richclie=
nt/filechooser/FileChooserUtils.java,v
> retrieving revision 1.5
> diff -u -r1.5 FileChooserUtils.java
> --- FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A031 Oct=
 2004 18:58:46 -0000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A01.5
> +++ FileChooserUtils.java=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03 Dec =
2004 13:35:07 -0000
> @@ -18,6 +18,7 @@
> =C2=A0import java.awt.Component;
> =C2=A0import java.io.File;
> =C2=A0
> +import javax.swing.JComponent;
> =C2=A0import javax.swing.JFileChooser;
> =C2=A0
> =C2=A0/**
> @@ -27,20 +28,26 @@
> =C2=A0 * @author Keith Donald
> =C2=A0 */
> =C2=A0public class FileChooserUtils {
> - =C2=A0 =C2=A0private static JFileChooser fileChooser;
> -
> +=20
> 0; =C2=A0
> =C2=A0 =C2=A0 =C2=A0private FileChooserUtils() {
> =C2=A0 =C2=A0 =C2=A0}
> =C2=A0
> =C2=A0 =C2=A0 =C2=A0public static File showFileChooser(Component parent, =
String=20
> defaultExtension, String approveButtonName,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescriptio=
n) {
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0if (fileChooser =3D=3D null) {
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser =3D new JFileChoos=
er();
> + =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D createFileC=
hooser(parent,defaultExtension,=20
> approveButtonName, fileTypeDescription, null );
> + =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0int returnVal =3D fileChooser.showDialog=
(parent, approveButtonName);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPROVE_OP=
TION) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSelected=
File();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFile=
Filter();
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
> - =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0else {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0
> + =C2=A0 =C2=A0
> + =C2=A0 =C2=A0public static File showFileChooser(Component parent, Strin=
g=20
> defaultExtension, String approveButtonName,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JC=
omponent accessory ) {
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0JFileChooser fileChooser =3D createFileChoos=
er(parent,defaultExtension,=20
> approveButtonName, fileTypeDescription, accessory );
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int returnVal =3D fileChooser.showDialo=
g(parent, approveButtonName);
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (returnVal =3D=3D JFileChooser.APPRO=
VE_OPTION) {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return fileChooser.getSel=
ectedFile();
> @@ -49,4 +56,17 @@
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return null;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> =C2=A0 =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0static JFileChooser createFileChooser( Component parent, S=
tring=20
> defaultExtension, String approveButtonName,
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0String fileTypeDescription, JC=
omponent accessory ){
> + =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0JFileChooser fileChooser =3D new JFileCh=
ooser();
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0DefaultFileFilter filter =3D new DefaultFile=
Filter();
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.addExtension(defaultExtension);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0filter.setDescription(fileTypeDescription);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0fileChooser.setFileFilter(filter);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0if( accessory !=3D null ){
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0fi=
leChooser.setAccessory(accessory);
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> +=20
> 0; =C2=A0 =C2=A0 =C2=A0return fileChooser; =C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
> + =C2=A0 =C2=A0}
> + =C2=A0 =C2=A0
> =C2=A0}
> \ No newline at end of file

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://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-59) Add callback to ApplicationLifecycleAdvisor for the shutdown stage of an application

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

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

Keith Donald updated RCP-59:
----------------------------

    Assignee:     (was: Keith Donald)

> Add callback to ApplicationLifecycleAdvisor for the shutdown stage of an application
> ------------------------------------------------------------------------------------
>
>                 Key: RCP-59
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-59
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Calvin Yu
>            Priority: Minor
>         Attachments: Application.java.patch, ApplicationLifecycleAdvisor.java.patch
>
>
> There are currently two ways to ensure extra processing is done before an application is shutdown: 1) in ApplicationLifecycleAdvisor.onPreWindowClose(), and by 2) overriding Application.close().  Both options are sub-optimal solutions because you still have to check that all windows are closed before doing processing.
> There should be an extra onPreShutdown() method in the ApplicationLifecycleAdvisor class for this use.

-- 
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-80) Provide dymanic wizard pages

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

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

Keith Donald updated RCP-80:
----------------------------

    Assignee:     (was: Keith Donald)

> Provide dymanic wizard pages
> ----------------------------
>
>                 Key: RCP-80
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-80
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Nitin Vazarkar
>            Priority: Minor
>
> I tried to use the wizard framework and found it sufficient only for 'static' wizard applications (which in my view are very rare). The FW forces you to create your pages in advance including the contents of the pages. A wizard rarely is used in that manner. Typically, values from one page are used in constructing the next page (i.e. the next page is built dynamically based on the selections in the last page).
> A related issue is that the values entered by the user are only available after you 'commit' the form. This is not suitable since you would like to use the values entered by the user to construct the dynamic pages (i.e. there should be some means for partial or page level commits).
> I have 'patched' the source to allow for the first case (a dynamic wizard). However, the implementation is not very clean. It would be nice if the framework handled it transparently.

-- 
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-92) Rich Client Support For Jasper Reports

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

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

Keith Donald updated RCP-92:
----------------------------

    Assignee:     (was: Keith Donald)

> Rich Client Support For Jasper Reports
> --------------------------------------
>
>                 Key: RCP-92
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-92
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Joe Kelly
>            Priority: Minor
>         Attachments: ConfigurableJRViewer.java, DefaultJasperReportGenerator.java, DefaultJasperReportGenerator.java, DefaultJasperReportGeneratorTest.java, HtmlReportDisplayer.java, JasperReportGenerator.java, JasperReportGenerator_usageNotes.txt, JRReportDisplayer.java, JRViewerOptions.java, MyPersonBean.java, MyPersonBean_JavaBeanNamingConvention.jasper, MyPersonBean_JavaBeanNamingConvention.jasper, MyPersonBean_JavaBeanNamingConvention.jrxml, ReportDialogPage.java, ReportException.java
>
>
> While the Spring Framework has some support classes for JasperReports, they seem to be tailored towards web apps, not rich client apps. I would like Spring Rich Client to have some support for JasperReports. See this forum topic for some discussion of this:
> http://forum.springframework.org/viewtopic.php?t=3276
> For my application, I have made a few classes that make it a bit easier to use JasperReports within a Spring Rich Client app. I will attach those classes to this feature request. They are very basic implementations but they could be a good starting point for a Spring Rich Client project developer.

-- 
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-82) ValidationEvent should not require anything to be passed in

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

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

Keith Donald updated RCP-82:
----------------------------

    Assignee:     (was: Keith Donald)

> ValidationEvent should not require anything to be passed in
> -----------------------------------------------------------
>
>                 Key: RCP-82
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-82
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Jim Moore
>            Priority: Minor
>
> For example: you have a screen that has a list (no FormModel) in a panel, and you want the WizardPage to be enabled or disabled based on whether or not the panel is valid (ie, something is selected in the list).  The selection/deselection is, logically, a valid/invalid event.
> Currently, you have to pass in a FormModel and the Constraint involved.  However, as the example illustrates, neither may be relivant to something being valid or invalid.

-- 
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-120) AutomaticTableModel

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

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

Keith Donald updated RCP-120:
-----------------------------

    Assignee:     (was: Keith Donald)

> AutomaticTableModel
> -------------------
>
>                 Key: RCP-120
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-120
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Stephan Schmidt
>            Priority: Minor
>
> As posted on the ML, here is the code for the AutomaticTableModel
> svn co http://snipforge.org/svn/so

-- 
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-111) Text and icon in toolbar

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

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

Keith Donald updated RCP-111:
-----------------------------

    Assignee:     (was: Keith Donald)

> Text and icon in toolbar
> ------------------------
>
>                 Key: RCP-111
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-111
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>            Reporter: Claudio Romano
>            Priority: Minor
>
> The toolbar should be customisable thru the properties framework to show text or icon or both.
> Link to discussion thread:
> http://forum.springframework.org/viewtopic.php?t=4018

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