One thing to note in the latest commit on the PR is that I made some changes suggested by @neykov to always add the configuration from the entity as parameters, and also to *prepend* new parameters. That means that in the UI, the list of parameters will be sorted in the reverse order of entity hierarchy, with the parameters defined on the current entity first, then the entity it inherited from, and so on. This is the _inheritance_ hierarchy, of entity definitions in BOm files or via Java class and interface inheritance, not the structural parent-child relationships. I am not 100% convinced this is the best way, as it does fill up the UI with more parameters, but at least they are all visible and in a sensible order.
Perhaps we could add some further properties to SpecParameter that can be used as display hints? Andrew. On Tue, 26 Jul 2016 at 20:42 Andrew Kennedy < [email protected]> wrote: > - https://github.com/apache/brooklyn-server/pull/229 > > I have created this PR to fix an issue with the handling of > brooklyn.parameters in BOM files. We now merge config keys and maps, so it > is expected that an entity will have its configuration be the union of the > config of its ancestors, with the lowest level config taking priority. This > PR does the same for parameters - instead of replacing the entire set of > parameters when an entity is declared, we add the new parameters, > overwriting any that already exist and have the same config key. This means > an entity can alter defaults or descriptions for a key when it is defined, > and these will be used when retrieving config. > > One issue is that this now results in long lists of parameters in the UI, > and one must also be quite careful referencing config to make sure the > correct entity is in scope. Also, if an entity has some parameters defined, > they are only available to its descendants. If you wish to make them > visible in the application UI details, they must be re-declared there, and > again, care must be taken with coping when retrieving the config values. > > I think this PR is probably good enough to use as-is, but I'm interested > in any feedback and ideas for further changes and improvements that can be > implemented in a future PR. If nobody objects, i would like to merge this > in a few days? > > Thanks, > Andrew. > -- > > Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft > -- Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft
