>> ...>> 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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
