I’ve been doing a lot of work in Flex lately, and the more I do, the more I’m convinced that this framework FINALLY provides what web-based applications have been seeking.

Several weeks ago we launched a dashboard for Investor Reports (more on that when it becomes public), and the ease of a well-constructed model-view-controller flexibility provided the most rapid development environment I’ve ever worked in.  But more recently, we started provided secure data services for IACP, who had immediate needs to capture registration information. 

Flex Form “Wizard” interfaces Data Validation Secure data transfer Rapid development

The result was two Flex-based forms, providing a simple wizard-like interface to guide users through a multi-step registration process.  Each step provides client-side data validation (further reinforced on the server side), minimizing the need for IACP’s staff to take the time to contact registrants and clarify information - critical when these registrations were being announced in mere days to thousands of members! 

We’ve developed an in-house system to automatically generate basic data gathering and validating code, given a well-constructed database schema.  This system feeds directly into the Flex architecture, and eliminates much of the mundane coding that is usually required.  These simple-looking forms would have taken 3-5x longer in ASP.NET or Cold Fusion, and give the user a much more pleasant experience. 

You can experience the Flex forms here and here [contributions and registrations not required ].

So, David was getting a lot of orders.  Each morning he’d come into the office, open up his online ecommerce manager, search for new orders, check his roasting log, print out what he needed to do, and start roasting.

That’s a lot to do before your first cup of coffee.

What’s a better idea? Click one button.  Immediately get a graph of all the unprocessed orders, showing you exactly what needs to be done. 

A demo of the Flex dashboard for Blanchard’s Coffee is here.  And, as always, Blanchard’s Coffee is here!

A few weeks ago I began a series on three-tiered architecture.  We’ve got a fascinating client that recently was able to take advantage of this structure in a remarkable way.

This project involved an excruciatingly large and complex number of calculations containing financial information.  A series of eleven reports is gradually built from four collections of base data.  Each section of reports begins with the “lowest-level” view (almost raw data) (which is overwhelming), and gradually comes up to higher levels that make more sense.  They then start to phase in the roll-up information from the other collections of base data, until the final reports which neatly tie up everything into a tangible “is this person doing what it is supposed to do” report.  OK, excellent. 

These calculations contain all kinds of industry-defined and proprietary calculations and methods, so that’s the business layer.

The “business layer” was excruciatingly difficult to write.  (Did I mention that?)
Do I want to change or rewrite any of these calculations?  No.  Do I want to forget how they work?  Yes.  Am I allowed to though?  No.  OK, that doesn’t matter, and it’s not the point.

The point is that after all these calculations are made, they need to be stored somewhere so we don’t have to wait 10 minutes to run through all the sets of calculations all over again whenever we want to view the reports.  So we store them in a database.  Hopefully that’s not a real shocker…

The database did have to be constructed with thought.  I’m going to save comments on database design for another time, and suffice to say for now that after it had been constructed (with the business layer in mind), it really doesn’t need to change very much.

So what’s left?  Ah, it would be great if we could SEE these reports.  We’ve got a slew of calculations, and we’re storing all the data and results, now let’s look at them (remember comments on practicality?).

The presentation layer contains a set of web pages that eventually get turned into PDFs.  Cool.  Really cool.  This layer sits neatly on top of our calculations, and HTML does its work, and the PDF generator does its work too.  The reports look pretty darn nice.

Well, we’ve just gotten a very useful update for our PDF generator package.  It has the ability to take the reports from looking “pretty darn nice” to “that’s simply smashing”!  At first I think, “Oh, MAN! I wish I could have had this beautiful update before I started writing this program!  Now I have to do THE WHOLE THING ALL OVER AGAIN!!”

NOT.  (Have you seen that great preview for Borak??)

I’m trying to forget all those dreadful calculations, remember?  (No, I’m not.  Yes, I am.)
And what part about the NUMBERS is going to change when I flip the switch from “big red font” to “small blue font”?  NOT MUCH.

I built a set of plugins to the business layer that my presentation layer calls all the time.  The presentation layer just interprets the results of these calls into — whatever it wants to do.  It used to use version 6 of our PDF generator package.  Well, let’s use version 7 now.  And let’s change the layout slightly to take advantage of some really cool things.  And let’s not take 6 weeks to do it.

Exactly nothing needed to be touched in the business and database layers in order to give our set of reports a complete overhaul.  In less than a day, I sent our client a new set of reports, and do you know what he said?

He said, “Cool.  That looks great.”

That’s the way it’s supposed to be. 

Not, “I didn’t authorize all this work!  I can’t afford a complete overhaul on these reports!”, but “Cool.  You made this whole thing flexible enough to change the look of the reports without breaking a sweat.  I’m really glad you did that.”

Yeah.  That’s the way it’s supposed to be. 

T-shirts are in.

Cool.

“The architecture doesn’t support this.”
“I just don’t see how this can work.”
“If you wanted to do that, we should have thought about that a long time ago.”
“We can’t do that.  It’s technically … operose…”

I’ve been developing a large web-based application for Investor Reports.  Because of its size, it is (naturally) dependent upon session variables as the end user navigates between several different pages of reports.  It’s written in PHP/mySQL.  We chose to use Corda’s Highwire tool to generate the PDFs from the resulting HTML reports, but I ran into problems when I started automating report generation.  Corda created the PDFs quite nicely when I used the browser to generate commands via a URL, but when I used the API, I got an message that my HTML was malformed. 

How dare a machine accuse me of such neophytism.

Giving it the benefit of the doubt, I pulled the HTML code directly from my reports and ran a quick validity check through Dreamweaver.  To my great satisfaction, the report was 100% XHTML-compliant, except for one < img> tag that the Corda server generated.  I saved the code to a flat HTML file, passed it to the Corda server through the API, and it generated a (quite lovely) PDF report.

What gives?

Should I:
 A. Generate a flat set of HTML pages each time the PHP reports are called, and then pass a set of commands to the Corda Server?  OK, that MIGHT work… but it’s kloogy.
 B. Develop a new set of API commands on top of the Corda set that would read from mySQL?  Interesting, but probably time-consuming.
 C. Use CURL to read in the resulting HTML, save it to a temp location, and continue as if nothing had happened?  Hmm…

It turned out that CURL spit out exactly what I was looking for: the answer.  “Please select an account.”  A very friendly notification that the session variables were gone.  Well that makes sense.  And it IS well-formed. Ok ok ok …

A quick bolt-on to the session manager enabled me to recreate everything necessary to “jump into” the application from a single URL.  Oh, but wait - since the Corda server is running on another port, will PHP maintain session lifespans within a new context?  Of course.  Why?  Because it’s cool like that.
 

(You): Hi - we’ve got a website and have been selling products online for a few years - our web guy moved to Switzerland though and we need somebody to make some changes…
(New tecchie): Sure, I’ll look at it.

** three weeks later **

(New tecchie): Man, this site is so screwed up. Whoever wrote this had no idea what he was doing. In order to make any changes I’m going to have to rewrite 30 different pages. It’ll take two months and twenty-six thousand dollars.
(You): What are my alternatives?
(New tecchie): Rewrite the whole site. It’ll take two and half months and cost twenty-eight thousand dollars.
(You): All I need is one product added!
(New tecchie): Dude, you should have bought a Dell…
(You): What does that have to do with my website??!!

Buying a Dell actually has nothing to do with your website. (OK, it could…don’t get all technical on me…) But scalability has everything to do with your website.

There’s actually a very simple reason why the above conversation is quite common: the site that you started a few years ago has slowly grown and gotten more complicated. It is now miraculously held together by layers and layers of rules and code, and attempting to change one thing now is like trying to upgrade the middle section of the leaning tower of Pisa. The tower won’t fall down on its own, but don’t start making structural changes!

In order to avoid scenarios like this, I’ve been using a “three-tiered architecture” approach for years. With this approach, the overall structure of your website looks like this:

With this setup, the data (e.g., product and pricing information), is the foundation of everything. A great deal of flexibility can come in, if the business layer is constructed to properly feed the data to the user interface. Here’s what can result:

1. You decide to change your shipping calculations. Those changes are done in one (and only one!) section of code. The formula is changed in the business layer, and the database and the user interface remain untouched.
2. You decide to add a product. Records are added to the database, and the business rules that read from the database automatically pick up on the new changes and carry the data to the user interface. (Result: “Hey, there’s a new product. BUY! BUY! BUY!”)
3. You decide to change the look and feel of your site to reflect your company’s new branding. Brown becomes orange, graphics and logos change, and navigation gets an overhaul. Your search and shopping cart functionality stays exactly the same though, because your business rules have not changed.

Technologies and programming languages change every day (*sigh*), but principles like this need to be applied everywhere. Over the next several days, I’ll demonstrate how we employ these kinds of techniques to provide scalability and stability to our applications.

Clyde is a horse, a Clydesdale to be specific, and he’s real - especially to my daughter.  I’m tempted sometimes to see Clyde and his many fellows (can you have too many stuffed animals?) as mere playthings, but . . . they’re not.  In the wonderful world of my daughter’s imagination, each has a name, a personality, and gifts to share.

So, it was kind of like waking up in “The Velveteen Rabbit” when I found I had a traveling companion with me while traveling out of town this week.  Drawn into her world by this little fragment that had stowed away in my briefcase, I was instantly filled with delight that seems to be the sole province of children.  My imagination took a turn with what his presence was supposed to convey:  Was he sent along as a work-horse so I’d finish with my client quicker and come home sooner?  Perhaps he was supposed to keep watch and guard my computer while I slept?

My delight was only exceeded when I called home that night and she asked me if I’d found any surprises.  I had to string her along a little bit, but then I sent pictures of Clyde helping me at my computer and putting me to sleep - and you could almost see and touch the joy in her voice as she exclaimed “Oh, my goodness!”

 Clyde slept with me each night - I’m not sure if I did that for me, for my daughter, or for Clyde - but it felt right.  It felt real.

Living in a digital world with electronic media where the ephermeral pictures and dialog (like this?) are tucked out of sight and mind on hard disks and NVM, I find that my most cherished possessions are still the ones that I can touch and hold - especially mementos of those I love.  Somehow, if I can just touch something that’s real for them, it becomes real for me, and there we are, standing in a shared reality.  Talk about portals to virtual worlds!

I can’t carry my loved ones with me everywhere I go, but I can be with them wherever I am - so I guess now I’ve discovered Clyde’s mission after all - to bring me into the presence of love and joy with my daughter even while we are physically apart.

Web sites are about sound-bites, so it’s hard to convey a sense of who we are and why folks choose to work and play with us in the messaging constraints of a web site - soooooo . . . we are introducing the Triact Associates Blog, where we will hold forth on topics we hope help you get to know us just a little better