[API Refactoring] Modify XWiki constructor
Hi, I'm trying to fix some unit tests and by doing so I'm working my way in the XWiki API. I have thousands of ideas to improve the design but honestly I don't know where to start from; it's a bit overwhelming ;-) We need to start somewhere, so we might as well start with the XWiki class constructor. ATM, the constructor is: public XWiki(String xwikicfgpath, XWikiContext context) public XWiki(String xwikicfgpath, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) public XWiki(InputStream is, XWikiContext context, XWikiEngineContext engine_context) The first parameter is used to pass a location of a config file. Actually this parameter is only used to create a XWikiConfig object. I believe we should delegate the creation of a XWikiConfig object to the XWikiConfig object itself so that our API can resist to change. Imagine that tomorrow I want to store a XWiki config in a database. Today the API would not cope with this because it's rigid and unflexible. It violates IOC. Here's my proposal for the XWiki class: - Deprecate the current constructors - add 2 new constructors: public XWiki(XWikiConfig config, XWikiContext context) public XWiki(XWikiConfig config, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) Thus the "user" must start by creating a XWikiConfig, then a XWikiContext, possibly an EngineContext and then only he can create a XWiki object. The idea is that the creation of a config should be left to the config object and NOT to the Wiki class (it's not its role). This leads to a better design. In addition to being more flexible this will allow for easier unit testing as we will not need a xwiki.cfg file anymore (it will still be used for functional testing though). Obviously the next step would be to transform XWikiConfig into an interface. What do you think? Thanks -Vincent _____________________________________________________________________________ D�couvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vid�os ! Cr�ez votre Yahoo! Mail sur http://fr.mail.yahoo.com
It makes sense.. So the following line xwiki = new XWiki("./xwiki.cfg", context, null, false); will become xwiki = new XWiki(new XWikiConfig("./xwiki.cfg"), context, null, false); As long is it is not adding too much coding it seems fine to me. Ludovic Vincent Massol a écrit :
Hi,
I'm trying to fix some unit tests and by doing so I'm working my way in the XWiki API. I have thousands of ideas to improve the design but honestly I don't know where to start from; it's a bit overwhelming ;-)
We need to start somewhere, so we might as well start with the XWiki class constructor. ATM, the constructor is:
public XWiki(String xwikicfgpath, XWikiContext context) public XWiki(String xwikicfgpath, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate) public XWiki(InputStream is, XWikiContext context, XWikiEngineContext engine_context)
The first parameter is used to pass a location of a config file. Actually this parameter is only used to create a XWikiConfig object.
I believe we should delegate the creation of a XWikiConfig object to the XWikiConfig object itself so that our API can resist to change. Imagine that tomorrow I want to store a XWiki config in a database. Today the API would not cope with this because it's rigid and unflexible. It violates IOC.
Here's my proposal for the XWiki class: - Deprecate the current constructors - add 2 new constructors:
public XWiki(XWikiConfig config, XWikiContext context) public XWiki(XWikiConfig config, XWikiContext context, XWikiEngineContext engine_context, boolean noupdate)
Thus the "user" must start by creating a XWikiConfig, then a XWikiContext, possibly an EngineContext and then only he can create a XWiki object. The idea is that the creation of a config should be left to the config object and NOT to the Wiki class (it's not its role).
This leads to a better design. In addition to being more flexible this will allow for easier unit testing as we will not need a xwiki.cfg file anymore (it will still be used for functional testing though).
Obviously the next step would be to transform XWikiConfig into an interface.
What do you think?
Thanks -Vincent
_____________________________________________________________________________ Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
participants (2)
-
Ludovic Dubost -
Vincent Massol