launchpad-dev team mailing list archive

[Richard Harding <rick.harding@xxxxxxxxxxxxx>]

On Tue, 19 Jun 2012, j.c.sackett wrote:

> Hey all--
>
> I've been working through a number of javascript modules lately, and
> I've noticed we still have a bunch of "lazr" namespaced modules, but
> they all live in "lp/app". In some cases we have "lazr" modules that are
> then consumed by "lp.app" modules and only the "lp.app" objects are used
> anywhere else.
>
> Is there any reason we're keeping the "lazr" namespace around in our js?
> I know Ian and I migrated the external lazr stuff into the main tree at
> one of the Thunderdomes, and at the time we kept the "lazr" just to
> simplify the refactor. It looks like some work has been done since then,
> and I think maybe it's time to just kill this and integrate them fully
> in the "lp.app".
>
> Thoughts?
>

There's two parts to this.

1) I definitely think the stuff in lib/lp/app/javascript can just be
lp.app.xxx for the modules/etc. I don't think the lazr gives us anything at
this time except for new users trying to figure out what it means.

2) I have a dream! With the combo loader moving forward, and getting
standardized throughout the various apps we do, I have a dream of shared
modules much like the Yahoo Gallery. Where we'd have builds of modules that
go out and can be shared, updated, and documented together.

We've recently seen cribbing of modules (like the morph animation module)
into multiple apps. I had to update the API for one app, but it's just not
going to happen that I then push that back from where we cribbed the morph
module from. I could definitely see us re-puposing the lazr namespace as
something to share modules between. It'd be our version of the yahoo
'gallery-' prefix to modules that are not from Yahoo, but shared through
their gallery.

This means we'd be getting the doc strings in the code up to shape, real
use of the version strings, and much more work, but I really think it'd pay
off. I had a conversation with timrc in irc tonight about a tastiepie ->
Y.App code that would be a standard way to generate tastiepie api requests
from client side Y.Model objects. This is perfect stuff to be shared,
tested, and documented in once place for all apps to use.


--

Rick Harding

Launchpad Developer
https://launchpad.net/~rharding
@mitechie