Xojo Web 2.0 with New API 2.0 Event Names

Xojo is usually pretty tight-lipped about future releases with good reason.  We, as users, usually hold them to features that they mention (even when they throw out the usual disclaimers about things might change) so it’s pretty unusual for them to offer any information on future releases.  In the past month or so there has been information leaking out through the forum that says that Web 2.0 is in the later stages of development and they are pretty confident on the feature set.

We already know that Web 2.0 is using API 2.0.  One thing we did not know until recently is that Web 2.0 is going to use the ill-fated new event names that so upset the community in the 2019 R2 release.  We don’t know exactly what the events are going to be in Web 2.0 but we can safely assume the standard Open and Close events are now going to be Opening and Closing.  I (naturally) have several thoughts about this.

First, I think the event name changes are needless.  Opening is not more clear than Open.  Closing is not more clear than Close.  I think the new names are as meaningless as the originals.  So I think using the new events names is a complete waste of time.  Instead of the twenty plus years of institutional memory we all have with event names, not to mention documentation and example code we have to learn new event names.

It won’t matter for Web 2.0.  Probably.  I say probably because we don’t know for sure but the hint is that ALL of the Web 2.0 classes and controls will have new names and thus not affect the 3rd party market as much (although we can presume that anyone selling 3rd party controls for Xojo web has a big task in front of them updating them for Web 2.0).  Does this class name change extend to WebApplication and WebSession too?  Only time will tell.

Another reason why it might not matter is that subclassing controls in Xojo web apps was hard.  Maybe non-existent?  Regardless in our really big web projects we NEVER subclassed web controls.

If indeed every control in Web 2.0 is using a new name it eliminates much of the griping that we had with Xojo 2019 R2 because there is no existing market.  It’s all new there are no naming conflicts.

Since events are added via dialog in the IDE most users will probably just roll with the changes.  Since converting any Web project is a one-way process most users project won’t notice it.  There’s still the possibility of Raising a non-existent event I suppose but I suspect that’s a more advanced feature many Xojo users don’t use and presumably the compiler will give a useful error message.

If the new event names are indeed the future it makes zero sense to have part of the product use Open and another part using Opening.  So this means there are going to be new controls (presumably for desktop and mobile at some point) that have new unique names and therefore use the new event names.  Again, same situation since if they have new control/class names there is no issue with conflicts.  This is similar to moving from the old HTTPSocket to URLConnection with similar functionality but slightly different events.

This last point is the most important one.  If Xojo hadn’t foisted the new events names in the old classes to begin with we wouldn’t be where we are at today.  I still think the new event names offer zero clarity from the old names, but whatever.  I’m just a user, don’t work for the company, and I’m not an MVP so my opinion doesn’t matter.

Okay, Xojo users.  What are your thoughts on using the new event names in Web 2.0?

One last random thought:  Because Web 2.0 sessions have been added at the Xojo Developer Conference (a.k.a. Xojo.Connect) I’m guessing that it will be released as a beta during the conference to attendees.  I am not planning on attending so you’ll have to get your news elsewhere.  This will be the first conference I’ve not attended since 2004 or so.  Hope everyone has fun and gets a lot of useful information out of it.

14 thoughts on “Xojo Web 2.0 with New API 2.0 Event Names

  1. Even the opinion of a MVP doesn’t matter because they are just window dressing. Geoff knows best – just trust his vision or some such.

    The new events are meaningless. There I totally agree. Xojo is now being modelled on Excel users. They understand the “AddRow”. And they probably get the Opening and Closing.

    That we get new controls is really really bad. We get the problems that lead to the removal of the new event names again, just in a different form.

    Geoff said to me that I could change to the new controls “at my leisure”. But there is no “at my leisure” because I live from Xojo and he adds again to busywork.

    If you have custom controls with event definitions the new events can lead to much fun.

  2. We still hope you join last minute as a regular attendee.
    You’d miss the chance to try new stuff and influence Xojo staff on the new things.

    I’d personally wish they would do make old and new event names aliases, so the compiler handles this transparently and you can only have old or new name for something.

    • 90% sure I won’t be attending the conference. I’ve been trying to influence Xojo for nearly 20 years to little, or no, effect. I’m tired of trying.

  3. What always gets me is the PR speak of „the old ways will be around for a long time“ … except bug fixes etc will only be in the „new ways“ so when you run into a bug you can’t work around then you are stuffed unless you use the „new way“.

    That‘s one of the reasons why I prefer the old model of software releases.

  4. As They intend to go to new controls on the desktop so they can be more ‘consistent’ events across platforms sometime in the future, that will obsolete a lot of desktop code… even those the have been had methods and property names API 2 ized already would have to be replaced… And then of course there will be no bug fixes for those old controls and they may not even show up in the library…

    Basically it looks like the desktop API2 situation will continue to be a mess for years because of the event situation.

    As I said awhile back on the forum they should have stayed with the same event names as for web as for desktop EXCEPT when their function was not analogous enough to the desktop to warrant a different name.

    Xojo needs to have people internally that Geoff respects enough who look very critically at his decisions that can argue vigorously with him when his (or other engineers) ideas have significant issues that he does not foresee… but I think over the years those who had been (or could have been) in that have left for various reasons (and perhaps not being heard is one off them?).

    Also from things I read from Ex employees (not Norm) I got the feeling that a group think mentality had set in there awhile back, and anyone who saw things differently were not listened to and/or were isolated.

    No one has explicitly said that, and I could be wrong, but that is what I have read between the lines over time.

    That is dangerous for a small company that relies on innovation IMO.


  5. With only one projekt left in Xojo I’m looking at this from over the fence, but still with great interest.
    I agree that “Opening” and “Closing” are horrible event names. The JS framework I’m using has the notion of “beforeEvent” and “Event” – for example “beforeShow” and “show” events. Most of the events are preventable from the “before” event making it a good way to make sure all pre-reqs are set correctly, load data etc.

    • Since they seem to only be getting any pre-alpha/alpha feedback from the MVP’s so it will be interesting to see what gets announced.

      • And what gets released and when. It wouldn’t surprise me if all the attendees get access to whatever state Web 2.0 is at the moment. Maybe late alpha? Maybe early beta?

  6. Hi! – New to Xojo and just found this blog. Great job! . Is there a Discord for Xojo devs? Would love a place to read and bounce off questions/ideas/etc.


  7. “Opening” doesn’t mean the same thing as “open” (in English at least). “Open” implies all the initialisation has been done (although in many languages this is not so), “opening” implies your code runs prior to full initialisation of the object. In the context of Web apps that distinction could be more important due to the inherent asynchronicity of the environment. This is particularly so when server objects represent client-side functions executing in horrible javascript we don’t care to see sometime in the future in a galaxy far far away. So we will just have to wait and see if there’s a reasonable official explanation or not.

Comments are closed.