Deep propagation of config options

[zombeerose]

I have encountered on several occasions an extensive layering of components that have ancestors that need to be customized depending on the circumstances.

Here is a brief "realish" example of what I mean:
* Module is the main component and created by our MVC view.
* Module contains a child component called Designer.
* Designer contains a child component called DesignerWindow.
* DesignerWindow contains a child component called DesignerForm.
* DesignerForm has a plugin called InsertLink.
* InsertLink contains a child component called SearchWindow.
* SearchWindow contains a child component called SearchGrid.
* SearchGrid has a url config option that defaults to '/module/search'

The linear hierarchy is:
Module > Designer > DesignerWindow > DesignerForm > InsertLink > SearchWindow > SearchGrid.

Now if a similar hierarchy is ever reused by Module BB but the url in the SearchGrid needs to change, then that config needs to be defined and propagated down the entire tree! That type of problem has plagued me for quite some time. Most of my modules are not that deep (3 layers on average) but I have a situation with 7 layers as above that has me spinning.

Does anybody have a better option than this? How do the other big apps tackle this? Thanks everybody!

[azuroff]

Somewhere in the initComponent method of SearchGrid, do something like this:

this.findParentByType(<xtype of containing Module>).<url config property>

[zombeerose]

Hmmm...my colleague had a similar idea. I guess there are drawbacks to every approach but I was hoping to avoid the components having any knowledge of their ancestors.

Any other ideas or design approaches??

[zombeerose]

I was thinking more about your idea @azuroff and another drawback is the lack of readability of the code. If an option is only being used by a deeply nested child, the purpose is vague and the code is cryptic. Documentation becomes an absolute necessity.

I have actually encountered a similar issue with ExtJS grids in which a config option (e.g. trackMouseOver) in the grid is not actually used by the grid. The documentation does not mention this and without searching, you won't know that the view uses it.

At least with the propagation approach, you can follow the chain, however tedious it is.

Does anyone have an option C???

[azuroff]

If an option is only being used by a deeply nested child, the purpose is vague and the code is cryptic. Documentation becomes an absolute necessity.

You can alleviate that somewhat by choosing an appropriate name for the property - searchGridUrl vs. url. But even then, if each layer has even one or two properties that need to be tweaked each time, you'd still end up with a big config in your Module definition.

I'm not sure how else you would do it, though.

[zombeerose]

@azuroff Thx for the feedback. I appreciate it. Have you encountered this issue in your development before?

[azuroff]

Not that deep. I think the deepest nesting our current application has is 4 levels -

window -> panel -> child panel -> component

but even in that case there's no configuration that we need to push all the way down to the lowest component.

[zombeerose]

I appear to be out of options because I just encountered a flaw in the findParent strategy. A window does not have a parent (i.e. ownerCt). Therefore, the findParentByType will not be able to bubble up past the window.

Anybody else???