|
| Re: ModA changing ModB's module parameters [message #1296 is a reply to message #1248] |
Fri, 20 February 2009 21:23  |
 Bob Frankel
Messages: 12
Registered: July 2009 |
Junior Member |
|
|
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.02646 seconds
] 
Search
Help
Register
Login
Home
