Re: [Spring Desktop] ideas for the Desktop version

Heya, everyone.  Sorry for jumping into this discussion late.

I prefer Claudio's distinctions for breaking out the modules.  In any case, we need to make sure (like Spring) that there's never a circular dependency between packages so that things can easily be broken apart later if needed.

Spring 3.0 will also be dropping JDK1.4 support.  Going to Java 5 just makes sense -- especially for a desktop app.  (In fact it's arguable that we should go to Java 6 given all the desktop improvements they made.)

There's a reason no Spring example shows injecting a Logger.  The nature of logging and the logging libraries means there's no real benefit to doing so.  Also, in general commons-logging is a bad thing (especially in multiple classloader environments), which is why slf4j exists, but you can write to the commons-logging API and use slf4j as the implementation.  That's what the Spring does on the SpringSource Application Platform (S2AP), for example.

I love the idea of new XML configuration.  A couple of comments on the examples:

<bean id="someBean" class="foobar">
    <property name="prefs">
        <desktop:prefs scope="user|system" path="path/to/preferences/node"/>
    </property>
</bean>

It's not clear from the example, but Spring already has support for the scoping capability (via aop:scoped-proxy) as described in section 3.4 of the reference manual.  I assume "user" scope would be defined based on a Spring Security SecurityContext and "system" would be a standard singleton?  Having the custom XML element would nicely hide those details from the user.

<desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView" mdi:closable="true" mdi:resizable="false">
    <property name="someService" ref="serviceId"/>
</desktop:view>

<desktop:view id="yetAnotherView" viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false" docking:draggable="true">
    <property name="someService" ref="serviceId"/>
</desktop:view>

In Spring 2.5 ADI style that might be done as

<context:component-scan package="com.myco"/>

@View
public class SomeView {
  @Autowired SomeView(SomeService someService) {..}
}

@View
@MdiConfiguration(closable=true, resizable=false)
public class OtherView {
  @Autowired OtherView(SomeService someService) {..}
}

@View
@DockingConfiguration(closable=false, draggable=false)
public class YetAnotherView {
  @Autowired YetAnotherView(SomeService someService) {..}
}


Modular plugin support is partly for plugins (a-la Eclipse or Netbeans), but mostly for making it easier to do good modularity.  Hot-swapping, discovery, etc are all just nice side-effects of having better modularity.  Fortunately, because of Spring Dynamic Modules this can always be added later, especially if we follow the SpringDM conventions. (eg, /META-INF/spring/application-context.xml)  S2AP can provide the underlying support for that if we want.  Otherwise we can keep OSGi use (but not OSGi compliance) out for now.  Having JSR-277 support (like WebStart and Netbeans) would be awesome so people don't have to download 50 copies of log4j and updates can happen faster/easier.

-Jim Moore
 Senior Consultant, SpringSource


-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev