|
[Spring Desktop] ideas for the Desktop version
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
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for the Desktopversion
|
|
Re: [Spring Desktop] ideas for the Desktop version
some comments inline... On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo < lieven.doclo@...> 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
Springframework-rcp-dev@...
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
On Tue, Jun 24, 2008 at 9:19 AM, Lieven Doclo < lieven.doclo@...> 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.net of 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?
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
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.htmlAnd 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+FrameworksAnother suggestion from me is to look at other existing frameworks (in
the desktop arena):
http://oswing.sourceforge.nethttp://xui.sourceforge.nethttp://www.tentackle.orghttp://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.
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for the Desktop version
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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.
some comments inline...
On Mon, Jun 23, 2008 at 10:29 AM, Lieven Doclo <lieven.doclo@...> 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
Springframework-rcp-dev@...
https://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
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas forthe Desktop version
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
Hi All,
You may also take a look at the docking framework I wrote some time ago:
http://sourceforge.net/projects/swingdockingIt 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:
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
|
|
Re: [Spring Desktop] ideas for theDesktop version
|
|
Re: [Spring Desktop] ideas for the Desktop version
> 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
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Docking Framework
|
|
Re: Docking Framework
|
|
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
On Wed, Jul 2, 2008 at 5:20 AM, Jim Moore < moore.jim@...> 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
Springframework-rcp-dev@...
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for the Desktop version
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 < moore.jim@...> 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>
<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
-------------------------------------------------------------------------
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
|
|
 Re: [Spring Desktop] ideas for the Desktop version
The XUI framework mentioned earlier is now dead/frozen, however
development is continuing under the banner of the Aria framework
( http://www.sf.net/projects/aria). The framework includes things like
data bindings and automatic form and dialog generation from POJOs with
data binding, validation and caching. Spring integration is possible
and is being enhanced at the moment with support for annotation driven
generation of the UI, client side caching and rule driven coordination
of the UI (updates etc...).
The framework includes docking and other desktop metaphors plus lots
of rich components. The framework also comes with WYSIWYG plugins for
NetBeans and Eclipse. The framework can target various widget sets
including Swing, SWT, AWT and MIDP and JDKs from 1.1.8 to the very
latest.
There is a draft article at http://www.formaria.org/spring/integrationexplaining some of the Spring integration.
Some or all of the framework might be of interest to this
project/current discussion and perhaps as the basis for future
development.
Luan
-------------------------------------------------------------------------
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
|
|
Re: [Spring Desktop] ideas for the Desktop version
|
|
Re: [Spring Desktop] ideas for the Desktop version
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I completely agree on the comments re: modules.
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, module life cycle management, etc... there is still a big advantage from a coding practices perspective of using modules (JRE 7 is probably going to be introducing module as a scoping feature). 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).
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).
This places a 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).
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. Instead, the listeners of those services are registered as services. As listener objects 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() ). This, I think, makes a strong case for not using global service lookup in the traditional sense.
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). 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.
- K
----------------------- Original Message -----------------------
Cc:
Date: Tue, 1 Jul 2008 23:20:43 -0400
Subject: Re: [Springframework-rcp-dev] [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 Sp
ringSource 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(So
meService 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 -------------------------------------------------------------------------
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
|
