launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

On Tue, Jan 31, 2012 at 7:05 AM, Richard Harding
<rick.harding@xxxxxxxxxxxxx> wrote:
> On Tue, 31 Jan 2012, Deryck Hodge wrote:
>
>> On Tue, Jan 31, 2012 at 6:29 AM, Richard Harding
>> <rick.harding@xxxxxxxxxxxxx> wrote:
>> > https://pastebin.canonical.com/59124/
>>
>> That's a nice pattern for this kind of problem, but just to be clear,
>> the call site could have been fixed without creating a new module, but
>> *just* including "lp.client" in the use modules, right?
>>
>> Cheers,
>> deryck
>
> yes, I'm sorry. I just assumed what Ian had didn't work and that the reason
> it didn't was because he had blind subscribe/publishers on both ends so I
> jumped right into the easiest way to bring them together without making
> them know too much of each other. You're right, in the example in the
> email it includes lp.client.
>
> I did find the case in the file I show in the diff "specifications-index.pt"
>  where the YUI block doesn't include lp.client. In reading Ian's email, it
> didn't sound like he wanted to specifically include lp.client since it
> wasn't doing lp.client specific code, but was more looking for a general
> event. That's why I didn't name it lp.client.event, but lp.cache.event
> since both ends are specifically looking to fire/watch for events around
> the lp.cache.
>
> --

So Rick and I worked on this all day.  Event listening works sometimes
and doesn't at other times, depending on how many YUI().use blocks are
involved.  We're really hitting core js architectural problems on
Launchpad the more we work on this.  I think the rabbit hole is too
deep to get all of this fixed before getting a working combo loader.
Launchpad has too many bolted on js-design patterns, many of which
compete with each other.

We should turn back the clock a bit and return to a single shared YUI
instance for Launchpad.  This will get Ian unblocked on landing stuff
and he can return to feature work.  We can move forward finishing the
work of deploying a working combo loader.  And then we should get some
consensus on what type of js architecture we want, before we continue
refactoring. Then we'll be refactoring toward a common goal, rather
than continuing to bolt on more and more ways of interacting with
stuff in js.

So Ian, let's chat about what this really means in voice today, if we
can get overlap time.

For the rest of you, thanks for enduring.  We can close this up now.
Look forward to more from us js handlers when we've thought through
better how to clean up all these competing patterns a bit.

Cheers,
deryck


-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/