electricDust

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...

Application user interfaces usually design themselves. Instructional information goes at the top of the pages as well as any string filters. Distinctive filters are located along the left or right side.  Lists are displayed in a table with the most important columns on the left and least important on the right.  Remove and delete options are almost always on the far right such that the user will not accidentally click on the icon. User experience (UX) gets a bit more tricky. Should we always prompt before deleting something?  Should the columns be sortable? Do we save the filter information so the user doesn't have to enter it in again? After a user modifies data, what kind of feedback should they get? Lots of questions can be asked - but the answer to each one generally means more coding and more maintenance. My biggest consideration when creating the UX is the technical aptitude of the user. That said, over the past few years, especially with the near complete migrati...

Now that the basic coding is framework is set up, it's time to step back before any development and take a look at the existing data structures as well as the user interface. Data Structures The TRIPS application was developed and implemented back in 2010.  There have been minimal table updates and the data gathered seems to meet the need of the users.  That said, since a front end rewrite is being done, it's a good idea to take a look at the back end database as well.   There are 14 tables that support the application. Ten of those tables are geared around a "trip" while the other 4 are tables used to buttress the app. I think the best approach here is to simply go through each table and see if there are any design flaws and / or data elements that were captured but have no real use. This process is important to so because the outcome may save time in not developing unnecessary interfaces to capture unused data. DC_STRAVEL_TRIPS Each row in the DC_STRA...