Message from discussion
Obtaining data-bind attributes after rendering for acceptance test lookups
Date: Fri, 27 Jul 2012 01:59:57 -0700 (PDT)
From: hlascel...@gmail.com
To: knockoutjs@googlegroups.com
Cc: hlascel...@gmail.com, hlascel...@gmail.com
Message-Id: <96b6fd32-0226-4e95-9a66-26ba3eb0b8f6@googlegroups.com>
In-Reply-To: <d5910a6e-0221-47c4-a6fe-202254739409@googlegroups.com>
References: <b9ef182c-29d1-4fe1-867f-00c3aa78f7ca@googlegroups.com>
<f7b59d60-2eab-4de1-953f-4ced812dc24d@googlegroups.com>
<d5910a6e-0221-47c4-a6fe-202254739409@googlegroups.com>
Subject: Re: Obtaining data-bind attributes after rendering for acceptance
test lookups
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_93_2780302.1343379597544"
------=_Part_93_2780302.1343379597544
Content-Type: multipart/alternative;
boundary="----=_Part_94_20776108.1343379597544"
------=_Part_94_20776108.1343379597544
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Thanks, yes you're right, we are... Still time to switch before we go live.
Is Knockout data-bind still the best bet, or is JSRender the way forward?
NB, Even if the unparsed attributes are still there, that's an improvement.
For Christmas, I would like the HTML nodes with string attributes already
populated in a manner of my choosing. So, in short, where is the killer
line in Knockout that says "taking this attribute string data-bind="value:
foo", get the foo object."
*Just before* that (or after, I'm not fussy), I would like a callback so I
can work on the data-bind string with access to the node.
Anyway, thanks for your help. I'll report back!
On Friday, 27 July 2012 03:06:02 UTC+1, rpn wrote:
>
> Are you using jQuery Templates or possibly another template engine?
> Otherwise, the "data-bind" attributes would be there in the markup.
>
> On Thursday, July 26, 2012 12:52:16 PM UTC-5, hlasc...@gmail.com wrote:
>>
>> Here is the method we use right now. It sets the "name" property based on
>> a "property_name" attribute we inject in our model by visiting it with
>> ko.mapping.
>>
>>
>> for (var key in ko.bindingHandlers) {
>> if (ko.bindingHandlers.hasOwnProperty(key)) {
>> var original_init = ko.bindingHandlers[key].init;
>> ko.bindingHandlers[key].init = function (element,
>> valueAccessor, allBindingsAccessor, viewModel, bindingContext) {
>> var v = valueAccessor();
>> if (ko.isObservable(v) && v.property_name){
>> $(element).attr('name', v.property_name);
>> original_init(element, valueAccessor,
>> allBindingsAccessor, viewModel, bindingContext);
>> }
>> };
>> }
>> }
>>
>>
>> On Thursday, 26 July 2012 18:32:34 UTC+1, hlasc...@gmail.com wrote:
>>>
>>> We love using knockout, but need a quick way to "find" elements onscreen
>>> using capybara.
>>>
>>> Knockout cleans up after itself so that the final rendered nodes have no
>>> data-bind attribute.
>>> Is there some way we can get it to (maybe only in test mode config) set
>>> attributes on the nodes based on parsed bindings?
>>>
>>> There are a million ways to skin this cat, but ultimately, given a page
>>> of several input boxes, it would be very handy
>>> to be able to lookup fields in capybara using data we have already
>>> supplied in the data-bind attribute.
>>>
>>> eg:
>>>
>>> <div data-bind="bindme: foo, options: bar">
>>>
>>> could render to
>>>
>>> <div data-bind-bindme="foo" data-bind-options="bar">
>>>
>>> For now I shimmed the value binding to do something similar, but it is
>>> hacky, and doesn't cover selects, checked, and any future bindings.
>>>
>>> NB! It is no good to me to add a real JS hash to the element nodes.
>>> Capybara works on a very "browser" level of interaction, so a real
>>> attribute is the best
>>> way forward.
>>>
>>> Cheers!
>>>
>>
------=_Part_94_20776108.1343379597544
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<div>Thanks, yes you're right, we are... Still time to switch before we go =
live. Is Knockout data-bind still the best bet, or is JSRender the way forw=
ard?</div><div><br></div><div>NB, Even if the unparsed attributes are still=
there, that's an improvement. For Christmas, I would like the HTML nodes w=
ith string attributes already populated in a manner of my choosing. So, in =
short, where is the killer line in Knockout that says "taking this attribut=
e string data-bind=3D"value: foo", get the foo object." </div><div><br=
></div><div>*Just before* that (or after, I'm not fussy), I would like a ca=
llback so I can work on the data-bind string with access to the node.</div>=
<div><br></div><div>Anyway, thanks for your help. I'll report back!<br><br>=
On Friday, 27 July 2012 03:06:02 UTC+1, rpn wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">Are you using jQuery Templates or possibly another tem=
plate engine? Otherwise, the "data-bind" attributes would be there in=
the markup.<br><br>On Thursday, July 26, 2012 12:52:16 PM UTC-5, <a>hlasc.=
....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Here is=
the method we use right now. It sets the "name" property based on a "prope=
rty_name" attribute we inject in our model by visiting it with ko.mapping.<=
br></div><div><br></div><div><div><br></div><div> for (var key=
in ko.bindingHandlers) {</div><div> if (ko.bind=
ingHandlers.<wbr>hasOwnProperty(key)) {</div><div> &nbs=
p; var original_init =3D ko.bindingHandlers[key].init;</div><=
div> ko.bindingHandlers[key].init =
=3D function (element, valueAccessor, allBindingsAccessor, viewModel, bindi=
ngContext) {</div><div> &nb=
sp; var v =3D valueAccessor();</div><div> =
if (ko.isObservable(v) && v.property_name){</=
div><div> &nb=
sp; $(element).attr('name', v.property_name);</div><div>  =
; original_init(element, v=
alueAccessor, allBindingsAccessor, viewModel, bindingContext);</div><div>&n=
bsp; }</div><div> &n=
bsp; };</div><div> }=
</div><div> }</div></div><div><br></div><br>On Thursday, 26 Ju=
ly 2012 18:32:34 UTC+1, <a>hlasc...@gmail.com</a> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">We love using knockout, but need a quick way to "fin=
d" elements onscreen using capybara.<div><br></div><div>Knockout cleans up =
after itself so that the final rendered nodes have no data-bind attribute.<=
/div><div>Is there some way we can get it to (maybe only in test mode confi=
g) set attributes on the nodes based on parsed bindings?</div><div><br></di=
v><div>There are a million ways to skin this cat, but ultimately, given a p=
age of several input boxes, it would be very handy</div><div>to be able to =
lookup fields in capybara using data we have already supplied in the data-b=
ind attribute.</div><div><br></div><div>eg:</div><div><br></div><div><di=
v data-bind=3D"bindme: foo, options: bar"></div><div><br></div><div>coul=
d render to</div><div><br></div><div><div data-bind-bindme=3D"foo" =
data-<wbr>bind-options=3D"bar"></div><div><div><br></div><div>For now I =
shimmed the value binding to do something similar, but it is hacky, and doe=
sn't cover selects, checked, and any future bindings.</div></div><div><br><=
/div><div>NB! It is no good to me to add a real JS hash to the element node=
s. Capybara works on a very "browser" level of interaction, so a real attri=
bute is the best</div><div>way forward.</div><div><br></div><div>Cheers!</d=
iv></blockquote></blockquote></blockquote></div>
------=_Part_94_20776108.1343379597544--
------=_Part_93_2780302.1343379597544--