"scott.stark(a)jboss.org" wrote :
| I see a view as a presentation option to the admin user. The purpose of the managed
project is to expose the managed properties/ops for tools. Presenting those to the admin
in a way they understand is the tools job. Even if we did provide hints for groupings, I
still see the tools wanting to display these in their specific ways and as components have
new managed features they will want to update their views.
There is no expectation that the UI of an admin console be dynamically rendered from
metadata delivered by the management api. It is the responsibility of a console and its
metadata to define how the data is ultimately presented. Support for versioning within a
console could handle changes to the underlying management metadata.
"adrian(a)jboss.org" wrote :
| But doesn't that defeat the whole purpose of the Managed project?
| The admin console could do everything, but expecting it to keep in step
| with changes is almost certainly a futile hope.
| Only if the admin console is able to react to new metadata (or old metadata
| for that matter) will the project have any hope of staying relevant.
| The task is equivalent in scope/work to updating the doco everytime
| somebody adds/changes configuration options.
| In practice, if it is done at all, it is usually late and then misleading for users
| of older versions.
Tests for the management view of a component should be included in the testsuite and run
as part of the build. The management view of a component should be considered as part of
its public API. If it changes in an incompatible way, then tests should fail and dependent
clients need to be updated.
View the original post :
Reply to the post :