springframework-rcp-dev

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

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

Finally,

I've gotten my newsreader to work (again, thanks to Jetbrains :))

So I'll repeat here what I've put on the forum.

1. Merge some modules 

- support + core + forms + binding + jdk5 = core
- retain modules jdk6, sandbox and resources

Perhaps we should also merge resources with the core, but only those resources 
directly needed in the core. The rest can be more something like 'skinning'.

I know this is quite controversial, but now we have the situation where no 
one knows where something should be put, so it ends up in support. Modules 
should also be selfcontained, no point in having a module that needs another 
module anyhow for it to work.

My suggestion:

Core = essential Desktop stuff needed to make a simple application (forms, 
basic binders and all underlying plumbing)
JDK6 = JDK6 specific stuff
Sandbox = playground for new stuff, should be followed-up on a regular basis 
though
Resources = extra resources (do we need to have this in Desktop?)
Components = extra components (Jan, perhaps we can put your components in 
here?)

2. Pull up the source level to 1.5

Java5 will give us a lot more leniency when dealing with some problems. For 
example, I'd like to introduce generics in the FormModel and ValueModel for 
starters. I think they're great candidates and I don't think it'll be a lot 
of work. Using enums in certain places may also increase readability.

3. Rename Binder to BindingFactory

Since we're not bound to the RCP codebase, we should finally do this... 

4. A lot more out-of-the-box bindings

Bindings are the mainstay of the application. Therefor I find it more than 
logical that we include more bindings in the standard Desktop. 

5. Pull useful stuff from the sandbox

Now that we have the opportunity to do so, we should evaluate what's present 
in the sandbox and promote it when useful.

6. Upgrade to Spring Security (Spring 2.5 in general)

Spring 2.5 gives us the possibility to do a lot more, so I think this makes 
sense

7. Try to refactor out the singletons like Application and ApplicationServices

We might be able to replace those with the Spring 2.5 @Component and @Autowired 
system...

8. Remove VLDocking

It has a GPL license, so it's not compatible with Desktop (unless someone 
wants to release Desktop under the GPL?)


Some stuff that has come up on the forums:

1. Modular plugin support (jwray)

OSGi-like support for plugins. Personally not my favorite, I don't know many 
enterprise applications that use a plugin model, but I might be wrong about 
this.

2. JIDE integration (jwray)

Great idea to include JIDE OSS into Desktop. It's a great collection of components 
and making binders for those components will raise the quality of the code. 
For commercial JIDE components, we can foresee a separate module, if needed.

3. Integrate mydoggy as a docking framework (peatar)

Looking into it, I've gotten the code from peatar, if I find the time I'll 
do a thorough test.

4. Replace commons-logging with slf4j (peatar)

Anyone that can make a clear pro-con analysis on this. I've only worked with 
commons-logging.

5. Logger injection (peatar)

PicoContainer has a LogInjector, do know though if this should be a Desktop 
feature... Sounds more like Spring-core... Perhaps this already exists in 
2.5, I don't know.


Feel free to comment, flame and add suggestions... 

Greetz,

Lieven

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

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

> 5. Logger injection (peatar)
> 
> PicoContainer has a LogInjector, do know though if this should be a
> Desktop feature... Sounds more like Spring-core... Perhaps this
> already exists in 2.5, I don't know.

Apparently, this can be solved using a @Logger annotation in combination 
with a beanpostprocessor... Again, might not be a Desktop feature, but handy 
nevertheless.

see: http://www.tzavellas.com/techblog/2007/03/31/implementing-seam-style-logger-injection-with-spring/

Greetz,

Lieven

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

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

some comments inline...


On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo <lie...@ji...>
wrote:

> Finally,
>
> I've gotten my newsreader to work (again, thanks to Jetbrains :))
>
> So I'll repeat here what I've put on the forum.
>
> 1. Merge some modules
>
> - support + core + forms + binding + jdk5 = core
> - retain modules jdk6, sandbox and resources
>
> Perhaps we should also merge resources with the core, but only those
> resources
> directly needed in the core. The rest can be more something like
> 'skinning'.
>
> I know this is quite controversial, but now we have the situation where no
> one knows where something should be put, so it ends up in support. Modules
> should also be selfcontained, no point in having a module that needs
> another
> module anyhow for it to work.
>
> My suggestion:
>
> Core = essential Desktop stuff needed to make a simple application (forms,
> basic binders and all underlying plumbing)
> JDK6 = JDK6 specific stuff
> Sandbox = playground for new stuff, should be followed-up on a regular
> basis
> though
> Resources = extra resources (do we need to have this in Desktop?)
> Components = extra components (Jan, perhaps we can put your components in
> here?)


>
> 2. Pull up the source level to 1.5
>
> Java5 will give us a lot more leniency when dealing with some problems. For
> example, I'd like to introduce generics in the FormModel and ValueModel for
> starters. I think they're great candidates and I don't think it'll be a lot
> of work. Using enums in certain places may also increase readability.
>
> 3. Rename Binder to BindingFactory
>
> Since we're not bound to the RCP codebase, we should finally do this...
>
> 4. A lot more out-of-the-box bindings
>
> Bindings are the mainstay of the application. Therefor I find it more than
> logical that we include more bindings in the standard Desktop.
>

integration with Beans Binding?


>
> 5. Pull useful stuff from the sandbox
>
> Now that we have the opportunity to do so, we should evaluate what's
> present
> in the sandbox and promote it when useful.
>
> 6. Upgrade to Spring Security (Spring 2.5 in general)
>
> Spring 2.5 gives us the possibility to do a lot more, so I think this makes
> sense


Also custom xml elements, this would allow for less xml


>
>
> 7. Try to refactor out the singletons like Application and
> ApplicationServices
>
> We might be able to replace those with the Spring 2.5 @Component and
> @Autowired
> system...
>
> 8. Remove VLDocking
>
> It has a GPL license, so it's not compatible with Desktop (unless someone
> wants to release Desktop under the GPL?)


Can a GPL licensed project contain Apache licensed jar files? If so, we can
create a separate project to handle the integration.


>
>
>
> Some stuff that has come up on the forums:
>
> 1. Modular plugin support (jwray)
>
> OSGi-like support for plugins. Personally not my favorite, I don't know
> many
> enterprise applications that use a plugin model, but I might be wrong about
> this.
>
> 2. JIDE integration (jwray)
>
> Great idea to include JIDE OSS into Desktop. It's a great collection of
> components
> and making binders for those components will raise the quality of the code.
> For commercial JIDE components, we can foresee a separate module, if
> needed.
>
> 3. Integrate mydoggy as a docking framework (peatar)
>
> Looking into it, I've gotten the code from peatar, if I find the time I'll
> do a thorough test.
>
> 4. Replace commons-logging with slf4j (peatar)
>
> Anyone that can make a clear pro-con analysis on this. I've only worked
> with
> commons-logging.


wouldn't do this, as commons-logging is the de-facto standard


>
>
> 5. Logger injection (peatar)
>
> PicoContainer has a LogInjector, do know though if this should be a Desktop
> feature... Sounds more like Spring-core... Perhaps this already exists in
> 2.5, I don't know.
>
>
> Feel free to comment, flame and add suggestions...
>
> Greetz,
>
> Lieven
>
>
>
>
> -------------------------------------------------------------------------
> 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
>

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

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

Hello Peter,

Thanks for the input. As for the Beans Binding, we could take a look at that 
indeed. Haven't work with the framework yet, but it looks nice. As for complexity, 
I'm not entirely sure whether it'll be an improvement, but we'll have to 
find that out, won't we?

As as for the commons-logging, I agree. But it was an idea on the forums, 
and slf4j can indeed do a bit more than commons-logging. But most of us (I 
think) work with commons-logging. Correct me if I'm wrong.

What custom elements do you have in mind? I see a number of candidates :).

As for the GPL/ASL issue, I think it's backwards, can a ASL project (Desktop) 
contain GPL jars (VLDocking) ? I don't think so, unless your project is also 
GPL. I'm no fan of the GPL license, so I still don't think we should provide 
it. We could put it in a separate module, but I'm afraid this'll cause confusion 
with the end-users: 'if I use Desktop with this module, I need to be GPL, 
otherwise I don't'... 

With your reply, I've got some more ideas:

9. Remove the closures in RCP (sorry Keith)

As Keith said to me on SpringOne: SIMPLIFY, SIMPLIFY!! Keith's closures were 
a great idea (bit over the top though), but I don't think anyone is using 
them. They're easily refactored out of the codebase thanks to some Java5 
improvemenrs and for the sake of readability, I think we're better of without 
the code. So I think we should drop that part of the code.

10. Implement custom namespace elements for Spring configuration

This can simplify the configuration greatly. We could also create Spring 
2.5 component stereotype annotations for easy configuration using <context:component-scan/>.

WDYT?

Greetz,

Lieven


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

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

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

On Tue, Jun 24, 2008 at 9:19 AM, Lieven Doclo <lie...@ji...>
wrote:

> Hello Peter,
>
> Thanks for the input. As for the Beans Binding, we could take a look at
> that
> indeed. Haven't work with the framework yet, but it looks nice. As for
> complexity,
> I'm not entirely sure whether it'll be an improvement, but we'll have to
> find that out, won't we?
>
> As as for the commons-logging, I agree. But it was an idea on the forums,
> and slf4j can indeed do a bit more than commons-logging. But most of us (I
> think) work with commons-logging. Correct me if I'm wrong.
>
> What custom elements do you have in mind? I see a number of candidates :).
>
> As for the GPL/ASL issue, I think it's backwards, can a ASL project
> (Desktop)
> contain GPL jars (VLDocking) ? I don't think so, unless your project is
> also
> GPL. I'm no fan of the GPL license, so I still don't think we should
> provide
> it. We could put it in a separate module, but I'm afraid this'll cause
> confusion
> with the end-users: 'if I use Desktop with this module, I need to be GPL,
> otherwise I don't'...


I meant a complete separate project (hosted somewhere else, on
dev.java.netof sourceforge), that is gpl licensed. That way we don't
have to worry about
licensing, and can leave the choice to the end-user.


>
>
> With your reply, I've got some more ideas:
>
> 9. Remove the closures in RCP (sorry Keith)
>
> As Keith said to me on SpringOne: SIMPLIFY, SIMPLIFY!! Keith's closures
> were
> a great idea (bit over the top though), but I don't think anyone is using
> them. They're easily refactored out of the codebase thanks to some Java5
> improvemenrs and for the sake of readability, I think we're better of
> without
> the code. So I think we should drop that part of the code.
>
> 10. Implement custom namespace elements for Spring configuration
>
> This can simplify the configuration greatly. We could also create Spring
> 2.5 component stereotype annotations for easy configuration using
> <context:component-scan/>.
>

this is what I meant with "custom elements"

candidates:

- java.util.Preferences instances in beans

something like this:

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

- view descriptors

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

this would allow for shorter xml that's more readable

I'm sure there are a lot more possibilities!

I think we need much closer integration with spring itself (xml support,
custom bean scopes, ...)



>
> WDYT?
>
> Greetz,
>
> Lieven
>
>
> > ----------------------------------------------------------------------
> > ---
> > 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
>
>
>
>
> -------------------------------------------------------------------------
> 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
>

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

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

Hi Lieven! Hi Spring-rich-client members!

(I am the peatar from the forum)

I created an example with the beans bindings some times ago. It seems to 
be powerful, but not really active and not well documented.
Although the mailing list was quite helpful.

> As as for the commons-logging, I agree. But it was an idea on the forums, 
> and slf4j can indeed do a bit more than commons-logging. But most of us (I 
> think) work with commons-logging. Correct me if I'm wrong.

Well, then we should work with commons-logging.

> As for the GPL/ASL issue

It is a bit complicated. I think the GPL (version 2!) removes licenses 
(even open source) and make the code GPLed.
See http://www.apache.org/licenses/GPL-compatibility.html
And please look into a conversation with a FSF member and me [1]

So I think, we should give mydoggy a try :-) (or xui). Please look at
http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks

Another suggestion from me is to look at other existing frameworks (in 
the desktop arena):

http://oswing.sourceforge.net
http://xui.sourceforge.net
http://www.tentackle.org
http://sourceforge.net/projects/pendulum (inactive)
(https://appframework.dev.java.net, https://beansbinding.dev.java.net )


Regards,
Peter (Karich ;-)).



[1]
 > Does this mean that I can't use any GPL library too?

This will depend on whether your project can be argued as a derived work
from the GPL library. If it is, then you must release your project
under the GPL. If it isn't, then you can choose what license to apply
to your work. It can be LGPL, or anything else.

Even if the source-code form of your project is not a derived work of a
GPLed library, its object-code form most certainly is if it is linked
with a GPLed library. So, even though you can choose licensing terms
for the source-code form, it may be that the object-code form must be
licensed under the GPL. In this case, if the choice of license of your
own project, or of any other libraries it is linked with, is
incompatible with the GPL, it won't be possible to distribute this
combined work in object-code form.

If this means it won't be possible at all to distribute your program in
object-code form, odds are that even its source form is a derived work
of the GPLed work, and thus not even the source form can be distributed
under a different license.

 > I want to use db4o as an optional database, which is under the GPL.

In general, if you code any portion of your program specifically to use
a GPLed library, even if optionally, then your program is a derived work
and it must thus be licensed as a whole under the GPL.

There are very rare exceptions to this general rule, but you shouldn't
count on them without talking to a lawyer you trust, ideally one who is
familiar with these issues.

Please bear in mind that this is not to be taken as legal advice, since
I'm not a lawyer.

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

[Arne L. <Arn...@ar...>]

Hi All,

You may also take a look at the docking framework I wrote some time ago:

http://sourceforge.net/projects/swingdocking

It uses JInternalFrames as Docking-Panels.
I have not packed a release yet (nor created a web-page), but it is 
ready to use.
And if someone has some questions about it, I'm on this list...

If someone is interested, I can write the SpringRCP integration.
It is not much code,
maybe you can completely take over the code into SpringRCP.

Regards,
Arne

Peter Karich schrieb:
> Hi Lieven! Hi Spring-rich-client members!
>   
> I think, we should give mydoggy a try :-) (or xui). Please look at
> http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks
>
> Another suggestion from me is to look at other existing frameworks (in 
> the desktop arena):
>
> http://oswing.sourceforge.net
> http://xui.sourceforge.net
> http://www.tentackle.org
> http://sourceforge.net/projects/pendulum (inactive)
> (https://appframework.dev.java.net, https://beansbinding.dev.java.net )
>
>
> Regards,
> Peter (Karich ;-)).
>   

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

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

Hi Arne!

> You may also take a look at the docking framework I wrote some time ago:
> http://sourceforge.net/projects/swingdocking

This is nice and Apache licensed ;-)
Could you provide a screenshot?
Or an example in the download section?

> If someone is interested, I can write the SpringRCP integration.
> It is not much code,
> maybe you can completely take over the code into SpringRCP.

This would be great, I think.
Maybe others would like to see it, too.

Regards,
Peter.

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

[Arne L. <Arn...@ar...>]

Hi Peter

Peter Karich schrieb:
>
> This is nice and Apache licensed ;-)
>   
;-)
> Could you provide a screenshot?
>   
It basically uses JInternalFrames. A Screenshot would look like some 
internal frames docked at each other.
> Or an example in the download section?
>   
http://swingdocking.svn.sourceforge.net/viewvc/swingdocking/trunk/samples/src/main/java/net/sf/swingdocking/samples/Sample.java?revision=17&view=markup

You need Java 6 for this.

Maybe I have some time next weekend to make a release, but you really 
can check it out with

svn co 
https://swingdocking.svn.sourceforge.net/svnroot/swingdocking/trunk 
swingdocking

and try it out.

Regards,
Arne

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

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

I’ll allow myself one comment on the merging of modules.

I agree that SpringRC probably has too many modules but we should keep in
mind that modules should be kept if it is possible that, at some point,
somebody might want to substitute an entire jar.

 

As such, a simple example is “resources” it could stay a module if somebody
want to use totally different icons/images.

(but resources could do with some trimming as a lot of it is not used at
all).

 

If modules are dependent both way then it make it very difficult to
substitute and hence merging them is a good idea.

 

Second suggestion for the refactoring… Do apply suggested patches that are
coming from real-life experience in order to make SpringRC more flexible (eg
JIRA 559, 553, 551, 550, 403, 437).

 

My £0.02 comments.

 

Thanks & best regards

 

Benoit

 

 

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

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.

 

From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Peter De Bruycker
Sent: 24 June 2008 06:55
To: spr...@li...
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the
Desktop version

 

some comments inline...



On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo <HYPERLINK
"mailto:lie...@ji..."lie...@ji...> wrote:

Finally,

I've gotten my newsreader to work (again, thanks to Jetbrains :))

So I'll repeat here what I've put on the forum.

1. Merge some modules

- support + core + forms + binding + jdk5 = core
- retain modules jdk6, sandbox and resources

Perhaps we should also merge resources with the core, but only those
resources
directly needed in the core. The rest can be more something like 'skinning'.

I know this is quite controversial, but now we have the situation where no
one knows where something should be put, so it ends up in support. Modules
should also be selfcontained, no point in having a module that needs another
module anyhow for it to work.

My suggestion:

Core = essential Desktop stuff needed to make a simple application (forms,
basic binders and all underlying plumbing)
JDK6 = JDK6 specific stuff
Sandbox = playground for new stuff, should be followed-up on a regular basis
though
Resources = extra resources (do we need to have this in Desktop?)
Components = extra components (Jan, perhaps we can put your components in
here?)



2. Pull up the source level to 1.5

Java5 will give us a lot more leniency when dealing with some problems. For
example, I'd like to introduce generics in the FormModel and ValueModel for
starters. I think they're great candidates and I don't think it'll be a lot
of work. Using enums in certain places may also increase readability.

3. Rename Binder to BindingFactory

Since we're not bound to the RCP codebase, we should finally do this...

4. A lot more out-of-the-box bindings

Bindings are the mainstay of the application. Therefor I find it more than
logical that we include more bindings in the standard Desktop.


integration with Beans Binding?
 


5. Pull useful stuff from the sandbox

Now that we have the opportunity to do so, we should evaluate what's present
in the sandbox and promote it when useful.

6. Upgrade to Spring Security (Spring 2.5 in general)

Spring 2.5 gives us the possibility to do a lot more, so I think this makes
sense


Also custom xml elements, this would allow for less xml
 



7. Try to refactor out the singletons like Application and
ApplicationServices

We might be able to replace those with the Spring 2.5 @Component and
@Autowired
system...

8. Remove VLDocking

It has a GPL license, so it's not compatible with Desktop (unless someone
wants to release Desktop under the GPL?)


Can a GPL licensed project contain Apache licensed jar files? If so, we can
create a separate project to handle the integration.
 




Some stuff that has come up on the forums:

1. Modular plugin support (jwray)

OSGi-like support for plugins. Personally not my favorite, I don't know many
enterprise applications that use a plugin model, but I might be wrong about
this.

2. JIDE integration (jwray)

Great idea to include JIDE OSS into Desktop. It's a great collection of
components
and making binders for those components will raise the quality of the code.
For commercial JIDE components, we can foresee a separate module, if needed.

3. Integrate mydoggy as a docking framework (peatar)

Looking into it, I've gotten the code from peatar, if I find the time I'll
do a thorough test.

4. Replace commons-logging with slf4j (peatar)

Anyone that can make a clear pro-con analysis on this. I've only worked with
commons-logging.


wouldn't do this, as commons-logging is the de-facto standard
 



5. Logger injection (peatar)

PicoContainer has a LogInjector, do know though if this should be a Desktop
feature... Sounds more like Spring-core... Perhaps this already exists in
2.5, I don't know.


Feel free to comment, flame and add suggestions...

Greetz,

Lieven




-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
HYPERLINK "http://sourceforge.net/services/buy/index.php"
\nhttp://sourceforge.net/services/buy/index.php
_______________________________________________
Springframework-rcp-dev mailing list
HYPERLINK
"mailto:Spr...@li..."Springframework-rcp-de
v...@li...
HYPERLINK
"https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"
\nhttps://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev

 

No virus found in this incoming message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 270.4.1/1515 - Release Date: 23/06/2008
19:16


No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.4.1/1515 - Release Date: 23/06/2008
19:16
 

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

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

Hello Benoit,

You're right about the modules, but at the moment, the split-up is just ridiculous. 
There's no code whatsoever in the forms module, a wee bit of code in core 
and binding and all the rest resides in support. Hence my merging proposition.

As for your issues, Jan's working on a new release, I think some of your 
issues are good candidates for inclusion.

Kind regards,

Lieven

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

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

[Claudio R. <cla...@li...>]

 >  1. Merge some modules
 >
 >  - support + core + forms + binding + jdk5 = core
 >  - retain modules jdk6, sandbox and resources

Hi All!!

I wrote my introduction in the forum :
http://forum.springframework.org/showthread.php?t=55848  :) 

I understand your point of view, looking at the modules as they are
today, it could make sense to merge them.

Nonetheless I think that to have modules with defined dependencies is a
good thing. My proposal for module would be:

Core module:
Contains objects like application lifecycle, security, page, view, and
action stuff. With the core module it should be possible to start an
application with action and views.

Binding/Form module:
I think that binding can be treated separately from the core stuff. Not
every Desktop Application needs bindings. If we separate the core from
the binding it will possible to use your binding of choice in
combination with the Spring Desktop core module.

Application module:
It contains all the rest: dialog, layout, progress, table, text, tree, ...

Sandbox module

Components module

JDK6


Separating the core module from the binding module would converge with
JSR 296 and 295. I think this two JSR's provide a good ground for
richclients. Does it make any sense to delve into this two JSR to check
whether it would make sense to integrate them into Spring Desktop?
Spring-Rich has its own binding, so we really have to be aware of the
pros/cons. To use standards may lead to a bigger acceptance / user base 
for Spring Desktop?

I think Spring Desktop could go further than the JSR 295 does and add 
additional value to it like the formModel stuff (validation), automatic 
binding, form builders and a lot "out of the box" bindings.

 >  7. Try to refactor out the singletons like Application and
ApplicationServices
 >
 >  We might be able to replace those with the Spring 2.5 @Component and
@Autowired
 >  system...

I think it would be great if we could get rid of this singletons. It
would mean a big refactoring of the codebase. The IOC pattern is the
better option in most cases, but of course I understand the reasons for
using the singleton pattern. If we want to replace the singletons we
must provide an easy-to-use-auto-wiring. Without auto wiring facilities
it would lead to a configuration mess.

Kevin Day mentioned other interesting alternatives (whiteboard) which 
maybe could be another direction?


These are just some thoughts…

Regards,
Claudio

[Springframework-rcp-dev] Docking Framework

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

Hi Lieven,

I am finished with the mydoggy integration into Spring RC. We talked 
about it in the forum.

Would you take a look at it? See [1] and the screenshot [2].
It uses a slightly changed version of mydoggy (upcoming 1.5) to load and 
save the layout, so you have to use the provided jars within the download.

MyDoggy is really great, but maybe others (like me) would like to see 
another framework like swingdocking?
Arne, do you think that this is possible? I would help.


Regards,
Peter K.

[1]
http://downloads.sourceforge.net/timefinder/timefinder-snapshot-30.06.2008.zip?use_mirror=osdn
[2]
http://karussell.files.wordpress.com/2008/06/mydoggy-layout-springrc.jpg

Re: [Springframework-rcp-dev] Docking Framework

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

Hello Peter,

I'll take a look at it this evening (got a deadline to catch today so...). 
TIA for the effort!

Greetz,

Lieven

Re: [Springframework-rcp-dev] Docking Framework

[Arne L. <Arn...@ar...>]

Hi Peter,
Hi Lieven,

I've provided integration for Swing-Docking at

http://jira.springframework.org/browse/RCP-561

Regards,
Arne

Peter Karich schrieb:
> Hi Lieven,
>
> I am finished with the mydoggy integration into Spring RC. We talked 
> about it in the forum.
>
> Would you take a look at it? See [1] and the screenshot [2].
> It uses a slightly changed version of mydoggy (upcoming 1.5) to load and 
> save the layout, so you have to use the provided jars within the download.
>
> MyDoggy is really great, but maybe others (like me) would like to see 
> another framework like swingdocking?
> Arne, do you think that this is possible? I would help.
>
>
> Regards,
> Peter K.
>
> [1]
> http://downloads.sourceforge.net/timefinder/timefinder-snapshot-30.06.2008.zip?use_mirror=osdn
> [2]
> http://karussell.files.wordpress.com/2008/06/mydoggy-layout-springrc.jpg
>
>
> -------------------------------------------------------------------------
> 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
>   

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

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

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

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

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

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


the name scope is not very clear in this context: when you have
java.util.Preferences, you can have preferences at the user (= the current
user) scope, and at the system (= for all users) scope. It's not the bean
scope in the application context.


>
>
> 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) {..}
> }


This is looking great!


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

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>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>BTW - the email archive for this list seems to be dead as of 6/17/08:&nbsp; <A href="http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev">http://sourceforge.net/mailarchive/forum.php?forum_name=springframework-rcp-dev</A>&nbsp;- is something going on?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>I completely agree on the comments re: modules.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This is still a rough idea, but I'm thinking that while many apps have no need for per-module class loaders, hot swappable modules,&nbsp;module life cycle management, etc... there is still a big advantage from a&nbsp;coding practices perspective of using modules (JRE 7 is probably going to be introducing module as a scoping feature).&nbsp; In these types of apps, the only OSGi-type event that would need to be fired is ServiceEvent.REGISTERED - and this would all happen at startup (i.e. at the time of dependency injection).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Maybe there is a way to introduce the module concept, and do it in such a way that apps that *want* to run in an OSGi container can do so by just ensuring they have the correct entries in their jar manifests (and using SpringDM).</DIV>
<DIV>&nbsp;</DIV>
<DIV>This places a&nbsp;requirement that the Desktop framework be designed in a manner compatible with SpringDM (keeping sub-systems modularized, not use global service lookups if at all possible, and possibly add required info to the jar manifests for apps that do need to run in an OSGi container).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Interestingly, one of the tenets of the whiteboard pattern is that objects that are traditionally thought of as services are actually not registered as global services.&nbsp; Instead, the listeners of those services are registered as services.&nbsp; As listener objects&nbsp;are registered with the container, the service is notified about their presence and adds the listener to itself (instead of the more traditional approach of having the listener look up the service, and call addListener() ).&nbsp; This, I think, makes a strong case for not using global service lookup in the traditional sense.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Given the above, I wonder if the module break out of the Desktop project should be aligned along functional lines (and possibly divided with modules for interface, implementation and possibly GUI).&nbsp; I could see having separate packages for jdk6 specific stuff (maybe), but a totally separate module seems to cut across concerns in an odd way.</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;"Jim Moore" <A href="mailto:moo...@gm..."><FONT color=#0000ff>&lt;moo...@gm...&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, 1 Jul 2008 23:20:43 -0400</DIV>
<DIV><B>Subject:&nbsp;<U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV>&nbsp;&nbsp;</DIV></DIV>Heya, everyone.&nbsp; Sorry for jumping into this discussion late.<BR><BR>I prefer Claudio's distinctions for breaking out the modules.&nbsp; 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.<BR><BR>Spring 3.0 will also be dropping JDK1.4 support.&nbsp; Going to Java 5 just makes sense -- especially for a desktop app.&nbsp; (In fact it's arguable that we should go to Java 6 given all the desktop improvements they made.)<BR><BR>There's a reason no Spring example shows injecting a Logger.&nbsp; The nature of logging and the logging libraries means there's no real benefit to doing so.&nbsp; 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.&nbsp; That's what the Spring does on the Sp
 ringSource Application Platform (S2AP), for example.<BR><BR>I love the idea of new XML configuration.&nbsp; A couple of comments on the examples:<BR><BR>&lt;bean id="someBean" class="foobar"&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;property name="prefs"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;desktop:prefs scope="user|system" path="path/to/preferences/node"/&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;/property&gt;<BR>&lt;/bean&gt;<BR><BR>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.&nbsp; I assume "user" scope would be defined based on a Spring Security SecurityContext and "system" would be a standard singleton?&nbsp; Having the custom XML element would nicely hide those details from the user.<BR><BR>&lt;desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView"&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;property name="someService" ref="serviceId"/&gt;<BR>&lt;/desktop:view
 &gt;<BR><BR>&lt;desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView" mdi:closable="true" mdi:resizable="false"&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;property name="someService" ref="serviceId"/&gt;<BR>&lt;/desktop:view&gt;<BR><BR>&lt;desktop:view id="yetAnotherView" viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false" docking:draggable="true"&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;property name="someService" ref="serviceId"/&gt;<BR>&lt;/desktop:view&gt;<BR><BR>In Spring 2.5 ADI style that might be done as<BR><BR>&lt;context:component-scan package="com.myco"/&gt;<BR><BR>@View<BR>public class SomeView {<BR>&nbsp; @Autowired SomeView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@MdiConfiguration(closable=true, resizable=false)<BR>public class OtherView {<BR>&nbsp; @Autowired OtherView(SomeService someService) {..}<BR>}<BR><BR>@View<BR>@DockingConfiguration(closable=false, draggable=false)<BR>public class YetAnotherView {<BR>&nbsp; @Autowired YetAnotherView(So
 meService someService) {..}<BR>}<BR><BR><BR>Modular plugin support is partly for plugins (a-la Eclipse or Netbeans), but mostly for making it easier to do good modularity.&nbsp; Hot-swapping, discovery, etc are all just nice side-effects of having better modularity.&nbsp; 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)&nbsp; S2AP can provide the underlying support for that if we want.&nbsp; Otherwise we can keep OSGi use (but not OSGi compliance) out for now.&nbsp; 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.<BR><BR>-Jim Moore<BR>&nbsp;Senior Consultant, SpringSource<BR><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>

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

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

Hi guys,

Been reading all the posts here and been comtemplating on OSGi. And frankly, 
as a business application developers, I really don't see the additional benefit 
of a modular system on a GUI level. Perhaps I'm thick, I don't know, but 
I really can't find a reason to provide a modular system on a GUI framework 
system.

Most application I come in contact with don't have a modular design (actually, 
that's incorrect, but not in the modular sense we're talking about here). 
Enterprise custom-built application don't need plugin functionality (although 
it could be handy on a development level, granted). They almost always see 
their thick-client gui as a entire module (in the sense we're talking about 
here), which might be split up in different modules (in the more traditional 
way, for development purposes).

Don't get me wrong, I do see OSGi as a good thing, but for clearly defined 
concerns (dao, service, webservice, domain (although disputable, who would 
want to take down a POJO layer...) and webstart GUI as a single module)... 
Using OSGi for GUI just seems overkill, could anyone give me an example on 
how he or she would split up his GUI application, 'cause that would be great.

Please enlighten me, let me see the OSGi light :).

Kind regards,

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] [Spring Desktop] ideas for theDesktop version

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

I think that if possible, we should support OSGI, because it allows for
interesting usecases such as:

- a debug module, containing a frontend to interrogate the system state (a
basic debug module could even be created by us)
- splitting modules according to your business domain (we do this on the
functional parts -> interfaces for integration points), so why not on ui
level?) -> this is what we do in our struts applications also (one struts
module per application module)

osgi bundles are also great for controlling your dependencies (limit the
exported packages to a minimum, so no dependencies on internal stuff)

regards,

Peter

On Fri, Jul 4, 2008 at 12:25 PM, Lieven Doclo <lie...@ji...>
wrote:

> Hi guys,
>
> Been reading all the posts here and been comtemplating on OSGi. And
> frankly,
> as a business application developers, I really don't see the additional
> benefit
> of a modular system on a GUI level. Perhaps I'm thick, I don't know, but
> I really can't find a reason to provide a modular system on a GUI framework
> system.
>
> Most application I come in contact with don't have a modular design
> (actually,
> that's incorrect, but not in the modular sense we're talking about here).
> Enterprise custom-built application don't need plugin functionality
> (although
> it could be handy on a development level, granted). They almost always see
> their thick-client gui as a entire module (in the sense we're talking about
> here), which might be split up in different modules (in the more
> traditional
> way, for development purposes).
>
> Don't get me wrong, I do see OSGi as a good thing, but for clearly defined
> concerns (dao, service, webservice, domain (although disputable, who would
> want to take down a POJO layer...) and webstart GUI as a single module)...
> Using OSGi for GUI just seems overkill, could anyone give me an example on
> how he or she would split up his GUI application, 'cause that would be
> great.
>
> Please enlighten me, let me see the OSGi light :).
>
> Kind regards,
>
> 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] [Spring Desktop] ideas for theDesktop version

[Luan O'C. <lua...@gm...>]

Take for example a business administration application. You might for
example have modules for CRM, HR, Finance, Reporting, MIS etc...

You might also modularize the application delivery, separating say the
basic windowing (SDI/MDI/Docking) from a common application stub and
from the application specific components.

An application might also be delivered in several forms for varying
usage levels: guest, registered users, administrators etc...

The rendering of the application might also vary with a rich/thick
client in some instances and a thin client in others.

You might have mixins or add-ons like client side caching or even
off-line use support.

I reckon there are lots of cases for modularizing the client and
without support for this the reusability of components drops right
off! Most enterprise clients may be built as an 'entire module' as you
put it, but I would suggest that that is a major problem with how apps
are typically built and it places too much responsibility on to the
application developer.

Luan

2008/7/4 Lieven Doclo <lie...@ji...>:
> Hi guys,
>
> Been reading all the posts here and been comtemplating on OSGi. And frankly,
> as a business application developers, I really don't see the additional benefit
> of a modular system on a GUI level. Perhaps I'm thick, I don't know, but
> I really can't find a reason to provide a modular system on a GUI framework
> system.
>
> Most application I come in contact with don't have a modular design (actually,
> that's incorrect, but not in the modular sense we're talking about here).
> Enterprise custom-built application don't need plugin functionality (although
> it could be handy on a development level, granted). They almost always see
> their thick-client gui as a entire module (in the sense we're talking about
> here), which might be split up in different modules (in the more traditional
> way, for development purposes).
>
> Don't get me wrong, I do see OSGi as a good thing, but for clearly defined
> concerns (dao, service, webservice, domain (although disputable, who would
> want to take down a POJO layer...) and webstart GUI as a single module)...
> Using OSGi for GUI just seems overkill, could anyone give me an example on
> how he or she would split up his GUI application, 'cause that would be great.
>
> Please enlighten me, let me see the OSGi light :).
>
> Kind regards,
>
> 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] [Spring Desktop] ideas for theDesktopversion

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

Thanks for the input. I'm starting to see the light...

I understand why you would modularize your application and I can see a lot 
of valid usecases in my daily work too. But you're talking on a project/finished 
product level (of which I already said is a great platform for OSGi development). 
I don't see a case for splitting up Spring Desktop's architectures into separate 
bundles... As I see it, most of your project's modules will use Spring RCP 
as a whole anyways... That my main concern. I haven't seen a meaningful for 
split-up of Spring Desktop yet (except for the Beans Binding framework, and 
that's a JDK7 feature...). 

That's my main point, as I see it, I don't see us using the same amount of 
split-up as Spring RCP 'just because we can'. The more I look at it, I'm 
convinced we should merge some of the modules (as stated in my original post). 
OSGi or Spring DM enabling those merged modules, I'm all for that... That 
way you can use OSGi or Spring DM on a project basis but you don't burden 
framework developers with that...

As I said, I do see modularizing applications as a good thing, but you shouldn't 
modularize your framework used to build those applications too much...

I hope you guys get what I'm saying :).

Kind regards,

Lieven 



> Take for example a business administration application. You might for
> example have modules for CRM, HR, Finance, Reporting, MIS etc...
> 
> You might also modularize the application delivery, separating say the
> basic windowing (SDI/MDI/Docking) from a common application stub and
> from the application specific components.
> 
> An application might also be delivered in several forms for varying
> usage levels: guest, registered users, administrators etc...
> 
> The rendering of the application might also vary with a rich/thick
> client in some instances and a thin client in others.
> 
> You might have mixins or add-ons like client side caching or even
> off-line use support.
> 
> I reckon there are lots of cases for modularizing the client and
> without support for this the reusability of components drops right
> off! Most enterprise clients may be built as an 'entire module' as you
> put it, but I would suggest that that is a major problem with how apps
> are typically built and it places too much responsibility on to the
> application developer.
> 
> Luan
> 
> 2008/7/4 Lieven Doclo <lie...@ji...>:
> 
>> Hi guys,
>> 
>> Been reading all the posts here and been comtemplating on OSGi. And
>> frankly,
>> as a business application developers, I really don't see the
>> additional benefit
>> of a modular system on a GUI level. Perhaps I'm thick, I don't know,
>> but
>> I really can't find a reason to provide a modular system on a GUI
>> framework
>> system.
>> Most application I come in contact with don't have a modular design
>> (actually, that's incorrect, but not in the modular sense we're
>> talking about here). Enterprise custom-built application don't need
>> plugin functionality (although it could be handy on a development
>> level, granted). They almost always see their thick-client gui as a
>> entire module (in the sense we're talking about here), which might be
>> split up in different modules (in the more traditional way, for
>> development purposes).
>> 
>> Don't get me wrong, I do see OSGi as a good thing, but for clearly
>> defined concerns (dao, service, webservice, domain (although
>> disputable, who would want to take down a POJO layer...) and webstart
>> GUI as a single module)... Using OSGi for GUI just seems overkill,
>> could anyone give me an example on how he or she would split up his
>> GUI application, 'cause that would be great.
>> 
>> Please enlighten me, let me see the OSGi light :).
>> 
>> Kind regards,
>> 
>> 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

Re: [Springframework-rcp-dev] [Spring Desktop] ideas fortheDesktopversion

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

An additional point:

We shouldn't use OSGi and modularize our framework just because it might 
solve our service locator singletons problems... That seems like hitting 
a fly with a sledgehammer. I'm sure there are more subtle solutions to that 
problem...

Greetings,

Lieven

> Thanks for the input. I'm starting to see the light...
> 
> I understand why you would modularize your application and I can see a
> lot of valid usecases in my daily work too. But you're talking on a
> project/finished product level (of which I already said is a great
> platform for OSGi development). I don't see a case for splitting up
> Spring Desktop's architectures into separate bundles... As I see it,
> most of your project's modules will use Spring RCP as a whole
> anyways... That my main concern. I haven't seen a meaningful for
> split-up of Spring Desktop yet (except for the Beans Binding
> framework, and that's a JDK7 feature...).
> 
> That's my main point, as I see it, I don't see us using the same
> amount of split-up as Spring RCP 'just because we can'. The more I
> look at it, I'm convinced we should merge some of the modules (as
> stated in my original post). OSGi or Spring DM enabling those merged
> modules, I'm all for that... That way you can use OSGi or Spring DM on
> a project basis but you don't burden framework developers with that...
> 
> As I said, I do see modularizing applications as a good thing, but you
> shouldn't modularize your framework used to build those applications
> too much...
> 
> I hope you guys get what I'm saying :).
> 
> Kind regards,
> 
> Lieven
> 
>> Take for example a business administration application. You might for
>> example have modules for CRM, HR, Finance, Reporting, MIS etc...
>> 
>> You might also modularize the application delivery, separating say
>> the basic windowing (SDI/MDI/Docking) from a common application stub
>> and from the application specific components.
>> 
>> An application might also be delivered in several forms for varying
>> usage levels: guest, registered users, administrators etc...
>> 
>> The rendering of the application might also vary with a rich/thick
>> client in some instances and a thin client in others.
>> 
>> You might have mixins or add-ons like client side caching or even
>> off-line use support.
>> 
>> I reckon there are lots of cases for modularizing the client and
>> without support for this the reusability of components drops right
>> off! Most enterprise clients may be built as an 'entire module' as
>> you put it, but I would suggest that that is a major problem with how
>> apps are typically built and it places too much responsibility on to
>> the application developer.
>> 
>> Luan
>> 
>> 2008/7/4 Lieven Doclo <lie...@ji...>:
>> 
>>> Hi guys,
>>> 
>>> Been reading all the posts here and been comtemplating on OSGi. And
>>> frankly,
>>> as a business application developers, I really don't see the
>>> additional benefit
>>> of a modular system on a GUI level. Perhaps I'm thick, I don't know,
>>> but
>>> I really can't find a reason to provide a modular system on a GUI
>>> framework
>>> system.
>>> Most application I come in contact with don't have a modular design
>>> (actually, that's incorrect, but not in the modular sense we're
>>> talking about here). Enterprise custom-built application don't need
>>> plugin functionality (although it could be handy on a development
>>> level, granted). They almost always see their thick-client gui as a
>>> entire module (in the sense we're talking about here), which might
>>> be
>>> split up in different modules (in the more traditional way, for
>>> development purposes).
>>> Don't get me wrong, I do see OSGi as a good thing, but for clearly
>>> defined concerns (dao, service, webservice, domain (although
>>> disputable, who would want to take down a POJO layer...) and
>>> webstart GUI as a single module)... Using OSGi for GUI just seems
>>> overkill, could anyone give me an example on how he or she would
>>> split up his GUI application, 'cause that would be great.
>>> 
>>> Please enlighten me, let me see the OSGi light :).
>>> 
>>> Kind regards,
>>> 
>>> 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-de
>>>> v
>>> --------------------------------------------------------------------
>>> -
>>> ----
>>> 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] Spring Security

[Fritz R. <fr...@wo...>]

Hi together,
as I've seen in the forum, there
was already a patch for using the spring-security.

Is it possible to include the patch into the current version of spring- 
rich-client?

Kind regards
Fritz

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

[luano <lua...@gm...>]

That's a fine point IMO given that there is such a wide range of things a
desktop application might do and some of the components one might use are
not so trivial. Promoting modularity from the ground up would be a good
thing in my eyes (depending on the cost of course). 

But modularity shouldn't be intrusive and if done right a developer should
be able to take a bundle of modules and start to build their application
without having to do any module configuration - which perhaps is
paraphrasing your intent when you say "you shouldn't modularize .. too
much".

-Luan


Lieven Doclo-2 wrote:
> 
> 
> As I said, I do see modularizing applications as a good thing, but you
> shouldn't 
> modularize your framework used to build those applications too much...
> 
> I hope you guys get what I'm saying :).
> 
> 

-- 
View this message in context: http://www.nabble.com/-Spring-Desktop--ideas-for-the-Desktop-version-tp18064778p18283658.html
Sent from the springframework-rcp-dev mailing list archive at Nabble.com.