HandleURL hasnt changed significantly except for two things:
HandleSpecialURL has been removed because of the confusion it created.
The object you are passed has been broken into the request part (read-only) and the response part, so its clear what you are doing when reading your code.
I know youre clamoring for info about this, but put a pin in that for now and lets see if what weve done should solves any of your issues.
Technically yes, but I am still going to suggest that video resources not be served directly by the app itself. Theyre just too memory and CPU intensive to serve and you would be better served by using a protected CDN.
As a matter of fact, yes. I finished preliminary work yesterday to get our default and image column types working yesterday. Youll be able to subclass the object, add your own JavaScript rendering code (which at runtime has access to the row, the cell, and the object representing the row) and just assign that to the column.
And I totally understand the above about using a separate server. In this apps current life though its serving up files created from IP video cameras to an individual who is running the web interface on their local machine (though possibly through a cloud service in the near future to avoid the need to configure passthroughs) There will literally be just the one or two users at a time. I am just not going to require that they setup a separate web server on the same Mac sitting in a closet. If need be Ill ignore web 2,0 entirely and use something completely custom in order to be able to do this but I really dont want to have to do that I absolutely understand that a single web2.0 server will not be as good as an instance of some other fully tweaked and properly configured web server to serve up large video files! But it should still be possible if you only have to serve it up to one person at a time. I have to say that the web1.0 version did this just fine once I added some support for the chunked encoding even with that requiring a separate request for each chunk since there was no keep alive! So while I get that this is not how you should run a commercial hosted app that needs to serve up multi TB of video. The Web interface lends itself so perfectly to local interfaces to things it should definitely be able to handle sending one or 2 several megabyte files to one or two users at a time! There has got to be a way for you to make that work without claiming that youre better than running apache at the same time Because setting up 2 passthoughs is just doubly as expensive time wise as setting up one and just the one works great even with web 1,0!
[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.
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]
[quote=481087:@Greg O’Lone]@James Sentman 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?
As a matter of fact, yes. I finished preliminary work yesterday to get our default and image column types working yesterday. Youll be able to subclass the object, add your own JavaScript rendering code (which at runtime has access to the row, the cell, and the object representing the row) and just assign that to the column.[/quote]
On some web proyects, I needed a listbox with a checkbox column, I try the to use the events to put a character or a picture as a checkbox emulation. It kind of wored but the round trip to the server needed to make each state change made it impractical, it was not responsive enought, when the user dont see the change inmidiatly, often clicked again just to se the tick apear briefly and disapear. Wo, it was a showstopper for xojo.
Will Web 2.0 have a solution for this basic need in a listbox? (client side check box behavior) If it is not planed, could you use this current “flux state” of the listbox to consider this?
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)
OR do you mean something else (which would be consistent with past practices)
I’m curious since there are some folks pointing ath this conversation expecting “LTS like Ubuntu does with LTS” and I’d like to be clear
[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)
OR do you mean something else (which would be consistent with past practices)
I’m curious since there are some folks pointing ath this conversation expecting “LTS like Ubuntu does with LTS” and I’d like to be clear[/quote]
As you know and have stated many times when you were an engineer here, Xojo doesnt 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, thats the one to use.
That said, the bug reports that have been filed were taken into account when designing the new one. There were countless things done to make sure the new framework doesnt suffer from the same issues as before.
For example…
The old web framework had an issue where disabled controls could have different appearances if their containers were also disabled. It was a fundamental design flaw that we made sure not to repeat this time around.
And the whole having to figure out if a control should be initialized in the Open or Shown event… the Opening event always fires after the initialization code has been generated, but before anything has been sent to the browser. This means that controls appear on the browser and set to their initial state quicker than they did before.
I know this. Some people dont.
Its why I said “there are people pointing at this conversation as if LTS is a thing now”
But the discussion above about LTS versions had some believing that there was some change and that 2019r3.1 would be LTS in the same way Ubuntu maintains LTS versions
EDITED
You seem frustrated or something from the way that opening line reads
[quote=481143:@Norman Palardy]I know this. Some people dont.
Its why I said “there are people pointing at this conversation as if LTS is a thing now”
But the discussion above about LTS versions had some believing that there was some change and that 2019r3.1 would be LTS in the same way Ubuntu maintains LTS versions
EDITED
You seem frustrated or something from the way that opening line reads[/quote]
Greg must be under great pressure. If I was him I would be barking at every other post. Not that yours needed any barking at
I asked that question based on comments I received elsewhere that basically said “See. Xojo IS dong an LTS version. Greg said so”
My question was simply to clarify this which I thought I made clear
Whether I’d ever said that before when I worked there really isnt relevant since things could have changed since then
[quote=481151:@Norman Palardy]I asked that question based on comments I received elsewhere that basically said “See. Xojo IS dong an LTS version. Greg said so”
My question was simply to clarify this which I thought I made clear
Whether I’d ever said that before when I worked there really isnt relevant since things could have changed since then[/quote]
I completely understand that, and you are right. I’m just putting myself in Greg’s shoes, the pressure he is under must be huge. Frustration is most probably something he is feeling right now. I bet he really really wishes to be able to finish all the tasks he is juggling and I can only imagine how many he is juggling right now.
[quote=481126:@Ivan Tellez]
Will Web 2.0 have a solution for this basic need in a listbox? (client side check box behavior) If it is not planed, could you use this current “flux state” of the listbox to consider this?[/quote]
[quote=481126:@Ivan Tellez]
Will Web 2.0 have a solution for this basic need in a listbox? (client side check box behavior) If it is not planed, could you use this current “flux state” of the listbox to consider this?[/quote]
Aha! Just so nobody gets any ideas about us adding more features to listbox before we ship, the flux state as has been stated is not that we are in a state where we are trying to figure out what will be available in the first shipping version. That was worked out months ago.
That said, a column type with a checkbox in it is something that is on our list of would be nice to have because it is a relatively simple control which helps us test some parts of the WebSDK custom column type API, like (as you mentioned) initializing controls and passing changed values back to the app. Thats about as close to yes as I can get at the moment.
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…
I absolutely understand that a single web2.0 server will not be as good as an instance of some other fully tweaked and properly configured web server to serve up large video files! But it should still be possible if you only have to serve it up to one person at a time. I have to say that the web1.0 version did this just fine once I added some support for the chunked encoding even with that requiring a separate request for each chunk since there was no keep alive! So while I get that this is not how you should run a commercial hosted app that needs to serve up multi TB of video. The Web interface lends itself so perfectly to local interfaces to things it should definitely be able to handle sending one or 2 several megabyte files to one or two users at a time! There has got to be a way for you to make that work without claiming that youre better than running apache at the same time 