Merge lp:~sidnei/lazr-js/combo-service into lp:lazr-js

- Implements a demo combo-service which is able to serve the contents of the 'build' directory (see examples/combo.html)
- Fix all examples to use pure loader goodness.

Hi Sidnei,

This looks good. If you have to, I think you could land it as-is, but I do have some comments about the branch:

• Nice formoverlay example in combo.html. It is very straight forward
• Why did some of the lazr module dependencies get updated?
• Do we need to include the css* module dependencies, or can they be inlined on the page? I worry about the two approaches confusing developers.
• test_extract_skinnable() and test_extract_skinnable_with_lazr_conventions() look like copy-n-paste code. Can the common parts be put into a parameterized method?
• Use Y.one() instead of Y.get()

I think we can define a global LAZR() function in lazr-meta to replace YUI(), but that can be saved for another branch.

Maris

On November 19, 2009, Māris Fogels wrote:
> I think we can define a global LAZR() function in lazr-meta to replace
> YUI(), but that can be saved for another branch.
>

I don't think that is particularly interesting since all applications will
need to merge in their own modules in the LAZR config. So why define a LAZR()
wrapper, when you'll need to define a LP(), U1(), LANDSCAPE() one?

--
Francis J. Lacoste
<email address hidden>

Thanks for the review.

- CSS modules: I've updated the examples to inline them.
- Module dependencies: Only overlay was changed, to make the dependencies more explicit, the other changes were about adding 'skinnable'.
- Tests: they look very similar, you have to look a bit closer to notice the difference yeah. :)
- Y.get(): I didn't introduce any new one. But it would be nice to do a once-over and clear them all.

FWIW, I don't think it's a good idea to define a global LAZR, since the plan to include lazr-meta.js other projects, each of which will have to define it's own YUI() instance.

On Thu, Nov 19, 2009 at 12:34 PM, Sidnei da Silva
<email address hidden> wrote:
> FWIW, I don't think it's a good idea to define a global LAZR, since the plan to include lazr-meta.js other projects, each of which will have to define it's own YUI() instance.

So, I was suggesting the global LAZR() YUI wrapper because there is
code in each example that constructs a LAZR_YUI_CONFIG, and then
passes that into a YUI() constructor. Instead of doing so, why not
combine the two steps into a project-specific LZR() convenience
function? The function would *not* be for use outside of lazr-js,
just for convenience inside. I can see every individual YUI project
going this route, wrapping the YUI constructor as their needs dictate.

Regarding including lazr-meta.js: we will have to see how it works in
practice. I assumed that lazr-meta was for the purpose of running the
lazr project for development and demonstration purposes. I did not
think other projects would ever import lazr-meta.

I am wary of the idea of combining meta-dependencies like this: at
most, you could pull in the YUI config object's "modules" section.
All of the other configuation settings should be left to the
individual project.