« Return to Thread: [Spring Desktop] ideas for the Desktop version
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:
springframework-rcp-dev-bounces@...
[mailto:springframework-rcp-dev-bounces@...] On Behalf Of Peter
De Bruycker
Sent: 24 June 2008 06:55
To: springframework-rcp-dev@...
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 <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
« Return to Thread: [Spring Desktop] ideas for the Desktop version
| Free embeddable forum powered by Nabble | Forum Help |