Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
|
From: Benoit X. <bx...@ob...> - 2008-06-24 09:52:16
|
Ill 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 |
