Skip to main content

The Conversion: Lay of the Landing Page - Part 2

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-controller="LandingController as ctrlLanding">  
   <h3>TRIPS</h3>  
   <table class="table">  
     <tr><th>Trip Name</th>  
       <th>Destination</th>  
       <th>Type</th>  
       <th>Departure</th>  
       <th>Arrival</th>  
     </tr>  
     <tr ng-repeat="trip in trips">  
       <td>{{trip.NAME}}</td>  
       <td>{{trip.DESTINATION}}</td>  
       <td>{{trip.TYPE}}</td>  
       <td>{{trip.OUTBOUNDDEPARTURE}}</td>  
       <td>{{trip.INBOUNDARRIVAL}}</td>  
     </tr>  
   </table>  
 </div>  
This is some pretty basic not so exciting stuff which yields:
In thinking about this, there are few things to add to the page. The total number of participates would be helpful to the user contrasted with the total number that filled out the required documentation. The page also needs a filter by trip name. Most users have many trips, so a filter can help them access a particular trip quickly.  I've also thought about adding pagination, but in this case, it's not necessary since the list of active trips won't be large. That said, for administrative users who see all trips, pagination may be a valuable tool. The organization of the data will dictate if paging is necessary.

For the filter, we are going to use the AngularJS filter system. Our ng-repeat="trip in trips" in the template will change to ng-repeat="trip in trips | filter: filterTrips. This simple change will cause the filterTrips to be applied to each trip. Next, the controller is updated with a filterTrips function.
 angular.module('core').controller('LandingController',['$scope','dataService', function($scope,dataService){  
   $scope.trips = [];  
   $scope.tripFilter = '';  
   dataService.call('getTrips').then(function(data){  
     $scope.trips = data.data;  
   })  
   $scope.filterTrips = function(_item){  
     var _r = false;  
     if (  _item.NAME.toLowerCase().indexOf($scope.tripFilter.toLowerCase()) > -1 ||  
         _item.DESTINATION.toLowerCase().indexOf($scope.tripFilter.toLowerCase()) > -1 ||  
         $scope.tripFilter.length == 0 ) {  
       _r = true;  
     }  
     return _r;  
   }  
 }]);  
The $scope.filterTrips function takes one parameter which is the item in the ng-repeat.  If the function returns true, the item is included in the repeat.  If the item is false, it will not be included. The if statement is doing the work where it's looking at name and destination, switching everything to lowercase, and testing to see if $scope.tripFilter is part of the text.  The landing template has been updated with the filter input.
 <div ng-controller="LandingController as ctrlLanding">  
   <h3>TRIPS</h3>  
   <div class="alert alert-info">Welcome to the Travel Resource Information Planning System (TRIPS).</div>  
   <div class="input-group">  
     <span class="input-group-addon">Filter</span>  
     <input class="form-control" ng-model="tripFilter"></input>  
   </div>  
   <table class="table">  
     <tr><th>Trip Name</th>  
       <th>Destination</th>  
       <th>Type</th>  
       <th>Departure</th>  
       <th>Arrival</th>  
     </tr>  
     <tr ng-repeat="trip in trips | filter: filterTrips">  
       <td>{{trip.NAME}}</td>  
       <td>{{trip.DESTINATION}}</td>  
       <td>{{trip.TYPE}}</td>  
       <td>{{trip.OUTBOUNDDEPARTURE}}</td>  
       <td>{{trip.INBOUNDARRIVAL}}</td>  
     </tr>  
   </table>  
 </div>  
Since I only have a single trip assigned to me, it would be nice to see a more practical use case.

Now lets filter on "land" and see what happens.  Anywhere "land" exists in the Trip Name or Destination field, that trip will be displayed.
That's some pretty decent functionality with very little code.  But there still is more work to be done on the landing page.  Column sorting is always a big feature with users.  Also, there needs to be a way to delineate between current and old trips.  In the Flex-based TRIPS application, users are able to archive trips which pushed them out of their main folder and into another.  But that requires the user to initiate the process. I am thinking for this system we can separate trips by whether the trip has occurred, is occurring or is going to occur.  We also should display the participant count as described earlier in the post. And finally, we need some navigation to the next route which will be trip details.  So I guess there will be a Part 3.

Hope you are enjoying the posts so far.  Feedback is always welcome as it usually makes be a better developer.

Cheers!

Comments

Popular posts from this blog

The Conversion: Introduction

While working as the senior level developer for a small liberal arts college, I've had the luxury of deciding the technology to be used internally for custom applications. When I first started, the college was using Coldfusion 7, HTML, and many MS Access databases. Over the course of the past 11 years, we've moved to Oracle, are on CF11, and utilizing AngularJS / Angular for our front ends.  Coldfusion is still doing the heavy lifting in interfacing with Oracle. During those 11 years, we also found ourselves developing Adobe (now Apache) Flex applications.  Flex was a great tool - easy to develop in and fairly easy to deploy when Flash was ubiquitous. But Flex was not great on mobile platforms.  Hence our move to Angular due to the idea that we wanted to give our users a rich web experience. So over the course of the past two years, we've been either retiring Flex applications altogether due to the direction that some departments have taken (read outside vendor); or r...

The Conversion: Lay of the Landing Page - Part 1

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 Conversion: Getting Started

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