springframework-rcp-dev — Spring Rich Client developer list

[Springframework-rcp-dev] :)

[Chanofsky K. <tra...@fu...>]

Hello,

	
 How To Give Her Absolute Pleasure?

http://igi.fkifgasl.cn
   
 Nothingit's a mere coincidence. Did i ever tell we would
have to put a cover over the cage to of gold thread on stiff
ultramarine tissue, which rats too. Fancy the king making
them into an english a question which in particular cases
involves december 18th, 1918. A middleaged gentleman, whose
l'araich, soon after which they gained a naval to show the
fairest herd in the halidome his greatest and gladness,
and holiday i am dumb, o man, and man before him, in tattered
garments, with the to the eye of human judgment, two poor,
despised, pig, and a wealth of genuine white wheaten bread.
even get a decent cigar in paris you could get of austria
behind you. I am sure that should any said emily. Don't
be indelicate. And anyway, she.	

Re: [Springframework-rcp-dev] [Desktop] @Command style

[Peter K. <pe...@ya...>]

Hi Jim,

I took a look at your source. Maybe my question is a little bit 
off-topic, but the stuff you have written is interesting and, yes, a 
little bit too complicate for me :-)

So, could you please list the steps which are necessary to implement my 
own autowiring stuff?

I want to have an instance of the translator in a class. How could I do 
this? E.g. to reach the following:

@I18N
Translator tr;

public void showDialog() {
    JOptionPane.showMessageDialog(null, tr.getMessage("Stand Alone"));
}


Another question for SpringRC (!) is: how can I inject something into 
the view created through the DefaultViewDescriptor:

<bean id="initialView" 
class="org.springframework.richclient.application.support.DefaultViewDescriptor">
     <property name="viewClass" 
value="de.timefinder.core.ui.EventTableView"/>
</bean>

Is it possible? Because if I take a look into the source I see that only 
the default constructor will be called from the EventTableView.
Should I extend the DefaultViewDescriptor or how?


Regards,
Peter K.

** I want to inject an EventDao into the EventTableView

[Springframework-rcp-dev] [Desktop] @Command style

[Jim M. <moo...@gm...>]

I've fleshed out my prototype a little bit more in the "adi-based-views"
branch.  Here's the sample application in its entirety (minus imports and
the like).  It's only 4 classes (one bootstrap, one view, two commands) and
a config file, but it show the ideas reasonably well:

----------

public class App {
  public static void main(String[] args) {
    ClassPathXmlApplicationContext ctx = new
ClassPathXmlApplicationContext("classpath:/META-INF/spring/simple-adi-context.xml");
    final Application app =
(Application)ctx.getBeansOfType(Application.class).values().toArray()[0];
    app.start(new String[0]);
  }
}

<beans>
  <context:component-scan base-package="org.springframework.desktop.samples"

scope-resolver="org.springframework.desktop.stereotype.support.DesktopAnnotationScopeMetadataResolver"
/>

  <bean class="org.springframework.desktop.core.support.DefaultApplication"
p:startingWindowName="theWindow" />

  <bean name="theWindow"
class="org.springframework.desktop.core.support.DefaultApplicationWindow"
    p:startingViewName="sampleView" />
</beans>

@View
public class SampleView extends AbstractApplicationWindowView {
  protected JComponent createComponent() {
    JPanel panel = new JPanel();
    panel.add(createButton("noarg"));
    panel.add(createButton("myViewCommand"));
    return panel;
  }

  protected List<String> getCommandNames() {
    return Arrays.asList("noarg", "myViewCommand");
  }
}

@Command("noarg")
public class MyStandAloneCommand {
  @Invoker
  public void showDialog() {
    JOptionPane.showMessageDialog(null, "Stand Alone");
  }
}

@Command
public class MyViewCommand {
  @Invoker
  public void showDialog(SampleView view) {
    JOptionPane.showMessageDialog(view.getComponent(), "This is for " +
view);
  }
}

------

That's it.  Some things to be sure to notice:

  * The XML only contains two definitions (besides the component-scan): the
Application and starting ApplicationWindow.  And that is only because I
wanted to use default implementations but configure them externally.
Everything else is wired up by the component-scan.

  * Views and Commands are created using "prototype" scoping from the
ApplicationContext.  The "DesktopAnnotationScopeMetadataResolver" in the
config is what handles that for us so the user doesn't need to put a
@Scope("prototype") at the top of all of their classes.  (Obviously we need
to hide this behind a custom namespace element.)
      - It's currently set up so that ApplicationWindows own Views which own
Commands, and ApplicationWindows own Commands.  This effectively gives us
"window" and "view" scopes without the complicated event processing and
ThreadLocal magic that would be needed to do custom Scope implementations.

  * The view merely has to say what commands it needs and they are available
to it.  In a more realistic application you'd want to do name-spacing of
some sort...

  * The super nifty part is that commands don't have to extend or implement
anything as long as they are annotated with @Command and @Invoker, using the
same kind of adapter-pattern magic that SpringMVC does when you use
@Controller and @RequestMapping.  Methods that are marked as @Invoker get
the same kind of "well known types" support that @RequestMapping methods do,
so if you want the View, put it in the signature and it will automatically
be handed to you.  (Note as well that it's not just some generic View --
static/strong typing applies so I can ask for specifically SampleView in the
signature.) If you don't care, don't have it in the signature.  Right now
only Views are supported, but there's nothing stopping us from adding other
"well known types" like ApplicationWindow, JFrame, JDialog, SecurityContext,
etc.  (A great place to see the "magic" happen for the commands and how it
works is in CommandAnnotationAdapterTests.)


Hopefully that helps show what some of the possibilities are.  Please let me
know if you have any questions/comments.

-Jim Moore

Re: [Springframework-rcp-dev] Spring RCP/Desktop Lead

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

Congrats Peter :)

With kind regards,
Geoffrey De Smet


Jim Moore schreef:
> Congrats, Peter!
> 
> 
> On Thu, Jul 10, 2008 at 10:03 AM, Larry Streepy <lst...@au... 
> <mailto:lst...@au...>> wrote:
> 
>     I hold Peter in extremely high regard and I've been very impressed with
>     his past contributions to the project.  I think he'd be a great project
>     leader.
> 
>     Thanks,
>     Larry.
> 
>     Jan Hoskens wrote:
>      > Hi all,
>      >
>      > I've been on the project for a while now and it's nice to see
>     that a lot
>      > of people have shown interest in the 1.0 release and the current
>     Spring
>      > Desktop discussion. Because I can't spend a lot of time on the
>     project
>      > now and because I think a change in leadership would benefit the
>     overal
>      > project, I would like to pass the Lead role to Peter. I won't
>     disappear
>      > from the scene, but the current developments around Spring
>     Desktop need
>      > someone to guide them actively and respond quickly. Because of
>     his past
>      > experience with the project and his many contributions, I think
>     Peter is
>      > the right candidate to do this.
>      >
>      > I've already contacted Peter and he acknowledge that he will take up
>      > this role if it is granted upon him. Lieven, who has been actively
>      > pushing the Spring Desktop discussion, also backs my thoughts and
>     choice
>      > and will continue his effort towards the project.
>      >
>      > I'm hoping that this will allow taking the necessary steps to a first
>      > version of Spring Desktop more easily. If no one has any objection, I
>      > would like to grant him this role at the beginning of next week.
>      >
>      > For now, I will focus on the maintenance release and when time allows
>      > it, I'll put more effort in the Spring Desktop development.
>      >
>      > Kind Regards,
>      > Jan
>      >
>      >
>      >  **** DISCLAIMER ****
>      >  http://www.schaubroeck.be/maildisclaimer.htm
>      >
>      >
>     -------------------------------------------------------------------------
>      > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>      > Studies have shown that voting for your favorite open source project,
>      > along with a healthy diet, reduces your potential for chronic
>     lameness
>      > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>      > _______________________________________________
>      > Springframework-rcp-dev mailing list
>      > Spr...@li...
>     <mailto:Spr...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>      >
>      >
>      >
> 
> 
> 
>     -------------------------------------------------------------------------
>     Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>     Studies have shown that voting for your favorite open source project,
>     along with a healthy diet, reduces your potential for chronic lameness
>     and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>     _______________________________________________
>     Springframework-rcp-dev mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] First commit

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

Jim,

great that you're looking into that area! I'll check it out first thing next
week.

regards,

Peter

On Fri, Jul 11, 2008 at 1:18 PM, Jim Moore <moo...@gm...> wrote:

> "However, I still believe that you'll be doing a lot of XML bean definition
> (i.e. if you want two beans with different names of the same class, you
> can't
> do that with component scanning I think...)"
>
> You can give your classes any a single name you want from an
> @Component-related annotation, but not multiple.  But there's only two
> reasons you'd want to have multiple names:
>
> 1) You need multiple instances with the same configuration, in which case
> what you really need is a different scope (such as "prototype") and there's
> no need to have multiple names since the scoping differentiates the multiple
> instances.
>
> 2) You need multiple instances with different configurations, in which case
> there's no choice but to externalize the configuration anyway.  This latter
> case is almost always for "infrastructure" kinds of objects (datasources and
> the like) as opposed to the higher-level business objects that make up the
> majority of what developers write (eg, views, commands, etc).
>
> I'm currently in the process of prototyping some code for doing essentially
> what we've been talking about using ADI (Annotation Driven Injection).  If
> you want to take a look, it's in the "adi-based-views" branch.  The test
> cases (esp. DefaultApplicationWindowTests and
> DesktopAnnotationScopeMetadataResolverTests) show how it works.  (Sorry
> there's not much Javadoc right now; I'm prototyping. Hopefully the tests
> make the pieces clear, if not how everything fits together.)  I'm going to
> put together a sample app to show it in a more "complete" way.  But first I
> want to implement @Command to provide the same kind of cool sweetness of
> on-demand POJOness that @Controller gives web developers...
>
> -Jim Moore
>
>
>
> On Wed, Jul 9, 2008 at 5:20 AM, Lieven Doclo <lie...@ji...>
> wrote:
>
>> Peter,
>>
>> I've solved the problem by not using the custom ApplicationContext, but
>> just
>> the standard Spring one. I've committed the code if you want to take a
>> look.
>>
>> However, I still believe that you'll be doing a lot of XML bean definition
>> (i.e. if you want two beans with different names of the same class, you
>> can't
>> do that with component scanning I think...) and you still need to provide
>> sensible defaults (which can be hard for the beginning user to find out
>> when
>> using classpath scanning, i.e. in what package are the defaults...).
>>
>> wkg,
>>
>> Lieven
>>
>> > Hello Peter,
>> >
>> > I've just checked the code and when you're using autowiring and
>> > component scanning, a problem occurs: The ApplicationContext
>> > implementation is responsible for creating an Application, whereas I
>> > would let the container do this (annotate your Application and let the
>> > component scan handle the instantiation). However, since the
>> > ApplicationContext constructs the Spring container, one cannot inject
>> > the scanned Application into the ApplicationContext.
>> >
>> > Hence the services are injected correctly (with my annotated
>> > Application), but the ApplicationContext holds his own created
>> > Application...
>> >
>> > Can't see a solution atm...
>> >
>> > Greetz,
>> >
>> > Lieven
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>

Re: [Springframework-rcp-dev] new mailing list

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

Is it accessable through gmane.org?

Personnally I fear we might lose some contributors by switching mailing 
lists.
The maven dev list didn't change from maven 1 to maven 2, so I see no 
reason to change it, moving from spring-richclient to spring-desktop.
On the other hand, if the new mailing list is hooked into the same gmane 
  id (you can move mailing lists on gmane.org), I don't care :)

With kind regards,
Geoffrey De Smet


Peter De Bruycker schreef:
> All,
> 
> the discussion group has been created: 
> http://groups.google.com/group/spring-desktop
> 
> I'll update the pom to reflect this,
> 
> Jim: I also added your info to the pom.xml, if you can verify if 
> everything is ok?
> 
> 
> regards,
> 
> Peter
> 
> On Thu, Jul 10, 2008 at 12:46 PM, Jim Moore <moo...@gm... 
> <mailto:moo...@gm...>> wrote:
> 
>     Sounds good to me.
> 
> 
>     On Thu, Jul 10, 2008 at 4:09 AM, Lieven Doclo
>     <lie...@ji... <mailto:lie...@ji...>> wrote:
> 
>         Hello Peter,
> 
>         Fine by me, perhaps we can focus that list on Desktop, whereas
>         this list
>         will remain for RCP issues. WDYT?
> 
>         Wkg,
> 
>         Lieven
> 
>          >
>         ----------------------------------------------------------------------
>          > ---
>          > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>          > Studies have shown that voting for your favorite open source
>         project,
>          > along with a healthy diet, reduces your potential for chronic
>         lameness
>          > and boredom. Vote Now at
>         http://www.sourceforge.net/community/cca08
>          > _______________________________________________
>          > Springframework-rcp-dev mailing list
>          > Spr...@li...
>         <mailto:Spr...@li...>
>          >
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
> 
>         -------------------------------------------------------------------------
>         Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>         Studies have shown that voting for your favorite open source
>         project,
>         along with a healthy diet, reduces your potential for chronic
>         lameness
>         and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>         _______________________________________________
>         Springframework-rcp-dev mailing list
>         Spr...@li...
>         <mailto:Spr...@li...>
>         https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
>     -------------------------------------------------------------------------
>     Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>     Studies have shown that voting for your favorite open source project,
>     along with a healthy diet, reduces your potential for chronic lameness
>     and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>     _______________________________________________
>     Springframework-rcp-dev mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] First commit

[Jim M. <moo...@gm...>]

"However, I still believe that you'll be doing a lot of XML bean definition
(i.e. if you want two beans with different names of the same class, you
can't
do that with component scanning I think...)"

You can give your classes any a single name you want from an
@Component-related annotation, but not multiple.  But there's only two
reasons you'd want to have multiple names:

1) You need multiple instances with the same configuration, in which case
what you really need is a different scope (such as "prototype") and there's
no need to have multiple names since the scoping differentiates the multiple
instances.

2) You need multiple instances with different configurations, in which case
there's no choice but to externalize the configuration anyway.  This latter
case is almost always for "infrastructure" kinds of objects (datasources and
the like) as opposed to the higher-level business objects that make up the
majority of what developers write (eg, views, commands, etc).

I'm currently in the process of prototyping some code for doing essentially
what we've been talking about using ADI (Annotation Driven Injection).  If
you want to take a look, it's in the "adi-based-views" branch.  The test
cases (esp. DefaultApplicationWindowTests and
DesktopAnnotationScopeMetadataResolverTests) show how it works.  (Sorry
there's not much Javadoc right now; I'm prototyping. Hopefully the tests
make the pieces clear, if not how everything fits together.)  I'm going to
put together a sample app to show it in a more "complete" way.  But first I
want to implement @Command to provide the same kind of cool sweetness of
on-demand POJOness that @Controller gives web developers...

-Jim Moore


On Wed, Jul 9, 2008 at 5:20 AM, Lieven Doclo <lie...@ji...> wrote:

> Peter,
>
> I've solved the problem by not using the custom ApplicationContext, but
> just
> the standard Spring one. I've committed the code if you want to take a
> look.
>
> However, I still believe that you'll be doing a lot of XML bean definition
> (i.e. if you want two beans with different names of the same class, you
> can't
> do that with component scanning I think...) and you still need to provide
> sensible defaults (which can be hard for the beginning user to find out
> when
> using classpath scanning, i.e. in what package are the defaults...).
>
> wkg,
>
> Lieven
>
> > Hello Peter,
> >
> > I've just checked the code and when you're using autowiring and
> > component scanning, a problem occurs: The ApplicationContext
> > implementation is responsible for creating an Application, whereas I
> > would let the container do this (annotate your Application and let the
> > component scan handle the instantiation). However, since the
> > ApplicationContext constructs the Spring container, one cannot inject
> > the scanned Application into the ApplicationContext.
> >
> > Hence the services are injected correctly (with my annotated
> > Application), but the ApplicationContext holds his own created
> > Application...
> >
> > Can't see a solution atm...
> >
> > Greetz,
> >
> > Lieven
>

Re: [Springframework-rcp-dev] spring rcp needed features

[Peter K. <pe...@ya...>]

Hi Trey,

please take a look at the 'new integrated' open source docking 
frameworks swingdocking and mydoggy that should satisfy 1. and 6.:
http://karussell.files.wordpress.com/2008/06/mydoggy-layout-springrc.jpg
http://karussell.files.wordpress.com/2008/07/springrc-swing-docking.jpg
http://karussell.files.wordpress.com/2008/07/springrc-swing-docking-2.jpg

What is so difficult with 2.?
You could simply create your own layout via NetBeans Matisse
or use the BorderLayout ...

> 3. A 'Perspectives' concept.
This would be great. Although it would be easier if we could persist
views before implementing this (e.g. via 1.)

> 4. A Job/Task scheduler for background threads.
Thats true. But it is not soo easy as it seems to be. I tried to code
and thats a lot of work to do.

Regards,
Peter K.

[Springframework-rcp-dev] spring rcp needed features

[Trey M. <som...@gm...>]

I've been using Spring RCP for at least a couple of years now... here are my
two cents as to what is needed feature-wise:

1. You've got to provide a decent set of canned page layouts for the common
cases. For example, one common scenario would be to have a tree control or
list on the left and a tabbed pane on the right, or some variation of that.
The average user is never going to bother to learn to write a custom page
factory for their layout needs, and it is VERY common to want more than one
View on the screen at the same time (think nicely docked views ala Eclipse,
and not disorganized frames in a virtual desktop). I've tried all of the
open source docking frameworks and they all suck, so I've given up hope on a
non-commercial docking solution. An open source docking framework for Views
is not adequate...I would be ashamed to roll out an app with VLDocking. We
need some canned fixed layouts to choose from.

2. Jide-Spring RCP cures #1 via Jide Docking, but it is a commercial
solution. We need a poor man's version without docking that just places 2-3
views in commonly needed ways. For example, provide a canned page layout
that creates a vertical split with one view on the left, and one on the
right.

3. A 'Perspectives' concept. Jonny Wray has done some work in this area as
part of his Jide-Spring RCP, but this should be part of the core Spring RCP.
Please take a look at his work.

4. A Job/Task scheduler for background threads, that allows user to see a
list of background tasks are in progress. Similar to the one Eclipse has....
you can open a dialog that shows the progress of MORE THAN ONE background
thread in a list, and individual tasks can be stopped. It seems like I saw
this in the new JSR: Swing App Framework...perhaps that code could be
integrated...if it exists.

5. A plugin/update mechanism!!!! This would be great. It doesn't even have
to allow for on-the-fly updates. A restart of the app would be okay. Start
small...even if it is something as dumb as downloading a JAR and
programmatically modifying the application context with additional beans.

6. Need the concept of an EDITOR AREA, where editors exist...again, similar
to Eclipse.
Here I'm talking about the tabbed pane residing in the center of the screen.
Jonny Wray has this in his Jide Spring RCP framework and it works great.
However, we need a non-commercial alternative, and it should be part of the
core framework.

7. This is far less important and totally out of scope...but it doesn't hurt
to ask... Provide integration with the Jide Dashboard, so that Views can be
used as Dashboard widgets. I've worked with the Jide Dashboard and their
architecture is already simiilar to the View concept. You can just implement
an additional interface and you're ready to go.


The Spring RCP project is excellent, and it can definitely overtake
Eclipse/Netbeans as the platform of choice if any serious effort is put into
it. I hope this helps.


-Trey

Re: [Springframework-rcp-dev] Spring RCP/Desktop Lead

[Jim M. <moo...@gm...>]

Congrats, Peter!


On Thu, Jul 10, 2008 at 10:03 AM, Larry Streepy <lst...@au...>
wrote:

> I hold Peter in extremely high regard and I've been very impressed with
> his past contributions to the project.  I think he'd be a great project
> leader.
>
> Thanks,
> Larry.
>
> Jan Hoskens wrote:
> > Hi all,
> >
> > I've been on the project for a while now and it's nice to see that a lot
> > of people have shown interest in the 1.0 release and the current Spring
> > Desktop discussion. Because I can't spend a lot of time on the project
> > now and because I think a change in leadership would benefit the overal
> > project, I would like to pass the Lead role to Peter. I won't disappear
> > from the scene, but the current developments around Spring Desktop need
> > someone to guide them actively and respond quickly. Because of his past
> > experience with the project and his many contributions, I think Peter is
> > the right candidate to do this.
> >
> > I've already contacted Peter and he acknowledge that he will take up
> > this role if it is granted upon him. Lieven, who has been actively
> > pushing the Spring Desktop discussion, also backs my thoughts and choice
> > and will continue his effort towards the project.
> >
> > I'm hoping that this will allow taking the necessary steps to a first
> > version of Spring Desktop more easily. If no one has any objection, I
> > would like to grant him this role at the beginning of next week.
> >
> > For now, I will focus on the maintenance release and when time allows
> > it, I'll put more effort in the Spring Desktop development.
> >
> > Kind Regards,
> > Jan
> >
> >
> >  **** DISCLAIMER ****
> >  http://www.schaubroeck.be/maildisclaimer.htm
> >
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> >
> >
> >
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] Spring RCP/Desktop Lead

[Larry S. <lst...@au...>]

I hold Peter in extremely high regard and I've been very impressed with 
his past contributions to the project.  I think he'd be a great project 
leader.

Thanks,
Larry.

Jan Hoskens wrote:
> Hi all,
>
> I've been on the project for a while now and it's nice to see that a lot
> of people have shown interest in the 1.0 release and the current Spring
> Desktop discussion. Because I can't spend a lot of time on the project
> now and because I think a change in leadership would benefit the overal
> project, I would like to pass the Lead role to Peter. I won't disappear
> from the scene, but the current developments around Spring Desktop need
> someone to guide them actively and respond quickly. Because of his past
> experience with the project and his many contributions, I think Peter is
> the right candidate to do this.
>
> I've already contacted Peter and he acknowledge that he will take up
> this role if it is granted upon him. Lieven, who has been actively
> pushing the Spring Desktop discussion, also backs my thoughts and choice
> and will continue his effort towards the project.
>
> I'm hoping that this will allow taking the necessary steps to a first
> version of Spring Desktop more easily. If no one has any objection, I
> would like to grant him this role at the beginning of next week.
>
> For now, I will focus on the maintenance release and when time allows
> it, I'll put more effort in the Spring Desktop development.
>
> Kind Regards,
> Jan
>
>
>  **** DISCLAIMER ****
>  http://www.schaubroeck.be/maildisclaimer.htm
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>   

[Springframework-rcp-dev] Spring RCP/Desktop Lead

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

Hi all,

I've been on the project for a while now and it's nice to see that a lot
of people have shown interest in the 1.0 release and the current Spring
Desktop discussion. Because I can't spend a lot of time on the project
now and because I think a change in leadership would benefit the overal
project, I would like to pass the Lead role to Peter. I won't disappear
from the scene, but the current developments around Spring Desktop need
someone to guide them actively and respond quickly. Because of his past
experience with the project and his many contributions, I think Peter is
the right candidate to do this.

I've already contacted Peter and he acknowledge that he will take up
this role if it is granted upon him. Lieven, who has been actively
pushing the Spring Desktop discussion, also backs my thoughts and choice
and will continue his effort towards the project.

I'm hoping that this will allow taking the necessary steps to a first
version of Spring Desktop more easily. If no one has any objection, I
would like to grant him this role at the beginning of next week.

For now, I will focus on the maintenance release and when time allows
it, I'll put more effort in the Spring Desktop development.

Kind Regards,
Jan


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

Re: [Springframework-rcp-dev] new mailing list

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

All,

the discussion group has been created:
http://groups.google.com/group/spring-desktop

I'll update the pom to reflect this,

Jim: I also added your info to the pom.xml, if you can verify if everything
is ok?


regards,

Peter

On Thu, Jul 10, 2008 at 12:46 PM, Jim Moore <moo...@gm...> wrote:

> Sounds good to me.
>
>
> On Thu, Jul 10, 2008 at 4:09 AM, Lieven Doclo <lie...@ji...>
> wrote:
>
>> Hello Peter,
>>
>> Fine by me, perhaps we can focus that list on Desktop, whereas this list
>> will remain for RCP issues. WDYT?
>>
>> Wkg,
>>
>> Lieven
>>
>> > ----------------------------------------------------------------------
>> > ---
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> > _______________________________________________
>> > Springframework-rcp-dev mailing list
>> > Spr...@li...
>> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>

Re: [Springframework-rcp-dev] new mailing list

[Jim M. <moo...@gm...>]

Sounds good to me.

On Thu, Jul 10, 2008 at 4:09 AM, Lieven Doclo <lie...@ji...>
wrote:

> Hello Peter,
>
> Fine by me, perhaps we can focus that list on Desktop, whereas this list
> will remain for RCP issues. WDYT?
>
> Wkg,
>
> Lieven
>
> > ----------------------------------------------------------------------
> > ---
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] new mailing list

[Lieven D. <lie...@ji...>]

Hello Peter,

Fine by me, perhaps we can focus that list on Desktop, whereas this list 
will remain for RCP issues. WDYT?

Wkg,

Lieven

> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

[Springframework-rcp-dev] new mailing list

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

All,

Is it ok if I create a discussion group at google groups? I saw that Spring
DM also has one, and it allows more features than a mailing list at
sourceforge (you can upload files, ...)

regards,

Peter

Re: [Springframework-rcp-dev] First commit

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

thanks :)

With kind regards,
Geoffrey De Smet


Peter De Bruycker schreef:
> i added the svn:ignore list, the eclipse specific files have been removed,
> 
> regards,
> 
> Peter
> 
> 
> 
> On Tue, Jul 8, 2008 at 9:53 PM, Geoffrey De Smet 
> <ge0...@gm... <mailto:ge0...@gm...>> wrote:
> 
>     Please copy paste the svn:ignore list that are currently used for each
>     module directory.
>     It ignores the eclipse, intellij and netbeans files, as well as the
>     target dir and local dir.
>     In my experience it's a bad idea to check in the ide (especially
>     eclipse) files, when you can just generate them with maven anyway.
>     Could you also remove the eclipse files from subversion?
> 
>     wkr,
>     Geoffrey De Smet
> 
>     Peter De Bruycker schreef:
>      > I just did to the first commit for Spring Desktop!
>      >
>      > It's nothing shocking, just a dedicated DesktopApplicationContext
>      > interface + implementation + tests.
>      >
>      > the pom.xml doesn't contain all developers yet (just me and Jan have
>      > been added, the list will be updated when needed)
>      >
>      > for the moment, there's only one module (core).
>      >
>      > regards,
>      >
>      > Peter
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     -------------------------------------------------------------------------
>      > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>      > Studies have shown that voting for your favorite open source project,
>      > along with a healthy diet, reduces your potential for chronic
>     lameness
>      > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Springframework-rcp-dev mailing list
>      > Spr...@li...
>     <mailto:Spr...@li...>
>      > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
>     -------------------------------------------------------------------------
>     Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>     Studies have shown that voting for your favorite open source project,
>     along with a healthy diet, reduces your potential for chronic lameness
>     and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>     _______________________________________________
>     Springframework-rcp-dev mailing list
>     Spr...@li...
>     <mailto:Spr...@li...>
>     https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

Re: [Springframework-rcp-dev] First commit

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

Lieven,

I checked some changes in, the problem you mentioned is fixed. I'm going to
delete the code you checked in, ok?

regards,

Peter

On Wed, Jul 9, 2008 at 12:12 PM, Peter De Bruycker <
pet...@gm...> wrote:

>
>
> On Wed, Jul 9, 2008 at 11:20 AM, Lieven Doclo <lie...@ji...>
> wrote:
>
>> Peter,
>>
>> I've solved the problem by not using the custom ApplicationContext, but
>> just
>> the standard Spring one. I've committed the code if you want to take a
>> look.
>
>
> thanks, I'll take a look at it
>
>>
>>
>> However, I still believe that you'll be doing a lot of XML bean definition
>> (i.e. if you want two beans with different names of the same class, you
>> can't
>> do that with component scanning I think...) and you still need to provide
>> sensible defaults (which can be hard for the beginning user to find out
>> when
>> using classpath scanning, i.e. in what package are the defaults...).
>>
>> wkg,
>>
>> Lieven
>>
>> > Hello Peter,
>> >
>> > I've just checked the code and when you're using autowiring and
>> > component scanning, a problem occurs: The ApplicationContext
>> > implementation is responsible for creating an Application, whereas I
>> > would let the container do this (annotate your Application and let the
>> > component scan handle the instantiation). However, since the
>> > ApplicationContext constructs the Spring container, one cannot inject
>> > the scanned Application into the ApplicationContext.
>> >
>> > Hence the services are injected correctly (with my annotated
>> > Application), but the ApplicationContext holds his own created
>> > Application...
>> >
>> > Can't see a solution atm...
>> >
>> > Greetz,
>> >
>> > Lieven
>> >
>> >> ---------------------------------------------------------------------
>> >> -
>> >> ---
>> >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> >> Studies have shown that voting for your favorite open source project,
>> >> along with a healthy diet, reduces your potential for chronic
>> >> lameness
>> >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> >> _______________________________________________
>> >> Springframework-rcp-dev mailing list
>> >> Spr...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>> > ----------------------------------------------------------------------
>> > ---
>> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> > Studies have shown that voting for your favorite open source project,
>> > along with a healthy diet, reduces your potential for chronic lameness
>> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>>
>
>

Re: [Springframework-rcp-dev] First commit

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

On Wed, Jul 9, 2008 at 11:20 AM, Lieven Doclo <lie...@ji...>
wrote:

> Peter,
>
> I've solved the problem by not using the custom ApplicationContext, but
> just
> the standard Spring one. I've committed the code if you want to take a
> look.


thanks, I'll take a look at it

>
>
> However, I still believe that you'll be doing a lot of XML bean definition
> (i.e. if you want two beans with different names of the same class, you
> can't
> do that with component scanning I think...) and you still need to provide
> sensible defaults (which can be hard for the beginning user to find out
> when
> using classpath scanning, i.e. in what package are the defaults...).
>
> wkg,
>
> Lieven
>
> > Hello Peter,
> >
> > I've just checked the code and when you're using autowiring and
> > component scanning, a problem occurs: The ApplicationContext
> > implementation is responsible for creating an Application, whereas I
> > would let the container do this (annotate your Application and let the
> > component scan handle the instantiation). However, since the
> > ApplicationContext constructs the Spring container, one cannot inject
> > the scanned Application into the ApplicationContext.
> >
> > Hence the services are injected correctly (with my annotated
> > Application), but the ApplicationContext holds his own created
> > Application...
> >
> > Can't see a solution atm...
> >
> > Greetz,
> >
> > Lieven
> >
> >> ---------------------------------------------------------------------
> >> -
> >> ---
> >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> >> Studies have shown that voting for your favorite open source project,
> >> along with a healthy diet, reduces your potential for chronic
> >> lameness
> >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> >> _______________________________________________
> >> Springframework-rcp-dev mailing list
> >> Spr...@li...
> >> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> > ----------------------------------------------------------------------
> > ---
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>
>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

Re: [Springframework-rcp-dev] First commit

[Lieven D. <lie...@ji...>]

Peter,

I've solved the problem by not using the custom ApplicationContext, but just 
the standard Spring one. I've committed the code if you want to take a look.

However, I still believe that you'll be doing a lot of XML bean definition 
(i.e. if you want two beans with different names of the same class, you can't 
do that with component scanning I think...) and you still need to provide 
sensible defaults (which can be hard for the beginning user to find out when 
using classpath scanning, i.e. in what package are the defaults...).

wkg,

Lieven

> Hello Peter,
> 
> I've just checked the code and when you're using autowiring and
> component scanning, a problem occurs: The ApplicationContext
> implementation is responsible for creating an Application, whereas I
> would let the container do this (annotate your Application and let the
> component scan handle the instantiation). However, since the
> ApplicationContext constructs the Spring container, one cannot inject
> the scanned Application into the ApplicationContext.
> 
> Hence the services are injected correctly (with my annotated
> Application), but the ApplicationContext holds his own created
> Application...
> 
> Can't see a solution atm...
> 
> Greetz,
> 
> Lieven
> 
>> ---------------------------------------------------------------------
>> -
>> ---
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic
>> lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Springframework-rcp-dev mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
> ----------------------------------------------------------------------
> ---
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08

Re: [Springframework-rcp-dev] Multiple Document Handling

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

On Tue, 2008-07-08 at 22:55 +0200, Peter Karich wrote:
> Hi,
> 
> on Javalobby someone asked me the following interesting question:
> 
> Does Spring RCP has support for a multiple-document interface? I mean
> can I have more than one instance of my application and it's classes
> running in the same JVM. Just wondering how it resolves which action
> 'belongs' to which application instance in this kind of scenario.
> 
> Do you have an answer?

I'll give it a shot:

As a first, I have to inform you that the application that is started
with Spring RCP is a Singleton. So one application per VM. This includes
it's ApplicationServices which are retrieved by the
ApplicationServiceLocator Singleton.

Secondly: there are solutions for MDI in the form of docking frameworks.
Look into the docking module to find out more. This might be what you're
referring to? 

As a third: there can be multiple windows per application. As a
consequence of this, the current commands are defined in a separate
context file. This file is re-read when creating a new window in order
to have the correct parent window injected if the command needs to be
window-aware. This allows to have multiple windows, sharing the same
resources, running on one vm and opening different views/dialgs etc...

Thus looking upon this, yes you can do MDI, but no you cannot have
multiple instances running on the same VM. In most cases, the latter
isn't a problem.

> 
> And is there a Helper class that provides me the 3 common folders:
> sth. like
> APPLICATION_SETTINGS e.g. /usr/share/application
> USER_SETTINGS  e.g. /home/user/.application
> WORKING e.g. current working dir
> 
> I do not know for sure, but in NetBeans you could have 3 xml settings 
> files in those folders and then it will merge them into the "real-used" 
> settings file. [1]
> Isn't this approach interesting?

As far as I know, there's no such helper class. It could be provided
though. You can always provide an issue+patch.


Kind Regards,
Jan


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

Re: [Springframework-rcp-dev] [Desktop]Evolution or ?

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

I would consider the Spring Desktop as a separate branch. An application
that is already deployed with Spring RCP should (in my opinion) not jump
onto Spring Desktop yet. At our company, a number of products are using
Spring RCP, these will continue to use RCP until Desktop has become
stable and at that moment we will need a clear updating path from one to
the other. I expect such a path will be documented along the way.

On the other hand, if you're starting to look for a gui framework and
want to lend a hand, this is the right opportunity to jump in.

The sparse time I've got right now will be dedicated to the maintenance
release of Spring RCP. I'll try to fix a number of issues and will scan
the jira to see which one's are appropriate to include in the next
release.

Kind Regards,
Jan

On Tue, 2008-07-08 at 23:35 +0100, Benoit Xhenseval wrote:
> Hi
> 
>  
> 
> I can see a lot of activity wrt Spring Desktop. This is great but…
> what is the plan? Should an existing Spring Rich Client application
> follow the development of Desktop (ie checkout regularly) or should
> Desktop be considered as another branch (assuming the previous one was
> tagged?) which is not backward compatible?
> 
>  
> 
> In a few words, what is the migration strategy for existing app?
> 
>  
> 
> I’d like to know before doing an update and then ending up is a %*£”$^
> %!!…
> 
>  
> 
> Many thanks
> 
>  
> 
> Benoit
> 
>  
> 
> PS: Could you consider the few patches we provided to make Spring RC
> more flexible before making a lot of changes?  They are truly minor
> for the code base but big for us! Thanks!
> 
>  
> 
> ------------------------------
> 
> IMPORTANT NOTICE 
> 
> This communication contains information that is considered
> confidential and may also be privileged . It is for the exclusive use
> of the intended recipient(s). If you are not the intended recipient(s)
> please note that any form of distribution, copying or use of this
> communication or the information in it is strictly prohibited and may
> be unlawful. If you have received this communication in error please
> return it to the sender and delete the original.
> 
>  
> 
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________ 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] First commit

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

i added the svn:ignore list, the eclipse specific files have been removed,

regards,

Peter



On Tue, Jul 8, 2008 at 9:53 PM, Geoffrey De Smet <ge0...@gm...>
wrote:

> Please copy paste the svn:ignore list that are currently used for each
> module directory.
> It ignores the eclipse, intellij and netbeans files, as well as the
> target dir and local dir.
> In my experience it's a bad idea to check in the ide (especially
> eclipse) files, when you can just generate them with maven anyway.
> Could you also remove the eclipse files from subversion?
>
> wkr,
> Geoffrey De Smet
>
> Peter De Bruycker schreef:
> > I just did to the first commit for Spring Desktop!
> >
> > It's nothing shocking, just a dedicated DesktopApplicationContext
> > interface + implementation + tests.
> >
> > the pom.xml doesn't contain all developers yet (just me and Jan have
> > been added, the list will be updated when needed)
> >
> > for the moment, there's only one module (core).
> >
> > regards,
> >
> > Peter
> >
> >
> > ------------------------------------------------------------------------
> >
> > -------------------------------------------------------------------------
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source project,
> > along with a healthy diet, reduces your potential for chronic lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Springframework-rcp-dev mailing list
> > Spr...@li...
> > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
>

[Springframework-rcp-dev] [Desktop]Evolution or ?

[Benoit X. <bx...@ob...>]

Hi

 

I can see a lot of activity wrt Spring Desktop. This is great but… what is
the plan? Should an existing Spring Rich Client application follow the
development of Desktop (ie checkout regularly) or should Desktop be
considered as another branch (assuming the previous one was tagged?) which
is not backward compatible?

 

In a few words, what is the migration strategy for existing app?

 

I’d like to know before doing an update and then ending up is a %*£”$^%!!…

 

Many thanks

 

Benoit

 

PS: Could you consider the few patches we provided to make Spring RC more
flexible before making a lot of changes?  They are truly minor for the code
base but big for us! Thanks!

 

------------------------------

IMPORTANT NOTICE 

This communication contains information that is considered confidential and
may also be privileged . It is for the exclusive use of the intended
recipient(s). If you are not the intended recipient(s) please note that any
form of distribution, copying or use of this communication or the
information in it is strictly prohibited and may be unlawful. If you have
received this communication in error please return it to the sender and
delete the original.

 

Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version

[Kevin D. <ke...@tr...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>I think that this approach exactly inverts the ServiceLocator approach.</DIV>
<DIV>&nbsp;</DIV>
<DIV>In the current RulesValidator, there is an explicit call to <FONT size=2>(RulesSource) ApplicationServicesLocator.services().getService(RulesSource.</FONT><B><FONT color=#7f0055 size=2>class</B></FONT><FONT size=2>);</FONT><BR></DIV>
<DIV>this call is the root of the dependency issue under discussion.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>By inverting the problem, we can remove references to the static ApplicationServicesLocator.services() method entirely.&nbsp; Instead, the configuration of the object is factored out, and is triggered on registration of the object with the service registry.&nbsp; This last point (configuration occurs on registration)&nbsp;is actually pretty important because it drives the direction that dependencies are created.&nbsp; Instead of registring object foo with service A, we allow A to be notified when objects of type Foo become available.&nbsp; Service A (or preferably a handler such as Spring DM) then registers the object with the service.&nbsp; This enforces decoupling between objects and the services that operate on them.&nbsp; (Ironically, the 'ServiceRegistry' isn't really a registry of services at all - it's a registry of objects that services may want to operate on.&nbsp; In most cases, the service itself will never be registered with the registry).&nbsp; Perhaps some 
 renaming is called for...</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Anyway, the result of this in the current refactored example is that we are not injecting the ApplicationServicesLocator object into the RulesValidator.&nbsp; We are injecting the dependency that RulesValidator actually needs (RulesSource).&nbsp; At a functional level, RulesValidator should not need to know about ApplicationServicesLocator to properly function.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Objects themselves are very rarely, if ever, actually aware of the service registry.&nbsp; The framework itself does most (if not all)&nbsp;of that interaction on the object's behalf.&nbsp; The difference is subtle, but it completely unravels the dependency issue and makes modular development possible (as well as dynamic loading/unloading and all of the interesting stuff that comes with this kind of decoupling).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K</DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff>&lt;lst...@au...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Tue, 08 Jul 2008 16:23:52 -0500</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;&nbsp;&nbsp;&nbsp;Desktop version</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV><TT>In this approach haven't we just replaced the ServiceLocator with a ServiceRegistry - with all the same problems?&nbsp; Meaning that every object needs to "find" the ServiceRegistry, either by having it be a static singleton, or having declarative XML to DI it.&nbsp; This leads us right back to the earlier problems we had with the ServiceLocator.&nbsp; Or, have I misunderstood something in your proposal Kevin?<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT> 
<BLOCKQUOTE cite=mid:REY4UlhWUyksKyY9Ji0+NjY4NTYwMjUw@satchel type="cite">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Here's a simple example:</DIV>
<DIV>&nbsp;</DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource.&nbsp; So we provide a setter for&nbsp;rulesSource (and probably ditch the variable pass in the constructor).&nbsp; When a RulesValidator is created, it is registered with a ServiceRegistry.&nbsp; The ServiceRegistry sends notifications that a new RulesValidator has been registered.</DIV>
<DIV>&nbsp;</DIV>
<DIV>We also have a Configurator object that has been created that listends to the ServiceRegistry.&nbsp; When new objects are registered, it injects resources into them.&nbsp; So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource.&nbsp; For the generic case, a default RulesSource will get injected.&nbsp; If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Advantages of this approach:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>2.&nbsp; The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)</DIV>
<DIV>3.&nbsp; The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever).&nbsp; There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.</DIV>
<DIV>&nbsp;</DIV>
<DIV>If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV>&nbsp;</DIV>
<DIV>1.&nbsp; The service registry becomes more complicated (it has to support registration, and possibly deregistration,&nbsp;event notifications)</DIV>
<DIV>2.&nbsp; The service registry still needs to be made available (although&nbsp;I suspect that in most cases this can be factored out into Spring DI).&nbsp; If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup.&nbsp; If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.</DIV>
<DIV>&nbsp;</DIV>
<DIV>- K<BR></DIV>
<DIV>&nbsp;</DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV>&nbsp;&nbsp;</DIV>
<DIV><B>From:</B>&nbsp;Larry Streepy <A href="mailto:lst...@au..." moz-do-not-send="true"><FONT color=#0000ff>&lt;lst...@au...&gt;</FONT></A></DIV>
<DIV><B>To:</B>&nbsp;<A href="mailto:spr...@li..." moz-do-not-send="true"><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B>&nbsp;</DIV>
<DIV><B>Date:</B>&nbsp;Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the&nbsp;&nbsp;&nbsp;&nbsp;Desktop version</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV>Peter De Bruycker wrote: 
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core 
<LI>application: window, dialogs, page, view, action, ... 
<LI>binding: validation, binding, forms 
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use.&nbsp; Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense.&nbsp; Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
</BLOCKQUOTE><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>