WebPages are not WebPages

Every now and then a hosting customer emails us and asks the same question:

“When should I use multiple webpages vs multiple containers in a single webpage?”

You would think it would be obvious. Of course like many things with Xojo it is not. At present the web framework doesn’t seem to make any distinction between web pages and containers. If you use implicit instances of your webpages it just loads the default page you selected when a Session is created. From that point forward a webpage and a container are nearly identical. The only difference is how you go about calling/embedding them.

One glaring problem with webpages not being special is they are not treated as traditional webpages. When the web was created it was created a series of documents (initially only HTML). You moved between documents by setting the URL in your browser. To navigate from page1.html to page2.html you just requested page2.html and the server served the page2.html sitting on the servers filesystem.

With Xojo webpages are not individual pages sitting on the server’s filesystem. They are just a container of controls in Javascript. This means you can’t navigate between webpages with a URL.

In a recent project it became clear we needed the ability to load a specific page. Specifically for oAuth purposes. If a user needs to grant our application access to post to Twitter for example on their behalf we have to forward them to Twitter to acquire the necessary tokens. On the way back from Twitter the user is forced to log back into the application and lost all continuity between their previous and current session (never mind its an entirely new session!). This is was not a desired user experience. We want the user to dig into the menus, select “Authorize Twitter”, be taken to Twitter, then return exactly where they left off as if nothing had happened.

The first step of that is enabling Xojo to understand the distinction between webpages. Make them a first class citizen like traditional webpages. We are introducing the WebPageController class. It’s purpose is to create a high level abstraction of moving between webpages in your web application. You no longer hide/show webpages. You simply add instances of them to the controller, then ask the controller to load a specific webpage when you need it. Your session’s HashTagChanged event can also do this so you can navigate to specific pages just by using a hashtag.

Find on GitHub
MIT Licensed

Upgrading Xojo CGI Apps

One of the things my customers and I have discovered is that updating Xojo CGI applications can be difficult.

Some people used special key combinations or administrator-only buttons to shut down their application executable. Others just tried to upload the new binary executable right over the old. Of course the FTP may let you do that but the old version is still running because people are still hitting it! Then you encounter “can not launch application on port 1234” for example because the old version of your binary is still running on that port.

So working with our customers we have developed a solution:

1. Add a timer to your WebApplication’s properties.

2. In the App.Open event let’s instantiate that timer and set it to fire every 5 seconds. Let’s also use AddHandler to handle the Timer.Action() event.

3. Let’s create the “timerShutdown_Action” method. This method will be fired every 5 seconds and it will look for the existence of the Appname.cgi. This file is created for you by Xojo when the application is compiled as a Linux CGI. Don't forget to add "sender As Timer" to the parameters or it won't compile!

You can see here we are getting a FolderItem object for the current directory. We are then appending the path of our current directory to the lowercase version of our application’s executable + “.cgi”. So if you name your Xojo WebApplication “TestApp” then when you compiled there was an accessory “testapp.cgi” file created. This is the file that connects your web application to the web server. It is the gate way in which your users use the application.

So we check to see if its still in the root folder sitting next to your application. If it is, great! That means everything is humming along exactly as it should. However if that file were to go missing, the WebApplication would just shut itself down.

4. So to deploy a new version of your Xojo Web Application you just delete the accessory .cgi file for your app, then wait a healthy 5-10 seconds and the app will shut itself down. Replace your files (including the CGI) with your new version and your users will be back in business.

If you attempt to shut down all sessions or shut down the app from inside the application itself you will run into issues. One customer was doing exactly this. They had set the WebApplication.AutoQuit property to true and then would loop through all the sessions performing WebSession.Quit(). This sounds great in theory but the problem is even if all sessions disappeared and the application shutdown, the CGI file sitting next to your application will just launch a new version of it.

So I hope this solution works for you as a quick and easy way to update your Xojo CGI Web Applications.