We are developing a new version of a pretty huge application which is currently made of JSP+JS pages, served by custom Servlets. Given the application deals with large amount of data, most of the business logic is implemented in the database as stored procedures. The main selling point of the application is its visual representation of the stored data. Basically anything can be modeled and visualized. The current version is visualized in Silverlight, which works best in IE and needs its plugin, which is obviously a bad thing. Our goal is to be browser-independent as possible, and the main issue is the diagram drawing. So we decided to give AngularJS+SVG a try. The development started with a brand new project, Spring MVC REST backend, single page AngularJS application. After a few months, we see now that it is a good choice, every functionality can be implemented. To release the next major version as quickly as possible, we decided to keep the old JSP forms (other parts apart from the visualization) for now, with the visualization rewritten in Angular. So the visualization component needs to be independent of running in a jsp or html, and needs to be independent of our framework (there are tabs as iframes: one diagram editor screen is a jsp in an iframe, now a full angular app; the backend is servlet-based, and many features are implemented in JS functions). My question is, how can we modularize the application as effectively as possible? I was inspired by this article about a flowchart app in AngularJS+SVG, and we're doing the SVG manipulation with Snap.SVG.
Right now these are the main parts (in separate .js files):
- the diagram directive with the basic event handling in the Controller, which contains a reference to the DiagramViewModel
- the DiagramViewModel JS class which is constructed from the given DiagramDataModel (which is a JSON object received from the backend), much like in the FlowChart app
- the DiagramEdit JS class which contains the methods for editing the diagram (there are read-only users), anything it does, it involves the DiagramViewModel so it has a reference to it
- the DiagramNavigation JS class which does the basic navigation (zooming, panning etc.)
- the angular module for wrapping the backend and framework JS methods (factories)
- other services in separate files (logger module, error handler module, etc.)
The point in doing so was that the controllers of the directives should be thin, so the logic is separated in the ViewModel and DiagramEdit classes. My main concern with this approach is that if any method in the ViewModel or Edit class wants to have a framework call, it should do it through a reference that is given to the ViewModel by the Controller in the ViewModel's constructor. So i'm basically doing angular's dependency injection by hand (the framework/backend wrapper factories are injected to the directive's controller, and I'm passing the reference to the ViewModel constructor). Should I just have one ViewModel that does all the magic (even if it would be very large, more than 3K lines)? Or should I use an angularJS factory as the ViewModel so the bakcend and framework's factories could be injected to the ViewModel factory? Should I have separate Angular modules for the groups of functionality? If so, how could they share the Diagram object? Should it just be shared in the $scope?
A very good example of my concern: There is an autocomplete input field on the toolbar. When it changes, the DiagramEdit makes a backend call to search in the objects. When the call returns, the Edit module iterates over the result and adds the SVG representation to the object. For doing so, I need the $sce module, injected by Angular. Then this list is visualized in an ng-repeat, bound to a variable in the Edit module.
After this release, we will continue developing the other pages and framework, and switch to Spring on the backend side. So this diagram module needs to have a well defined interface, independent of the backend calls and the other parts of the client application.
Another great article found about larger scale Angular development is this.
