Single input dependent on two properties #108

crimar opened this Issue Sep 6, 2012 · 4 comments


None yet
2 participants

crimar commented Sep 6, 2012

I have multiple cases where an end date is the sum of a start date and a duration and I would like to show that end date in a date picker. shows my current approach. The start date and the computed end date are both shown in date pickers (these seem to require a recent Chrome or Opera browser).

What I like is that the helper function makes the second date picker update when the first date picker changes the start date. The back-converter takes care of writing back the duration instead of the date. What seems odd is that I did not specify which of the two parameters to the helper to write back to and it seems to use the right one by chance.

Could you advice on how to do this reliably? Or will inputs always write back to the last parameter of any helper function?



BorisMoore commented Sep 7, 2012

The current behavior is to bind to the last parameter. (see this comment). However there are some changes coming in the next update with some new features which should help this kind of scenario a lot. The above behavior will be modified for the new design. So best to stay with what you have for now, and then see how the new features
work for you once I have committed them.

BorisMoore added a commit that referenced this issue Dec 3, 2012

Commit counter 22. Major update, including some BREAKING CHANGES. and…
… many

new features. More samples and documentation for new features will be added
incrementally in coming updates.

Unit tests have been added (and more to come...).

Detailed APIs modified for consistent arguments and consisten use of this
pointer, and for maximum extensibility. Context is now ctx for view context,
tagCtx for tag arguments and properties, and linkCtx for data linking contect.
See updated samples for usage...

Direct data-binding of tags now supported:
{^{foo ...}}, or {^{:someExpression}} will be data-bound without requiring
wrapper elements.

New JsViews Tag Controls feature, along with many improvements to custom
tags, Instantiation of tags as control instances... See tabs and tree control

Observable paths can now be 'deep' - by adding a ^ to the path. "a.b^c.d.e"
will now listen to change of b, of c, of d, and of e, rather than only listening
to leaf changes.

Computed observables - allowing specification of dependencies and optionally
an associated setter.

Support added for doing data-linking without initializing, using the syntax

Compiled templates restructured for easier debugging.

View object restructured for clarity.

View now has a type property, e.g. type="item"
Only "item" views have index properties, but to get the index from a nested
view use view.get("item").index.

nodes collection on a view is now a function, view.nodes().

Settings grouped onto a $.views.settings object.
View navigation features improved, with view.get(...) and $.view(elem, ...)
tagCtx object provides improved access to the args and properties of a tag

Adding resources (helpers, converters, tags, etc) to a template now supported
by passing parent template to API. e.g. $.tags({...}, parentTemplate).
Many improvements to custom tags, - used also as part of JsViews integration
for new JsViews Tag Controls. (Instantiation of tags as control instances).

Template inclusion now supported with simpler syntax {{for tmpl=.../))

Fixes (or at least relates too) issues #118, #113, #108, #107, #104, #100,
#88, #83, #80

BorisMoore commented Dec 3, 2012

This is now supported, in commit 22. But I have not yet added a sample, so leaving this open for now. (Meantime, you can take a look at the unit tests to get an idea of how it works.)


BorisMoore commented Dec 5, 2012

Further update on its way soon. For the moment the above jsfiddle is not fully working.

BorisMoore added a commit that referenced this issue Dec 10, 2012

Commit counter 23. Several fixes and improvements. Main changes as fo…

Fixes and improvements for 'Computed Observables' - (see #100, #102 and
#126) and added to a new samples folder: demos/features/observability to

Further development of new deep observability feature -
New API $.observable.observe() allows for observing deep paths, which can
include computed observables with declared dependencies. They also allow
a.b.c when a or b are null to render an empty string, and not throw. Just
set noerror=true.

Added a new sample features/observability/observing-paths.html which shows
deep observability, and how intermediate objects can be allowed to switch
between defined and undefined/null values, without throwing and while
continuing to observe. Addresses #108 and #83.

$.observable.observe is also a convenient replacement for
$(...).on("propertyChange", ...) and all the *_editable-data.html samples
have been modified to illustrate this usage:
$.observable.observe(app, "selectedItem", handler)

Modified demos/step-by-step/04_form-elements.html to show rendering a radio
button group using a {{for}} over a data array. Fix for #125, which is
illustrated in this sample.

Provided support for modifying Observable event names ("propertyChange",
"arrayChange") and "data-link" attribute name, in $.views.settings.

Fix for #124

BorisMoore commented Dec 10, 2012

There are some fixes and changes in commit 23 that address this. See samples here for using Computed Observables to do two-way binding with multiple dependencies. For example,
This approach gives you full control.

On your original question, <input data-link="first + ' ' + last" /> will now bind back to the first parameter by default. While you can't (yet) specify a different binding directly here, by using Computed Observables, you can...

@BorisMoore BorisMoore closed this Apr 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment