In this ten-part developer diary, Justin James chronicles using the OutSystems Agile Platform to write a real-world Web application called Rat Catcher. This series will also publish in the OutSystems About Agility blog.
Read the previous installments in the series: Getting started with the OutSystems Agile Platform, Learning the basics of the OutSystems Agile Platform, Describing the OutSystems Agile Platform Service Studio experience, Working with the OutSystems Agile Platform's Integration Studio, Deploying an application created with the OutSystems Agile Platform, Adding ECT to an eSpace with the OutSystems Agile Platform, Working with scheduled jobs in the OutSystems Agile Platform, Using AJAX in the OutSystems Agile Platform, and Securing your OutSystems Agile Platform application.
In part eight of this series, I talked about how I used AJAX throughout Rat Catcher, but it involved some retrofitting because I did not plan for it. When I was ready to make changes to the site's look and feel, it required much more than some retrofitting. I made the biggest rookie mistake when I started development for this project: I put my layout into a table. I know better. I've been using CSS for layouts since around 2000 and table-less layouts for about four years now. Ten years of knowledge and experience thrown out the window to get something done quickly. At least I had the good sense to put my login code, header, and footer all within their own Web Blocks.My first task was to move to a table-less layout. First, I put a Container Widget on my header, footer, and login blocks, and moved all of the existing items within that container. Then I edited the eSpace's style sheet and created classes for each of those containers, and set the containers' Style property to the new class (Figure A). While the new CSS classes were still blank, it was a start that would allow me to experiment a bit. More importantly, it broke the Web Screen into Container Widgets that I could assign classes to and manipulate separately. Figure A
The CSS editor is pretty basic, so you may want to paste your CSS in from somewhere else.
Next, I started slicing and dicing the Introduction page. (The Introduction page is one of the most complicated pages in terms of the layout because it has the login Web Block on the side.)
- I moved the on-screen Web Blocks out of the existing table.
- I created a new, empty CSS class for the content of each Web Screen, and I moved the existing content into it.
- I started to edit the CSS classes that I created to get to the layout that I wanted.
Some screens, such as the account purchase page, still need some tables.
Rat Catcher still has a very plain look, but once the logo is selected, the color scheme will change, and I will see if the menu works better with icons.
I have some great ideas for additional functionality and a number of minor bugs to fix, yet I would rather be working on the graphics. I also know that once I get the main graphics loaded in and the color scheme picked, I may very well decide to revamp the menus to split the major functionality into up-front, large icons and shift the other functionality to a less prominent position. This will allow me to tighten up the design so that it works better on smaller screens, and it will probably help significantly with the usability. As of the time of this writing, the actual application looks the same as it always has, but the underlying HTML is much better, thanks to going table-less; plus, I have options for the future. The lesson I learned here is to do it right from the beginning!
When I started writing about my experiences using the Agile Platform, I imagined that there would be five or six installments, but then it blossomed into a 10-part series. Along the way, I learned a ton of new things, and I have come to really like working with the Agile Platform.
I started off feeling a little bit off-kilter with the Agile Platform's development paradigm, but now I cannot think of any reason why I would ever go back to plain vanilla ASP.NET for this type of development work. Am I saying that I would never use ASP.NET again? Absolutely not. But for a data driven Web application, or an application that does not need to use custom controls or have absolute control over the underlying HTML, I think that the Agile Platform is so much more productive than ASP.NET (or PHP or J2EE, for that matter), that it would be a hard sell for me. For the first time in a long time, I actually enjoyed worked on a Web application.
I estimate that I've invested about 40 hours into Rat Catcher on the Agile Platform end of things. Some of this time was spent learning new techniques. For example, I needed to take the existing backend DLL that embodies the processing engine and wrap it in a WCF service. My biggest time sink was spent around deployment. While deploying the application to my Platform Server was a cinch, choosing to put the application behind a reverse proxy using IIS's URL Rewrite module caused me all sorts of headaches. About 90% of the pain was on the IIS side though, and hopefully my discussion of the topic will help someone else out who decides to go down that path. I was forced to do this by only having one IP address, but for future deployments, I would want either another IP address dedicated to the Platform Server box, or a proper firewall in front with a reverse proxy, like Microsoft Threat Management Gateway. I was not keeping track, but I know I lost at least 10 hours to this part of the project, and it would have been a 30 second issue without my local technical limitations. The moment someone offers a turnkey third-party hosting product for the Agile Platform, I will be there. I looked at the information for deploying to Amazon Web Services, and my eyes glazed, but I may need to explore that route (or move the backend processing component to Azure) if the application becomes a hit.
While I can't say for sure how much time I would have spent on this project if I had used ASP.NET, I know that it would have been a lot longer. The Agile Platform delivered three main benefits for me to significantly reduce the time to develop Rat Catcher:
- The tight integration of the data modeling into the development scenario allowed me to make changes in the data model and have them instantly reflected in the application. This was far superior to the ORMs I typically see that require changes to be made in the database, and then have the ORM's model regenerated, and then have the changes reflected in the business objects. The TrueChange system played heavily into this. Another angle here is the way the identifier for an entity becomes its own type, and how the system automatically bases things on that type. Along the same lines, Service Studio is subtly clever about certain things; for example, if you have a variable called EmailAddress and the entity has an attribute named EmailAddress, it automatically populates assignments because it guesses (it's right 95% of the time) that you want to assign the EmailAddress attribute's value to the "EmailAddress" variable.
- The visual nature of the Actions allowed me to easily see what any given Action does, even if I had not looked at that Action in months (yes, the project was actually spread out across about three months). As a result, the source of most bugs was found without using the debugger. (I can count on one hand the number of times I used the debugger!) The "code" is literally self-documenting (and the documentation is always up-to-date), which has been a goal for developers for a long time.
- The Service Studio paradigm allowed me to "think out loud," which is impossible in ASP.NET. Because changes were easily and quickly reflected through the system, I did not bother to perform the usual planning that I would have done in an ASP.NET project. The funny thing is that the planning I normally would do (i.e., Visio diagrams of data models and workflows) looks just like how Service Studio works in general. While I did not follow a true, Agile methodology, I can see why this is called the Agile Platform and not the Rapid Development Platform (even though that would have been accurate as well). Changes were painless. The number of times I used a Find All to figure out how to cascade a change was either two or three times, and it was related to a major structural overhaul in how I was handling the reports. That is really amazing to me. I started this part of the project with only a vague idea of what I wanted to do or how to do it, and the tools actually made it easier for me to explore new ideas and concepts because it was so simple to make changes.
At this stage in the game, Rat Catcher has been in a public beta for some time, and I have gotten a ton of great feedback on it. It also looks like someone who was using an early prototype of Rat Catcher (I wrote a simple WinForms .NET application to interact with the backend a long time ago) has switched to the new Web version, and I hope to get more feedback from that person as well.
At the time of this writing, my bug list is down to three items, and my "must-have" functionality list is getting pretty short too. Right now, the major standout items are to finish improving the look and feel of the application and to tie in the billing system. I am waiting on the billing end of things because I am evaluating a number of different choices, and there is no hurry to do it until the rest of the application is good to go. I have some minor pain points, like a number of emails that need more descriptive text, a need to redirect users from the login system to the page they were trying to reach, and so on. I also have a number of lower priority items that I would like to get some traction on as well, but they are not critical to the product.
I am really pleased with how well this project has developed over time, and I have learned a lot along the way. An extra special thanks goes out to Miguel Baltazar (the OutSystems Solutions Delivery Manager in the United States), who has really been good at finding things that need to be fixed, and showing me better ways of using the Agile Platform to achieve my goals.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
---------------------------------------------------------------------------------------Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.