Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

re-organizing binding parameters #2

Open
mbest opened this issue Dec 17, 2011 · 0 comments
Open

re-organizing binding parameters #2

mbest opened this issue Dec 17, 2011 · 0 comments

Comments

@mbest
Copy link
Owner

mbest commented Dec 17, 2011

Each binding has a unique name, such as value and text. Bindings generally take a single parameter; for example: text: 'Hello'.

Some binding (options, foreach, template) often take multiple parameters. Currently there are two methods used to specify multiple parameters. 'options' uses multiple top-level bindings (options: list, optionsText: 'name', optionsValue: 'id'), but only 'options' has a binding handler. 'foreach' and 'template' use a sub-object (template: {name: 'me', data: mydata}), but can also be called with a single parameter (template: 'me').

Another class of bindings (css, style, attr, event) also take multiple parameters, but for a different reason. These current accept an object where the property name is the class, style, etc. to be bound to and the value is the dependency for that binding.

I propose that all independent bindings be specified at the top level. If a binding requires multiple parameters, these will specified using a sub object. In the case of bindings that require two parameters (key and value), we'll use a method of combining the binding type with the key, such as style.color: 'blue'

@ghost ghost assigned mbest Dec 17, 2011
mbest pushed a commit that referenced this issue Feb 2, 2012
…ew $parentContext variable

Benefit #1: Can reach custom properties on *all* ancestor contexts, and are not limited to those that haven't been overwritten
(e.g., if we had $index, would now be able to reach all ancestor $index values, not just the closest one)
Benefit #2: Allows discrimination between properties at the current level and properties at the parent level, which
is good because not all custom properties may make sense to inherit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant