So a little fun bit of backstory. I'm updating a web form at work and basically what it does is allows a user to order some brochures by selecting the quantity of each brochure they'd like to order. Clicking submit takes you through the process of going to an order confirmation screen, inputting your address and finally getting an order complete screen.
Sounds easy enough, right? Well, read on my friends.
I got a change request (oh, I do love the change requests..) to add an out of stock message to the second screen (so the order confirmation screen) saying which brochures are...well, out of stock and will not be shipped until they come in.
So this is basically easy to do. Let's break it down.
1. Find out which brochures are out of stock (this is pulled from the database)
2. Put these items in an array
3. If the array has contents (hey, sometimes the user is smart and orders brochures that are actually in stock! who knew?) they display the out of stock message and list the contents of the array.
Oh joy! We're finished....let's set the task to 100% and...oh wait. There's a button where the user can go BACK to the first screen and change up their order? Shit.
Normally this would have been fine, if the first screen was a part of the multiview. But it's not. It's its own separate weird entity that populates a data table and remembers what the user picked last time they were here. That's pretty neat. It's too bad that the button used to get BACK to this screen does a stupid javascript postback which causes any ASP.NET control which may have to be changed (like maybe... an out of stock message) to be completely invisible to the server because...the postback never gets to the server level.
This form is a beast. Re-writing it would take a ...really long time. The solution? The button no longer does a postback, but clears out the form and forces the user to start over. Not a bad solution. Not a great one but hey, business logic wins again. Because kids, if you can't do it well, at least you can do it fast.