[OPEN-ILS-DEV] Thoughts about the Staff Client Part 1 of 4 - TT2 and AngularJS

[Liam Whalen]

I am going to send four emails about my thoughts on the staff client.  I have not had time to investigate the prototype code very much yet, but I think some of the issues I am thinking about are things that should be considered before full development is begun regardless of the technical aspects of the code.

I am concerned that combining the use of TT2 with AngularJS adds complexity to the staff client design that will inhibit participation with staff client development, adds a layer of complexity to the MVC desgin, and could end up making the app incompatible with later versions of the AnuglarJS framework.

By using TT2 with AngularJS, we are no longer using the AngularJS framework, we are now creating a hybrid system. In essence, we are rolling our own staff client by using multiple processes.  For developers outside of the Evergreen community who like using AngularJS, having to learn TT2 could result in those developers losing interest in assisting with the staff client.

As well, the complexity of the Model View Control design is increased when TT2 processing defines the AngularJS controllers and directives that could be used on a page.  At this point, the developer needs to examine the Perl code to see what the values of these variables are at the time of processing.

Instead of having an MVC system that is self contained, where the models are easily identifiable within the files of the AngularJS code base, and the relations between those models and the view via controllers can be discerned by reading the AngularJS code, developers now have to maintain a secondary list of conditions defined outside of AngularJS that vary depending on some criteria such as the URL being used.

Also, for those unfamiliar with MVC, it may be tempting to make things work by using variables via TT2 that do not make sense in the context of the file that the person is editing.  In this case, the code still works, but the abstraction starts to fall apart and becomes a hinderance rather than an asset when thinking about the code.  I do not think the community has the time to police this sort of development, and best practices listed on a Wiki may not get followed.

Additionally, Google is talking about developing server side parsing of some AngularJS code.  While this will unlikely be mandatory for an AngularJS app in the near term, the benefits added by server side processing may be deemed important in new versions of the AngularJS framework.  In this case, a later version of the framework may require server side processing in order to use newer features.  Which would put the community in the position of either figuring out how to process something via TT2 then send it to server side AngularJS (and this may not be possible without an extreme effort), or we have to start limiting what we can use in the newer versions of the framework or are limited to using only older versions of the framework.

I realize this is very much a what-if scenario, but I think the possible problems are important enough for it to be considered before large scale development combining TT2 and AngularJS commences.

In the case of content being created via TT2, I am less concerned because that can be refactored fairly easily and without the fear of breaking the application. I am thinking of things like localization and custom messages.

Also, using TT2 as a preprocess before AngularJS adds the possibility that the template may inject Angular syntax into a piece of content by mistake. Errors like this would be very hard to track down and a solution (other than procedures to verify that content template values are not AngularJS code) is not generalizable for fixing something like this.  Again, this is an edge case, but it adds an element of unknown to all debugging that will have to be considered at some point once the source of an error eludes a developer for a long period of time.

In the end, by combining TT2 and AngularJS we are no longer using a framework.  At this point we are rolling our own solution via the combination of two separate systesm.  I am going to touch on Google Best practices in another email, but in general, the advice I hear from the AngularJS team communications is develop everything in AngularJS to the fullest extent possible.

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140122/8c5a2be0/attachment-0001.htm>