Web 2.0 Questions

Targets Web
1

Hi,

as some of you know - the main application of our company (8 Employees till now) runs completely on the the Xojo WE. Our clients are authorities and local governments all over in Germany. Our application is some kind of “system relevant”, so we are very gingerly with changes (except of bugfixes, for sure).

We got used to all the the little and bigger bugs and tweaks in Web 1 Framework, but thats why we were really looking forward to Web 2.0.

Now, as I watched the Web 2.0 Video of @Greg O’Lone, a lot of questions and worries came to my mind.

  1. Most Important: will Web 1.0 stick around once Web 2.0 is fully released? I worry about, that our project with over 40 partly highly complex custom controls will not be transferable.
  2. Will the structure with the App and Session objects stay the same as in Web 1.0?
  3. How will the new WebSDK work like?
  4. Will the control-name structure in the frontend stay stay the same? I mean with random ids and something.
  5. Why are you using jQuery and Bootstrap? There are several better Frameworks out there. These two already feel old and outdated and it will not getting easier for us find young developer with such a conservative software stack (just our opinion).

There are more questions in our mind, but that are the most important which could break our project.

Thanks, and: anyway, this seems to be really good work Xojo.

2

The new IDEs will only support Web 2.0, but you can always use an older version of the IDE to support Web 1 projects.

Mostly. App and Session still exist, but we’ve refactored some things based on bug reports and feature requests we’ve gotten over the years.

3

Similar to how it does today, but since we have redesigned everything From scratch, the WebSDK has to be similarly refactored. Because a few things are still in flux (like listbox) the WebSDK specs haven’t been frozen yet.

This hasn’t changed although we’re using less characters. After doing some math, we found that we could reduce the length and still maintain the entropy.

4

The main reason for using Bootstrap is that it gave us a huge selection of quality, liberally licensed (MIT) controls to choose from. Our thought from the beginning of this project was that we didn’t want to get bogged down having to create and maintain lots of controls from scratch and would rather be providing the glue that makes Xojo web apps easy. jQuery is there because Bootstrap relies on it.

5

I’d like to add a little to my comment about this…

We looked at lots of different frameworks when doing the initial planning and research and one of the things we were looking for was stability. Remember, we try really hard not to break user projects, and every time we make a shift like this, we often have to break that rule. Whether it’s because the underlying framework doesn’t support something that the previous one did or something else like that, but we really wanted to be working with frameworks that had some history, were very stable, weren’t going to disappear a year after we implemented them and we could depend on for the foreseeable future.

Some of the the frameworks we evaluated back then never made it to the mainstream and don’t even exist any more.

6

[quote=480918:@Greg O’Lone]I’d like to add a little to my comment about this…

We looked at lots of different frameworks when doing the initial planning and research and one of the things we were looking for was stability. Remember, we try really hard not to break user projects, and every time we make a shift like this, we often have to break that rule. Whether it’s because the underlying framework doesn’t support something that the previous one did or something else like that, but we really wanted to be working with frameworks that had some history, were very stable, weren’t going to disappear a year after we implemented them and we could depend on for the foreseeable future.

Some of the the frameworks we evaluated back then never made it to the mainstream and don’t even exist any more.[/quote]
I think the described plan was a great decision

7

Hi there,

how fast is the new canvas? Could you also create a 2D web game with it? How big is the difference to the old canvas?

Thanks Norbert

8

@Greg O’Lone. My question is related to the one above from @Norbert Kollmetz. Rather than a 2D game, I’d like to be able to display medical radiology images in a browser (scroll through CT images). I have already written a library in Xojo to parse these files and output the images as JPEGs which could be pushed down to the browser. Does the client do any caching of images? Would I be able to send down 50 or 100 images for caching and then scroll through them by intercepting the MouseWheel event perhaps?

9

@Greg O’Lone. Regarding the new Listbox, it still seemed a little laggy when scrolling, mostly due to the brief display of the hatched blue stripes indicating that the client is pulling down more data. Does the client do any caching of upcoming rows? This might mask the fact that its polling the server a little more slickly?

10

[quote=480921:@Norbert Kollmetz]Hi there,

how fast is the new canvas? Could you also create a 2D web game with it? How big is the difference to the old canvas?

Thanks Norbert[/quote]
For the first release, the Canvas hasn’t technically changed and we’ll be upgrading it to be backed by jCanvas later this year.

That said, communications between the server and the browser (and vice-versa) have been optimized quite a bit, so you’ll probably see some improvements there.

11

I suspect that you’d still need to write your own WebSDK control for doing this, probably similar to the way Google Maps works in that they download the tile you are looking at and the eight surrounding it… but you could certainly do that in the current web framework if you wanted to.

12

It does actually. The listbox caches 5x as many rows as are being displayed at any given time, but if the user decides to scroll quickly beyond what is cached, there will always be a refresh delay.

13

Thanks for clarifying @Greg O’Lone and well done on your hard work.

14

Currently we currently have about 40 or so customers who use our web app based on a sub domain.

Example: usd101.domain.com, usd201.domain.com, and so on.

These sub domains currently all access the same webapp but we separate database connections and other items within the application based on the DomainURL

Is Web 2.0 going to change how this works?

15

[quote=480933:@Jeff Hamby]Currently we currently have about 40 or so customers who use our web app based on a sub domain.

Example: usd101.domain.com, usd201.domain.com, and so on.

These sub domains currently all access the same webapp but we separate database connections and other items within the application based on the DomainURL

Is Web 2.0 going to change how this works?[/quote]
Our goal is that in the new control panel you’ll be able to add a domain (or subdomain) and then tell it which app to point at. I see no reason why we wouldn’t allow you to point multiple domains at the same app.

16

Thanks Garry! I can’t tell you how happy we are to be so close to getting it into our users’ hands!

17

I’m assuming this will still use to use that subdomain to tell the application which database to use? in our case, each subdomain corresponds to a different database.

18

I liked the video. Here’s my questions and feedback:

BrowserHistoryTrigger
Is there a limit to data size? I don’t need anything massive but having something extend beyond the short URL character limit would be nice. This could be dynamic too. So when the Data is too long it instead uses a token which references a local storage version of the state. Would be harder to “modify” by the general user but would make worrying about the length of the data easier for developers.

SVG
Will there be a designated SVG control? You mentioned how you could swap the ProgressWheel SVG for a different SVG. Will ImageViewer be cross-compatible with SVG’s or will we need to hack the ProgressWheel and turn of the spin?

Listbox
Will we be able to control the “fetch” size of the infinite scroll?
Just re-iterating that can we PLEASE get a WebContainer as a Custom Column Type as this would really reduce the overhead in designing these especially for novice users.

MenutItem
I didn’t see “Icons” as part of the feature set. Please tell me this will be included(?)

WebSDK
It would be cool if you sort of supported our existing WebSDK controls in Web 2.0 kinda as-is with no future improvements and instead made a new WebSDK control that’s more standardized. That would make project migration a lot more seamless.

ActionStacks
I kind of hacked a feature like this in Web1.0 I Would call Script.StartRecording which did an ExecuteJavascript to start a function definition. Then I would do whatever I wanted in code. Then call Script.EndRecording which use ExecuteJavascript to close out the function. This allowed me to capture all the events Xojo ran on the browser and wrap them nicely in stored, reusable and loop able event. The only downside was the Server-Side model would get out of sync. I’m curious if you have any details on how this might work? Will the ActionStacks do something similar but allow the server-side to stay in sync?

Visual Session Controls
Can you go into more detail about this? I didn’t really understand what you meant in the video.

LayoutModes
I’m excited to see the move to Bootstrap 4.4.x. Will it be possible to specify column-count in the Fluid mode? Bootstrap 4 now uses flex-box behind the scene as the CSS implementation but IT IS STILL a 12-column grid layout system. Almost all of the modern layout frameworks use a column-based approach coupled with screen size media queries.
I know you mentioned a future item for supporting more Multiple Layouts per view. I think this could work but there could be a few flaws this solution could have that I hope can be avoided!

  1. Being able to say Small(12) Medium(4) Large(3) for columns without having to maintain 3 separate layouts is very important. In most cases I don’t want to actually maintain the properties of 3-4 screen sizes for every single control (only certain ones) so when I set something to Small(12) I know that means also for medium and large and “everything up” unless I bother to go change them otherwise.
  2. Having to constantly reposition and resize my controls for every layout would not be fun. I know when I say S(6) it is exactly half and positioned correctly - no manual process or mistakes.
  3. Being able to simply resize my Xojo IDE window to see the responsiveness change through different screen breaks or “Layouts” seems a lot more useful than having to manually toggle through each Layout. I understand this might not make sense for Locale specific layouts but I think this feature would be very useful.
  4. Having to switch between each layout to determine the size of a control on each layout or to change its size makes each control difficult to understand and manage. So being able to see what size the control has across all Layouts in the properties panel without having to change anything is important.

I was thinking about managing control-level style properties with multiple layouts. Here’s a couple ideas I had.
1) me.layout(0).style.borderColor = &cFF0000
2) me.layout(“S”).style.borderColor = &cFF0000
3) me.style.borderColor(&cFF0000, &c880000, &c660000) **ParamArray, And when given less properties than total layout count the last property is applied to all remaining layouts.

I think it would also be more helpful to allow the creation of an application LayoutSet. This is where you could set rules like screen size or locale requirements for each layout. Then you could set the LayoutSet on the view. This way you wouldn’t need to recreate your page-size breakpoints and locale options for every single view. You just reuse your layout set!

19

Oh, and how about existing IDE bugs or so? What if the IDE in last Web 1 version has some bugs? And how about existing bugs? Will they stick around forever, when you abondened the Web 1 Framework?

How about the documentation? As you delivered API 2.0, all docs were updated, ans users of older versions were in the unfortunate position, that they haven’t have an online documentation anymore.

How about providing a LTS version of Web 1?

As I said, our complete company relies on this. And because the changes in the UI and the SDK are tremendous, I doubt that we can convert it to Web 2.0.

Not to speak about possible bugs which are surely occurring after such changes.

20

Lets put it this way… you’ll still be able to find out what subdomain called the app, so that logic would be handled by you (as I’m assuming it is today).