Do Xojo Inc plan to make Xojo Web more client centric? Developing my web project I am find things that are being sent back to the server which really would be much better handled on the client thus putting extra load on the server and latency within the UI. For example I have multiple labels with mouse up events that when clicked I display/hide an image. Currently with Xojo each time you click the label the event is sent back to and handled by the server. This is a total waste of time and effort for the server and slows down the UI etc. Ideally Xojo should have events that are “client side” and the code within the event handler should be converted to the appropriate Javascript by Xojo. I fully appreciate that this is easier said than done but if Xojo is to become more mobile friendly this really does need to be looked at.
Well, it would still need to trigger the server to do the same action there.
But indeed it may be possible to have code from action events being written in Javascript, too.
So your button could show/hide the object in javascript, send query to server and not wait for answer.
In effect what I am suggesting is “client side” events that are limited in function to maybe UI type stuff so that you could do things that the user sees and have the current events that actually handle what goes on in the background. It may well be that the client side events would just be placeholders where developers could add their own javascript although I would much prefer it to be Xojo basic and for Xojo to convert it but that may be asking a lot.
The purpose of this post is to start a discussion on the future of Xojo Web projects and what needs to be added / enhanced to make Xojo better as at the moment I feel that far too much is happening at the server side that should not be.
One solution could be that the ‘client-side’ uses XojoScript ( with the help of a XojoScript -> Javascript compiler ).
Guy, yes I think XojoScript > Javascript compiler would be a good way forward and could be encompasses within the current Xojo events.
While we don’t announce future plans like this, I see two paths.
- File a feature request
- Create a custom control using the sdk.
Knowing exactly what the developer wants will probably fall to the libpsychic.dll library which never seems to get finished for some reason. 
I think the solution would be for Xojo to support a subset of commands / object properties that get converted to Javascript so that they can run on the client. This is something that Omnis Studio implemented a good few years ago with their WebClient technology and it worked very well. I’m out of the Omnis loop these days but i’m sure they now use Javascript instead of a browser plug-in which they originally started out with.
Hi Greg, thanks for you comments. I am more than happy to create a feature request and will provide lots of info as fully understand that “mind reading” is difficult 
What I wanted to do was see if anyone else felt the same way before I put in a feature request as I am new to Xojo and feel like I am learning many things every time I open up the forum (which is about every 30 minutes at the moment) and I did not want to post something to the Feedback system that was completely daft and stupid. I will give this post a few days to run to see what others say and will then put up a feature request.
We are always looking for ways to make the web framework more efficient (such as doing more client-side). And as @Greg O’Lone already said, feature requests help.
There’s really nothing thats “daft & stupid”
There may be things we can’t do now so they get deferred or not actioned
Or things we won’t do - but the report will get a response to that effect
Everything else gets considered in due course
Thanks guys for your responses, I will think it through and put up a feature request. It is so good to work with a company that actually wants to here from customers to help make a better product.
Slings & arrows aside we really do try as best we can
I’ve got a request in already that is related to this:
<https://xojo.com/issue/31768>
At least the ability to show on the client side that it’s waiting for a response from the server would make a huge difference in usability.
I made a request of this type there are two and a half years, but Xojo Inc. had refused:
(https://xojo.com/issue/19486)>]<https://xojo.com/issue/19486>
Ouch. Yeah the thread/timer solution doesn’t work for latency issues, just for processor intensive tasks. Hopefully that was a misunderstanding of what you were asking and they just ignored your response explaining it.
I created the case because of a discussion on here and I’m pretty sure a Xojo employee seemed semi-positive about the idea. I’ll look around for it.
Here it is:
https://forum.xojo.com/8490-web-edition-basic-client-side-operations
That thread also regressed into “if you have a process that takes a long time send feedback to the app to show that it’s processing” when that is not what the original request was about.
It is possible to use code like:
In Shown event of Window:
ExecuteJavaScript("document.getElementById('"+MyControl1.ControlID+"').onclick=function(){myClickFunction();}")
ExecuteJavaScript("document.getElementById('"+MyControl2.ControlID+"').onclick=function(){myClickFunction();}")
...
ExecuteJavaScript("function myClickFunction(){document.getElementById('"+myAlertControl.get_controlID+"').style.backgroundColor='red';}")And in the MouseDown event of controls:
myServerMethod
ExecuteJavaScript("document.getElementById('"+myAlertControl.get_controlID+"').style.backgroundColor='black';")Each time a user clicks on the button: the “myClickFunction” function is executed directly in the client browser, bypassing the server. This function applies immediately a color waiting to control, to prevent its action is recorded and the server response is expected.
On the server, the methods of the MouseDown event is called and the result is returned to the client browser, with javascript method (document.getElementById(‘“+myAlertControl.get_controlID+”’).style.backgroundColor=‘black’;), so that color waiting is removed.
I used this method for several months, but sometimes, especially if the network is fast (LAN …), and / or browser / computer is fast, I had problems with pages that are freezed for a while …
I realized that it was because of this code. 
I do not know why. I have not had time to solve this problem.
EDIT: Maybe I should use a webPageSource or webControlSDK, but this is an old code that I had used before webControlSdk be published. If someone has a better solution, let me know 
I would still prefer to have things built in and supported.
Like icons in the weblistbox. I know I can add them with javascript, but the framework will ignore them and remove them if something changes on the listbox.
I think built in support would be the holy-grail but I have real doubts that it would happen within the next two years as Xojo have so much going on at the moment. So I was thinking how we might be able to get better client site ability with less work for Xojo Inc.
How about having an event on a control called “Javascript Client Event” which has a parameter of the event type that has occurred. When you then go into the editor for that event you are no longer going to write Xojo script but Javascript so their would be no syntax checking etc by Xojo. The one caveat would be that it would be helpful to be able to reference object ID so maybe their could be something like “[Xojo:ID:txtFirstName]” which would return the ID of the object. This would then allow us to interact within the Javascript when the event occurs. Obviously debugging etc would no be part of Xojo as the code within the event would be pure Javascript.
I accept this isnt the ideal but would allow a short term solution to being able to handle client side things without putting load on Xojo Inc. This would also allow us to use third-party Javascript code without Xojo Inc needing to support etc these external libraries.
you could do this with the Web SDK for new controls, I think.
But not so easy for extending built in controls like Weblistbox.