Remove the need to duplicate JS code

[pysailor]

This PR implements #10. Basically, all JS that should be compiled into the bundle needs to be defined via bower, not added locally. Potentially, the mechanism (see src/plone/patternslib/static/Makefile) needs to be enhanced still to compile CSS as well. I assign this to @thet as the most recent commiter for review.

[thet]

I'll review next week!

Without checking the changeset in detail, I can comment this beforehand:

• If we provide a precompiled bundle, then this addon is usable out of the box (which is already the case).
• If we do not provide each dependency, then this addon cannot be used in dev mode, where all JS dependencies are delivered individually.

I think we need to keep all bower managed dependencies. I don't see a duplication of code here.

[thet]

There was some discussion @ plone conf. IMO, we should keet as it is. The registry.xml files including all resources are very valuable in the usecase, when you want just depend on a subset of all patternslib patterns. That wouldn't be supported in the future otherwise. But maybe I missed some other discussion. What do you think @pysailor ?

[pysailor]

OK, I'll try to summarize our discussion we had at ploneconf:

• Our original use case was: plone.patternslib should enable Patternslib in Plone just by installing the package. Therefore, we ship with a compiled bundle, which gets registered on install.
• Additionally, any developer who wishes to work on the bundle would fetch the latest version of Patternslib + dependencies (via bower+npm, or out of convenience via the Make file). Once the work is done, a new version of the bundle is compiled and commited.

@thet, I think these are the additional use cases you have:

• An integrator might not always want to have the complete bundle of all Patterns, but only a subset. That makes it necessary to have the individual packages available separately.
• A developer might want to turn on the debug-mode for some JS files. For this we also need the code available in place.

Therefore the suggestion was to keep the current (unfortunate) duplication of code, i.e. the complete JS code of Patternslib/Patterns plus additional custom JS code that lives outside of Patternslib like pat-leaflet. That way, all the individual packages can still stay registered in the registry.cml

In this case, we need a good mechanism for quickly updating this duplicated code in case there are changes upstream (e.g. bugfix in some pattern). Here I think we agreed to use use bower+npm plus a Make file, so that there can be a command like make update or similar that will update the sources.

In any case, the compiled bundle will always be checked in and registered by default, since this the perceived use-case for the standard user.

@thet Is that about correct?

[thet]

yes, that's correct.