So enough about me and my employer from the first two blog posts. It's time to get some real work started. This project is about converting the Adobe Flex based TRIPS application to and AngularJS front end. Now, I have done some work in Angular 2.x (Typescript), but that was a separate deployment into a different (but similar) framework. Because of the time frame I have to convert this application and it's overall complexity, I am going to stick with AngularJS.
Before I get into details, just a quick note about the application framework. In order to make the management applications easier, I built a small portal based on the concept of users, roles and functions. All employees can be users of the system provided they accept the FERPA agreement. Access to functionality depends on the roles the user has and which functions are assigned that role. For example, our faculty users have access to class lists and course information via their FACULTY role. But student accounts doesn't see any of those things because they don't have the FACULTY role. They have an AR role.
There are some functions that everyone has access to. This is mediated by the ANY role. The TRIPS application is one of those functions.
The portal framework is really just a few tables, queries and a page that builds out the users' menus. It's only been over the past few weeks that I've made a structural change to the tables. And this was to correct a data design flaw from the inception of the system 12 years ago. The main menu CF page contains all the javascript libraries and CSS files needed for the system to operate consistently from function to function. However, the developer is free to add additional libraries as needed or put them in the application's specific folder. The main menu page also acts as the Angular module in all the function controllers reside.
The only file that will exist in the root of the trips folder is the main.cfm. More on the main.cfm in the next blog post.
Before I get into details, just a quick note about the application framework. In order to make the management applications easier, I built a small portal based on the concept of users, roles and functions. All employees can be users of the system provided they accept the FERPA agreement. Access to functionality depends on the roles the user has and which functions are assigned that role. For example, our faculty users have access to class lists and course information via their FACULTY role. But student accounts doesn't see any of those things because they don't have the FACULTY role. They have an AR role.
There are some functions that everyone has access to. This is mediated by the ANY role. The TRIPS application is one of those functions.
The portal framework is really just a few tables, queries and a page that builds out the users' menus. It's only been over the past few weeks that I've made a structural change to the tables. And this was to correct a data design flaw from the inception of the system 12 years ago. The main menu CF page contains all the javascript libraries and CSS files needed for the system to operate consistently from function to function. However, the developer is free to add additional libraries as needed or put them in the application's specific folder. The main menu page also acts as the Angular module in all the function controllers reside.
Folder Structure
One of the first tasks for any application is to come up with a name which in this case I already have. The next item is name the work space where the code will reside. The existing project, as far as the folder structure is concerned, is brilliantly titled: travel_system. The application itself is called TRIPS. Since an entirely new application is going to be created, I feel that a new folder space is warranted. In this case, trips will be the new folder. And a new work folder will minimized confusion between the old/current application and the new one.
Over the course of the past three years in learning AngularJS, I have settled on a folder structure. When I first starting working with AngularJS, I took a "well, it works" approach by basically having one controller for the whole application with no routing and using booleans to switch screen containers on and off. While I was able to get off the ground fairly quickly using that paradigm, I couldn't fly very high - enhancements and maintenance quickly became a nightmare.
So I smartened up a bit by using a router and separating out services, controllers, and templates. My folder structure looks like this:
apps
- app 1
- app 2
- trips
- controllers - stores all controllers for the application
- data - stores the Coldfusion component (CFC) that makes all the database calls to the database
- routes - stores the router file
- services - stores any services used by the application, i.e. the dataService.js
- templates - stores any html templates. Generally, there should be a template for each controller
I used to store the CFC in a separate area of the server for reuse potential. But I've found over time that I rarely reuse components when they are written for a specific application. While we look for ways to integrate various functionality together, in the scheme of things, that's actually rare. Keeping all the application files in place makes developing and maintaining much easier. Also, if someone else should have to troubleshoot something in a pinch, they don't have to jump around a folder structure wondering if they are looking at the right code.
Comments
Post a Comment