launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

On Mon, Jan 30, 2012 at 2:39 PM, Ian Booth <ian.booth@xxxxxxxxxxxxx> 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/