For the full technical rundown, see also
http://docs.angularjs.org/api/ng.$q[Angular $q Docs].
-2013-12-06 Template Cornucopia
-------------------------------
+2013-12-06 Template Cornucopia and Dynamic Strings Experiment
+-------------------------------------------------------------
Using Angular on top of Template Toolkit gives us lots of options for
managing templates. TT lets us INCLUDE (etc.) shared templates on the
~~~~~~~~~~~~~~~~~~~~~~~
Angular templates, regardless of origin, must be represented as
-separate, addressable chunk. To give an inline chunk of HTML an
-"address", it can be inserted into a <script> block like so:
+addressable chunks. To give an inline chunk of HTML an "address", it
+can be inserted into a <script> block like so:
[source,html]
-----------------------------------------------------------------------------
fetched from the server as needed.
To change the inline template example above into a lazy-loaded template,
-move the template to it's own web-accessible file:
+drop the <script> tags and move the template to it's own web-accessible
+file:
[source,html]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Then load the file using the URL as the ID.
-
[source,js]
-----------------------------------------------------------------------------
$modal.open({
});
-----------------------------------------------------------------------------
-Angular Directives / Embedded Templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The template file is not fetched from the server until the first time
+it's used. After that, it's cached by the browser.
+
+Angular Dialog Services w/ Dynamic Strings
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the examples above, each type of template is context-specific. In other
+words, there is a template file specific to uncataloged item checkin.
+Context-specific templates have their place, but we also need
+a way to present generic alerts and confirmation dialogs, because
+a) we may not always be aware of the type of message
+we want to display ahead of time and b) if we always use context-specific
+dialogs, the number of templates will grow and grow, even though 95% of
+each template is boilerplate dialog rendering HTML -- the only thing unique
+about each will be the message and how the user actions are handled.
+
+I just added two new services: egAlertDialog and egConfirmDialog. Presumably,
+these will be used frequently, so they are good candidates for genericizing.
+
+[source,js]
+-----------------------------------------------------------------------------
+egConfirmDialog.open(
+ 'Copy Alert Message for {{copy_barcode}}',
+ evt.payload, // copy alert message text
+ { copy_barcode : barcode_str,
+ ok : function() { console.log('user clicked OK') }
+ cancel : function() { console.log('user clicked cancel') }
+ }
+);
+-----------------------------------------------------------------------------
+
+Naturally, we don't want hard-coded strings within the code. Here's where
+an i18n experiment begins....
+
+I18N Exeriment
+~~~~~~~~~~~~~~
+
+In my
+http://yeti.esilibrary.com/dev/pub/techspecs/web-staff-prototype.html[original tech specs],
+I suggested that we don't need dynamic strings, since all strings will live
+in templates. While this is certainly possible, it's probably not
+sustainable, because of the template repetition issues mentioned above.
+If possible, though, I would like to keep the management of dynamic strings
+as simple as possible.
+
+For my experiment, I'm embedding the dynamic strings directly within the
+TT template. This lets us manage regular template strings and dynamic
+strings within the same gettext environment, so there's one less hurdle
+for managing i18n. Such string collections could be put within the main
+template, in an included template, or as a separate t_strings.js.tt2
+file, loaded as a standalone JS file. For now, I'm just loading them
+directly in the body of the index.tt2 file:
+
+[source,html]
+-----------------------------------------------------------------------------
+<script>
+angular.module('egCoreMod').factory('egCheckinStrings', function() {return {
+
+/*
+Put our strings into an angular service so that our controller can
+access them. Store them as a collection of string-key => string-value
+pairs. Strings may contain angualr-style variables, which will be
+interpolated by the dialogs.
+*/
+
+UNCAT_ALERT_DIALOG :
+ '[% l('Copy "{{copy_barcode}}" was mis-scanned or is not cataloged') %]',
+
+COPY_ALERT_MSG_DIALOG_TITLE :
+ '[% l('Copy Alert Message for {{copy_barcode}}') %]'
+}});
+</script>
+-----------------------------------------------------------------------------
+
+And here's the confirm dialog code:
+
+[source,js]
+-----------------------------------------------------------------------------
+egConfirmDialog.open(
+ egCheckinStrings.COPY_ALERT_MSG_DIALOG_TITLE,
+ evt.payload, // copy alert message text
+ { copy_barcode : args.copy_barcode,
+ ok : function() {
+ // on confirm, redo checkout w/ override
+ performCheckin(args, true)
+ },
+ cancel : function() {
+ // on cancel, push the event on the list
+ // to show that it happened
+ checkinSvc.checkins.items.push(evt);
+ }
+ }
+);
+-----------------------------------------------------------------------------
+
+You may wonder why I created these as services instead of directives.
+http://www.befundoo.com/blog/angularjs-popup-dialog/[These folks], who
+developed some similar code, do a pretty good job of explaining why a service
+is best in this context. (See "Why create the AngularJS Popup Dialog
+Service?"). More on Angular directives later.
Future Topics...
----------------
* My (currently) preferred parent scope, child scope, service pattern
- * Routing vs Loading
* Deep Linking / Managing the _first load_ problem
- * When to use Angular Templates vs Template Toolkit Templates
* Displaying bib records in the prototype
* More testing
projects / working / Evergreen.git / commitdiff