Burke, If an external tool desperately wishes to inspect a module's medaata, it would still do it through reflection since it can find the activator's class name in the config file and load it, though this would require a few more lines of code
Wyclif On Fri, Sep 9, 2011 at 4:50 PM, Darius Jazayeri <[email protected]>wrote: > As a developer although I initially liked being able to configure these > things in config.xml, I've come to dislike doing it that way, because it's > often not flexible enough, it doesn't deal with relationships between those > metadata, etc. > > So, I do think we should document that people can create metadata on module > startup via the activator. And I think we should provide some utility > classes for things like createGlobalPropertyIfNonExistent. > > I don't see any reason to stop supporting the creation of these metadata in > config.xml though. And since you can already create metadata through the > activator, I don't think it's safe to trust inspecting config.xml to see > what metadata the module creates. > > -Darius > > On Fri, Sep 9, 2011 at 1: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 >> > > ------------------------------ > 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]
