Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion

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

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