Re: [Springframework-rcp-dev] [Spring Desktop] ideas fortheDesktopversion

[Lieven D. <lie...@ji...>]

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