springframework-rcp-dev — Spring Rich Client developer list

Re: [Springframework-rcp-dev] The Spring Experience 2007

[Geoffrey De S. <ge0...@gm...>]

Will do :)

With kind regards,
Geoffrey De Smet

Peter De Bruycker schreef:
> You're correct. The documentation in the wiki is not u to date.
> 
> A docbook sounds like a good approach. As a matter of fact, we discussed 
> this at JavaPolis ;-)
> 
> I think Geoffrey was going to do the setup.
> 
> Peter
> 
> On Dec 20, 2007 5:15 PM, Eduardo Ito <zi...@su... 
> <mailto:zi...@su...>> wrote:
> 
>     Good to see it aproaching to a release!
> 
>     The biggest problem preventing bigger adoptions is documentation...
>     It does not need to be comprehensive, but must be correct and up to
>     date, explaining the main concepts, lecing the details in javadocs.
> 
>     Looking at the wiki I'm not confident that the information there is
>     entirely correct. I would suggest creating a docbook document like the
>     Spring project.
> 
> 
>     On 12/20/07, Jan Hoskens < jh...@sc...
>     <mailto:jh...@sc...>> wrote:
>      > I won't be at TSE, but I guess you can mention that we'll have a 1.0
>      > release in januari. We will fix the known bugs and try to provide a
>      > decent documentation.
>      >
>      > After this release we'll need to discuss which road we are going to
>      > take. A personal point here is that I think we need an additional
>      > pattern to easily create CRUD based applications. But we'll get
>     to that
>      > next month.
>      >
>      > Kind Regards,
>      > Jan
>      >
>      >
>      > On Fri, 2007-12-07 at 10:50 -0500, Jim Moore wrote:
>      > > Who's going to TSE this year?  Is there anything you guys want
>     to make
>      > > sure I talk about in my "Desktop Matters" presentation?
>      > >
>      > >
>      > >
>      > > -Jim Moore
>      > >
>      > >  Senior Consultant, SpringSource
>      > >
>      > >
>      > >
>      > >
>      > >
>     -------------------------------------------------------------------------
>      > > SF.Net email is sponsored by:
>      > > Check out the new SourceForge.net Marketplace.
>      > > It's the best place to buy or sell services for
>      > > just about anything Open Source.
>      > > http://sourceforge.net/services/buy/index.php
>      > > _______________________________________________
>     Springframework-rcp-dev mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>     <https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev>
>      >
>      >
>      >  **** DISCLAIMER ****
>      >  http://www.schaubroeck.be/maildisclaimer.htm
>      >
>      >
>     -------------------------------------------------------------------------
> 
>      > SF.Net email is sponsored by:
>      > Check out the new SourceForge.net Marketplace.
>      > It's the best place to buy or sell services
>      > for just about anything Open Source.
>      >
>     http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>      > _______________________________________________
>      > Springframework-rcp-dev mailing list
>      > Spr...@li...
>     <mailto:Spr...@li...>
>      >
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>     <https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev>
>      >
> 
> 
>     --
>     Eduardo Issao Ito
>     Summa Technologies
> 
>     "Discipline is never an end in itself, only a means to an end"
> 
>     -------------------------------------------------------------------------
> 
>     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/
>     <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
>     _______________________________________________
>     Springframework-rcp-dev mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> 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

[Springframework-rcp-dev] [Spring-JIRA] Closed: (RCP-506) Continuous integration info in pom.xml is wrong

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

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

Jan Hoskens closed RCP-506.
---------------------------

         Assignee: Jan Hoskens
       Resolution: Fixed
    Fix Version/s: 0.3.0

Changed ciManagement system to bamboo,
added url "https://build.springframework.org/bamboo/browse/RCP"
removed notifier (as far as I know this is not yet supported by bamboo)

http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c?view=3Drev&re=
vision=3D1868

> Continuous integration info in pom.xml is wrong
> -----------------------------------------------
>
>                 Key: RCP-506
>                 URL: http://opensource.atlassian.com/projects/spring/brow=
se/RCP-506
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>         Environment: all
>            Reporter: Anders B=C3=A5tstrand
>            Assignee: Jan Hoskens
>            Priority: Trivial
>             Fix For: 0.3.0
>
>   Original Estimate: 0d
>  Remaining Estimate: 0d
>
> The pom.xml file says the project uses continuum, but states no link:=20
> http://spring-rich-c.sourceforge.net/integration.html
> In fact, Bamboo is in use, and here is the link:
> http://build.springframework.org:8085/bamboo/browse/RCP

--=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] Commented: (RCP-422) Update the schema's in the examples to match for spring 2.0

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

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

Jan Hoskens commented on RCP-422:
---------------------------------

I did forget the support/test contexts (thanks for the patch), but your other patches may have been made with an old checkout. 

> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
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] Reopened: (RCP-422) Update the schema's in the examples to match for spring 2.0

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker reopened RCP-422:
-----------------------------------


> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
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] The Spring Experience 2007

[Peter De B. <pet...@gm...>]

You're correct. The documentation in the wiki is not u to date.

A docbook sounds like a good approach. As a matter of fact, we discussed
this at JavaPolis ;-)

I think Geoffrey was going to do the setup.

Peter

On Dec 20, 2007 5:15 PM, Eduardo Ito <zi...@su...> wrote:

> Good to see it aproaching to a release!
>
> The biggest problem preventing bigger adoptions is documentation...
> It does not need to be comprehensive, but must be correct and up to
> date, explaining the main concepts, lecing the details in javadocs.
>
> Looking at the wiki I'm not confident that the information there is
> entirely correct. I would suggest creating a docbook document like the
> Spring project.
>
>
> On 12/20/07, Jan Hoskens <jh...@sc...> wrote:
> > I won't be at TSE, but I guess you can mention that we'll have a 1.0
> > release in januari. We will fix the known bugs and try to provide a
> > decent documentation.
> >
> > After this release we'll need to discuss which road we are going to
> > take. A personal point here is that I think we need an additional
> > pattern to easily create CRUD based applications. But we'll get to that
> > next month.
> >
> > Kind Regards,
> > Jan
> >
> >
> > On Fri, 2007-12-07 at 10:50 -0500, Jim Moore wrote:
> > > Who's going to TSE this year?  Is there anything you guys want to make
> > > sure I talk about in my "Desktop Matters" presentation?
> > >
> > >
> > >
> > > -Jim Moore
> > >
> > >  Senior Consultant, SpringSource
> > >
> > >
> > >
> > >
> > >
> -------------------------------------------------------------------------
> > > SF.Net email is sponsored by:
> > > Check out the new SourceForge.net Marketplace.
> > > It's the best place to buy or sell services for
> > > just about anything Open Source.
> > > http://sourceforge.net/services/buy/index.php
> > > _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
> >
> >  **** DISCLAIMER ****
> >  http://www.schaubroeck.be/maildisclaimer.htm
> >
> >
> -------------------------------------------------------------------------
> > SF.Net email is sponsored by:
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services
> > for just about anything Open Source.
> >
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
>
>
> --
> Eduardo Issao Ito
> Summa Technologies
>
> "Discipline is never an end in itself, only a means to an end"
>
> -------------------------------------------------------------------------
> 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
>

Re: [Springframework-rcp-dev] The Spring Experience 2007

[Eduardo I. <zi...@su...>]

Good to see it aproaching to a release!

The biggest problem preventing bigger adoptions is documentation...
It does not need to be comprehensive, but must be correct and up to
date, explaining the main concepts, lecing the details in javadocs.

Looking at the wiki I'm not confident that the information there is
entirely correct. I would suggest creating a docbook document like the
Spring project.


On 12/20/07, Jan Hoskens <jh...@sc...> wrote:
> I won't be at TSE, but I guess you can mention that we'll have a 1.0
> release in januari. We will fix the known bugs and try to provide a
> decent documentation.
>
> After this release we'll need to discuss which road we are going to
> take. A personal point here is that I think we need an additional
> pattern to easily create CRUD based applications. But we'll get to that
> next month.
>
> Kind Regards,
> Jan
>
>
> On Fri, 2007-12-07 at 10:50 -0500, Jim Moore wrote:
> > Who's going to TSE this year?  Is there anything you guys want to make
> > sure I talk about in my "Desktop Matters" presentation?
> >
> >
> >
> > -Jim Moore
> >
> >  Senior Consultant, SpringSource
> >
> >
> >
> >
> > -------------------------------------------------------------------------
> > SF.Net email is sponsored by:
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________ Springframework-rcp-dev mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>


-- 
Eduardo Issao Ito
Summa Technologies

"Discipline is never an end in itself, only a means to an end"

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-422) Update the schema's in the examples to match for spring 2.0

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

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

Lieven Doclo updated RCP-422:
-----------------------------

    Attachment: spring-richclient-samples-simple.patch
                spring-richclient-petclinic-standalone.patch
                spring-richclient-petclinic-server.patch

> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
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-422) Update the schema's in the examples to match for spring 2.0

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

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

Lieven Doclo updated RCP-422:
-----------------------------

    Attachment: spring-richclient-petclinic-gui.patch
                spring-richclient-petclinic-client.patch
                spring-richclient-petclinic-business.patch

not all apparently, still found some in src/test/resources of support and in samples. Patched attached

> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
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-422) Update the schema's in the examples to match for spring 2.0

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

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

Lieven Doclo updated RCP-422:
-----------------------------

    Attachment: spring-richclient-support.patch
                spring-richclient-samples-vldocking.patch

> Update the schema's in the examples to match for spring 2.0
> -----------------------------------------------------------
>
>                 Key: RCP-422
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-422
>             Project: Spring Framework Rich Client Project
>          Issue Type: Task
>          Components: Samples
>    Affects Versions: 0.2.1
>            Reporter: Geoffrey De Smet
>            Assignee: Geoffrey De Smet
>             Fix For: 0.3.0
>
>         Attachments: spring-richclient-petclinic-business.patch, spring-richclient-petclinic-client.patch, spring-richclient-petclinic-gui.patch, spring-richclient-petclinic-server.patch, spring-richclient-petclinic-standalone.patch, spring-richclient-samples-simple.patch, spring-richclient-samples-vldocking.patch, spring-richclient-support.patch
>
>
> Now use:
> <beans xmlns="http://www.springframework.org/schema/beans"
>             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>             xsi:schemaLocation="http://www.springframework.org/schema/beans
>                 http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
> Also replace singleton="false" with scope="singleton".

-- 
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] The Spring Experience 2007

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

I won't be at TSE, but I guess you can mention that we'll have a 1.0
release in januari. We will fix the known bugs and try to provide a
decent documentation. 

After this release we'll need to discuss which road we are going to
take. A personal point here is that I think we need an additional
pattern to easily create CRUD based applications. But we'll get to that
next month.

Kind Regards,
Jan


On Fri, 2007-12-07 at 10:50 -0500, Jim Moore wrote:
> Who’s going to TSE this year?  Is there anything you guys want to make
> sure I talk about in my “Desktop Matters” presentation?
> 
>  
> 
> -Jim Moore
> 
>  Senior Consultant, SpringSource
> 
>  
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: 
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________ 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] StatusBar a concrete class...

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

Seems reasonable to me. 
+1

Kind Regards,
Jan


On Wed, 2007-12-19 at 09:40 +0100, Peter De Bruycker wrote:
> Does anyone know why the StatusBarCommandGroup is a CommandGroup?
> 
> I think it'd be better if we have something like this:
> 
> 
> public interface StatusBar extends ControlFactory,
> ApplicationWindowAware {
>     ProgressMonitor getProgressMonitor();
> 
>     void setMessage(Message message);
> 
>     void setMessage(String message);
> 
>     void setErrorMessage(Message message);
> 
>     void setErrorMessage(String message); 
> 
>     void setVisible(boolean visible);
> 
>     void setCancelEnabled(boolean enabled);
> }
> 
> with a default implementation, and perhaps an implementation using
> JXStatusBar from SwingLabs.
> 
> the ApplicationLifecycleAdvisor.getStatusBarCommandGroup could then be
> replaced with a "public StatusBar createStatusBar()" method which can
> be overridden to create the correct instance.
> 
> What do you think?
> 
> Peter
> 
> On Jul 9, 2007 2:27 PM, Benoit Xhenseval < bx...@ob...> wrote:
>         Hi Jan,
>         
>         You are right, I have looked deeper and had a chat with Jonny
>         too; the StatusBar itself could stay a concrete class.
>         Unfortunately, the StatusBarCommandGroup is concrete and
>         cannot be injected. It would be nice and simplify use of say
>         the jide Status Bar...  The only we found to replace a
>         StatusBar was to extend the StatusBarCommandGroup and replace
>         all methods. 
>         
>         I'd say that the StatusBarCommandGroup would be better as an
>         interface.
>         
>         Thanks for considering this.
>         
>         Best regards
>         
>         Benoit.
>         
>         
>         
>         -----Original Message----- 
>         From: spr...@li...
>         [mailto:spr...@li...]
>         On Behalf Of Jan Hoskens
>         Sent: 09 July 2007 12:59
>         To: spr...@li...
>         Subject: Re: [Springframework-rcp-dev] StatusBar a concrete
>         class... 
>         
>         Hmm,
>         
>         As far as my eclipse search shows me, the StatusBar is only
>         used
>         internally by the StatusBarCommandGroup. The implementation of
>         StatusBar
>         is quite specific. I don't think we need interfacing at that
>         level 
>         because it's actually the StatusBarCommandGroup that takes
>         care of this.
>         You can create your own CustomStatusBar without extending the
>         Status Bar
>         and then extend the StatusBarCommandGroup by overriding all
>         methods and 
>         delegating to your own CustomStatusBar.
>         
>         Then again, at that point (the StatusBarCommandGroup) it might
>         be
>         feasible/preferable to have an interface but I don't know how
>         tight the
>         specific StatusBarCommandGroup is coupled in the rcp-code. 
>         
>         Kind Regards,
>         Jan
>         
>         On Fri, 2007-07-06 at 17:55 +0100, Benoit Xhenseval wrote:
>         > Hi
>         >
>         > I'm trying to change the StatusBar to split it to have a
>         section for
>         > scrolling messages. I'm a bit surprised that quite a few
>         interfaces 
>         > are using StatusBar which is a concrete class.
>         >
>         >
>         >
>         > Should I use only the StatusBarCommandGroup???
>         >
>         >
>         > At the moment, my approach is to have:
>         > - my lifecycleAdvisor to override
>         getStatusBarCommandGroup() 
>         > - returning a StatusBarCommandGroup that overrides
>         createStatusBar()
>         > (but requires a StatusBar itself!!! so I must extends that
>         class even
>         > if I do not intend to use it...
>         >
>         > Is my approach ok? 
>         >
>         >
>         >
>         > However this seems extension of the StatusBar seems to cause
>         some
>         > issue, the initialize method on StatusBar is called which
>         then creates
>         > items in the JPanel…
>         >
>         > 
>         > Could the StatusBar be refactored to be an interface?
>         >
>         >
>         >
>         > I'm willing to provide a patch if you're ok with this:
>         >
>         > Interface StatusBar {
>         >
>         >     ProgressMonitor getProgressMonitor() 
>         >
>         >     void setMessage(String message)
>         >
>         >     void setMessage(ImageIcon icon, String message)
>         >
>         >     void setErrorMessage(String message)
>         >
>         >     void setErrorMessage(ImageIcon icon, String message) 
>         >
>         >     void setVisible(boolean visible)
>         >
>         > }
>         >
>         >
>         >
>         > Let me know, we're a bit stuck at the moment…
>         >
>         >
>         > Thanks!
>         >
>         > Benoit
>         >
>         >
>         >
>         > No virus found in this outgoing message.
>         > Checked by AVG Free Edition.
>         > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release
>         Date:
>         > 06/07/2007 06:36
>         >
>         >
>         >
>         ------------------------------------------------------------------------- 
>         > This SF.net email is sponsored by DB2 Express
>         > Download DB2 Express C - the FREE version of DB2 express and
>         take
>         > control of your XML. No limits. Just data. Click to get it
>         now.
>         > http://sourceforge.net/powerbar/db2/
>         > _______________________________________________
>         Springframework-rcp-dev mailing list
>         Spr...@li...
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>         
>         
>          **** DISCLAIMER ****
>          http://www.schaubroeck.be/maildisclaimer.htm
>         
>         -------------------------------------------------------------------------
>         This SF.net email is sponsored by DB2 Express
>         Download DB2 Express C - the FREE version of DB2 express and
>         take 
>         control of your XML. No limits. Just data. Click to get it
>         now.
>         http://sourceforge.net/powerbar/db2/
>         _______________________________________________ 
>         Springframework-rcp-dev mailing list
>         Spr...@li...
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>         
>         
>         No virus found in this incoming message.
>         Checked by AVG Free Edition.
>         
>         Version: 7.5.476 / Virus Database: 269.10.2/891 - Release
>         Date: 08/07/2007 18:32
>         
>         
>         No virus found in this outgoing message.
>         Checked by AVG Free Edition.
>         
>         Version: 7.5.476 / Virus Database: 269.10.2/891 - Release
>         Date: 08/07/2007 18:32 
>         
>         
>         
>         
>         -------------------------------------------------------------------------
>         This SF.net email is sponsored by DB2 Express
>         Download DB2 Express C - the FREE version of DB2 express and
>         take 
>         control of your XML. No limits. Just data. Click to get it
>         now.
>         http://sourceforge.net/powerbar/db2/
>         _______________________________________________ 
>         Springframework-rcp-dev mailing list
>         Spr...@li...
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>         
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________ 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-97) Creating ActionCommands without a CommandFaceDescriptor causes memory leaks

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

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

Jan Hoskens commented on RCP-97:
--------------------------------

After a quick code sweep it seems to me that 2 is the way to go here. 

If at some point you want to change a property of the FaceDescriptor this change should not be reflected by all commands (as is the case now with a shared object). On the other hand not reacting at all (as in 1 and 3)  breaks the purpose of the whole listening aspect. (you might want to change the faceDescriptor at runtime)

> Creating ActionCommands without a CommandFaceDescriptor causes memory leaks
> ---------------------------------------------------------------------------
>
>                 Key: RCP-97
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-97
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>            Reporter: Calvin Yu
>         Attachments: CommandFaceButtonManager.patch
>
>
> If no CommandFaceDescriptor is specified, then CommandFaceDescriptor.BLANK_FACE_DESCRIPTOR.  The ActionCommand's CommandFaceButtonManager then calls addPropertyChangeListener() on this descriptor, adding itself as the listener.  Unless another CommandFaceDescriptor is set for that ActionCommand, the CommandFaceButtonManager will never be removed from BLANK_FACE_DESCRIPTOR, and therefore the manager and command will never be garbage collected since the descriptor is a static.
> Possible solutions:
> 1) Remove AbstractPropertyChangePublisher's final modifiers on the addPropertyChangeListener() methods, so that they can be overriden by BLANK_FACE_DESCRIPTOR to be a no-op.
> 2) Create a new blank CommandFaceDescriptor instead of using a constant.
> 3) Modify CommandFaceButtonManager so that it isn't added as a PropertyChangeListener if the descriptor is BLANK_FACE_DESCRIPTOR.
> I've attached a patch to solution #3.  While I believe #3 isn't the most optimal solution, it does have less potential side effects to solutions #1 and #2.

-- 
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] Closed: (RCP-483) missing to remove view from ApplicationEventMulticaster when view is closed

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

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

Jan Hoskens closed RCP-483.
---------------------------

         Assignee: Jan Hoskens
       Resolution: Fixed
    Fix Version/s: 0.3.0

Moved adding of listener to AbstractApplicationPage.createPageComponent
Added removing of listener in AbstractApplicationPage.close(PageComponent)

http://spring-rich-c.svn.sourceforge.net/viewvc/spring-rich-c?view=rev&revision=1866

> 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
>            Assignee: Jan Hoskens
>            Priority: Critical
>             Fix For: 0.3.0
>
>
> 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] StatusBar a concrete class...

[Peter De B. <pet...@gm...>]

Does anyone know why the StatusBarCommandGroup is a CommandGroup?

I think it'd be better if we have something like this:


public interface StatusBar extends ControlFactory, ApplicationWindowAware {
    ProgressMonitor getProgressMonitor();

    void setMessage(Message message);

    void setMessage(String message);

    void setErrorMessage(Message message);

    void setErrorMessage(String message);

    void setVisible(boolean visible);

    void setCancelEnabled(boolean enabled);
}

with a default implementation, and perhaps an implementation using
JXStatusBar from SwingLabs.

the ApplicationLifecycleAdvisor.getStatusBarCommandGroup could then be
replaced with a "public StatusBar createStatusBar()" method which can be
overridden to create the correct instance.

What do you think?

Peter

On Jul 9, 2007 2:27 PM, Benoit Xhenseval <bx...@ob...> wrote:

> Hi Jan,
>
> You are right, I have looked deeper and had a chat with Jonny too; the
> StatusBar itself could stay a concrete class. Unfortunately, the
> StatusBarCommandGroup is concrete and cannot be injected. It would be nic=
e
> and simplify use of say the jide Status Bar...  The only we found to repl=
ace
> a StatusBar was to extend the StatusBarCommandGroup and replace all metho=
ds.
>
> I'd say that the StatusBarCommandGroup would be better as an interface.
>
> Thanks for considering this.
>
> Best regards
>
> Benoit.
>
>
> -----Original Message-----
> From: spr...@li... [mailto:
> spr...@li...] On Behalf Of Jan
> Hoskens
> Sent: 09 July 2007 12:59
> To: spr...@li...
> Subject: Re: [Springframework-rcp-dev] StatusBar a concrete class...
>
> Hmm,
>
> As far as my eclipse search shows me, the StatusBar is only used
> internally by the StatusBarCommandGroup. The implementation of StatusBar
> is quite specific. I don't think we need interfacing at that level
> because it's actually the StatusBarCommandGroup that takes care of this.
> You can create your own CustomStatusBar without extending the Status Bar
> and then extend the StatusBarCommandGroup by overriding all methods and
> delegating to your own CustomStatusBar.
>
> Then again, at that point (the StatusBarCommandGroup) it might be
> feasible/preferable to have an interface but I don't know how tight the
> specific StatusBarCommandGroup is coupled in the rcp-code.
>
> Kind Regards,
> Jan
>
> On Fri, 2007-07-06 at 17:55 +0100, Benoit Xhenseval wrote:
> > Hi
> >
> > I'm trying to change the StatusBar to split it to have a section for
> > scrolling messages. I'm a bit surprised that quite a few interfaces
> > are using StatusBar which is a concrete class.
> >
> >
> >
> > Should I use only the StatusBarCommandGroup???
> >
> >
> > At the moment, my approach is to have:
> > - my lifecycleAdvisor to override getStatusBarCommandGroup()
> > - returning a StatusBarCommandGroup that overrides createStatusBar()
> > (but requires a StatusBar itself!!! so I must extends that class even
> > if I do not intend to use it...
> >
> > Is my approach ok?
> >
> >
> >
> > However this seems extension of the StatusBar seems to cause some
> > issue, the initialize method on StatusBar is called which then creates
> > items in the JPanel=85
> >
> >
> > Could the StatusBar be refactored to be an interface?
> >
> >
> >
> > I'm willing to provide a patch if you're ok with this:
> >
> > Interface StatusBar {
> >
> >     ProgressMonitor getProgressMonitor()
> >
> >     void setMessage(String message)
> >
> >     void setMessage(ImageIcon icon, String message)
> >
> >     void setErrorMessage(String message)
> >
> >     void setErrorMessage(ImageIcon icon, String message)
> >
> >     void setVisible(boolean visible)
> >
> > }
> >
> >
> >
> > Let me know, we're a bit stuck at the moment=85
> >
> >
> > Thanks!
> >
> > Benoit
> >
> >
> >
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.5.476 / Virus Database: 269.10.1/888 - Release Date:
> > 06/07/2007 06:36
> >
> >
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________ Springframework-rcp-dev
> mailing list Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 08/07/200=
7
> 18:32
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.2/891 - Release Date: 08/07/200=
7
> 18:32
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Spring-JIRA] Updated: (RCP-509) Add Hibernate Validator notification to the GUI validation framework

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

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

Lieven Doclo updated RCP-509:
-----------------------------

    Attachment: HibernateRulesValidator.java
                HibernateRulesMessageInterpolator.java

Andy Dupue already made a HibernateValidator, I adapted it so you can also use rules in combination with the validator annotations (for example, to validate the @AssertTrue annotated methods).

> Add Hibernate Validator notification to the GUI validation framework
> --------------------------------------------------------------------
>
>                 Key: RCP-509
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-509
>             Project: Spring Framework Rich Client Project
>          Issue Type: New Feature
>          Components: Application Framework
>            Reporter: Lieven Doclo
>         Attachments: HibernateRulesMessageInterpolator.java, HibernateRulesValidator.java
>
>
> Use the Hibernate Validator to validate formobjects instead of or in combination with rules.

-- 
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-509) Add Hibernate Validator notification to the GUI validation framework

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

Add Hibernate Validator notification to the GUI validation framework
--------------------------------------------------------------------

                 Key: RCP-509
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-509
             Project: Spring Framework Rich Client Project
          Issue Type: New Feature
          Components: Application Framework
            Reporter: Lieven Doclo


Use the Hibernate Validator to validate formobjects instead of or in combination with rules.

-- 
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-438) Inline validation of Integer fields

[Peter De B. (JIRA) <no...@at...>]

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

Peter De Bruycker updated RCP-438:
----------------------------------

              Assignee: Peter De Bruycker
    Remaining Estimate: 0d
     Original Estimate: 0d

> Inline validation of Integer fields
> -----------------------------------
>
>                 Key: RCP-438
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-438
>             Project: Spring Framework Rich Client Project
>          Issue Type: Bug
>          Components: Binding System
>    Affects Versions: 0.2.1
>            Reporter: Danie Roux
>            Assignee: Peter De Bruycker
>         Attachments: RCP-438.patch
>
>   Original Estimate: 0d
>  Remaining Estimate: 0d
>
> Validation does not execute after initial key-press. 
> For example: 
> Fails validation
> a9999  
> .09js
> Passes validation
> 9aaaa
> 1.2

-- 
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-508) Improve configurability of toolbar creation

[Jonny W. (JIRA) <no...@at...>]

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

Jonny Wray updated RCP-508:
---------------------------

    Attachment: spring-rcp-support.patch

The attached patch contains a number of changes related to improving the configuration of the tool-bar, and buttons in them.

* The ButtonFactory interface was changed to return AbstractButton in a couple of methods. This allows alternative implementations to not have to override the Swing concrete classes. All cascading changes (eg DefaultButtonFactory) have also been made.
* The CommandGroup now uses the ComponentFactory, exposed via CommandServices, to construct the tool-bar. The createToolBar method was recently added to ComponentFactory but wasn't been used as far as I could tell. The type returned from the component factory was changed from JToolBar to JComponent, again allowing for conceptual tool-bar components that don't override JToolBar.
* The concept of a tool-bar specific button factory was introduced to the command services, and is used for tool-bar construction in the command group. If a tool-bar specific button factory is not specified in the command services it defaults to the regular button factory.

Non of these changes should effect existing applications unless they are overriding default implementations of the interfaces that have changed.


> Improve configurability of toolbar creation
> -------------------------------------------
>
>                 Key: RCP-508
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-508
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.2.1
>            Reporter: Jonny Wray
>         Attachments: spring-rcp-support.patch
>
>
> In attempting to integrate the Jide action framework into Spring RCP I've come across a number of places where the configuration of the toolbars could be improved. 

-- 
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-508) Improve configurability of toolbar creation

[Jonny W. (JIRA) <no...@at...>]

Improve configurability of toolbar creation
-------------------------------------------

                 Key: RCP-508
                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-508
             Project: Spring Framework Rich Client Project
          Issue Type: Improvement
          Components: Command System
    Affects Versions: 0.2.1
            Reporter: Jonny Wray



In attempting to integrate the Jide action framework into Spring RCP I've come across a number of places where the configuration of the toolbars could be improved. 


-- 
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-507) Platform independent shortcut configuration is needed

[Jonny W. (JIRA) <no...@at...>]

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

Jonny Wray updated RCP-507:
---------------------------

    Attachment: springrcp-support-2.patch

I've added a second patch that adds variant i18n to the previously described solution. So, this provides:

* The use of the 'shortcut' modifier in the command label property signifies the platform specific shortcut modifier, as defined by the platform specific Toolkit, should be used. This is equivalent to ctrl on windows and meta on MacOS.
* The provided properties files have been modified to use shortcut rather than the platform specific ctrl.
* Predefined platform variants of win, macosx and linux have been defined and the default locale is modified accordingly. This allows, for example, a macosx specific resource bundle properties file to defined the exit command label as 'Quit'
* The provided bundle properties file have a macosx variant file defined that specifies the Quit label. The actual text was obtained by changing the locale on a Mac machine and using the translated Quit label in Safari.
* In order to overcome a problem in the bundle search algorithm used by ResourceBundle.getBundle an extension of org.springframework.context.support.ResourceBundleMessageSource is given that allows language specific bundles with a variant, but without a country, to be used. Note that this problem with ResourceBundle was a know bug in Sun's bug tracker and a solution was provided for Java6, which we obviously can't use. The solution provided is simple but does the job.

The same result could be achieved without the introduction of the shortcut modifier or the use of the ResourceBundleMessageSource extension. However, that solution would require a much larger number of properties files many with much the same content, violating DRY principles. 


> Platform independent shortcut configuration is needed
> -----------------------------------------------------
>
>                 Key: RCP-507
>                 URL: http://opensource.atlassian.com/projects/spring/browse/RCP-507
>             Project: Spring Framework Rich Client Project
>          Issue Type: Improvement
>          Components: Command System
>    Affects Versions: 0.2.1
>            Reporter: Jonny Wray
>         Attachments: springrcp-support-2.patch, springrcp-support.patch
>
>
> The current parsing of the messages file to create shortcuts does not allow for platform independent shortcut definitions, eg ctrl on windows and command on Mac OSX. Also, a number of common commands have their shortcuts set to ctrl which isn't correct on Mac OS and maybe other platforms.

-- 
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] close method in PageComponent

[jwray <jon...@fi...>]

Peter,

thanks for the reply, that clarifies things, and it'll be no problem
bringing the JIDE code back in sync. with HEAD. 

As for project interest, I'm still using it in an old internal project at
work and I'm in the prototyping stage of another newer application. I also
still get help requests regarding the JIDE integration code, so there's
still interest out there. 

I really believe the RCP project has a lot of hidden potential, especially
when considered in conjunction with the rest of the Spring infrastructure.
For example, in my new project I'm using an embedded Mule ESB for both
external service communication and internal event propagation. Mule's
support for spring events, and thus by extension Spring RCP, made this
integration very straightforward and powerful.

Jonny


Peter De Bruycker-2 wrote:
> 
> Jonny,
> 
> Great you found some time to work on it ;-)
> I'm happy to see there's still interest in the community for the project,
> even though we haven't been very active lately.
> 
> About the close and dispose methods:
> - dispose is a lifecycle method that can be overridden to provide extra
> cleanup needed when the PageComponent is being closed.
> - The close method is just a convenience method: it's not intended to be
> overridden, it should essentially just call ApplicationPage.close(this).
> 
> Hope this helps,
> 
> Peter
> 
> On Dec 14, 2007 3:29 AM, jwray <jon...@fi...> wrote:
> 
>>
>>
>> Peter,
>>
>> I've found some time to work on updating the JIDE integration code
>> against
>> the current HEAD and one error I'm getting is my concrete Editor
>> implementation do not implement the close method from pageComponent. What
>> I'm wondering is what the motivation was for adding this method over the
>> already included and used dispose() method? For example, the
>> AbstractApplicationPage.close(PageComponent) method calls dispose on the
>> page component.
>>
>> I'd like to be consistent in the operation semantics between RCP and the
>> JIDE extension but I can't find anywhere that close is used and I'm
>> puzzled
>> as to its used.
>>
>> thanks,
>>
>> Jonny
>> --
>> View this message in context:
>> http://www.nabble.com/close-method-in-PageComponent-tp14328984p14328984.html
>> Sent from the springframework-rcp-dev mailing list archive at Nabble.com.
>>
>>
>> -------------------------------------------------------------------------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services
>> for just about anything Open Source.
>>
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/close-method-in-PageComponent-tp14328984p14331722.html
Sent from the springframework-rcp-dev mailing list archive at Nabble.com.

Re: [Springframework-rcp-dev] close method in PageComponent

[Peter De B. <pet...@gm...>]

Jonny,

Great you found some time to work on it ;-)
I'm happy to see there's still interest in the community for the project,
even though we haven't been very active lately.

About the close and dispose methods:
- dispose is a lifecycle method that can be overridden to provide extra
cleanup needed when the PageComponent is being closed.
- The close method is just a convenience method: it's not intended to be
overridden, it should essentially just call ApplicationPage.close(this).

Hope this helps,

Peter

On Dec 14, 2007 3:29 AM, jwray <jon...@fi...> wrote:

>
>
> Peter,
>
> I've found some time to work on updating the JIDE integration code against
> the current HEAD and one error I'm getting is my concrete Editor
> implementation do not implement the close method from pageComponent. What
> I'm wondering is what the motivation was for adding this method over the
> already included and used dispose() method? For example, the
> AbstractApplicationPage.close(PageComponent) method calls dispose on the
> page component.
>
> I'd like to be consistent in the operation semantics between RCP and the
> JIDE extension but I can't find anywhere that close is used and I'm
> puzzled
> as to its used.
>
> thanks,
>
> Jonny
> --
> View this message in context:
> http://www.nabble.com/close-method-in-PageComponent-tp14328984p14328984.html
> Sent from the springframework-rcp-dev mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] close method in PageComponent

[jwray <jon...@fi...>]

Peter,

I've found some time to work on updating the JIDE integration code against
the current HEAD and one error I'm getting is my concrete Editor
implementation do not implement the close method from pageComponent. What
I'm wondering is what the motivation was for adding this method over the
already included and used dispose() method? For example, the
AbstractApplicationPage.close(PageComponent) method calls dispose on the
page component.

I'd like to be consistent in the operation semantics between RCP and the
JIDE extension but I can't find anywhere that close is used and I'm puzzled
as to its used.

thanks,

Jonny
-- 
View this message in context: http://www.nabble.com/close-method-in-PageComponent-tp14328984p14328984.html
Sent from the springframework-rcp-dev mailing list archive at Nabble.com.

Re: [Springframework-rcp-dev] i18n Questions

[jwray <jon...@fi...>]

Xavier,

Thanks for the reply.

That's exactly what I'm doing, over-riding the mac specific properties in a
file such as messages_en_US_macos.properties and it works fine. 

The problem is that I now need to specify such a file for every English
speaking country to get the macos variants applied to it. What I'd like is
to have a default English file with Mac variant but without specifying the
country, eg messages_en_macosx.properties, that is then used for all English
speaking countries. Every variation of file name without the country code
I've tried has not worked.

Jonny


Xavier Breton wrote:
> 
> The way I know i18n works is that it looks first for the country
> specific properties file ex.
> messages_en_US, if it doesn't found the property it looks for it on
> the language specific bundle messages_en and then you can have as well
> a default bundle to be used if the property weren't found, this is a
> properties file without the language and the country, ex.
> messages.properties
> 
> You can try puting the generic information in the default bundle file,
> then overide the specific with another bundle file for example for the
> language then for the country and then for the variant code you're
> using (macosx).
> 
> Maybe the information in the java tutorial can help you with this issue.
> http://java.sun.com/docs/books/tutorial/i18n/index.html
> This is the page where you can find an example using variant code.
> http://java.sun.com/docs/books/tutorial/i18n/locale/create.html
> 
> Xavier
> 
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/i18n-Questions-tp14310171p14320923.html
Sent from the springframework-rcp-dev mailing list archive at Nabble.com.

Re: [Springframework-rcp-dev] i18n Questions

[jwray <jon...@fi...>]

Eduardo,

The problem of the Mac using a different shortcut key and sometimes a
different word for certain commands (eg Quit rather than Exit in English) is
exactly analogous to different languages using different words for the same
concept. Command labels and shortcut definitions are already specified in
messages resources files so using the same mechanism as a way of dealing
with labeling the commands differently on different platforms is a sound
approach I believe. That's probably why Locale has the mechanism in place
for dealing with such platform variants (thanks to Peter for pointing that
out to me)

Jonny


Eduardo Issao Ito wrote:
> 
> I'm not sure if it is the best approach...
> I should not be forced do internationalize my application, just to
> make it work on the Mac.
> 
> I think that i18n/platform are two orthogonal features.
> 
> 
> Eduardo Issao Ito
> Summa Technologies
> 
> "Discipline is never an end in itself, only a means to an end"
> 
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/i18n-Questions-tp14310171p14320890.html
Sent from the springframework-rcp-dev mailing list archive at Nabble.com.