{"action":"created","issue":{"url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/660","labels_url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/660/labels{/name}","comments_url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/660/comments","events_url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/660/events","html_url":"https://github.com/tombatossals/angular-leaflet-directive/issues/660","id":63242098,"number":660,"title":"improvements","user":{"login":"nmccready","id":583593,"avatar_url":"https://avatars.githubusercontent.com/u/583593?v=3","gravatar_id":"","url":"https://api.github.com/users/nmccready","html_url":"https://github.com/nmccready","followers_url":"https://api.github.com/users/nmccready/followers","following_url":"https://api.github.com/users/nmccready/following{/other_user}","gists_url":"https://api.github.com/users/nmccready/gists{/gist_id}","starred_url":"https://api.github.com/users/nmccready/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nmccready/subscriptions","organizations_url":"https://api.github.com/users/nmccready/orgs","repos_url":"https://api.github.com/users/nmccready/repos","events_url":"https://api.github.com/users/nmccready/events{/privacy}","received_events_url":"https://api.github.com/users/nmccready/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-03-20T14:50:46Z","updated_at":"2015-03-20T15:12:07Z","closed_at":null,"body":"I am the main contributor to angular-google-maps and myself and my company are seriously considering leaflet and mapbox. Therefore we were hoping to use this directive and make improvements.\r\n\r\nMyself and the company (realtymaps) I work for are seriously considering contributing to this directive. However we wanted to run by some ideas before we begin working on them.\r\n\r\nMarkers:\r\n\r\nThe data structure accepted seems flat and we would like an easier more efficient way to remove and add data without having to check the specific layer name for each marker.\r\n\r\nThus, supporting the following structures alternatives proposed:\r\n\r\n* all nested with options (this would be default and this not backwards compat)\r\n```\r\nmarkers = \r\n    layer1:\r\n        options: {\r\n           color: '#fff',\r\n           icon: 'someUrl'\r\n        }\r\n        data: [] // or {} ie same root structure now but no need for internal layer option (unless slapped on at creation)\r\n    layer2:\r\n     //.. identical but different options and or data\r\n```\r\n\r\n*  Attributes checked in the markers directive markers-options and markers-nested\r\n\r\n```\r\n<leaflet markers-options=\"{ layer1: {color: '#fff', icon:'someUrl'}, layer2: {...}, ...}\"></leaflet> \r\n``` \r\nWhere markers-options evaulates the expression as an object, function .. whatever to get the options.\r\nWhich would yield the same data structure for markers now but setting the options for all markers according to their layer.\r\n\r\n```\r\n<leaflet markers-nested=\"true | or parsed expression\"  markers=\"someNestedMarkers\"></leaflet>\" \r\n``` \r\nWhere the the controller:\r\n```\r\nvar someNestedMarkers = {\r\n  layer1:{\r\n    1:{\r\n       lat: 45, lng:100\r\n     }, ....\r\n  },\r\n  bikes:{\r\n    1:{\r\n       lat: 45, lng:100\r\n     }\r\n  }\r\n}\r\n```\r\n\r\nThe above structure makes it much easier to remove the data from the correct layer without having to iterate through each marker to figure out what to delete and then what to add."},"comment":{"url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/comments/84039970","html_url":"https://github.com/tombatossals/angular-leaflet-directive/issues/660#issuecomment-84039970","issue_url":"https://api.github.com/repos/tombatossals/angular-leaflet-directive/issues/660","id":84039970,"user":{"login":"zacronos","id":3067460,"avatar_url":"https://avatars.githubusercontent.com/u/3067460?v=3","gravatar_id":"","url":"https://api.github.com/users/zacronos","html_url":"https://github.com/zacronos","followers_url":"https://api.github.com/users/zacronos/followers","following_url":"https://api.github.com/users/zacronos/following{/other_user}","gists_url":"https://api.github.com/users/zacronos/gists{/gist_id}","starred_url":"https://api.github.com/users/zacronos/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zacronos/subscriptions","organizations_url":"https://api.github.com/users/zacronos/orgs","repos_url":"https://api.github.com/users/zacronos/repos","events_url":"https://api.github.com/users/zacronos/events{/privacy}","received_events_url":"https://api.github.com/users/zacronos/received_events","type":"User","site_admin":false},"created_at":"2015-03-20T15:12:07Z","updated_at":"2015-03-20T15:12:07Z","body":"Hi folks, I work with @nmccready are RealtyMaps, so I would likely be contributing here as well if we switch from angular-google-maps to angular-leaflet-directive.  After some discussion with @nmccready, I have an alternative to the proposal above.\r\n\r\nThe following could be implemented as 2 separate features/PRs, and would be backward-compatible.  To be more clear, we are offering to do the work, but we don't want to put in the time if the PR will just be rejected, so we'd like to at least get approval for the general approach of the API enhancements before work begins on our end.\r\n\r\nFeature 1: per-layer marker defaults\r\n----------------\r\n\r\nA new directive, `markers-defaults`, would work basically as `marker-options` described above; it would be an object mapping layer names to options that should be applied by default for all markers on that layer.  If an option is defined in an given marker object as well as in the defaults for that layer, the marker object's value would override.\r\n\r\nThis would be a more convenient way of handling options for different types of markers.\r\n\r\nFeature 2: nested marker containers\r\n---------------\r\n\r\nRight now, markers can only be defined as a single container (`[]` or `{}`) of markers.  If markers come from more than 1 data source though, this requires manually merging the lists/maps of objects together for leaflet.\r\n\r\nInstead, a new directive could be added, `markers-nested=<true | false>`, which if true causes `markers` to be interpreted as a container of containers of markers.  This makes it easy for the application to add or remove multiple markers at a time, and wouldn't require much more than adding a nested loop to the existing leaflet code.\r\n\r\nFeature 2: alternative implementations\r\n----------------------\r\n\r\nOr, instead of a directive to turn this new behavior on, instead a new directive could have this behavior; perhaps `markers-multi` is always a container of container of markers, where `markers` is always just a container of markers.  In this case, it would probably be an error to use both `markers` and `markers-multi` in the same leaflet tag, however.\r\n\r\nOr, no new directive would be needed if we make this a breaking change to the API and always use the container of containers approach...  but I'm guessing you'll want to keep backward compatibility if possible, so I mention the idea here only for completeness.\r\n"}}