Menu
▾
▴
[Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version
|
From: Arne L. <Arn...@ar...> - 2008-07-06 14:38:38
|
Hi to all, 1. Of course Lieven is right that we should not use OSGi, if we just want to remove our service locator singleton. I wonder why we couldn't simply remove the service locator and directly inject the needed services to the needing beans?! 2. There are at least three use-cases where Spring-Desktop could benefit from OSGi: a) OSGi provides a mechanism that could be used to dynamically plug in business modules into a Spring-Desktop-Application. Spring-Deskop should provide a mechanism to add and remove menu or toolbar entries dynamically on startup or shutdown of these business bundles (i.e. entries in the "New"-submenu. The bundles could register Actions as OSGi Services. And the menus must be aware of that. b) OSGi service-resolution may be used to dynamically switch implementations of the application-services. We could provide a bundle with default-implementations and if needed someone could register a bundle with a higher ranking, forcing to use his implementation. c) With OSGi we could provied an update-mechanism to update parts of the application without needing to restart it. 3. Besides the OSGi debate Spring-Desktop should definitely provide a Spring bean-scope "window" to be able to configure commands in the normal application-context (if needed with scope "window") and get rid of the separate commans-context. Regards, Arne Lieven Doclo schrieb: > 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 >> > > > > > ------------------------------------------------------------------------- > 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 > |
