| ModA changing ModB's module parameters [message #1248] |
Fri, 20 February 2009 10:20  |
Eclipse User |
|
|
|
I have a question about one module changing another modules config
parameter. More explicitly, when it changes a front-end module that then
pushes its config parameter to a delegate. Are there any rules for this?
Lets take a look at an example
ModA uses ModB. ModA increments one of ModBs module wide config
parameter (e.g. maxRuntimeEntries)
ModB is the front end for different implementations (e.g. Bios impl.,
Linux impl, etc.). Lets call the delegate ModBDelegate.
I have ModB pushing its module config parameter to ModBDelegate in its
module$use.
ModB.Proxy.delegate$.maxRuntimeEntries = ModB.maxRuntimeEntries; // proxy
is ModBDelegate
The maxRuntimeEntries can be changed (e.g. set, incremented, decremented)
in the apps cfg file and that works fine. How can ModA change the
setting? There is no order guarantee, so it cannot do it in its
module$use (since ModB could have already pushed the setting to
ModBDelegate).
Should ModA be restricted to setting the module config parameter in
module$meta$init (or instance$meta$init)? Or should ModB change the way it
is pushing the parameter to the delegate? Or should the delegate pull it
from the front-end when it needs it (e.g. in ModBDelegates
module$static$init)?
Thanks,
Todd
|
|
|
| Re: ModA changing ModB's module parameters [message #1296 is a reply to message #1248] |
Fri, 20 February 2009 16:23  |
| Eclipse User |
|
|
|
i could be wrong, but if ModA truly *uses* ModB (and this static
relationship is captured in package requires statments), then we can
ensure that ModA's module$use will run be ModB's module$use....
Todd Mullanix wrote:
> I have a question about one module changing another modules config
> parameter. More explicitly, when it changes a front-end module that
> then pushes its config parameter to a delegate. Are there any rules for
> this?
>
> Let�s take a look at an example
>
> ModA uses ModB. ModA increments one of ModB�s module wide config
> parameter (e.g. maxRuntimeEntries)
> ModB is the front end for different implementations (e.g. Bios impl.,
> Linux impl, etc.). Let�s call the delegate ModBDelegate.
>
> I have ModB pushing its module config parameter to ModBDelegate in its
> module$use.
> ModB.Proxy.delegate$.maxRuntimeEntries = ModB.maxRuntimeEntries; //
> proxy is ModBDelegate
>
>
> The maxRuntimeEntries can be changed (e.g. set, incremented,
> decremented) in the app�s cfg file and that works fine. How can ModA
> change the setting? There is no order guarantee, so it cannot do it in
> it�s module$use (since ModB could have already pushed the setting to
> ModBDelegate).
>
> Should ModA be restricted to setting the module config parameter in
> module$meta$init (or instance$meta$init)? Or should ModB change the way
> it is pushing the parameter to the delegate? Or should the delegate pull
> it from the front-end when it needs it (e.g. in ModBDelegate�s
> module$static$init)?
>
> Thanks,
> Todd
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.05709 seconds
Home