Config map expressions annoyance

[schepurny]

I know that this originates from back in the IBM VisualAge days, but I would be very happy to see this problem "fixed". Please!

This is an issue that has greatly annoyed myself and my colleagues. In the config map browser, the config expressions are counter-intuitively treated as a detect, meaning that the first one true is the only set of required maps loaded and then the rest are ignored. Instead, many (all) of us believe that it should be a select (include all required maps that have a true expression).

This also creates enormous complexity when working in multiple platforms and environments. For example if you have 6 different criteria, then you would need to write up to 63 config expressions to cover every case instead of the 6 you would normally need otherwise! This is not a big stretch considering many of us work in multiple platforms (Win, Linux, AIX), with multiple deployment types, and multiple environments (Test, Production, Emulated, etc).

Another issue is that the behavior is based on the order that the expressions are listed, although there is no option to reorder the config expressions.

Not a very OO type of design overall in my opinion.

[Eric Clayberg]

I know that this originates from back in the IBM VisualAge days, but I would be very happy to see this problem "fixed". Please! This is an issue that has greatly annoyed myself and my colleagues. In the config map browser, the config expressions are counter-intuitively treated as a detect, meaning that the first one true is the only set of required maps loaded and then the rest are ignored. Instead, many (all) of us believe that it should be a select (include all required maps that have a true expression). This also creates enormous complexity when working in multiple platforms and environments. For example if you have 6 different criteria, then you would need to write up to 63 config expressions to cover every case instead of the 6 you would normally need otherwise! This is not a big stretch considering many of us work in multiple platforms (Win, Linux, AIX), with multiple deployment types, and multiple environments (Test, Production, Emulated, etc).

Realistically, the basic structure of ENVY is not going to be changed by us or anyone else.

That said, have you tried nested configs which provide a relatively simple solution to this?

You can see a discussion of the technique in my old Advanced VisualAge Development presentation (slides 69-71).

Another issue is that the behavior is based on the order that the expressions are listed, although there is no option to reorder the config expressions.

That could easily be fixed with a small browser enhancement.

Not a very OO type of design overall in my opinion.

That is true with respect to the first issue, but too much is already dependent on that behavior to ever change it.

[schepurny]

Realistically, the basic structure of ENVY is not going to be changed by us or anyone else.

That said, have you tried nested configs which provide a relatively simple solution to this?

I wouldn't consider this part of the basic structure of ENVY.. it's just a poor design of a relatively small aspect. I would just consider a change like this to be an amendment, and even the Constitution has had amendments.

I realize that I can use nested configs as a workaround, and we are doing this in many cases, however I prefer a fix to the underlying design flaw than a workaround. Nested configs are fine in alot of cases, but can impact productivity when you have many levels of config maps (as we do) and changing one class can lead to having to trace down and reversion several levels of config maps.

Another issue is that the behavior is based on the order that the expressions are listed, although there is no option to reorder the config expressions.

That could easily be fixed with a small browser enhancement.

That would be a decent addition to a future release!

[Eric Clayberg]

I wouldn't consider this part of the basic structure of ENVY.. it's just a poor design of a relatively small aspect.

I disagree. This is actually a pretty fundamental design issue that affects both config maps and app/subapp configs.

Changing from a detect to a select strategy would likely break every set of config expressions in every config map ever created up to this point.