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

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

How will we continue from now on? Who will create the projects? The way
things are looking, I'm able to spend more time on spring desktop.

On Wed, Jul 2, 2008 at 5:20 AM, Jim Moore <moo...@gm...> wrote:

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