electricDust

When starting out on my AngularJS journey, I couldn't get a good handle on the router native to the framework. So I adopted the use of the wonderful angular-ui / ui-router.  During the past few years of development, I've honed in (for better or worse) my paradigm for setting new applications and nearly every AngularJS app has a routes.js file. Without going into background, I wanted a way to load the ui-router dynamically. Typically, the routes gets defined in a .js file and typically looks something like this: angular.module('core').config(function($stateProvider, $urlRouterProvider) { $urlRouterProvider.otherwise("/landing/201820"); $stateProvider .state('landing', {url: "/landing/:term", templateUrl: "apps/noted/templates/landing.html"}) .state('uploadCalendar', {url: "/uploadCalendar", templateUrl: "apps/noted/templates/uploadCalendar.html"}) .state('noteTakers...

So I really dropped the ball on blogging about the Travel System project or anything else for that matter. Planning for our annual user group conference began to take over any free time. Then updates to other application; then break; then yada, yada, yada. But the TRIPS application made it out of development into pilot during the later part of the fall semester. All users were notified during that time the existing would be retired and were given the opportunity to use the new system. Because the data structure did not change, it was a very smooth transition. Whatever data was entered into one system, it was available in the other. The old Adobe Flex-based application was retired when we came back from break in early January.  Thus far, I haven't heard any user complaints other than some uncertainty on how to use the new system. But we will see once the spring semester gets into full swing. So what does it look like? Prior posts have described the development paradigms and some...

Dates. I hate dates. I haven't quite figured out how to be proficient with dates moving from system to system, especially when the user has to enter them. For this project, four dates and times need be stored: outbound departure and arrival; and inbound departure and arrival. To achieve the data entry aspect of this, I am going to utilize the date and time pickers in  AngularStrap . [The Next Day] Did I mention I hate dates. The UI is a bit more challenging that I thought it would be. There are 8 inputs and six labels. If I remember correctly, I had the same problem with the Flex-based system as well. After mulling it around it wound up looking not too bad. This is the before: Not too bad - functional in the least. [The Next Next Day] The new semester has started and I've been putting small fires out here and there. But now it's time to get this project back on track! At the moment, this is the after: This looks a little less cluttered.  The user will sele...

For as much development and blogging that's been happening, I haven't moved the project too far along. In fact, I am behind on my goal of being completed by the end of August.  That said, the new TRIPS application is almost at the top of the development hill - much of the ground work has been developed and the more I work on it, the clearer the vision becomes. This blog post will revolve around the user interface and experience for the landing and trip templates. Starting with the landing page, a New Trip button needs to be added which routes to the trip template with an id of 0. Remember, a 0 id will inform the saveTrip() code to insert a trip as opposed to updating it. The new trip button isn't something the user is going to use all the time, but it still needs to be obvious. I initially thought the right side of the filter would be a good place, but the filtering capability may be expanded in the near future with options. So I will start with putting the button o...

With the core methodology set up in Part 2 to get the trip data from the AngularJS front end to the CF middle tier, we are ready to save to the database. All of our custom data is stored in Oracle, but the following will apply to most, if not all, relational databases. I try to steer away from doing anything overly fancy to minimize refactoring down the road if platforms should change. At the moment, the trip function only receives the trip data and breaks it down into a CF structure and then returns that structure back to the application. <cffunction name="saveTrip" returnformat="json" returntype="struct" access="remote"> <cfset _params = getHttpRequestData()> <cfset _content = deserializeJSON(_params.content)> <cfset _trip = deserializeJSON(_content.objectData)> <cfreturn _trip> </cffunction> Now I have a design decision to make. I can either create individual functions to save e...

Ack! A few days off work and then updates to other applications that needed to be made has delayed more work on TRIPS. But we're back and ready to continue. In the last post , we started to build out the trip.html template and it's corresponding controller. The dataService was updated with an abstraction that would allow a CFC method to be called and data to be passed.  This post will focus on retrieving that data from the dataService to the CFC method. Before we get started, I thought it would be kind of cool to keep a count of the number of lines of code for the project.  I'm not sure if it will provide any insight, but it might be nice to compare the line count to the number of lines in the Flex application.  Rather than posting the counts on each blog post, I have created a separate post tracking the line count per post . In review, let's take a look at the dataService code that's going to call the Coldfusion function to save the trip information. this.p...

With the development of the landing page, we are ready to add the trip details page. This page will be used to edit the trip information, manage sponsors, activities, and waivers. Due to the amount of data displayed on the page, I think that the participants listing will get their own page. We've already, in the last post , added the trip route to the router.  But just as a refresher, it looks like the following: angular.module('core').config(function($stateProvider, $urlRouterProvider) { $urlRouterProvider.otherwise("/trips/landing"); $stateProvider .state('landing', {url: "/trips/landing", templateUrl: "apps/trips/templates/landing.html"}) .state('trip', {url: "/trips/trip/:id", templateUrl: "apps/trips/templates/trip.html"}) }); The next steps are to create the trip template and controller files.  Because a parameter is being passed to the trip controller, the $stateParams...

In Part 1 of Lay of the Landing Page , the basic landing page framework was established.  In Part 2 , the table was added as well as some AngularJS filtering capability.  For Part 3, the participant count, column sorting and routing to the trip edit and detail page will be developed. The participant count is fairly straight forward to get as it is just a count of records in the trip_persons table. The more difficult part is determining who completed the required documentation.  Fortunately, because this is conversion project, the code already exists to get this data. Since college sponsored trips mostly revolve around the students, the participant count on the landing page will be the number of students on the trip. But when user drills down into a trip, a breakdown of all participants will be displayed. With the Students column (student participant count) added, we can see that the table is getting a little crowded. There are three options: reduce the number of ...

In Part 1  of developing the landing page for the new travel application, we set up the landing controller and created the the CF function to get the trips relevant to the user. The next step is to begin developing the UI, the landing.html template, so we can actually see the trips. Just a quick refresher - the landing controller code is a follows: angular.module('core').controller('LandingController',['$scope','dataService', function($scope,dataService){ $scope.trips = []; dataService.call('getTrips').then(function(data){ $scope.trips = data.data; }) }]); And the landing template is empty at the moment. <div ng-controller="LandingController as ctrlLanding"> <h3>TRIPS</h3> </div> The first step for the landing template is to create the table. This includes setting up the columns and looping through the $scope.trips array and generating the rows. <div ng-controlle...

In the last post  the groundwork has been laid for real development to begin. The data service, router, and landing pages have been created and are ready for code. The last thing to add for this part of the process is the Coldfusion component. A data folder has been added to store any cfcs relevant to the TRIPS application. The first is to write the CFFUNCTION that will return the list of trips. My development pattern for creating CF functions is fairly routine.  First, decide on a name, parameters and return type.  Sometimes the naming of a function is the hardest part.  I've settled on actionDataObject.  So in this case, the function will be named: getTrips.    At moment, the landing controller (landing.js) is empty. angular.module('core').controller('LandingController',['$scope','dataService', function($scope,dataService){ }]); The basic task of this controller is getting the list of trips.  First is the establishment of an empty tr...

The first step in my high level development process is to create the landing page and determine it's contents. In the prior post , it was decided that the new travel system landing page will display a list of trips relevant to the user.  These would be trips that they created and / or trips that other users shared with them. In the MAIN.CFM post, I outlined the folder structure that I generally use get a project off the ground.  For this post, we are going to add the following: routes/routes.js services/dataService.js controllers/landing.js templates/landing.html ROUTES.JS I don't use the native ngRoute for AngularJS, but instead settled on the AngularJS UI-Router .  To me, this router seems easier to implement and understand than ngRoute. The route.js file starts out as the following: Basically, this little bit of code is saying if the route doesn't match any of the $stateProvider.states, then route to the landing route.  The landing route itself is...