|
Re: Docking Framework
|
|
Re: [Spring Desktop] ideas for theDesktop version
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
I think that if possible, we should support OSGI, because it allows for interesting usecases such as: - a debug module, containing a frontend to interrogate the system state (a basic debug module could even be created by us)
- splitting modules according to your business domain (we do this on the functional parts -> interfaces for integration points), so why not on ui level?) -> this is what we do in our struts applications also (one struts module per application module)
osgi bundles are also great for controlling your dependencies (limit the exported packages to a minimum, so no dependencies on internal stuff) regards, Peter On Fri, Jul 4, 2008 at 12:25 PM, Lieven Doclo < lieven.doclo@...> wrote:
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
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 < lieven.doclo@...>:
> 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
>> Springframework-rcp-dev@...
>> 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
> Springframework-rcp-dev@...
> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
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 < lieven.doclo@...>:
>
>> 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
>>> Springframework-rcp-dev@...
>>> 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
>> Springframework-rcp-dev@...
>> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas fortheDesktopversion
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 < lieven.doclo@...>:
>>
>>> 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
>>>> Springframework-rcp-dev@...
>>>> 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
>>> Springframework-rcp-dev@...
>>> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Spring Security
Hi together,
as I've seen in the forum, there
was already a patch for using the spring-security.
Is it possible to include the patch into the current version of spring-
rich-client?
Kind regards
Fritz
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
That's a fine point IMO given that there is such a wide range of things a desktop application might do and some of the components one might use are not so trivial. Promoting modularity from the ground up would be a good thing in my eyes (depending on the cost of course).
But modularity shouldn't be intrusive and if done right a developer should be able to take a bundle of modules and start to build their application without having to do any module configuration - which perhaps is paraphrasing your intent when you say "you shouldn't modularize .. too much".
-Luan
Lieven Doclo-2 wrote:
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 :).
|
|
Re: [Spring Desktop] ideas for theDesktopversion
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 < lieven.doclo@...> 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 < lieven.doclo@...>:
>
>> 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
>>> Springframework-rcp-dev@...
>>> 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
>> Springframework-rcp-dev@...
>> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Hi Lieven,
like you, I think that almost all people will use springRC as one bundle.
So it could be that no splitting is necessary (only the traditional way
of jar bundles of course)
But maybe I missed the point you are talking about.
I don't know a lot of OSGi, but is it possible with this library to load
plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your
program or to offer additional features)
This would be great for SpringRC and then my vote will be pro OSGi ;-)
Regards,
Peter.
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
[Spring Desktop] ideas for the Desktop version
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 < lieven.doclo@...>:
>>>
>>>
>>>> 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
>>>>> Springframework-rcp-dev@...
>>>>> 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
>>>> Springframework-rcp-dev@...
>>>> 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
> Springframework-rcp-dev@...
> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideasfor theDesktopversion
Hello Peter,
Indeed, plugin functionality would be great. But I still don't know whether
OSGi is the way to go there... Perhaps we can find a more KISS method to
do this...
This weekend I did some research and I've looked at the current applications
of OSGi and where it might fit into Spring Desktop. The main problem I would
have with using OSGi in Spring Desktop's main architecture (for whatever
reason) is that I would not want a user to be obligated to use OSGi just
to create a straight-forward application. The advantages are also clear (better
incremental development, upgrade parts of your app on the fly,...), but don't
outweigh my doubts at the moment.
If someone can show me an example where a framework uses OSGi transparently
(the user doesn't know OSGi is used and isn't obligated to use OSGi when
he uses the framework), I'm all ears. But I don't think this is possible.
One way or another, OSGi will pop his head up and bother the average Joe
programmer who just wants to make his address book in Spring Desktop... What
I want to say here, it's great to consider enterprise level features such
as OSGi (and features like that should be considered and eventually foreseen),
but when you're burdening the smaller applications with these features you'll
lose a lot of the current RCP users...
Greetz,
Lieven
> Hi Lieven,
>
> like you, I think that almost all people will use springRC as one
> bundle.
> So it could be that no splitting is necessary (only the traditional
> way
> of jar bundles of course)
> But maybe I missed the point you are talking about.
> I don't know a lot of OSGi, but is it possible with this library to
> load
> plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of
> your
> program or to offer additional features)
> This would be great for SpringRC and then my vote will be pro OSGi ;-)
>
> Regards,
> Peter.
> ----------------------------------------------------------------------
> ---
> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideasfor theDesktopversion
Lieven Doclo wrote:
> Hello Peter,
>
> Indeed, plugin functionality would be great. But I still don't know whether
> OSGi is the way to go there... Perhaps we can find a more KISS method to
> do this...
>
> This weekend I did some research and I've looked at the current applications
> of OSGi and where it might fit into Spring Desktop. The main problem I would
> have with using OSGi in Spring Desktop's main architecture (for whatever
> reason) is that I would not want a user to be obligated to use OSGi just
> to create a straight-forward application. The advantages are also clear (better
> incremental development, upgrade parts of your app on the fly,...), but don't
> outweigh my doubts at the moment.
>
> If someone can show me an example where a framework uses OSGi transparently
> (the user doesn't know OSGi is used and isn't obligated to use OSGi when
> he uses the framework), I'm all ears. But I don't think this is possible.
> One way or another, OSGi will pop his head up and bother the average Joe
> programmer who just wants to make his address book in Spring Desktop... What
> I want to say here, it's great to consider enterprise level features such
> as OSGi (and features like that should be considered and eventually foreseen),
> but when you're burdening the smaller applications with these features you'll
> lose a lot of the current RCP users...
>
> Greetz,
>
> Lieven
I don't think that there necessarily has to be a huge amount of
dependency on OSGi to allow Spring Desktop to support it.
With reference to the current SRCP, it seems to me that there would need
to be a certain amount of OSGi-aware classes that would allow for
modules to appear and disappear, but that the core would not necessarily
need rewriting.
e.g. there would need to be a different way of managing
commands/actions, than the current commands-context.xml. So, an
equivalent, but OSGi-aware implementation might allow for actions to be
registered and deregistered.
If the app designer wants to use OSGi, choose the OSGi-aware
implementations of classes, much like we have a variety of
ApplicationPageFactories supporting SDI/MDI interfaces currently.
Rogan
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for the Desktop version
1) The principle reason for the ApplicaionServices singleton was for substantial convenience. For example, creating something like a wizard dialog means calling "new" on it, so it's not coming from Spring, and doing all the DI on it manually could be cumbersome (especially since the calling object would need to know everything that it would need to pass in and get that DIed first). Fortunately, this is not difficult to solve: Spring MVC has the same kinds of issues and solves it very cleanly, if you're familiar with the patterns there.
2) Agreed, but let's go for the "this solves an immediate need" modularity stuff first. 3) Great idea. On Sun, Jul 6, 2008 at 10:38 AM, Arne Limburg < Arne.Limburg@...> wrote:
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
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).
From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.
Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).
Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).
This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.
- K
----------------------- Original Message -----------------------
Cc:
Date: Fri, 04 Jul 2008 22:22:50 +0200
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
Hi Lieven, like you, I think that almost all people will use springRC as one bundle. So it could be that no splitting is necessary (only the traditional way of jar bundles of course) But maybe I missed the point you are talking about. I don't know a lot of OSGi, but is it possible with this library to load plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your program or to offer additional features) This would be great for SpringRC and then my vote will be pro OSGi ;-) Regards, Peter. ------------------------------------------------------------------------- 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/com
munity/cca08_______________________________________________ Springframework-rcp-dev mailing list Springframework-rcp-dev@...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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Hi Everyone,
It's been a long time since I've participated, so hopefully my
viewpoints won't be too dated :-)
IOn the issue of OSGi, I would argue along the lines of Jim Moore - do
it later when we find a pressing need that can't be solved without it,
and work to cleanly modularize our codebase to ensure no cyclic
dependencies etc.
To Kevin's question about the decision to not use DI for the core
services (and to use a service locator pattern instead), the main
reason that it came about was due to the massive amount of XML that
would be required to inject the desired services into every object.
Additionally, the number of dynamic objects that need access to
platform services can be huge, and there was no good way to get the
quickly wired in. You either had to resort to intermediate factories
that could be DI'd and have the factories wire in the services (and
that required extra interfaces on the created objects to accept the
injection), or invent some other similar scenario to get the services
into the dynamic objects.
I'm still of the opinion that a service locator singleton (with a
pluggable implementation) provides benefits and doesn't require the
complexity of having to have a declarative model that knows about every
single kind of object that might come into existence during the life of
the application. But, I'm always ready to be educated out of any
antiquated notions I may hold if someone can show me how the wiring of
dynamic objects can be handled in a simple way (very little XML and
minimal biolerplate).
Learning curve and the amount of XML you have to write in order to get
your application running were two significant factors we faced with the
adoption of Spring RCP. I personally feel that requiring new app
developers to learn yet another complex piece of machinery (OSGi) in
addition to all the rest of Spring Rich (which is significant by
itself) would not be beneficial to the project's uptake.
Just my $.02 worth - boy, I hate how the current economy makes my
opinions worth less each month :-)
Thanks,
Larry.
Kevin Day wrote:
Eclipse is entirely built on top of OSGi bundles (in fact,
Eclipse's Equinox project is the baseline OSGi implementation).
From my perspective, I don't think that OSGi is necessarily
appropriate for a lot of GUI apps (although I do think it probably has
more applicability than we might give it credit - even a simple music
player could benefit greatly from a pluggable codec system). From my
perspective, the *module* approach is the important thing. And if we
are going to do modules, we might as well do something that is at least
upwards compatible with OSGi. Certainly, the full OSGi functionality
is not necessary for most apps - I actually a think a very small subset
would be appropriate - and this sub-set could be run inside AND outside
an OSGi container with a little bit of Spring DI magic.
Here's the basic premise: Because OSGi supports dynamic loading
and unloading of modules, they have been forced to address the issue of
dynamic dependency management. The core result is that modules do
*not* interact directly with each other. Instead, they either locate
other modules (using a service locator type pattern), or they have
those modules injected (using the whiteboard pattern). Time has shown
that the dynamic dependency injection pattern is more reliable, easier
to test and results in more flexible systems (allowing modules to be
dynamically loaded and unloaded without impacting the operation of the
application). In dynamic environments, it also makes service consumers
much, much simpler to write (there is almost no boilerplate code - this
is all refactored up into the framework).
Most importantly, modularity forces better design practices
overall. There are absolutely cases where functionality is so closely
tied together that it will always reside in the same module - but I
suspect that a lot of that sort of thing is occuring in the current
code base because of the use of service locator type patterns instead
of dependency injection (could be wrong on that, and I certainly don't
want to step on any toes - but sometimes it's healthy to have an
outsider question a design decision :-) ).
This actually raises an interesting question that I hope someone
with a deeper history in the Spring-RCP project can answer: How did
the original decision to depart from Spring IOC/DI come about in the
RCP project? Was it b/c of objection of creating and maintaining tons
of Spring xml files, or was there some other reason? I think that
maybe by understanding this, we may learn many of the things that need
to be considered as we have the current discussion. It's super easy to
set back at the end of years of development and question design
decisions that were made early on - and in doing so, it's easy to miss
some extremely important detail that went into the decision.
- K
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Yes please, let's design modularity in from the start, even if it is
implemented fully now.
2008/7/7 Kevin Day < kevin@...>:
> Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox
> project is the baseline OSGi implementation).
>
> From my perspective, I don't think that OSGi is necessarily appropriate for
> a lot of GUI apps (although I do think it probably has more applicability
> than we might give it credit - even a simple music player could benefit
> greatly from a pluggable codec system). From my perspective, the *module*
> approach is the important thing. And if we are going to do modules, we
> might as well do something that is at least upwards compatible with OSGi.
> Certainly, the full OSGi functionality is not necessary for most apps - I
> actually a think a very small subset would be appropriate - and this sub-set
> could be run inside AND outside an OSGi container with a little bit of
> Spring DI magic.
>
> Here's the basic premise: Because OSGi supports dynamic loading and
> unloading of modules, they have been forced to address the issue of dynamic
> dependency management. The core result is that modules do *not* interact
> directly with each other. Instead, they either locate other modules (using
> a service locator type pattern), or they have those modules injected (using
> the whiteboard pattern). Time has shown that the dynamic dependency
> injection pattern is more reliable, easier to test and results in more
> flexible systems (allowing modules to be dynamically loaded and unloaded
> without impacting the operation of the application). In dynamic
> environments, it also makes service consumers much, much simpler to write
> (there is almost no boilerplate code - this is all refactored up into the
> framework).
>
> Most importantly, modularity forces better design practices overall. There
> are absolutely cases where functionality is so closely tied together that it
> will always reside in the same module - but I suspect that a lot of that
> sort of thing is occuring in the current code base because of the use of
> service locator type patterns instead of dependency injection (could be
> wrong on that, and I certainly don't want to step on any toes - but
> sometimes it's healthy to have an outsider question a design decision :-)
> ).
>
>
> This actually raises an interesting question that I hope someone with a
> deeper history in the Spring-RCP project can answer: How did the original
> decision to depart from Spring IOC/DI come about in the RCP project? Was it
> b/c of objection of creating and maintaining tons of Spring xml files, or
> was there some other reason? I think that maybe by understanding this, we
> may learn many of the things that need to be considered as we have the
> current discussion. It's super easy to set back at the end of years of
> development and question design decisions that were made early on - and in
> doing so, it's easy to miss some extremely important detail that went into
> the decision.
>
> - K
>
> ----------------------- Original Message -----------------------
>
> From: Peter Karich < peathal@...>
> To: springframework-rcp-dev@...
> Cc:
> Date: Fri, 04 Jul 2008 22:22:50 +0200
> Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas
> for theDesktopversion
>
> Hi Lieven,
>
> like you, I think that almost all people will use springRC as one bundle.
> So it could be that no splitting is necessary (only the traditional way
> of jar bundles of course)
> But maybe I missed the point you are talking about.
> I don't know a lot of OSGi, but is it possible with this library to load
> plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your
> program or to offer additional features)
>
> This would be great for SpringRC and then my vote will be pro OSGi ;-)
>
> Regards,
> Peter.
>
>
> -------------------------------------------------------------------------
> 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/com munity/cca08
> _______________________________________________
> Springframework-rcp-dev mailing list
> Springframework-rcp-dev@...
> 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
> Springframework-rcp-dev@...
> 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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Some parts of this message have been removed.
Learn more about Nabble's security policy.
thanks for the explanation on where the service locator pattern came from - that helps a lot. I'm wondering if there may be value in trying to capture the true complexity of the dependency graph that's involved and see what sorts of things maybe could benefit from refactoring, injection by convention perhaps - it sounds like there has been a lot of movement in the Spring web framework to simplify this kind of declarative injection.
I certainly want to minimize the amount of boiler plate/explicit configuration required for consumers of the framework. The configuration-by-convention approach that some web frameworks are beginning to use is quite appealing.
- K
----------------------- Original Message -----------------------
Cc:
Date: Mon, 07 Jul 2008 11:45:49 -0500
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
Hi Everyone,
It's been a long time since I've participated, so hopefully my viewpoints won't be too dated :-)
IOn the issue of OSGi, I would argue along the lines of Jim Moore - do it later when we find a pressing need that can't be solved without it, and work to cleanly modularize our codebase to ensure no cyclic dependencies etc.
To Kevin's question about the decision to not use DI for the core services (and to use a service locator pattern instead), the main reason that it came about was due to the massive amount of XML that would be required to inject the desired services into every object. Additionally, the number of dynamic objects that need access to platform services can be huge, and there was no good way to get the quickly wired in. You either had to resort to intermediate factories that could be DI'd and have the factories wire in the services (and that required extra interfaces on the created objects
to accept the injection), or invent some other similar scenario to get the services into the dynamic objects.
I'm still of the opinion that a service locator singleton (with a pluggable implementation) provides benefits and doesn't require the complexity of having to have a declarative model that knows about every single kind of object that might come into existence during the life of the application. But, I'm always ready to be educated out of any antiquated notions I may hold if someone can show me how the wiring of dynamic objects can be handled in a simple way (very little XML and minimal biolerplate).
Learning curve and the amount of XML you have to write in order to get your application running were two significant factors we faced with the adoption of Spring RCP. I personally feel that requiring new app developers to learn yet another complex piece of machinery (OSGi) in addition to all the rest of Spring Rich (which is significant by itself
) would not be beneficial to the project's uptake.
Just my $.02 worth - boy, I hate how the current economy makes my opinions worth less each month :-)
Thanks,
Larry.
Kevin Day wrote:
Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).
From my perspective, I don't think that OSGi is necessarily appropriate for a lot of GUI apps (although I do think it probably has more applicability than we might give it credit - even a simple music player could benefit greatly from a pluggable codec system). From my perspective, the *module* approach is the important thing. And if we are going to do modules, we might as well do something that is at least upwards compatible with OSGi. Certainly, the full OSGi functionality is not necessary for most apps - I actually a think a very small subset would be appropriate - and this sub-set could be run inside AND outside an OSGi container with a little bit of Spring DI magic.
Here's the basic premise: Because OSGi supports dynamic loading and unloading of modules, they have been forced to address the issue of dynamic dependency management. The core result is that modules do *not* interact directly with each other. Instead, they either locate other modules (using a service locator type pattern), or they have those modules injected (using the whiteboard pattern). Time has shown that the dynamic dependency injection pattern is more reliable, easier to test and results in more flexible systems (allowing modules to be dynamically loaded and unloaded without impacting the operation of the application). In dynamic environments, it also makes service consumers much, much simpler to write (there is almost no boilerplate code - this is all refactored up into the framework).
Most importantly, modularity forces better design practices overall. There are absolutely cases where functionality is so closely tied together that it will always reside in the same module - but I suspect that a lot of that sort of thing is occuring in the current code base because of the use of service locator type patterns instead of dependency injection (could be wrong on that, and I certainly don't want to step on any toes - but sometimes it's healthy to have an outsider question a design decision :-) ).
This actually raises an interesting question that I hope someone with a deeper history in the Spring-RCP project can answer: How did the original decision to depart from Spring IOC/DI come about in the RCP project? Was it b/c of objection of creating and maintaining tons of Spring xml files, or was there some other reason? I think that maybe by understanding this, we may learn many of the things that need to be considered as we have the current discussion. It's super easy to set back at the end of years of development and question design decisions that were made early on - and in doing so, it's easy to miss some extremely important detail that went into the decision.
- K
-------------------------------------------------------------------------
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 Springframework-rcp-dev@...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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktopversion
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I think I detect some mild sarcasm :-) I was under the impression that Desktop was an opportunity to take a fresh look at things. If this is intended to be an incremental update, please let me know. Cheerio - K
----------------------- Original Message -----------------------
Cc:
Date: Mon, 7 Jul 2008 17:56:06 +0100
Subject: Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion
Yes please, let's design modularity in from the start, even if it is
implemented fully now.
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
|
Re: [Spring Desktop] ideas for theDesktop version
On Friday 04 July 2008, Lieven Doclo escreveu:
> 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 :).
We are developing a suite of applications using spring rcp. They all have a
common core, but include a different set of spring beans, separated out into
different xml files. It is somewhat painful to deal with all this and I hope
that an osgi base might make it easier. Could certainly be wrong.
But we have applications that deal with a core set of common objects, but are
targeted for different users and which all have some additional specialized
beans. It would be nice to be able to handle all that gracefully and easily.
We have a LOT of spring bean defs, probably too many. And all of them can be
overwhelming.
-------------------------------------------------------------------------
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
Springframework-rcp-dev@...
https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev
|
