Menu
▾
▴
springframework-rcp-dev
|
From: Jonny W. <jwr...@gm...> - 2008-07-04 17:44:22
|
Lieven, I think the others have echoed my main reasons for wanting a modules/plugin system - separation of functionality and delivery of different functionality to different users is one of my main use cases. In terms of the actual framework, I can see where you're coming from as most of the time you'll use everything. However, maybe aspects that could be potentially replaced by another solution should be modularized? For example, the factories for creating pages and windows now have multiple implementations for basic and various docking solutions, but you only need one. I'm sure there's other aspects of the framework that could have drop in replacements. Jonny On Fri, Jul 4, 2008 at 5:03 AM, Lieven Doclo <lie...@ji...> wrote: > Thanks for the input. I'm starting to see the light... > > I understand why you would modularize your application and I can see a lot > of valid usecases in my daily work too. But you're talking on a > project/finished > product level (of which I already said is a great platform for OSGi > development). > I don't see a case for splitting up Spring Desktop's architectures into > separate > bundles... As I see it, most of your project's modules will use Spring RCP > as a whole anyways... That my main concern. I haven't seen a meaningful for > split-up of Spring Desktop yet (except for the Beans Binding framework, and > that's a JDK7 feature...). > > That's my main point, as I see it, I don't see us using the same amount of > split-up as Spring RCP 'just because we can'. The more I look at it, I'm > convinced we should merge some of the modules (as stated in my original > post). > OSGi or Spring DM enabling those merged modules, I'm all for that... That > way you can use OSGi or Spring DM on a project basis but you don't burden > framework developers with that... > > As I said, I do see modularizing applications as a good thing, but you > shouldn't > modularize your framework used to build those applications too much... > > I hope you guys get what I'm saying :). > > Kind regards, > > Lieven > > > > > Take for example a business administration application. You might for > > example have modules for CRM, HR, Finance, Reporting, MIS etc... > > > > You might also modularize the application delivery, separating say the > > basic windowing (SDI/MDI/Docking) from a common application stub and > > from the application specific components. > > > > An application might also be delivered in several forms for varying > > usage levels: guest, registered users, administrators etc... > > > > The rendering of the application might also vary with a rich/thick > > client in some instances and a thin client in others. > > > > You might have mixins or add-ons like client side caching or even > > off-line use support. > > > > I reckon there are lots of cases for modularizing the client and > > without support for this the reusability of components drops right > > off! Most enterprise clients may be built as an 'entire module' as you > > put it, but I would suggest that that is a major problem with how apps > > are typically built and it places too much responsibility on to the > > application developer. > > > > Luan > > > > 2008/7/4 Lieven Doclo <lie...@ji...>: > > > >> Hi guys, > >> > >> Been reading all the posts here and been comtemplating on OSGi. And > >> frankly, > >> as a business application developers, I really don't see the > >> additional benefit > >> of a modular system on a GUI level. Perhaps I'm thick, I don't know, > >> but > >> I really can't find a reason to provide a modular system on a GUI > >> framework > >> system. > >> Most application I come in contact with don't have a modular design > >> (actually, that's incorrect, but not in the modular sense we're > >> talking about here). Enterprise custom-built application don't need > >> plugin functionality (although it could be handy on a development > >> level, granted). They almost always see their thick-client gui as a > >> entire module (in the sense we're talking about here), which might be > >> split up in different modules (in the more traditional way, for > >> development purposes). > >> > >> Don't get me wrong, I do see OSGi as a good thing, but for clearly > >> defined concerns (dao, service, webservice, domain (although > >> disputable, who would want to take down a POJO layer...) and webstart > >> GUI as a single module)... Using OSGi for GUI just seems overkill, > >> could anyone give me an example on how he or she would split up his > >> GUI application, 'cause that would be great. > >> > >> Please enlighten me, let me see the OSGi light :). > >> > >> Kind regards, > >> > >> Lieven > >> > >>> -------------------------------------------------------------------- > >>> -- > >>> --- > >>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >>> Studies have shown that voting for your favorite open source > >>> project, > >>> along with a healthy diet, reduces your potential for chronic > >>> lameness > >>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > >>> _______________________________________________ > >>> Springframework-rcp-dev mailing list > >>> Spr...@li... > >>> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > >> --------------------------------------------------------------------- > >> ---- > >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > >> Studies have shown that voting for your favorite open source project, > >> along with a healthy diet, reduces your potential for chronic > >> lameness > >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > >> _______________________________________________ > >> Springframework-rcp-dev mailing list > >> Spr...@li... > >> https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > > ---------------------------------------------------------------------- > > --- > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |
|
From: Peter K. <pe...@ya...> - 2008-07-04 20:23:37
|
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. |
|
From: Lieven D. <lie...@ji...> - 2008-07-07 11:06:25
|
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 |
|
From: Rogan D. <li...@da...> - 2008-07-07 12:33:31
|
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 |
|
From: Kevin D. <ke...@tr...> - 2008-07-07 16:15:09
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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 :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Peter Karich <A href="mailto:pe...@ya..."><FONT color=#0000ff><pe...@ya...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Fri, 04 Jul 2008 22:22:50 +0200</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Hi Lieven,<BR><BR>like you, I think that almost all people will use springRC as one bundle.<BR>So it could be that no splitting is necessary (only the traditional way <BR>of jar bundles of course)<BR>But maybe I missed the point you are talking about.<BR>I don't know a lot of OSGi, but is it possible with this library to load <BR>plugins etc.? Like in Eclipse or NetBeans? (E.g. to update parts of your <BR>program or to offer additional features)<BR><BR>This would be great for SpringRC and then my vote will be pro OSGi ;-)<BR><BR>Regards,<BR>Peter.<BR><BR><BR>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at <A href="http://www.sourceforge.net/community/cca08"><FONT color=#0000ff>http://www.sourceforge.net/com
munity/cca08</FONT></A><BR>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR><A href="mailto:Spr...@li..."><FONT color=#0000ff>Spr...@li...</FONT></A><BR><A href="https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev"><FONT color=#0000ff>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev</FONT></A><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Larry S. <lst...@au...> - 2008-07-07 16:46:00
|
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 > |
|
From: Kevin D. <ke...@tr...> - 2008-07-07 17:29:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 07 Jul 2008 11:45:49 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><TT>Hi Everyone,<BR><BR>It's been a long time since I've participated, so hopefully my viewpoints won't be too dated :-)<BR><BR>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.<BR><BR>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.<BR><BR>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).<BR><BR>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.<BR><BR>Just my $.02 worth - boy, I hate how the current economy makes my opinions worth less each month :-)<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT>
<BLOCKQUOTE cite=mid:REY1UFNUTiZDVDs0Ji0+NTY1Nzg1NzE4@satchel type="cite">
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>Eclipse is entirely built on top of OSGi bundles (in fact, Eclipse's Equinox project is the baseline OSGi implementation).</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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).</DIV>
<DIV> </DIV>
<DIV>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 :-) ).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT></BLOCKQUOTE><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Luan O'C. <lua...@gm...> - 2008-07-07 16:56:07
|
Yes please, let's design modularity in from the start, even if it is implemented fully now. 2008/7/7 Kevin Day <ke...@tr...>: > 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 <pe...@ya...> > To: spr...@li... > 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 > 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 > > |
|
From: Kevin D. <ke...@tr...> - 2008-07-07 17:36:55
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.3268" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>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<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> "Luan O'Carroll" <A href="mailto:lua...@gm..."><FONT color=#0000ff><lua...@gm...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Mon, 7 Jul 2008 17:56:06 +0100</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for theDesktopversion</U></B></DIV>
<DIV> </DIV></DIV><FONT face=Tahoma size=2>
<DIV>Yes please, let's design modularity in from the start, even if it is<BR>implemented fully now.<BR><BR></DIV></FONT></BODY></HTML>
|
|
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 > |
|
From: Jim M. <moo...@gm...> - 2008-07-07 12:35:13
|
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 <Arn...@ar...> 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 > |
|
From: Thomas R. C. <tho...@gm...> - 2008-07-07 18:20:45
|
> > 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. Yes, the separate commands context has been the bane of my spring rcp programming. |
|
From: Thomas R. C. <tho...@gm...> - 2008-07-07 18:16:37
|
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. |
|
From: Thomas R. C. <tho...@gm...> - 2008-07-07 18:26:23
|
This all looks great!
On Tuesday 01 July 2008, Jim Moore escreveu:
> Heya, everyone. Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules. In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just
> makes sense -- especially for a desktop app. (In fact it's arguable that
> we should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger. The nature of
> logging and the logging libraries means there's no real benefit to doing
> so. Also, in general commons-logging is a bad thing (especially in
> multiple classloader environments), which is why slf4j exists, but you can
> write to the commons-logging API and use slf4j as the implementation.
> That's what the Spring does on the SpringSource Application Platform
> (S2AP), for example.
>
> I love the idea of new XML configuration. A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
> <property name="prefs">
> <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/> </property>
> </bean>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of
> the reference manual. I assume "user" scope would be defined based on a
> Spring Security SecurityContext and "system" would be a standard singleton?
> Having the custom XML element would nicely hide those details from the
> user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
> @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
> @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
> @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity. Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml) S2AP can provide the underlying
> support for that if we want. Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now. Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
> Senior Consultant, SpringSource
|
|
From: Peter De B. <pet...@gm...> - 2008-07-08 12:26:45
|
C
On Mon, Jul 7, 2008 at 8:26 PM, Thomas R. Corbin <tho...@gm...>
wrote:
> This all looks great!
>
> On Tuesday 01 July 2008, Jim Moore escreveu:
> > Heya, everyone. Sorry for jumping into this discussion late.
> >
> > I prefer Claudio's distinctions for breaking out the modules. In any
> case,
> > we need to make sure (like Spring) that there's never a circular
> dependency
> > between packages so that things can easily be broken apart later if
> needed.
> >
> > Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just
> > makes sense -- especially for a desktop app. (In fact it's arguable that
> > we should go to Java 6 given all the desktop improvements they made.)
> >
> > There's a reason no Spring example shows injecting a Logger. The nature
> of
> > logging and the logging libraries means there's no real benefit to doing
> > so. Also, in general commons-logging is a bad thing (especially in
> > multiple classloader environments), which is why slf4j exists, but you
> can
> > write to the commons-logging API and use slf4j as the implementation.
> > That's what the Spring does on the SpringSource Application Platform
> > (S2AP), for example.
> >
> > I love the idea of new XML configuration. A couple of comments on the
> > examples:
> >
> > <bean id="someBean" class="foobar">
> > <property name="prefs">
> > <desktop:prefs scope="user|system"
> > path="path/to/preferences/node"/> </property>
> > </bean>
> >
> > It's not clear from the example, but Spring already has support for the
> > scoping capability (via aop:scoped-proxy) as described in section 3.4 of
> > the reference manual. I assume "user" scope would be defined based on a
> > Spring Security SecurityContext and "system" would be a standard
> singleton?
> > Having the custom XML element would nicely hide those details from the
> > user.
> >
> > <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> > <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> > mdi:closable="true" mdi:resizable="false">
> > <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > <desktop:view id="yetAnotherView"
> > viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> > docking:draggable="true">
> > <property name="someService" ref="serviceId"/>
> > </desktop:view>
> >
> > In Spring 2.5 ADI style that might be done as
> >
> > <context:component-scan package="com.myco"/>
> >
> > @View
> > public class SomeView {
> > @Autowired SomeView(SomeService someService) {..}
> > }
> >
> > @View
> > @MdiConfiguration(closable=true, resizable=false)
> > public class OtherView {
> > @Autowired OtherView(SomeService someService) {..}
> > }
> >
> > @View
> > @DockingConfiguration(closable=false, draggable=false)
> > public class YetAnotherView {
> > @Autowired YetAnotherView(SomeService someService) {..}
> > }
> >
> >
> > Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> > but mostly for making it easier to do good modularity. Hot-swapping,
> > discovery, etc are all just nice side-effects of having better
> modularity.
> > Fortunately, because of Spring Dynamic Modules this can always be added
> > later, especially if we follow the SpringDM conventions. (eg,
> > /META-INF/spring/application-context.xml) S2AP can provide the
> underlying
> > support for that if we want. Otherwise we can keep OSGi use (but not
> OSGi
> > compliance) out for now. Having JSR-277 support (like WebStart and
> > Netbeans) would be awesome so people don't have to download 50 copies of
> > log4j and updates can happen faster/easier.
> >
> > -Jim Moore
> > Senior Consultant, SpringSource
>
>
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-08 12:40:25
|
2nd attempt: Can we reach a consensus here? I think we need to go as fast as possible, to keep the momentum going... 1. code organization: - core - application: window, dialogs, page, view, action, ... - binding: validation, binding, forms - resources 2. singleton/service locator: Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ... 3. osgi support First make sure we have something working, then see what we can do to improve? Again: I think we need to go fast, so we have something working as soon as possible. I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge! regards, Peter |
|
From: Rogan D. <ro...@da...> - 2008-07-08 13:04:48
|
Peter De Bruycker wrote: > 2nd attempt: > > Can we reach a consensus here? > I think we need to go as fast as possible, to keep the momentum going... > > 1. code organization: > > * core > * application: window, dialogs, page, view, action, ... > * binding: validation, binding, forms > * resources > This looks like a reasonable split to me. > I already started on work on the application infrastructure code > (window, page, pagecomponent, view, editor) that will allow for much > simpler (and less) xml, multiple view instances at the same time > (formerly known as editors) Is there some way of instructing the different views on which object to present? e.g. in Eclipse, you can have multiple instances of a Java code editor, each editing a different .java source file. How do you specify which file to edit? Regards, Rogan |
|
From: Peter De B. <pet...@gm...> - 2008-07-08 13:11:38
|
On Tue, Jul 8, 2008 at 3:04 PM, Rogan Dawes <ro...@da...> wrote: > Peter De Bruycker wrote: > > 2nd attempt: > > > > Can we reach a consensus here? > > I think we need to go as fast as possible, to keep the momentum going... > > > > 1. code organization: > > > > * core > > * application: window, dialogs, page, view, action, ... > > * binding: validation, binding, forms > > * resources > > > > This looks like a reasonable split to me. > > > I already started on work on the application infrastructure code > > (window, page, pagecomponent, view, editor) that will allow for much > > simpler (and less) xml, multiple view instances at the same time > > (formerly known as editors) > > Is there some way of instructing the different views on which object to > present? e.g. in Eclipse, you can have multiple instances of a Java code > editor, each editing a different .java source file. How do you specify > which file to edit? > to open a view, you do ApplicationPage.showView(String id). I created a new method ApplicationPage.showView(String id, Object input) the ApplicationPage checks if a view with the given id and input is already open. if not, it opens a new one, otherwise it shows the existing one the input is passed on to the View, so it can render itself using this object (the object can be anything, a file, a customer object, ...) > > Regards, > > 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 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |
|
From: Rogan D. <ro...@da...> - 2008-07-08 13:26:26
|
Peter De Bruycker wrote: > > Is there some way of instructing the different views on which object to > present? e.g. in Eclipse, you can have multiple instances of a Java code > editor, each editing a different .java source file. How do you specify > which file to edit? > > to open a view, you do ApplicationPage.showView(String id). > > I created a new method ApplicationPage.showView(String id, Object input) > the ApplicationPage checks if a view with the given id and input is > already open. if not, it opens a new one, otherwise it shows the > existing one > > the input is passed on to the View, so it can render itself using this > object (the object can be anything, a file, a customer object, ...) > Perfect. Thanks! Rogan |
|
From: Arne L. <Arn...@ar...> - 2008-07-08 18:09:47
|
Hi Peter, great that you started committing. I would prefer having having two more modules: 1. Separate an action module. Business modules may implement actions not needing to know about the application displaying it. 2. Move out the forms from the binding/validation module. The binding and validation stuff may be used without forms. Regards, Arne Peter De Bruycker schrieb: > 2nd attempt: > > Can we reach a consensus here? > I think we need to go as fast as possible, to keep the momentum going... > > 1. code organization: > > * core > * application: window, dialogs, page, view, action, ... > * binding: validation, binding, forms > * resources > > 2. singleton/service locator: > > Get rid of it by clever use of custom xml, component scanning + > autowiring, convention over configuration, simpler object structures, ... > > 3. osgi support > > First make sure we have something working, then see what we can do to > improve? > > > Again: I think we need to go fast, so we have something working as > soon as possible. > > > I already started on work on the application infrastructure code > (window, page, pagecomponent, view, editor) that will allow for much > simpler (and less) xml, multiple view instances at the same time > (formerly known as editors) and easier integration possibilities with > 3rd party component providers (i.e. Jide, SwingDocking, ...), and I > expect to be able to check them in this week. If you have > questions/remarks/suggestions on these parts of the framework, don't > hesitate to give me a nudge! > > > 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 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |
|
From: Larry S. <lst...@au...> - 2008-07-08 20:00:03
|
Peter De Bruycker wrote: > 2nd attempt: > > Can we reach a consensus here? > I think we need to go as fast as possible, to keep the momentum going... > > 1. code organization: > > * core > * application: window, dialogs, page, view, action, ... > * binding: validation, binding, forms > * resources > > 2. singleton/service locator: > > Get rid of it by clever use of custom xml, component scanning + > autowiring, convention over configuration, simpler object structures, ... I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects? > > 3. osgi support > > First make sure we have something working, then see what we can do to > improve? Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away? > > > Again: I think we need to go fast, so we have something working as > soon as possible. > > > I already started on work on the application infrastructure code > (window, page, pagecomponent, view, editor) that will allow for much > simpler (and less) xml, multiple view instances at the same time > (formerly known as editors) and easier integration possibilities with > 3rd party component providers (i.e. Jide, SwingDocking, ...), and I > expect to be able to check them in this week. If you have > questions/remarks/suggestions on these parts of the framework, don't > hesitate to give me a nudge! > > > regards, > Peter Good to see things getting ramped up! Thanks, Larry. |
|
From: Kevin D. <ke...@tr...> - 2008-07-08 20:48:02
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV> </DIV>
<DIV>Here's a simple example:</DIV>
<DIV> </DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource. So we provide a setter for rulesSource (and probably ditch the variable pass in the constructor). When a RulesValidator is created, it is registered with a ServiceRegistry. The ServiceRegistry sends notifications that a new RulesValidator has been registered.</DIV>
<DIV> </DIV>
<DIV>We also have a Configurator object that has been created that listends to the ServiceRegistry. When new objects are registered, it injects resources into them. So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource. For the generic case, a default RulesSource will get injected. If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Advantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>2. The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)</DIV>
<DIV>3. The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever). There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.</DIV>
<DIV> </DIV>
<DIV>If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).</DIV>
<DIV> </DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)</DIV>
<DIV>2. The service registry still needs to be made available (although I suspect that in most cases this can be factored out into Spring DI). If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup. If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV>Peter De Bruycker wrote:
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core
<LI>application: window, dialogs, page, view, action, ...
<LI>binding: validation, binding, forms
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Larry S. <lst...@au...> - 2008-07-08 21:24:02
|
In this approach haven't we just replaced the ServiceLocator with a ServiceRegistry - with all the same problems? Meaning that every object needs to "find" the ServiceRegistry, either by having it be a static singleton, or having declarative XML to DI it. This leads us right back to the earlier problems we had with the ServiceLocator. Or, have I misunderstood something in your proposal Kevin? Thanks, Larry. Kevin Day wrote: > How about we start with a concrete example of how the service locator > is currently used, and consider how it could be refactored? > > Here's a simple example: > > Currently RulesValidator has the ability to set a RulesSource object > in the constructor, or if none is specified, it uses > ApplicationServicesLocator to look up a RulesSource. > > > Another approach is to consider that we know that any given > RulesValidator is *always* going to need a RulesSource. So we provide > a setter for rulesSource (and probably ditch the variable pass in the > constructor). When a RulesValidator is created, it is registered with > a ServiceRegistry. The ServiceRegistry sends notifications that a new > RulesValidator has been registered. > > We also have a Configurator object that has been created that listends > to the ServiceRegistry. When new objects are registered, it injects > resources into them. So as the RulesValidator is registered, the > Configurator becomes aware of it, and injects the appropriate > RulesSource. For the generic case, a default RulesSource will get > injected. If a given RulesValidator needs a specific instance, the > Configurator can determine which one to provide using a number of > different strategies (xml, annotations, convention or any of a ton of > other ways of declaritively specifying this kind of thing). > > > Advantages of this approach: > > 1. The RulesValidator needs no knowledge of the ServiceRegistry - > that dependency is completely gone. > 2. The RulesSource needs no knowledge of the ServiceRegistry (Spring > DI should be able to take care of the registration as it creates the > RulesSource) > 3. The behavior of configuration of objects becomes factored out into > a separate entity (Configurator, or whatever). There is no longer any > self configuration, which keeps the RulesValidator and RulesSource clean. > > If the Configurator is in a separate 'module' (or we follow > appropriate design guidelines to ensure there isn't dependency creep), > it may be possible to have different implementations of the basic > configuration policy (i.e. one using xml files, one using annotations, > one 'by-convention', etc...). > > Disadvantages of this approach: > > 1. The service registry becomes more complicated (it has to support > registration, and possibly deregistration, event notifications) > 2. The service registry still needs to be made available (although I > suspect that in most cases this can be factored out into Spring DI). > If it does need to be made available, I believe that it should be done > by injection (at least at the module level) and not via static > lookup. If a module wants to store a copy of the service registry in > a static variable with global module scope, then so be it - but I > think the overall framework should not require this. > > > Comments? I think it may be worthwhile to take a look at a bunch of > cases like this and make sure that it really makes sense. > > - K > > ----------------------- *Original Message* ----------------------- > > *From:* Larry Streepy <lst...@au...> > <mailto:lst...@au...> > *To:* spr...@li... > <mailto:spr...@li...> > *Cc:* > *Date:* Tue, 08 Jul 2008 14:59:53 -0500 > *Subject: _Re: [Springframework-rcp-dev] [Spring Desktop] ideas for > the Desktop version_* > > Peter De Bruycker wrote: >> 2nd attempt: >> >> Can we reach a consensus here? >> I think we need to go as fast as possible, to keep the momentum going... >> >> 1. code organization: >> >> * core >> * application: window, dialogs, page, view, action, ... >> * binding: validation, binding, forms >> * resources >> >> 2. singleton/service locator: >> >> Get rid of it by clever use of custom xml, component scanning + >> autowiring, convention over configuration, simpler object structures, ... > > I'm still unclear on how we do this without an explosion of XML or > intermediate factories, lots of boilerplate (including additional > members on objects), or some other nasty artifact that makes the > platform difficult to use. Maybe I missed how this was to be done in > the earlier email exchange, or I'm just being dense. Could you please > elucidate how we get rid of the service locator and keep the solution > simple to implement even with dynamic objects? > >> >> 3. osgi support >> >> First make sure we have something working, then see what we can do to >> improve? > > Do you mean to get the basic modularity cleaned up first and then look > at OSGi, or do you mean get OSGi working right away? > >> >> >> Again: I think we need to go fast, so we have something working as >> soon as possible. >> >> >> I already started on work on the application infrastructure code >> (window, page, pagecomponent, view, editor) that will allow for much >> simpler (and less) xml, multiple view instances at the same time >> (formerly known as editors) and easier integration possibilities with >> 3rd party component providers (i.e. Jide, SwingDocking, ...), and I >> expect to be able to check them in this week. If you have >> questions/remarks/suggestions on these parts of the framework, don't >> hesitate to give me a nudge! >> >> >> regards, >> Peter > > Good to see things getting ramped up! > > Thanks, > Larry. > |
|
From: Kevin D. <ke...@tr...> - 2008-07-08 21:54:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content=text/html;charset=ISO-8859-1>
<META content="MSHTML 6.00.2900.3059" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff leftMargin=1 topMargin=1 rightMargin=1><FONT face=Arial size=2>
<DIV>I think that this approach exactly inverts the ServiceLocator approach.</DIV>
<DIV> </DIV>
<DIV>In the current RulesValidator, there is an explicit call to <FONT size=2>(RulesSource) ApplicationServicesLocator.services().getService(RulesSource.</FONT><B><FONT color=#7f0055 size=2>class</B></FONT><FONT size=2>);</FONT><BR></DIV>
<DIV>this call is the root of the dependency issue under discussion.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>By inverting the problem, we can remove references to the static ApplicationServicesLocator.services() method entirely. Instead, the configuration of the object is factored out, and is triggered on registration of the object with the service registry. This last point (configuration occurs on registration) is actually pretty important because it drives the direction that dependencies are created. Instead of registring object foo with service A, we allow A to be notified when objects of type Foo become available. Service A (or preferably a handler such as Spring DM) then registers the object with the service. This enforces decoupling between objects and the services that operate on them. (Ironically, the 'ServiceRegistry' isn't really a registry of services at all - it's a registry of objects that services may want to operate on. In most cases, the service itself will never be registered with the registry). Perhaps some
renaming is called for...</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Anyway, the result of this in the current refactored example is that we are not injecting the ApplicationServicesLocator object into the RulesValidator. We are injecting the dependency that RulesValidator actually needs (RulesSource). At a functional level, RulesValidator should not need to know about ApplicationServicesLocator to properly function.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Objects themselves are very rarely, if ever, actually aware of the service registry. The framework itself does most (if not all) of that interaction on the object's behalf. The difference is subtle, but it completely unravels the dependency issue and makes modular development possible (as well as dynamic loading/unloading and all of the interesting stuff that comes with this kind of decoupling).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>- K</DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..."><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..."><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Tue, 08 Jul 2008 16:23:52 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV><TT>In this approach haven't we just replaced the ServiceLocator with a ServiceRegistry - with all the same problems? Meaning that every object needs to "find" the ServiceRegistry, either by having it be a static singleton, or having declarative XML to DI it. This leads us right back to the earlier problems we had with the ServiceLocator. Or, have I misunderstood something in your proposal Kevin?<BR><BR>Thanks,<BR>Larry.<BR><BR>Kevin Day wrote:</TT>
<BLOCKQUOTE cite=mid:REY4UlhWUyksKyY9Ji0+NjY4NTYwMjUw@satchel type="cite">
<META content="MSHTML 6.00.2900.3059" name=GENERATOR><FONT face=Arial size=2>
<DIV>How about we start with a concrete example of how the service locator is currently used, and consider how it could be refactored?</DIV>
<DIV> </DIV>
<DIV>Here's a simple example:</DIV>
<DIV> </DIV>
<DIV>Currently RulesValidator has the ability to set a RulesSource object in the constructor, or if none is specified, it uses <FONT size=2>ApplicationServicesLocator to look up a RulesSource.</FONT></DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Another approach is to consider that we know that any given RulesValidator is *always* going to need a RulesSource. So we provide a setter for rulesSource (and probably ditch the variable pass in the constructor). When a RulesValidator is created, it is registered with a ServiceRegistry. The ServiceRegistry sends notifications that a new RulesValidator has been registered.</DIV>
<DIV> </DIV>
<DIV>We also have a Configurator object that has been created that listends to the ServiceRegistry. When new objects are registered, it injects resources into them. So as the RulesValidator is registered, the Configurator becomes aware of it, and injects the appropriate RulesSource. For the generic case, a default RulesSource will get injected. If a given RulesValidator needs a specific instance, the Configurator can determine which one to provide using a number of different strategies (xml, annotations, convention or any of a ton of other ways of declaritively specifying this kind of thing).</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Advantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The RulesValidator needs no knowledge of the ServiceRegistry - that dependency is completely gone.</DIV>
<DIV>2. The RulesSource needs no knowledge of the ServiceRegistry (Spring DI should be able to take care of the registration as it creates the RulesSource)</DIV>
<DIV>3. The behavior of configuration of objects becomes factored out into a separate entity (Configurator, or whatever). There is no longer any self configuration, which keeps the RulesValidator and RulesSource clean.</DIV>
<DIV> </DIV>
<DIV>If the Configurator is in a separate 'module' (or we follow appropriate design guidelines to ensure there isn't dependency creep), it may be possible to have different implementations of the basic configuration policy (i.e. one using xml files, one using annotations, one 'by-convention', etc...).</DIV>
<DIV> </DIV>
<DIV>Disadvantages of this approach:</DIV>
<DIV> </DIV>
<DIV>1. The service registry becomes more complicated (it has to support registration, and possibly deregistration, event notifications)</DIV>
<DIV>2. The service registry still needs to be made available (although I suspect that in most cases this can be factored out into Spring DI). If it does need to be made available, I believe that it should be done by injection (at least at the module level) and not via static lookup. If a module wants to store a copy of the service registry in a static variable with global module scope, then so be it - but I think the overall framework should not require this.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>Comments? I think it may be worthwhile to take a look at a bunch of cases like this and make sure that it really makes sense.</DIV>
<DIV> </DIV>
<DIV>- K<BR></DIV>
<DIV> </DIV></FONT>
<DIV style="FONT-SIZE: x-small; FONT-FAMILY: Tahoma">
<DIV>----------------------- <B>Original Message</B> -----------------------</DIV>
<DIV> </DIV>
<DIV><B>From:</B> Larry Streepy <A href="mailto:lst...@au..." moz-do-not-send="true"><FONT color=#0000ff><lst...@au...></FONT></A></DIV>
<DIV><B>To:</B> <A href="mailto:spr...@li..." moz-do-not-send="true"><FONT color=#0000ff>spr...@li...</FONT></A></DIV>
<DIV><B>Cc:</B> </DIV>
<DIV><B>Date:</B> Tue, 08 Jul 2008 14:59:53 -0500</DIV>
<DIV><B>Subject: <U>Re: [Springframework-rcp-dev] [Spring Desktop] ideas for the Desktop version</U></B></DIV>
<DIV> </DIV></DIV>Peter De Bruycker wrote:
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite">2nd attempt:<BR><BR>Can we reach a consensus here?<BR>I think we need to go as fast as possible, to keep the momentum going...<BR><BR>1. code organization:<BR>
<UL>
<LI>core
<LI>application: window, dialogs, page, view, action, ...
<LI>binding: validation, binding, forms
<LI>resources </LI></UL>2. singleton/service locator:<BR><BR>Get rid of it by clever use of custom xml, component scanning + autowiring, convention over configuration, simpler object structures, ...<BR></BLOCKQUOTE><BR>I'm still unclear on how we do this without an explosion of XML or intermediate factories, lots of boilerplate (including additional members on objects), or some other nasty artifact that makes the platform difficult to use. Maybe I missed how this was to be done in the earlier email exchange, or I'm just being dense. Could you please elucidate how we get rid of the service locator and keep the solution simple to implement even with dynamic objects?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR>3. osgi support<BR><BR>First make sure we have something working, then see what we can do to improve?<BR></BLOCKQUOTE><BR>Do you mean to get the basic modularity cleaned up first and then look at OSGi, or do you mean get OSGi working right away?<BR><BR>
<BLOCKQUOTE cite=mid:6f9...@ma... type="cite"><BR><BR>Again: I think we need to go fast, so we have something working as soon as possible.<BR><BR><BR>I already started on work on the application infrastructure code (window, page, pagecomponent, view, editor) that will allow for much simpler (and less) xml, multiple view instances at the same time (formerly known as editors) and easier integration possibilities with 3rd party component providers (i.e. Jide, SwingDocking, ...), and I expect to be able to check them in this week. If you have questions/remarks/suggestions on these parts of the framework, don't hesitate to give me a nudge!<BR><BR><BR>regards,<BR>Peter<BR></BLOCKQUOTE><BR>Good to see things getting ramped up!<BR><BR>Thanks,<BR>Larry.<BR><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
</BLOCKQUOTE><BR>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>-------------------------------------------------------------------------<BR>Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!<BR>Studies have shown that voting for your favorite open source project,<BR>along with a healthy diet, reduces your potential for chronic lameness<BR>and boredom. Vote Now at http://www.sourceforge.net/community/cca08<BR><BR></DIV></FONT>
<STYLE type=text/css> P, UL, OL, DL, DIR, MENU, PRE { margin: 0 auto;}</STYLE>
<FONT face=Tahoma size=2>
<DIV>_______________________________________________<BR>Springframework-rcp-dev mailing list<BR>Spr...@li...<BR>https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev<BR><BR><BR></DIV></FONT></BODY></HTML>
|
|
From: Peter De B. <pet...@gm...> - 2008-07-02 05:27:47
|
How will we continue from now on? Who will create the projects? The way
things are looking, I'm able to spend more time on spring desktop.
On Wed, Jul 2, 2008 at 5:20 AM, Jim Moore <moo...@gm...> wrote:
> Heya, everyone. Sorry for jumping into this discussion late.
>
> I prefer Claudio's distinctions for breaking out the modules. In any case,
> we need to make sure (like Spring) that there's never a circular dependency
> between packages so that things can easily be broken apart later if needed.
>
> Spring 3.0 will also be dropping JDK1.4 support. Going to Java 5 just
> makes sense -- especially for a desktop app. (In fact it's arguable that we
> should go to Java 6 given all the desktop improvements they made.)
>
> There's a reason no Spring example shows injecting a Logger. The nature of
> logging and the logging libraries means there's no real benefit to doing
> so. Also, in general commons-logging is a bad thing (especially in multiple
> classloader environments), which is why slf4j exists, but you can write to
> the commons-logging API and use slf4j as the implementation. That's what
> the Spring does on the SpringSource Application Platform (S2AP), for
> example.
>
> I love the idea of new XML configuration. A couple of comments on the
> examples:
>
> <bean id="someBean" class="foobar">
> <property name="prefs">
> <desktop:prefs scope="user|system"
> path="path/to/preferences/node"/>
> </property>
> </bean>
>
> It's not clear from the example, but Spring already has support for the
> scoping capability (via aop:scoped-proxy) as described in section 3.4 of the
> reference manual. I assume "user" scope would be defined based on a Spring
> Security SecurityContext and "system" would be a standard singleton? Having
> the custom XML element would nicely hide those details from the user.
>
> <desktop:view id="someView" viewClass="com.acme.foo.bar.SomeView">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="otherView" viewClass="com.acme.foo.bar.OtherView"
> mdi:closable="true" mdi:resizable="false">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> <desktop:view id="yetAnotherView"
> viewClass="com.acme.foo.bar.YetAnotherView" docking:closable="false"
> docking:draggable="true">
> <property name="someService" ref="serviceId"/>
> </desktop:view>
>
> In Spring 2.5 ADI style that might be done as
>
> <context:component-scan package="com.myco"/>
>
> @View
> public class SomeView {
> @Autowired SomeView(SomeService someService) {..}
> }
>
> @View
> @MdiConfiguration(closable=true, resizable=false)
> public class OtherView {
> @Autowired OtherView(SomeService someService) {..}
> }
>
> @View
> @DockingConfiguration(closable=false, draggable=false)
> public class YetAnotherView {
> @Autowired YetAnotherView(SomeService someService) {..}
> }
>
>
> Modular plugin support is partly for plugins (a-la Eclipse or Netbeans),
> but mostly for making it easier to do good modularity. Hot-swapping,
> discovery, etc are all just nice side-effects of having better modularity.
> Fortunately, because of Spring Dynamic Modules this can always be added
> later, especially if we follow the SpringDM conventions. (eg,
> /META-INF/spring/application-context.xml) S2AP can provide the underlying
> support for that if we want. Otherwise we can keep OSGi use (but not OSGi
> compliance) out for now. Having JSR-277 support (like WebStart and
> Netbeans) would be awesome so people don't have to download 50 copies of
> log4j and updates can happen faster/easier.
>
> -Jim Moore
> Senior Consultant, SpringSource
>
>
> -------------------------------------------------------------------------
> 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
>
>
|
Thanks for helping keep SourceForge clean.
X