I didn't suggest that everything should be moved out of the config.xml and get rid of it but rather making some to be fetched via the module activator which will still be defined in the config file.
Wyclif On Fri, Sep 9, 2011 at 4:07 PM, Burke Mamlin <[email protected]>wrote: > The benefit of config.xml is that it centralizes module configuration and > exposes the dependencies & configuration settings in a manner that's readily > accessible to others – e.g., the module service, the module repository, or > any other tool inspecting an omod. If these settings were applied > programmatically, it might allow module authors to avoid editing the XML > file, but it would obfuscate these settings to a process inspecting the > module without running it (e.g., inspecting the omod). > > -Burke > > On Fri, Sep 9, 2011 at 3:05 PM, Wyclif Luyima <[email protected]> wrote: > >> Hi >> >> Can't we have modules defining their Privileges and global properties via >> the module activator(The newer BaseModuleActivator) and we add methods like >> getPrivileges() and getGlobalPropeties(), we can even add more like getRoles >> to allow modules to define roles too. Off the top of my head, this has the >> benefits below: >> >> 1- The module developer only defines a single constant for the name or key >> /value mapping for each entry e.g the privileges would be name/description >> and he/she doesn't have to hardcode them again in the config.xml file as >> they are doing right now. >> 2- Makes registering of new components e.g roles easier by adding new >> methods to the base activator class >> 3- Makes the config.xml file shorter and reduces the logic for parsing it >> since there would be one entry point into the config.xml file's DOM to fetch >> all things defined in the activator >> 4- It also makes it easier to integrate some things via spring that we are >> currently doing in the module config file. >> >> I believe those who were around during the initial design and development >> of the module engine have reasons why it is the way it is, so please chime >> in. >> >> Wyclif >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
