← Back to team overview

launchpad-dev team mailing list archive

Re: Do we need the lazr namespace in our javascript?

 

On 06/21/2012 10:11 AM, j.c.sackett wrote:
> On 06/20/2012 01:42 AM, Huw Wilkins wrote:
> 
>> When we pulled the external dependency into Launchpad we discussed that
>> YUI and yui-gallery should be considered our upstreams. I still think
>> this is a good idea, in that it would force us to write extensible,
>> clean, documented widgets and it will mean that we'll be properly
>> contributing back to the open source YUI community.

We intended lazr.js to be our UI library that could be be used by all UI
developers. We even dared to dream that as an early adopter of YUI3, our
widgets would be the premier UI library. We adopted the documentation
guidelines so that out work could be used by other communities. We were
naive. We did not know how to build proper YUI widgets.

/me is fixing the bug-tag widget that is not a widget.

> I remember that conversation and still think this is a good idea; having
> our own gallery-esque space didn't really work out--there's lots of
> reasons for that, but the net take away is rather than silo-ing our work
> if we want it shared we should share at the best level.
> 
> That said, before we move too far in the "shared code" conversation, I
> take it that there are no disagreements with removing the "lazr"
> namespace within the LP javascript?

There was a recent discussion to have a Canonical JS UI library. When
designers update the library, they update all Canonical sites. As an
organisation we want it. We do not know how to have such a library
because the principle users have conflicting design interests or
infrastructures that must interact with the library. lazr.js failed
because u1, landscape, and launchpad have divergent interests.

I image we will want to reuse our js code as we do more non-launchpad
projects. We probably want to reduce Lp line count by creating a project
that we control and package easily so that landing a feature does not
require painful orchestration of landing and deploying two branches
simultaneously. This would not be a lazr project. This would be
launchpad-js, or something to do with our new name [1].

I think most of the pain we had last year is that lazr.js had no concept
of stable and unstable components. The pickers are still under active
development. Maybe such code should not be in a separate library, or we
have a way to keep and use the unstable code in our tree when it is also
included in the external project.

[1] /me want the team renamed to the 137 Imperial Cloud Squadron, Easter
Division.
-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature


Follow ups

References