« Contacts history for … | Home | Register Script for M… »

Moving from Web 1 to Web 2

Now we are 2022 and Web 2 is out there for two years. We still have to move some Web 1 projects to Web 2 and we build up technical debt by waiting. If an easy transition is not possible, the decision may be to either rewrite projects from scratch in Web 2 or to move to other tools beside Xojo. But let's look into the details:

One thing we used a lot of control sets. Those are still not supported for Web 2 as of Xojo 2021r3. You can open the old project in the new IDE and they show in the control list as group (since the IDE can do it for desktop controls). But it won't compile for some reason. When you try to create a new control set, you get the message in the IDE, that control arrays are not supported. Reworking old projects with hundreds of controls in control arrays doesn't sound practically.

We use styles in our projects. The WebStyle objects import, but the editor for them is gone. They are basically now passed to compiler as classes, so all style assignments need to be reworked. Sadly the new IDE doesn't show any more what style is assigned to a button, so we would have to go through all controls in the old IDE to write down which style was assigned to which control and recreate that in code. For most styles, we may get rid of them by putting in a global bootstrap.css file into the project to define the base styling for the whole app.

The event names changed are something we have to deal with. We can't easily do search and replace in the IDE, but maybe we could do that with text format for the project. Like replacing "DoubleClick(X as Integer, Y as Integer, Details as REALbasic.MouseEvent)" with "DoublePressed(row as integer, column as integer)". But then we may still have to look for those events use maybe the parameters there. Maybe also "#Pragma Unused" needs to be updated since the parameters passed changed. We'd wish the IDE would help on batch converting events there.

We have a couple of functions looking on platform property in the code base. Mostly to do statistics on what devices people use and to switch to smaller mobile layout dynamically based on the device if needed. We have a desktop layout designed for a wider screen and a mobile one which needs scrolling, since it's more narrow, but very long. We may still do that, but now have to relay on the size of the webpage. Some example projects for Xojo suggest to check whether width and height is >420 to use desktop layout and mobile one otherwise.

Method name changes are annoying. It would be much easier if the developers at Xojo spend the time to define the new name as aliases for the old names. Or keep the old names for compatibility and marked them as deprecated like on desktop controls. Here is a list to translate a few of the changes:

ListIndexSelectedRowIndex
RowTagRowTagAt
CellCellValueAt
DeleteAllRowsRemoveAllRows
RemoveRowRemoveRowAt
RowTagRowTagAt
LastIndexLastAddedRowIndex
HeadingHeaderAt
ConfirmMessageConfirmDisconnectMessage
TimeOutUserTimeout
ShowURLGoToURL
MsgBoxMessageBox
SegmentIndexItemIndex
Text on WebPopupMenuSelectedRowValue
ForeColorDrawingColor
DrawRectDrawRectangle
FillRectFillRectangle
PenWidthPenSize
DrawStringDrawText
FillRoundRectFillRoundRectangle

The new names may sound better, but the burden of changing all the names doesn't get easier, even after years of API 2 improvements.

Some things are missing or I can't find them anymore. LaunchMessageDelay for example. All the code using WebToolbar needs to be updated since WebToolbar editor seems to be gone. All the toolbar definition now needs to be done in code. So we have to go back to old Xojo version and write down what the toolbar looked like and recreate it in code. Since WebToolbarButton lost the name property (Why?), we may use Tag to decide what to do. WebToolbarContainer is also gone, so no search field any more?

We miss ColumnStyle in the listbox to define right alignment for columns. Seems like you can use WebListBoxStyleRenderer class, then put in a custom style, where I set a custom CSS property to get alignment. Not convenient, but maybe possible. And certainly not convenient to setup a renderer for each row. Maybe we can cache the object and reuse it.

Once you fixed all those bugs, another thing stays and those are unclear problems reported:

CustomerDetailsPage.InvoiceList.Name Layout (property name)Syntax error
CustomerDetailsPage.LoadCustomerTimer.Name Layout (property name)This item does not exist
CustomerDetailsPage.LoadCustomerTimer.Name Layout (property name)Type "Int32" has no member named "Browser"
InvoiceDetailsDialog.InvoiceItemList.Name Layout (property name)Syntax error

The old timer used for LoadCustomerTimer does show a Left and Top property in the inspector, but a newly created timer doesn't show that! By creating a new WebTimer there, copying the run event and then deleting old and renaming the new, two errors are fixed. Looks like the compiler creates code to assign left and top and then complains that those don't exist.

Instead of recreating, it seems like saving project as text format and then loading it again seems to bring the InitialValue property back. It was there and value got preserved! Just for some reason it wasn't showing. Sadly, the project doesn't build as it's something else. Looking further, I found this:

InitialValue = "#Strings.InvoiceNumber #Strings.DatePaid #Strings.Total" You may know Xojo assembles code to initialize the web page before calling the Opening event in the constructor. And this code gets wrongly generated if the constant used is localized, I presume. Reported as case 67291 via feedback.

What does it all mean?

We are in 2022, Xojo Web 2 is about two year old, but porting an older project is still a major tasks with rewrites in lots of places. For a new project, using the Web 2 framework may be compelling. But porting an older project may be a challenge, not possible or simply too much effort. I hope Xojo Inc. can make that path easier with a few changes in releases later this year.

13 01 22 - 10:06