[OPEN-ILS-DEV] staff client prototype, feedback/1

[steven]

> Indeed, we will want to combine and minify the JS files.  I address this briefly in my dev log:
> 
> http://yeti.esilibrary.com/dev/pub/web-staff-log.html#_2013_12_16_js_minification
> 
> We can go all the way to a single, minified JS file if we want to take it that far.   

I saw the blog post and read it very quickly, but reading again I see
that, as an experiment, you minified all the js files and then linked
them together into one bundle, which can be sourced in a single <script>
tag.  I don't know whether this will scale, when for example, the
web-based client grows to encompass all existing workflows.  Also, some
workflows (eg, Acquisitions) are quite complex and they should be
designed to load in different sets of js files depending on the needs of
the user.

A more standard approach is to define the dependencies amongst the js
modules, and then let an optimization tool bundle first and then minify.
By defining the dependencies, the developer discovers a 'natural' way to
organize the software into modules; it may take several tries before a
'perfect' way is found. Also, we are not talking about the kind of
dependencies found in Angularjs, but something more general, as pointed
out by the author of the blog post.  Also, during development, one does
not want bundling nor minifying because it hinders debugging, so the
build process needs to switch between the modes without a lot of
ceremony.

I notice in the O'Reilly book on AngularJS (March 2013), Chapter 3,
Developing in AngularJS, ends with a subsection called 'Integrating
AngularJS with RequireJS', which is probably worth reviewing, although
I've not read it myself.

> Agreed that rearranging the OpenSRF JS libs to use function closures
> would be a good thing.  I'm not keen on requiring 3rd-party JS for
> OpenSRF, though, since it's a small bit of code and not everyone using
> OpenSRF JS will want to use Angular, etc., but I could be crazy.

Let me restate what I think the issue here is: The web-based staff
client will use legacy js libs that are also used in legacy web apps,
but you don't want to modify them, especially if that means adding 3rd
party js libs for the legacy web apps. I think the best thing to do is
to wrap the legacy js libs into closures so that they participate in
whatever module dependency mechanism that will be used in the new web
app. This means maintaining two versions of the legacy js libs, which I
don't think is a big issue.

> Thanks for reviewing the code, Steven!

I'm just starting the code review.  I'm going throught the code base and
will write an email as I see an issue or if I want to suggest something,
so the process is going to be somewhat slow and will be taken in small
steps.

-- 
steven <steven.chan at bc.libraries.coop>
bc libraries co-op/sitka