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: MAIN.CFM

Within the current development pattern I have for our portal system, the main.cfm is the starting point for an application. For the most part, this is really boilerplate and serves to get the application off the ground. The way the portal works is that the user lands on the main menu page and provide with a menu of options. Each option is called a function and is assigned a unique id. When the user clicks on a menu option, the page is reloaded with the function id. The process checks to see if the user is actually allowed to have access to the function. It then accordingly looks up the path and displays the page via a . In the case of the TRIPS application, the included file is the main.cfm page for the application. So far the project looks like this: we have the folder structure defined with no files aside from the main.cfm. The main.cfm contains a few javascript includes, the overarching controller for the application as well as the route viewer. The next blog post will foc

The Conversion: Trips for Keeps - Part 2

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

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 ret