Web 2.0 Questions

Targets Web
62

[quote=481133:@Norman Palardy]LTS as in “critical bug fixes will be applied to this LTS version as they are found” like Ubuntu does with their LTS versions ?
That would be nice (and damned surprising)

[/quote]

[quote=481136:@Greg O’Lone]As you know and have stated many times when you were an engineer here, Xojo doesn’t back-patch older versions of the IDE.

2019r3.1 will be the last build of Xojo which has any support for the old web framework whatsoever and we will not be fixing and more of the bugs reported against it. If you want or need to use the old web framework, that’s the one to use.[/quote]

@Norman Palardy this is the exact thin I asked for.

I am not talking about the bugs in the webframework. As I said, we got used to it. But there are several bugs in the IDE itself.

I was asking, if there will be a LTS Version of the Xojo web 1 framework, because there is a high potential, that not alle project can be translated into the web 2.0 framework. Xojo is not only used by hobbyists or “citizen developers”. We’re a professional company with high professional demands. And we took results with the web 1 framework further as some couldn’t imagine.

If the Framework is not continued, which we’ve chosen 6 years ago, thats fine. That’s how it goes. But that the development environment expires is critical.

There’s no other company or professional tool which comes to my mind, which discontinous its product without an extendable support from one day to another.

To be honest. It was always risky for us to use Xojo. Because no one knows it, because of its own IDE and because we’re hardly rely on things that the Xojo Inc. plans.

Our reaction now is, that we have to put hundrets of hours of work in a rewrite of our application, just to get newer IDE versions. We will see if its not maybe better to completely change to another stack.

Please don’t get me wrong. I really appreciate the hard work you put into the new framework, and it seems to become a well working product. But the underlying strategy of completely abandon the old one is making me nuts.

Sorry for the rant. But I’m kinda frustrated about the news, even though I was very looking forward to web 2.0.

63

Sorry for my ignorance Lars but if, as you said,
“and we took results with the web 1 framework further as some couldn’t imagine.” and
“because we’re hardly rely on things that the Xojo Inc. plans.”

then what if still use older versions of Xojo framework for the already developed projects and use the new Xojo framework for future ones?
Off course I agree with you for the need of a tools that will parse and “translate” the old to new framerork to the new one, at least to an extender degree that be ready for a most extensive developer’s review for fixing manually points of interest in its code… but maybe Xojo wants to leave it for external third-party developers…

64

I understood from Greg presentation that current projects could be migrated to Web 2.00, with the same one way feature as API 1.00 to API 2.00, which means Web 2.00 projects would not be backward compatible. No matter the work involved to migrate from one API to another, it will be nowhere near the amount of work involved into moving to another development tool.

@Greg O’Lone :
Among the requested features I regularly see in the forum is the possibility to edit cell content. From your presentation, there were not many details about the new WebListbox, besides the dynamic loading.

Is it possible to edit cells content ? Or is it planned ?

65

The thing is not, that we have to use an older version of Xojo. I complain about, that we are forced to stick to an IDE version is far away from being bug free. I just want to profit from future IDE changes.

What if Apple changes a thing, which makes the old IDE unuseable in the future?

Every company which delivers developer tools or languages abandon their frameworks from time to time, but they remain usable in future releases, until day X in a forseeable future, like Microsoft does with .NET 2.0 - 5.0 in VisualStudio, or Apple with Cocoa.

The most IDEs keep their backward compatibility. That was my point.

66

[quote=481396:@Hanif Saad]Hi Greg,

The existence of HandleURL and HandleSpecialURL looks just fine. We use HandleURL to handle and supply response towards Javascript( ChartJS, Pace etc) and HandleSpecialURL to response towards user API call (database CRUD etc). It makes separating the logic and code easier. and less conditional statements. So, there are no more HandleSpecialURL in Web2.0?

----1. HandleURL-----:

// Chartjs script file Request----------
dim jsfiles() as string = array(“pace.min.js”,“Chart.bundle.min.js”, _
“chartjs-plugin-datalabels.min.js”,“utils.js”)
dim cssfiles() as string = array(“pace-theme.css”, “ourapp.css”)
dim jpgfiles() as string = array(“landingpage.jpg”)
dim i as integer
dim handled as boolean = false
for i = 0 to jsfiles.ubound
if(Request.Path = jsfiles(i)) then
handled = true
Request.MIMEType = “application/javascript”
exit for
end if
next i

if(not handled) then
for i = 0 to cssfiles.ubound
if(Request.Path = cssfiles(i)) then
handled = true
Request.MIMEType = “text/css”
exit for
end if
next i
end if

…

— 2. HandleSpecialURL--------

Lots of if then else / switch for CRUD operations and data parsing especially from microcontrollers, pi and smart phones…[/quote]
There is not. You can always just check to see if the first part of the path is “api” or “special” and call some other method to separate your logic.

To clarify, HandleSpecialURL came first in the old framework. It was created by my predecessor to solve a very narrow need. Then we started getting requests to broaden the scope and HandleURL was added. It’s what HandleSpecialURL should have been all along.

67

[quote=481417:@Lars Lehmann]@Norman Palardy this is the exact thin I asked for.

I am not talking about the bugs in the webframework. As I said, we got used to it. But there are several bugs in the IDE itself.

I was asking, if there will be a LTS Version of the Xojo web 1 framework, because there is a high potential, that not alle project can be translated into the web 2.0 framework. Xojo is not only used by hobbyists or “citizen developers”. We’re a professional company with high professional demands. And we took results with the web 1 framework further as some couldn’t imagine.

If the Framework is not continued, which we’ve chosen 6 years ago, thats fine. That’s how it goes. But that the development environment expires is critical.

There’s no other company or professional tool which comes to my mind, which discontinous its product without an extendable support from one day to another.

To be honest. It was always risky for us to use Xojo. Because no one knows it, because of its own IDE and because we’re hardly rely on things that the Xojo Inc. plans.

Our reaction now is, that we have to put hundrets of hours of work in a rewrite of our application, just to get newer IDE versions. We will see if its not maybe better to completely change to another stack.

Please don’t get me wrong. I really appreciate the hard work you put into the new framework, and it seems to become a well working product. But the underlying strategy of completely abandon the old one is making me nuts.

Sorry for the rant. But I’m kinda frustrated about the news, even though I was very looking forward to web 2.0.[/quote]
We thought long and hard about this decision and there were several reasons for abandonment.

First is that the old framework is going on 10 years old. It was built at a time when jQuery was in its infancy and bootstrap was but a twinkle in somebody’s eye. Unfortunately our framework had some design flaws which made it nearly impossible to fix the underlying problems without breaking everything like dominos.

We also don’t want to have to maintain two web frameworks… and we would have had to. If it’s in the product, people would have expected us to fix bugs in it. This way means we are fixing a huge swath of reported bugs and feature requests, and getting everything up-to-date all at the same time.

Lastly there’s the confusion factor. Having two similar controls From different frameworks with the exact same name (let’s say WebButton) is problematic in the IDE, not to mention confusing.

68

[quote=481425:@Michel Bujardet]I understood from Greg presentation that current projects could be migrated to Web 2.00, with the same one way feature as API 1.00 to API 2.00, which means Web 2.00 projects would not be backward compatible. No matter the work involved to migrate from one API to another, it will be nowhere near the amount of work involved into moving to another development tool.

@Greg O’Lone :
Among the requested features I regularly see in the forum is the possibility to edit cell content. From your presentation, there were not many details about the new WebListbox, besides the dynamic loading.

Is it possible to edit cells content ? Or is it planned ?[/quote]
Cell editing is something we want to do and is on the roadmap. I just don’t know if it’ll be in the first release. The control we’ve chosen can do it, but we have some things to work out first.

69

Look, we make changes to the IDE all the time, but making this contingent on the IDE being “bug free” is a non-starter. No product of this size is ever truly free of bugs. Things do get deprecated and removed from the product from time-to-time… and we’ve been publicly talking about this change happening since XDC 2016. [quote=481438:@Lars Lehmann]What if Apple changes a thing, which makes the old IDE unuseable in the future?[/quote]
The only time I can recall this in the entire time I’ve worked with this product (that is way before I worked here) was this latest Catalina thing where it ran only 64-bit apps, but there are easy solutions… keep an older Mac or macOS around or run an older OS in a VM. [quote=481438:@Lars Lehmann]Every company which delivers developer tools or languages abandon their frameworks from time to time, but they remain usable in future releases, until day X in a forseeable future, like Microsoft does with .NET 2.0 - 5.0 in VisualStudio, or Apple with Cocoa.

The most IDEs keep their backward compatibility. That was my point.[/quote]
And yet they don’t. Visual Studio no longer compiles VB6 and Xcode no longer compiles Carbon or even 32-bit apps.

70

As I said, I understand this. No one is able to deliver a bug free software. But your software is the basement of someones businesses, with employees, customers and so on. So if you make decisions for your product, you do this for their products as well. And if you plan to stop fixing bugs in an enterprise environment, then you’ll put up with the fact, that someone who had trust in your product could get into trouble some day. I’m not talking about the near distant future.

But think about, if a project can not be translated into the new framework, then it is not unrealistic, that your current IDE version will stop working after a couple of months or a year or two. This is just one new MacOS version ahead. And then?

There were others, for example as Apple changed their security behaviour and suddenly no debug on web project were able to connect.

Thats a nice Idea, I’ll keep old Macs for my young employees, that they can work on a legacy language. Other hint would be to close the business at all.

Yes after years. Sure new frameworks and tools will come, and thats a good thing. But VB was maintained for 6 years. It also was possible to transfer your apps to 64 bit in a wide time range (1.5 years or so?). They always supported the old things for several years until they finally got kicked. VB.NET still sticks around in maintanance, even though it’s old and has no future.

I’m not saying, that you have to keep web 1 for ever. I’m saying, that you deliver a new framework which no one had his hands on, where no really practical testing and deep tested user feedback could be collected and you’re canceling the old one from day one on. This like you had ship API 2.0 while killing API 1 and the “new Xojo freamework” from one day to another. That also would have cause a lot rumble in the community.

71

Catastrophizing?

Maybe if you actually run into a show stopper problem in the future that can reasonably be fixed the last version of Xojo that supports the original web framework, you could present your case to Xojo then and even offer to pay for some developer time to fix the problem. I would think they would at least consider it at that point. Right now you’re just tilting at windmills.

72

I’ve been reading this post for days and as you can see each of us has different needs and we are entrusting our hopes to the new framework. From what I saw in @Greg O’Lone’s presentation I think he did a great job and I thank him for that. After reading @Lars Lehmann 's various doubts I can only go along with his line of thinking. I’m very concerned about the transition to the new framework… Because of the API 2.0 I couldn’t use the HTTPSecureSocket anymore and I had to stay still at 2018r4. For many people it’s just a bug, for me it means that if I had to update xojo for some other reason, I have to tell the customer that he can no longer send invoices. This is just a comparison to show that certain decisions made by xojo can cost many of us dearly. I’ve been using xojo for 5 years, and even though I’ve used the forum a few times, I’ve always seen a friendly community willing to help others. Lately, however, I’m noticing too many unhappy users. The worrying thing is that, from what I could see, it seems that the xojo team is not very open to listen to some needs. The answer is create feedback and you’ll see… I also don’t understand why nobody else on the team is answering all these questions. I don’t think all these decisions can be made by Greg alone. Ok the rest of the team will be working on Android, Worker, PDF etc. but since the current target is web 2.0 I think these things need to be revised.
I apologize for my English if some things are not clear.

73

Can we let Greg get back to work on the framework itself rather than answering a bunch of questions here.

The guy is already wearing a cape and getting dressed in a phone booth.

74

Any project from Web Framework 1.0 should be able to transition to Web Framework 2.0. How much effort will be required will of course vary. However, this is a cost of doing business. We have not gone back to versions of Xojo prior to the current major release and patched either. If someone using a build from 2016 said they can no longer build apps for Mac because that release doesn’t build 64 bit, we would tell them to upgrade to the latest version. That upgrade might involve them having to deal with other issues because things to change as well know very well.

Yes transitioning from Web Framework 1.0 to 2.0 isn’t as simple as opening the project and looking for things that have changed. You WILL have compile errors that you WILL have to fix before you can run. So there is a cost, but it is a one-time cost. It’s a cost of doing business. While it could be argued that us patching old versions is also a cost of doing business, we almost never get asked to do that. As a result, we don’t make a habit of doing it. Web Framework 1.0 has also been around for a long time now so if there were any showstoppers, we’d likely know about them. Having said that, some day far down the road, something may come up making Web Framework 1.0 unusable with the then current versions of various web browsers. Hopefully, no one will have waited that long to transition.

While I understand the concern, I strongly urge you each to wait until you have a pre-release or actual release to try. Then you can see how big of a one-time job you have in front of you.

FWIW, I have been converting a desktop app to a Web Framework 2.0 app and now that I have recreated the layouts, because both are API 2.0 compliant, I can just copy and paste code between the two projects will little to no modification.

75

Actually, what Lars means is that even when .NET came out in 2002 with no support for VB6 code, old IDE, languaje and runtimes got support and bugfixes until 2005, when .New was in their third release.

“Bug free” means that most other tools make A big release and then just bugfixes to fine tune the tool instead of fixing some thing, broke others and having various releases installed acording to the target or the proyect.

But, yes, this one is on Lars, this release mode is the xojo way, as advertised, you get early access to new features in exchange of a more stable releases and LTS.

76

Don’t get me wrong, but maybe you’ve lost them as customers before they can ask?

That is what we now have to do. We have to wait until every decision is made. :slight_smile:

My Concerns are not about the code, they are about the layout and huge custom controls. You have to know, that almost 50% of our entire application is made of custom controls, because the inbuild ones were not suitable enough for us. Not to talk about the huge CSS altering we did and the bigger size of some new controls.

We’re facing the fact, that we have to rewrite (or reassemble) our entire frontend - across over 600 UI components.

Just to clearify this:
I don’t complain, that there will come a new framework. Thats awesome.
I complain about the hard killed Web Fw 1. We’re only one MacOS update away from the time where we’re not able to use the old IDE anymore (the IDE itself, not the compiled program).

And: as I know Xojo from the last mayor releases - Web 2.0 will not be bug free. That would also be no problem, If we could use Web 1 until it’s fully stable.

Most of the changes are communicated months before. If Web 1 comes to a point where it can hardly not continued, then this is known months before and it can then be abonded. That is how I experience the end of other products life time.

Anyway, I don’t think, that I am alone with my complains. We’ll see whats happening. Thanks for listening.

77

Apropos of nothing but “Catastrophizing” is a word I learned from one of my son’s Jr High counselors and it is an AWESOME word.

78

also… all our questions and concerns can be made concrete or made to evaporate as soon as you do a pre-release :slight_smile: A significant portion of them will just evaporate once we can actually use the thing :slight_smile:

79

Will there be a way to Xojo.TriggerServerEvent on controls other than the WebSDK custom control? It would be nice to subclass the existing controls and add functionality for them to capture new events.

I did this for instance in Web 1.0 on the WebListBox when I needed custom controls in certain cells and columns.
I first subclassed the WebControlWrapper as an “EventListener” object with no visual component.
Then had this pass off the ExecuteEvent to the WebListbox. The subclassed WebListBox would then get assigned an EventListener property that had to be manually hooked up for each instance.

While this worked, it was a bit of a hassle to implement and hook up all the time. Exposing “ExecuteEvent” for all the controls that gives us any event that Xojo doesn’t handle would be a nice feature.

80

Oh this would be nice. As an alternative usage case, I needed to trigger the Resized event on children controls when implementing the BKS_WebSplitter. I’m sure there might be other reasons to tell the Xojo framework that a control has resized from Javascript.

81

Hi what version on XOJO have Web 2.0 ?

thanks