For years we’ve been waiting for Web Framework 2.0 from Xojo. Some of us, like me, actually dreaded it because of the additional work it would inevitably entail. Would it be worth the transition? Would it work as intended? Would be it be, dare I say, fun to use?
The Planning Phase
When Xojo first announced that they were reworking the web framework I was, understandably, upset. Not only is GraffitiSuite for Xojo Web a great product line, but there’s ten years of products, enhancements and bug fixes there — not to mention my other Xojo Web-based projects. That’s hard for a one-man shop to cope with. My hope, however, was that Web 2.0 would change little of the API and everything would just work. However, I know that I don’t stick to the same API when redesigning because there’s always something you see that can be done better. API should rarely, if ever, be a limiter of progress.
I started planning pretty early for GraffitiSuite, albeit unintentionally at first. Due to the way the WebSDK for 1.0 worked when it was released, I’d already built a superclass for all of my components to make things work the way I expected them to. This was one of the keys to making my transition from Web 1.0 to Web 2.0 a lot easier, and it would’ve been much more painful if I’d done as I planned and moved my controls off of that superclass when the old SDK was more stable.
When I first heard that there would be an all-new WebSDK, I started making things even more generic so I could offload more of the work from the individual components as I knew my superclass would be sticking around. This separation of the support code (things like parsing strings for FontAwesome icons, converting colors to usable strings, converting Date objects, etc) from the functionality (updating an individual control’s in-browser data, for instance), much like separating your UI code from your processing code, gave me even more flexibility going into Web 2.0.
Shimming JavaScript
As you might have gathered, I knew I’d be writing some Xojo and JavaScript code to glue my components on to the new SDK. I obviously had no way of knowing how much code I’d be writing or what it might look like, so there was a very long and uncomfortable waiting period. Just waiting. Wondering.
Finally, Xojo released the first test build! I spent the next 48 hours digging in to the framework JavaScript looking for hints of how I’d proceed (as there was no documentation or examples at this point) and found my path.
Something I love? The Xojo framework for Web 1.0 relied on a JS class called “Xojo”, but for 2.0 they chose the name “XojoWeb”. This was really key in making my job a lot easier. I created my own JavaScript class named XojoLegacy that loaded in to the browser’s memory in a variable named “Xojo” which matched the needed signatures of the functionality from Xojo Web 1.0 and called their counterparts (with some obvious data conversion work) in Xojo Web 2.0. I made this class safe for use with other WebSDK 2.0 components whose developers might do the same thing by only loading it if the variable was unset, and was ready to start looking at the Xojo side of the conversion.
Shimming Xojo
I went through countless iterations getting my superclass right. It was tiresome and frustrating at times. Getting the event order I needed, loading the data at the right times and in the right places, and so on. I spent the vast majority of the testing phase on this though, if I’m honest, I did a lot of messing around and trying things that I half-expected to not work the way I wanted but would have nonetheless been neat.
I built a lot of test cases. Subclasses of my GraffitiControlWrapper that did little or nothing. Sometimes these are the best investigative tools we have as we can eliminate a ton of variables that are present in established code. Indeed, this process saved me a lot of heartache later as it exposed issues I hadn’t expected and would’ve driven me mad if I’d been trying to track them down in my large Xojo classes.
After getting comfortable with my superclass, it was time to do a real test and put one of my products in Web 2.0. I was hopeful, but realistic. I knew there’d be things to do, and that it would take time and effort. The first thing I noticed? WebStyle was entirely different. Painfully different. Now it was just a class that let you send CSS values directly to a control’s layout. Not ideal when I have tons of code devoted to applying Web 1.0’s WebStyles to various parts of my existing products but, in the end, something easily dealt with. I created a new singleton class called GraffitiWebStyle that allows for users to load in CSS blocks. This was crafted in such a way that I didn’t need to remove the previous code for handling WebStyles, and really turned out pretty nicely. A little app to convert WebStyles from Web 1.0 in to CSS and I was ready to move on.
With all of that sorted out, I could dig in and get things working. The first major issue I ran into is that my first attempt failed to show anything in the browser. After inspecting the DOM, it was obvious as to why. My subclass was creating a DIV with the ID of the control, but Web 2.0 already does that where Web 1.0 didn’t. Removing a couple of lines of HTML that was being sent to the browser cleared that right up. And…drumroll…the product worked! Of course there were little things that needed tweaking and I had to retest everything, but I was on my way!
The Demo
Here’s the most lengthy part of the process, honestly. I started out trying to convert my Web 1.0 demo project to Web 2.0 by loading a copy in the new IDE. This demo has tons of ContainerControls, WebStyles, Images, Pages, and so on. It didn’t come out the way I wanted it to, so I decided to take the more responsible path and rebuild. It sounds awful at first glance, I know, but I’m really happy I decided to do it this way. I get the opportunity to reevaluate how I’m doing things and that’s actually been pretty enlightening as I look at 10 year old code and WebPages.
In the end, it’s still pretty easy:
- I move over the GraffitiSuite product class that I’m ready to implement from my Web 1.0 project to my Web 2.0 project (thanks to my superclass it’s literally just copy/paste)
- I do a test run to look for errors and correct any that I find as there are some minor differences in my implementation
- I create a new demo page and add my component to it
- Layout the demo support controls
- Add the demo code (in most cases copy/pasted from the Web 1.0 demo project)
- Run the project and test
To put this all in to perspective: when I started the conversion process I was expecting to get, at most, two products converted per day. That meant it would have taken me a month to get GraffitiSuite for Xojo Web 2.0 in the hands of customers. With the planning that I did and the right decisions along the way, I can do as many as five with testing. That’s nothing short of amazing!
My Lessons
I learned a lot in this process. A lot about my old code, my own preconceived notions of how the process should work, and about the abilities of Web 2.0. I’ve actually been having a lot of fun doing this conversion as I’m almost constantly getting that “Oh! IT WORKS!” feeling when I hit the Run button.
Another lesson I learned is that rebuilding is worth it. I have a number of Xojo Web 1.0 apps that I was going to convert by loading in the IDE. Now? No way. It’s not that the IDE doesn’t do a good job, it’s that I’m building familiarity with the new framework. That familiarity is worthwhile in itself, and I encourage others who have been skeptical (or downright stubborn) to give it a chance. If you know your project, what you need from your project, and what the goal is…it’s all cake.
Final Thoughts
So how do I feel about Web 2.0 overall? I love it. I’ve always been a fan of jQuery (even though most browsers offer similar functionality out-of-the-box now) and Bootstrap, so seeing that Web 2.0 was going to leverage both made me quite happy. I’m also very glad that CGI is gone as it was always a thorn in my side. Tons of other minor nuisances have been dealt with as well, and it’s making me much more productive.
Remember that the experience I outline here may not be the same as yours. I’m detailing the conversion of custom components and their supporting elements, which is different from converting other types of projects. I do believe that rebuilding rather than converting is the best path forward for generating experience in Web 2.0.
Are there bumps in the road? Sure! Are they worth barreling into at full speed? Oh yeah! Bring it on Web 2.0, I’m ready!