launchpad-dev team mailing list archive

[Ian Booth <ian.booth@xxxxxxxxxxxxx>]

>> ...>> Ian, is this just because the events are fired and listened to off the Y
>> instance? Did you see if these events were fired with respect to a DOM
>> element do they still suffer the YUI() sandboxing issue?
> 
> I was too curious so I ran a series of tests. It didn't make sense or it
> seemed we'd always be running into this.
> 

We are :-(
Bug 923619 - our model change events are not being properly propagated.
I'm fixing this regression right now.

> So I've pasted a series of tests here:
> http://paste.mitechie.com/show/523/
> 
> Basically yep, you're right. Two independant YUI() blocks cannot talk
> across each other for events or the Y.XXX namespace.
> 
> The reason we don't typically hit this is that we don't tend to have these
> blocks talk to each other. They always include some modules of application
> code we write.
>

We do tend to have such blocks - see the above bug.


> The tests show that as soon as you move one half of the code into a YUI
> module and define something that the other block can add to it's use()
> list, things work. Their namespaces are brought together. Events work, the
> Y.xxx namespace is up to date, etc.
> 
> So now knowing that in order for two blocks of code to communicate events
> between each other, the key is to get the blocks into the same YUI() block.
> In this case, it would seem like adding lp.bugs.bugtask_index as a use() of
> the YUI() block in the form-picker-macros would allow the events to be
> fired and shared between setup_bugtask_table and the setup code in the TAL.
> 
> Does that make sense Ian?
>

It makes sense but I personally don't like it - it introduces
unnecessary coupling between YUI blocks and specifically in the case of
form-picker-macros, we would not be wanting to start having "external",
bespoke YUI modules referenced by a re-usable macro. Before you know it,
we'd have a bunch of spaghetti references connecting all of our YUI
blocks together. As we evolve our YUI use further, and get rid of the
Javascript embedded in TAL, I think this issue will become less prevalent.