You can't, given that one can write code like this:
MyModuleActivator extends BaseModuleActivator {
public void afterStartup() {
if (Context.getAdministrationService().getGlobalProperty("foo") ==
null)) {
// create new GP
}
}
}
-Darius
On Fri, Sep 9, 2011 at 2:56 PM, Burke Mamlin <[email protected]>wrote:
> So we can't reliably know the privileges required/created by a module?
>
> -Burke
>
> 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
>>
>
> ------------------------------
> 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]
