electricDust

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

The following chart is a list of blog posts and the corresponding line counts of the TRIPS application per post.  The blog series is a semi-detailed process of converting a Flex based application to AngularJS. Blog Controllers Templates Data Route Main trips landing trip landing trip Service CFC Trips for Keeps (P. 1) 3 23 12 45 23 32 94 8 9 Trips for Keeps (P. 2) 3 23 18 45 23 32 102 8 9 Trips for Keeps (P. 3) 3 23 28 45 27 32 175 8 9 I see UI/X 3 23 39 56 36 32 175 8 9 I see UI/X - Part 2 3 23 70 53 93 32 272 8 9