On Mon, Jan 30, 2012 at 2:39 PM, Ian Booth <ian.bo...@canonical.com> wrote: > 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. >
I'm sorry to jump in here mid-conversation, but the patterns outlined in the opening email are *not* patterns we should emulate. As a general rule, if you can't do Y.fire in one module and Y.on in another, that's a sign that things are poorly factored. We should not take to publishing global events unless something is truly a global object. *Maybe* a case could be made for the js client in this regard, but even YUI itself doesn't take this approach. If you use Y.Widget you end up with Y.Base and Y.Node for this very reason -- so that the "Y" in the context of widget knows about everything it needs to know about. So no, don't do: * global event publishing * YUI.Env as a global namespace This last is especially ugly. It defeats the whole point of the js sandbox when there's no need for it. How do we fix these issues then? Everything should live in a proper YUI module now. Any module that depends on functionality in another should be sure that dependent module is included via the "use" block. If something needs to be shared across modules, then that functionality should be broken out into its own module. I'm not able to offer more than this without digging deeper into the specifics of the failing code, but I am highly confident that we should avoid the two suggestions above at all costs. And apologies if I'm being too harsh here. I've had a grouchy Monday, and I'm just trying to make sure I'm clear that this is not a pattern we want to start in Launchpad. If we need to talk about design choices or about how to best refactor the spots causing us issues, then I can stay later one day this week to catch up with you, Ian, about it. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ _______________________________________________ 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
