My apologies; after checking the code it turns out that zip CAN take
an iterator as an argument (guess the docs need updating ...). It
turns out the problem is with both of our understanding of repeat (I
really should have looked at the code in the first place, but I was
lazy):
repeat: function (elem, /* optional */n) {
var m = MochiKit.Base;
if (typeof(n) == 'undefined') {
return {
repr: function () {
return "repeat(" + m.repr(elem) + ")";
},
toString: m.forwardCall("repr"),
next: function () {
return elem;
}
};
}
... and the rest doesn't matter, because in your example n IS
undefined. So as you can see, all repeat does is give you back an
object that has a method which, when called, returns the original
object you passed it in the first place. Why does this matter?
Consider the following:
>>> var a = zip(text, repeat(BR()));
>>> console.log(a);
[["This", br], ["is", br], ["a", br], ["test", br]]
>>> appendChildNodes("test2", a);
If you actually do that in Firebug, and try clicking on the brs,
you'll see something rather strange: all four BRs, when clicked on,
will take you to the same place in the DOM, and that place is the one
<br> that's actually inside test2, at the end. Which brings up the
question, why is there even one BR there anyway; if zip worked there
should be four, otherwise there should be none.
Imagine if you did this instead:
<div id="test1"/>
<div id="test2"/>
<div id="test3"/>
<script>
var a = P({}, "hi");function(x) { return [x, BR()];}
$("test1").appendChild(a);
$("test2").appendChild(a);
$("test3").appendChild(a);
</script>
Would you get this?
hi
hi
hi
Actually no, because there is only ever one P with the word "hi" in
it, and his name "a". So when you add "a" to test1, he's in test1.
Then you add him to test2; now he's no longer in test1. Add him to
test 3, and he's no longer in test2 or test1. No matter how many
times you append him to the DOM, there's only ever one "a", and you'll
only ever see one "hi" on the screen.
Now let's refactor your code a bit:
var a = BR();
var test2 = zip(text, repeat(a));
appendChildNodes("test1", test2);
And suddenly everything makes sense. All you're doing is sticking "a"
after each peice of text, but since "a" can only live in one place, he
keeps getting moved to the most recent append. The last append
happens to the last word, so the final resting place of "a" is at the
end of test2 (which is where, if you use firebug, you can see that the
one <br> ends up).
So what's the solution then? Make a new BR every time, like so:
var brAdder = function(x) { return [x, BR()]; }
appendChildNodes("test2", map(brAdder, text));
Hope that helps,
Jeremy
P.S. To be honest, the repeat function doesn't seem very useful to me,
unless you want to repeat a primitive; however, I noticed it used a
few times within other Mochikit functions, so I imagine it has a
purpose that isn't about making lots of references to the same
individual HTML element ;-)
On Apr 26, 4:59 pm, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> machineghost schrieb:
>
> >zip(text, list(repeat(BR(), text.length)));
> > [["This", br], ["is", br], ["a", br], ["test", br]]
>
> Right, this works, since you're using an array here. This is basically
> the same as my Test 1.
>
> Thanks for pointing out that zip should only be used with arrays, not
> with iterators. I did not expect that the docs for zip need to be taken
> so literally, and I'm still not sure that this is the problem. For
> instance, the following works as expected:
>
> zip(text, repeat("*"));
>
> And if you replace zip with izip (which *is* an Iter library function),
> the Test 2 does not work either. As I understand the difference between
> zip and izip is that izip returns an iterator instead of an array, but I
> would expect of an Iter lib function that it also takes iterators as
> input, and the documentation does not claim otherwise here.
>
> The following does not work, either:
>
> list(izip(text, repeat(BR()));
>
> So I'm still puzzled.
>
> > I think appendChildNodes handles flattening that mess for you, but if
> > not just use the function.
>
> Yes, as I already wrote, you don't need to flatten since this is done
> implicitly. My Test 1 works nicely, without flattening.
>
> -- Christoph
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
