{"action":"created","issue":{"url":"https://api.github.com/repos/aurelia/templating-resources/issues/16","labels_url":"https://api.github.com/repos/aurelia/templating-resources/issues/16/labels{/name}","comments_url":"https://api.github.com/repos/aurelia/templating-resources/issues/16/comments","events_url":"https://api.github.com/repos/aurelia/templating-resources/issues/16/events","html_url":"https://github.com/aurelia/templating-resources/issues/16","id":57487538,"number":16,"title":"Support \"with\" binding similar to knockout","user":{"login":"jaimerivera","id":2261112,"avatar_url":"https://avatars.githubusercontent.com/u/2261112?v=3","gravatar_id":"","url":"https://api.github.com/users/jaimerivera","html_url":"https://github.com/jaimerivera","followers_url":"https://api.github.com/users/jaimerivera/followers","following_url":"https://api.github.com/users/jaimerivera/following{/other_user}","gists_url":"https://api.github.com/users/jaimerivera/gists{/gist_id}","starred_url":"https://api.github.com/users/jaimerivera/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jaimerivera/subscriptions","organizations_url":"https://api.github.com/users/jaimerivera/orgs","repos_url":"https://api.github.com/users/jaimerivera/repos","events_url":"https://api.github.com/users/jaimerivera/events{/privacy}","received_events_url":"https://api.github.com/users/jaimerivera/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/aurelia/templating-resources/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-02-12T16:57:52Z","updated_at":"2015-08-13T20:58:04Z","closed_at":null,"body":"In Durandal 2.0 it was possible to expose a view model as a property of a parent view model by using knockout's 'with' binding and state its view.  To aid in portability of existing Durandal apps and to support the particular use case this type of composing is needed.  In the example below \"dateRangeVM\" is the view model property.  By using the compose binding, a custom view could be specified.\r\n```\r\n<!--Date Range Selection-->\r\n<div class=\"form-group\" data-bind=\"with: dateRangeVM\">\r\n         <div data-bind=\"compose:{ view: 'dateRangeSelection'}\"></div>\r\n</div>\r\n```\r\n\r\nThere may be a better way to accomplish this in Aurelia with custom elements and behaviors.  The outer view model would need to still have access to the inner view model to query state and values."},"comment":{"url":"https://api.github.com/repos/aurelia/templating-resources/issues/comments/130843149","html_url":"https://github.com/aurelia/templating-resources/issues/16#issuecomment-130843149","issue_url":"https://api.github.com/repos/aurelia/templating-resources/issues/16","id":130843149,"user":{"login":"jods4","id":3832820,"avatar_url":"https://avatars.githubusercontent.com/u/3832820?v=3","gravatar_id":"","url":"https://api.github.com/users/jods4","html_url":"https://github.com/jods4","followers_url":"https://api.github.com/users/jods4/followers","following_url":"https://api.github.com/users/jods4/following{/other_user}","gists_url":"https://api.github.com/users/jods4/gists{/gist_id}","starred_url":"https://api.github.com/users/jods4/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jods4/subscriptions","organizations_url":"https://api.github.com/users/jods4/orgs","repos_url":"https://api.github.com/users/jods4/repos","events_url":"https://api.github.com/users/jods4/events{/privacy}","received_events_url":"https://api.github.com/users/jods4/received_events","type":"User","site_admin":false},"created_at":"2015-08-13T20:58:04Z","updated_at":"2015-08-13T20:58:04Z","body":"I was thinking about the `$parent` issue, which is a bit tricky.\r\nThe best solution -- and it would open up other scenarios -- would be for Aurelia bindings to support \"ambient\" properties / functions that are tied to the context but not directly on it.\r\n\r\nBut without that, there's another trick we could pull off. `$parent` could be added as a non-enumerable property. That way we modify the object in a hard to notice way. It could still break though:\r\n- if user code already depends on its own `$parent` property.\r\n- if user code uses `Object.getOwnPropertyNames()`. This is not common, though. Generic code that goes over properties (e.g. serialization) usually uses `for..in` or `Object.keys()`.\r\n\r\nI think that would be acceptable, maybe with a warning in the doc. In cases when those condition are unacceptable then `with` shouldn't be used (it's always possible to do without it after all)."}}