[Opensource] Réf. : [Opensource] Future Design Pattern

[Raul DAVIDOVICH]

sounds great.. plus it reminds us a bit of good design practices ;-)

thanks

---------------------------------------------------
Raul Davidovich
Responsable Informatique
Cvitkovic & Associés Consultants

(33) 1 45 15 40 68
(33) 1 45 15 40 41 Fax
-------------------------------------------------------
http://www.caconcology.com


|---------+------------------------------->
|         |           Michael Rimov       |
|         |           <rimovm at centercomp.c|
|         |           om>                 |
|         |           Envoyé par :        |
|         |           opensource-admin at jco|
|         |           rporate.com         |
|         |                               |
|         |                               |
|         |           29/10/2002 05:12    |
|         |           Veuillez répondre à |
|         |           opensource          |
|         |                               |
|---------+------------------------------->
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                                  |
  |       Pour :    opensource at jcorporate.com                                                                                                        |
  |       cc :                                                                                                                                       |
  |       Objet :   [Opensource] Future Design Pattern                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|




Hey All,

I had an "aha!" moment today and wanted to pass it on. :)  A quick note on
a design pattern that for the 5.1 release you'll start to see
happening.  What we're going to be dealing with is configuration settings
and construction.  Here's the gist:

Current Methodology:

Each component is aware of ConfigManager.  Each component queries
ConfigManager or the setup table to load it's own settings.  So here's
ascii art for what I'm talking about:
             Component ---- getMyConfigSettings() ---> ConfigManager

Future Methodology:

Each component's settings will be defined in a bean-like manner, and the
factory that creates the component will SET the component's attributes, as
opposed to the component setting it's own attributes.  So it will look a
little more like so:

             Factory Object -- getConfigSettings() --> ConfigManager
            |
            |--- setComponentSettings() --> Component.

The reason I'm looking at doing this is so that we can provide a layer of
abstraction between the components and the component configurations.  This
way we can use pretty much any configuration system such as JMX, JNDI...
whatever we want, but the component won't care how the settings are stored,

it just wants it's settings set. And it will help us modularize Expresso
components without forcing a specific configuration underpinning like
exists now.

Ok, I'm done and going back in the cave. :)


       -Mike



_______________________________________________
Opensource mailing list
Opensource at jcorporate.com
http://mail.jcorporate.com/mailman/listinfo/opensource
Archives: http://mail.jcorporate.com/pipermail/opensource/