Porting Desktop to Web

I’m just dipping my toes into this web app thing for the first time, and I’m dismayed by the amount of drudgery it looks like it will take to port a desktop app to web. I can copy and paste methods and properties, thankfully, but it looks like all my controls have to be painstakingly recreated from scratch. Are there any shortcuts? It’d be nice if Xojo could take a Label or TextField copied from desktop and automagically change it to a WebLabel or WebtextField…

I dont think you can copy/paste anything from the ui, unfortunately.

Oh my goodness, all kinds of stuff is incompatible, or changed seemingly unnecessarily. Why does a WebPopup have a “SelectionChanged” event rather than the “Change” event of the desktop control? And TextFields, instead of having a KeyDown event which is passed Key as String, have a KeyPressed event which is passed Details as RealBasic.KeyEvent. What the…?

OK, it runs now, but it’s uuuugly. Why do the popups have a different text size than the Labels and TextFields. Ugh, I’m going to have to learn stuff :frowning:

Maintaining an older desktop application and the newer web application is where I really learned the value of disconnecting the UI and the business logic. The UI, whichever event, calls methods. Methods can be moved without too much effort. The transition was quite a bit of work.

@Julia Truchsess , here are some important things that you need to know is that when your app is out in the real world…

  1. There is a delay (however small) between when an action is taken on the browser, when the xojo code runs in your app and then when the result of that code appears back on the browser. It’s what we call “round trip” and it depends on network traffic, how physically far a user is from your app and among other things, how long it takes for your app to respond. The result is that you’re going to have to think asynchronously when designing.

  2. Remember that there are multiple users accessing the app at the same time. Any properties that you want to be unique to a particular user should be attached to the Session object because each user/browser combination gets an instance of the Session class. Any properties attached to App or a Module will be global to all users.

  3. You’ll need to be very careful not to create circular references up and down the Session structure. For instance, Session hierarchy looks like this:

Session Pages Controls Dialogs Controls

It’s very important that the lower items don’t refer directly to the higher ones (like having a reference to Session in a Page). If you do, the Session and it’s contents will never be destroyed, even when a user leaves your app. If you need such functionality, you’ll need to use WeakRefs.

I’m sure there are others, but those are three big ones that we hear about a lot.

Thanks, @Greg O’Lone This particular app is a very simple calculator, with everything (controls, methods, properties) on one Page, so hopefully I won’t have any leaks. Latency will be what it is, not much I can do about that.

The calculator uses a number of lookup tables, and your post has got me thinking that these might be more efficiently deployed in a Module, as there’s no reason (I think) for each session to have separate instances of those.

We also separated the business logic from the UI. While desktop and web interfaces are different, the back-end logic can be re-used between the two.

More tips for Porting Desktop to Web apps are on this page:


just teasing, but be prepared to get some useful tool for this purpose …

I’ve been through this as well. I copy & pasted methods. UI has to be completely recreated. There is no concept of parent controls. If you depend on that, put your controls in a WebContainer class and then place the WebContainer in the UI either at design time or programmatically. “Conversion” is very painful. I suggest using GraffitiSuite Web Controls. We are using them all over.

Many UI properties have been moved to Styles. And as odd as it may seem, Styles don’t inherit from their Parent style, even though the Xojo UI allows for this. Instead. Duplicate the “parent” style, give it the new name, and then add to it.