Menu
▾
▴
Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
|
From: Jonny W. <jwr...@gm...> - 2008-07-04 17:44:22
|
Lieven, I think the others have echoed my main reasons for wanting a modules/plugin system - separation of functionality and delivery of different functionality to different users is one of my main use cases. In terms of the actual framework, I can see where you're coming from as most of the time you'll use everything. However, maybe aspects that could be potentially replaced by another solution should be modularized? For example, the factories for creating pages and windows now have multiple implementations for basic and various docking solutions, but you only need one. I'm sure there's other aspects of the framework that could have drop in replacements. Jonny On Fri, Jul 4, 2008 at 5:03 AM, Lieven Doclo <lie...@ji...> wrote: > 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 > > > > > ------------------------------------------------------------------------- > 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 > |
