{"action":"created","issue":{"url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/650","repository_url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf","labels_url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/650/labels{/name}","comments_url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/650/comments","events_url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/650/events","html_url":"https://github.com/fgpv-vpgf/fgpv-vpgf/issues/650","id":156537401,"number":650,"title":"Geo Module Refactoring","user":{"login":"alyec","id":7646414,"avatar_url":"https://avatars.githubusercontent.com/u/7646414?v=3","gravatar_id":"","url":"https://api.github.com/users/alyec","html_url":"https://github.com/alyec","followers_url":"https://api.github.com/users/alyec/followers","following_url":"https://api.github.com/users/alyec/following{/other_user}","gists_url":"https://api.github.com/users/alyec/gists{/gist_id}","starred_url":"https://api.github.com/users/alyec/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyec/subscriptions","organizations_url":"https://api.github.com/users/alyec/orgs","repos_url":"https://api.github.com/users/alyec/repos","events_url":"https://api.github.com/users/alyec/events{/privacy}","received_events_url":"https://api.github.com/users/alyec/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/labels/feedback:%20discussion","name":"feedback: discussion","color":"d4c5f9"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2016-05-24T15:26:33Z","updated_at":"2016-06-02T12:44:17Z","closed_at":null,"body":"# Refactoring of geo module's core services\r\n\r\nOur terminology at the moment is all over the place.  Part of the refactoring should involve naming things better.  `LegendItem`, `LegendEntry`, `LegendGroup`, `LegendPlaceHolder` will all be classes which fit into the legend.  `LegendItem` will be at the root of this hierarchy with the remaining classes.  `Layer`s are strictly map objects, `LayerRecord`s contain the layer map object + additional state.\r\n\r\n## Legend Entry Service\r\nThis service is mostly a container for an object hierarchy.  This can be converted to ES6 classes along with some refactoring as we add ES6 properties and inheritance.\r\n\r\n### LegendItem\r\nA base class of the legend subclassed into single \"entries\" and \"groups\" (contains all the UI related state for the display of layers)\r\n- options { opacity, visiblity, ... }\r\n- flags { outOfScale, userAdded, layerType, ... }\r\n- use ES6 props for options and flags\r\n- template enum[ entry, group, placeholder ]\r\n  - abstract, only set by child classes\r\n  - should drive the clickAction via the associated directive\r\n- getLayerRecord: null if no binding (e.g. structured legend)\r\n- name\r\n- legendId (formerly id -- want to keep it clear that it is split)\r\n- sortingGroupType enum[feature,raster]\r\n- getSortGroupIndex: convert the type enum to an int for CSS reference\r\n- remove: governed by options\r\n- sortable? add this if needed\r\n\r\n### LegendPlaceHolder(LegendItem)\r\nA placeholder's main purpose is to keep a reference while the layer is loading\r\n- all state should be derived from the bound layerRecord (e.g. error, loading ...)\r\n- should never exist in an unbound state\r\n- constructor should take a callback to generate the appropriate legendItem once the layer has finished loading\r\n  - callback format: () => return legendItem [entry,group]\r\n  - layerRecord must be in a loaded state\r\n\r\n### LegendEntry(LegendItem)\r\nA single line legend UI element\r\n- symbology {}\r\n\r\n### LegendGroup(LegendItem)\r\nA collapsible group of LegendItems (Groups or Single Entries)\r\n- add, remove (operates on all legendItem instances)\r\n- getItembyLegendId\r\n- walkItems\r\n- expanded (ES6 prop)\r\n- items (public read, add/remove write)\r\n\r\n### LegendEntryDynamic(LegendEntry)\r\n- parent\r\n- root\r\n\r\n### LegendGroupDynamic(LegendGroup)\r\n- parent\r\n- root\r\n- _subLayers\r\n- both parent and root can be null if it is the root element\r\n\r\n\r\n## Legend Service\r\n\r\nBinds layerRecords and legendItems together.  Currently only `auto legend` is implemented, these could become classes or just separate function sets within the same service.  This should probably be revisited when work starts on structured legends.\r\n\r\n- auto legend works by taking a layerRecord and generating a legendItem\r\n  - addLayer(layerRecord, index - position in legend) => legendPlaceHolder (for binding the callback)\r\n  - getLayerIndexAbove(mapObj): for layer positioning in index\r\n  - moveLayer(mapObj, id, pos): sync legend state to map state\r\n- structured legend works by magic\r\n\r\n## Layer Registry\r\n\r\nLayer registry tracks all layers created by the system.\r\n\r\n### LayerRecord\r\n- constructor should take a map reference\r\n- state\r\n- metadata (should be cached after first retrieval)\r\n- isOffScale: RO prop\r\n- maxScale, minScale: RO prop\r\n- updateScaleState: to be consumed by zoom event listeners in registry\r\n- removeLayer: called from legendEntry\r\n\r\n### FeatureRecord (LayerRecord)\r\n- featureCount: int\r\n\r\n### DynamicRecord (LayerRecord)\r\n- featureCount: { subLayerId => count }  subLayerId == featureIdx ???"},"comment":{"url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/comments/223280124","html_url":"https://github.com/fgpv-vpgf/fgpv-vpgf/issues/650#issuecomment-223280124","issue_url":"https://api.github.com/repos/fgpv-vpgf/fgpv-vpgf/issues/650","id":223280124,"user":{"login":"alyec","id":7646414,"avatar_url":"https://avatars.githubusercontent.com/u/7646414?v=3","gravatar_id":"","url":"https://api.github.com/users/alyec","html_url":"https://github.com/alyec","followers_url":"https://api.github.com/users/alyec/followers","following_url":"https://api.github.com/users/alyec/following{/other_user}","gists_url":"https://api.github.com/users/alyec/gists{/gist_id}","starred_url":"https://api.github.com/users/alyec/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alyec/subscriptions","organizations_url":"https://api.github.com/users/alyec/orgs","repos_url":"https://api.github.com/users/alyec/repos","events_url":"https://api.github.com/users/alyec/events{/privacy}","received_events_url":"https://api.github.com/users/alyec/received_events","type":"User","site_admin":false},"created_at":"2016-06-02T12:44:16Z","updated_at":"2016-06-02T12:44:16Z","body":"Based on the way `LayerRecord` and the rest of the hierarchy is shaping up we may be able to move all of it into geoApi.  It would be fairly easy to have the class proxy calls like setOpacity to the ESRI layer it contains.\r\n\r\nI think this change would be too jarring for the beta release but it might make sense to look at after that.  Legend would stay as is, since it governs the UI's layer hierarchy and controls but it could call those proxy functions on it's matched `LayerRecord` which would remove the need for legend to keep `_layerRef` at all."}}
{"actor":{"display_login":"alyec"}}