GitHub user ahgittin opened a pull request:
https://github.com/apache/incubator-brooklyn/pull/704
clean up how locations are rendered in the js gui, and expand "delete"
there was (is) confusion between catalog name and location displayName and
a named location.
it deserves a major sort-out, i think treating location defs as catalog
items and location instances as entities;
and only using the catalog api, not a dedicated locations api (or if there
is, it delegates to catalog),
also removing all the LocationManager blah.
but until then we needed something which avoided confusion where catalog
item names for locations
aren't rendered, and magic display names from location-metadata were being
showed so it looked
like nothing was being added, though the location worked.
for locations, a catalog item name now does nothing, but the location's
name (i.e. human-readable ID aka catalog item ID, not the display name)
is shown in the catalog accordion list (the "IdentifierName"), better info
(but not the full yaml yet) is shown in the detail,
and versions are at least handled without bugs, even if only one version
for location is really supported in the gui.
also adds delete for entity and apps and policies, and fixes delete for
locations.
@nakomis this should help prevent the user-confusion which you experienced
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ahgittin/incubator-brooklyn jsgui-locations
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-brooklyn/pull/704.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #704
----
commit 91532f39a43bdf6c1d46210c599503c1166c2215
Author: Alex Heneveld <[email protected]>
Date: 2015-06-21T19:21:21Z
clean up how locations are rendered in the js gui, and expand "delete"
there was (is) confusion between catalog name and location displayName and
a named location.
it deserves a major sort-out, i think treating location defs as catalog
items and location instances as entities;
and only using the catalog api, not a dedicated locations api (or if there
is, it delegates to catalog),
also removing all the LocationManager blah.
but until then we needed something which avoided confusion where catalog
item names for locations
aren't rendered, and magic display names from location-metadata were being
showed so it looked
like nothing was being added, though the location worked.
for locations, a catalog item name now does nothing, but the location's
name (i.e. human-readable ID aka catalog item ID, not the display name)
is shown in the catalog accordion list (the "IdentifierName"), better info
(but not the full yaml yet) is shown in the detail,
and versions are at least handled without bugs, even if only one version
for location is really supported in the gui.
also adds delete for entity and apps and policies, and fixes delete for
locations.
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
