referencing array elements like LPP[0].price

[DrZim]

Not sure if it is us not understanding something, but when we render something like this:

value="{{link LPP[0].price}}"

where price is 0.99 for example, it shows "undefined". Other ones like

 value="{{link pbpsize}}"

in the same template at the same level link and display the value or "null" fine. A few days ago these were displaying well, so not sure if we did something bad or that the latest edition shows these values differently.

[DrZim]

It's giving an object name of "LPP[0].price" instead of "price", so it's probably referencing the link object differently. Line 282 maybe?

binding.value = convert(binding.data[binding.field], binding.converter, binding.data, elem);

The binding.field has "LPP[0].price". Would this reference binding.field.LPP[0].price or binding.field."LPP[0].price" like binding.field.apples (where the name includes the array reference and dot) ?

[DrZim]

maybe something like this? I am just glad I got this far LOL. binding.value = convert(eval('(binding.data.' + binding.field + ')'), binding.converter, binding.data, elem);

I tried to replicate your method, which is very nice: myObject[property][property][property]

[jamiemthomas]

This is actually a more complex scenario that I have not added support for yet. If you need to output the value in a read-only way, you can still use ${LPP[0].price}.

The {{link}} tag is specifically designed to both output and link the data to the element/attribute/input control, so it actually needs to set up a binding to the LPP array and to the price attribute on an LPP. This way, if the LPP array changes or the price on the first LPP changes, the binding will update. Additionally, this expression is evaluated explicitly, not through execution of the code itself (such as through eval), because the string representation of the expression must be parsed and interpreted such that a valid link can be established while walking the path from the source, $data, to the leaf, the price.

I think it is very important to support property paths like this. The key will be understanding the right set of constraints to place on the expression to ensure it can be parsed and linked effectively.

Again, thanks for the feedback. It may be time to start documenting some of the supported, and not supported, usages of declarative linking.

[DrZim]

I "emailed" your code that I modified, horribly committing the eval sin, however it does add and remove array elements correctly with check boxes. Your code is well written enough that an amateur like myself can hack it. :)

[DrZim]

My coworkers don't want to use my 'hacked" version. They are eagerly awaiting more thoughts on what to do to accommodate hierarchical references. Given time, I could rewrite it to use associative array notation, removing the evals, but the script is working very well. There was one part that had difficulties, which was a one off reference LPP[0].price, but I think that was me missing something small.

[jamiemthomas]

I apologize for being a bit out of touch... With a team of 25 I sometimes get pulled in unexpected directions... I should be able to work on this some tomorrow and work towards supporting what you are attempting to accomplish. Ultimately, I want to support both evaluating expressions containing property paths (including array indexers) as well as support binding to changes along these paths. This requires actually walking the path by parsing and incrementally evaluating the code, so it is a bit tricky, but doable.

Again, if you do not need linking (just one-time template binding) then you should be able to use the ${} syntax, which ultimately evaluates your literal expression during template rendering.

[DrZim]

Thanks for the update. We really appreciate all that you accomplish.