[quote=480942:@Brock Nash]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.[/quote]
We have not set any artificial limit.[quote=480942:@Brock Nash]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?[/quote]
The ImageViewer will now provide the correct mime-type for svg.
[quote=480942:@Brock Nash]Listbox
Will we be able to control the “fetch” size of the infinite scroll?
[/quote]
If the underlying control supports it, I see no reason why we couldn’t make that possible.
[quote=480942:@Brock Nash]
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.[/quote]
Funny that you ask this. Today I’m actually working out some of the details surrounding custom column types. While I doubt that using WebContainers will be in the first release, it’s something we could investigate. To be honest, I do have some concerns that actual WebContainers would result in too much traffic to be responsive though, but we’ve got some ideas about pushing HTML templates to the browser that I bet would come in very handy here.
[quote=480942:@Brock Nash]MenutItem
I didn’t see “Icons” as part of the feature set. Please tell me this will be included(?)[/quote]
Yes. WebMenuItems do support icons.
[quote=480942:@Brock Nash]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.[/quote]
From the WebSDK controls I’ve seen thus far, I’m not sure that this would work. How we create controls on the Xojo side, the DOM itself and the javascript framework are all completely brand new, but I’ll keep an open mind for now.
[quote=480942:@Brock Nash]ActionStacks
… 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?[/quote]
ActionStacks are still in the design phase. I’ve got some pretty extensive notes on my white board here though
[quote=480942:@Brock Nash]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.[/quote]
So am I… especially since Bootstrap 3 hit EOL this winter.
I think the best answer right now is… let’s wait until the first prerelease ships and see whether it lets you accomplish what you need… I suspect it will.
Bug reports that were filed against the old web framework are being used to make sure that Web 2.0 doesn’t exhibit those behaviors, but beyond that we are not fixing bugs in or delivering updated versions of the old web framework.
The online documentation will be updated to API 2.0. If you need the documentation that goes with the old web framework, use the local language reference in the IDE itself.
That’s 2019r3.1.
To be fair, because the controls themselves are either all from Bootstrap or other stable MIT licensed code, I think we’re going to find a lot less issues out of the gate than you think. As Geoff and I have both stated, we have been working on a web version of Feedback and a couple of other internal projects to test Web 2.0 as we go and a lot of the obvious bugs have already been caught. As I said above, lets see what happens when we get this into users’ hands.
[quote=480971:@Greg O’Lone]@Brock Nash BrowserHistoryTrigger Is there a limit to data size?
We have not set any artificial limit.[/quote]
I understand Xojo hasn’t set a limit but URL’s have a hard limit in length to 2,083 characters. If we exceed this I’m suggesting Xojo detect that and auto-generate a token and store the larger value in client-side storage. It would be harder for the end-client to manipulate the value compared to the url Hash parameter but would avoid unexpected issues
[quote=480971:@Greg O’Lone]@Brock Nash 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.
…I do have some concerns that actual WebContainers would result in too much traffic to be responsive though…[/quote]
Concerns for sure. But how much overhead in just trying it out to see? I would assume quicker than designing and implementing custom column type. I actually do this in the current framework. I just embed the WebContainer, then move the DOM position with Jquery and play with the position styling a bit so it displays ok. I’m not usually loading 100’s of these on a page just a handful. So maybe for Web2.0 it could get disabled for infinite scroll or that cell could get a spinner until the more complicated piece comes in… Just the overhead for a user goes way down by making it a WebContainer - seems more the Xojo way to keep things simple.
I guess my thoughts is “could you subclass the new WebSDK control to have a WebSDKLegacy version”. And then wrap all the old events and methods into the new ones. I understand there might be some drastic changes but if we could default nesting it in a positioned div or something it could probably make the average WebSDK port ok. And if this is possible it just makes sense to make the porting code take care of this for us. The WebSDK is the number one reason I don’t think most my programs will port easily
I also hope what I brought up about my concerns on the responsive design and different screen-sizes make sense. I think it could be done with the Multi-Layout approach albeit with some important considerations. The main thing I need is for a (field/label) on a form to be 100% width on mobile and be two columns (50%) on tablet and potentially three columns (33.3%) on large screens. If this isn’t easy and intuitive to do, then you’re missing the mark. A static width for all screen sizes with a fluid overflow is really not ok
Not really. The portion of the WebDK for custom column types is done (I finished in the hour since my last post to you). But again, I’m willing to look at some point in the future, if the demand is high enough. Right now I’m trying to get us to a point where we can let everyone start playing with it… since we’ve all got so much unlimited free time on our hands (NOT!)
Will and Xojo.TriggerServerEvent still work the same? If so there’s a fair number of my Listbox customizations that will port over without modification
Are the attributes customizable beyond
type and color? Transparency, bar thickness and shape, removing drop shadows etc
Can animation be configured beyond what you get for free (as in the demo)?
Can new chart types be provided as drop in replacement through the SDK? Sankey, pyramid, waterfall come to mind[/quote]
We used ChartJS so whatevers there, we should be able to do.
Really liking the direction with Web 2.0. I see lots of uses for this and Im now definitely considering going back to a Pro subscription after a 2 year hiatus.
Really appreciate the level of effort going into it.
One question about the listbox caching stuff. The server appears to be sending the rows on demand only. While this is a decent strategy I wonder if the server could already send these rows in the background to the browser after the first visible rows are displayed, so before the user starts scrolling. Or if we can somehow devise such a scheme.
The underlying control certainly has the ability to pull data from a data source on the browser itself if thats what youre asking but it cant do both at the same time AFAIK.
What problem Is it that are you trying to solve before you even know if it exists?
Like Lars and Brock, I have a complex project with dozens of custom controls (webSdk) used by many companies.
@Brock Nash , could you please create a Feedback for the creation of this webSDKlegacy? (unless Greg totally exludes it of course) My English is too basic.
[quote=481040:@Greg O’Lone]The underlying control certainly has the ability to pull data from a data source on the browser itself if thats what youre asking but it cant do both at the same time AFAIK.
What problem Is it that are you trying to solve before you even know if it exists?[/quote]
Correct me if I’m wrong but I believe that the question was if the Listbox could load just enough to display and then load the rest of the rows in the background. A midpoint between full lazy loading and sending all everything to the browser before displaying like what we have in Web 1.0. I would expect this could be done by sending the initial 10-20 rows and then sending the rest in later requests until all have been sent, get the data to the user as quick as possible while avoiding the loading bars with waiting for the user to scroll before loading more content.
Yes, Alex nailed it. The aim is basically to avoid showing those “wait-bars” altogether. So the browser sends a request to the database, the server first returns like the 30 first rows to the browser, the browser displays them super fast and now while the user decides on what to do next the server returns the other 2000 rows to the browser which loads it into the listbox without the user really noticing. Sorry if I haven’t made myself clear enough.
I had been doing something like this already by using a timer to load in more data after the first load, 100 rows at a time. If Xojo is already going through the effort to put the lazy loading system together, I would love to see another mode added to the list (Load Type = All, Lazy, On-Demand)
I understand that many people live where Internet speed, limits and cell phones have unlimited capacity, so it makes sense to create a 2000 row or bigger listbox and you want it to show the first 50 (or what it could be shown on screen) immediately and keep loading everything so the user will not see any delay if they scroll fast to the middle or end of the listbox, but there are some Xojo users that create applications where the internet is slow, it is limited (speed) or the cell phones will have problems loading everything on their browsers.
I think many internet users are used to lazy loading and understand that not everything on a page is downloaded at first.
I would say, that if you want something that is not designed like that by Xojo, you could create a Feature Request for an option to indicate your Web app, to not wait until the scroll event to pull more data but keep sending it on the background.
I would not want this feature for the reasons I explained above, if Xojo can make it optional with the current way to do things as default, I think it will be ok for most (all) of us.
Greg, everything I see in the demo is fantastic. Thank you so much for all your hard work on this!
Im less concerned about webSDK changes because I mostly used it to get around problems I had with the built in controls that are either going to be no longer a problem, or Ill be taking a different tack with future controls than I was originally. Ill be re-writing things significantly anyway to take better advantage of the new functions so Im not worried about the work. Will there be some webSDK documentation when the pre-release ships?
How are things like HandleURL going to work with a fully http/1.1 server? Are you still going to create events for us when requests are made and we have to return from those in order to send things? Or will we be able to access these streams at a lower level and send data in real time? I ask because there are 2 things I need to be able to do for a future project that are currently impossible or impractical with the current version. I need to be able to serve up a motion jpeg stream on the same port as the built in server but cannot do this currently as nothing is sent until I return and the connection is closed. I also need to implement my own server events stream using the same port as the server which is also impossible currently for the same reason. Any chance these things will be possible going forward? Or should I put in new feature requests for lower level access to the server sockets?
Can I assume that the HTTP/1.1 server will be able to serve up larger resources via chunked encoding? This is absolutely required by the html5 video display control for example, and is used by default by curl and other things that I would like to be able to support some connections from that currently just cause things to fail.
Will I be able to do custom renderers for listbox cells at all? I would love to be able to write some webSDK library or include other javascript to manage the contents of a listbox column. I love the new lazy loading, thats going to be absolutely fantastic. Perhaps I can get by with the tag for the contents if that is supported in a listbox cell?
The sooner I get my hands on this in a pre-release the sooner I can start experimenting and answering my own questions Let me just say again how much Im looking forward to developing with this!
I would assume quicker than designing and implementing custom column type. I actually do this in the current framework. I just embed the WebContainer, then move the DOM position with Jquery and play with the position styling a bit so it displays ok. I’m not usually loading 100’s of these on a page just a handful. So maybe for Web2.0 it could get disabled for infinite scroll or that cell could get a spinner until the more complicated piece comes in… Just the overhead for a user goes way down by making it a WebContainer - seems more the Xojo way to keep things simple.
Let me just say again how much Im looking forward to developing with this!