[quote=481858:@Alexis Colon Lugo]Hi what version on XOJO have Web 2.0 ?
thanks[/quote]
It will be included in Xojo2020r1.
none that are shipping yet
be patient
ok
thanks
Im not sure what you mean here. Could you describe an example?
Right now each control has a list of events to choose from, I think he is asking for another event that is a catch all for anything that is not handled by the framework, a sort of UnhandledException type of event. That way if you wanted to implement custom logic via ExecuteJavascript you would not need to do it in 2 places. Any events that get passed back to the framework with the control ID would raise this event. The hard part would be how you handle the parameters, possibly just a string with the raw data and let the user parse it.
I figure this would be good for subclassing controls to add custom functionality like ListBox with custom cells.
[quote=482212:@Alex Bombay]Right now each control has a list of events to choose from, I think he is asking for another event that is a catch all for anything that is not handled by the framework, a sort of UnhandledException type of event. That way if you wanted to implement custom logic via ExecuteJavascript you would not need to do it in 2 places. Any events that get passed back to the framework with the control ID would raise this event. The hard part would be how you handle the parameters, possibly just a string with the raw data and let the user parse it.
I figure this would be good for subclassing controls to add custom functionality like ListBox with custom cells.[/quote]
If that’s the case then there shouldn’t be any events that fall into this category… unless what you’re actually looking for is a list of events that the user hasn’t implemented, but that goes down a different rabbit hole… We’re specifically not forwarding events from the browser to the server when they don’t have any property value side effects in this case. The Resized event will always fire because it changes the Width and Height but an event like Button.Pressed would not if the user hadn’t implemented the event or used AddHandler on it. We’ve also done away with the events that fire repeatedly, like MouseMove and Resizing.
[quote=481860:@Norman Palardy]none that are shipping yet
be patient[/quote]
We are all going to go outside and start clapping for Web 2.0
Sorry, I don’t think I made it quite clear, it’s not unimplemented events on the server-side, its more like events that were created via ExecuteJavascript that do not fit into the client framework.
Example:
You subclass a Listbox and via javascript, you add an event in the client-side framework (the same way you would if it were a custom control) for maybe a custom checkbox cell of some sort. This event would then end up at the server where the framework wouldn’t know what to do with it (of course) so it would trigger this “UnhandledEvent” event. In other terms, adding the ExecuteEvent from WebCustom control to all controls (WebControl) so we can extend controls without having to make a dictionary to store references and handle them via WebCustomControl.
[quote=482228:@Alex Bombay]Sorry, I don’t think I made it quite clear, it’s not unimplemented events on the server-side, its more like events that were created via ExecuteJavascript that do not fit into the client framework.
Example:
You subclass a Listbox and via javascript, you add an event in the client-side framework (the same way you would if it were a custom control) for maybe a custom checkbox cell of some sort. This event would then end up at the server where the framework wouldn’t know what to do with it (of course) so it would trigger this “UnhandledEvent” event. In other terms, adding the ExecuteEvent from WebCustom control to all controls (WebControl) so we can extend controls without having to make a dictionary to store references and handle them via WebCustomControl.[/quote]
The best answer I can give you at the moment is that the new WebSDK is still under construction. That’s not to say that the hierarchy of controls is and what you will and will not be able to subclass, but rather the little bits and pieces that make it something we can turn over to our users to play with. We had a huge advantage the last time we created the WebSDK in that Web Framework 1.0 had existed for about a year and a half at that point which gave us a long time to “get it right” internally before making it public. This time, because we’re trying to release it at the same time, we’re having to be very careful so that it’s flexible and powerful, but so that you won’t inadvertently wreak havoc in your (and other people’s) projects.
I’d also like to hear from @Brock Nash to find out if this is what he’s describing before we dig any further into the weeds so I know if I’m answering one question or two separate ones.
[quote=482235:@Greg O’Lone]The best answer I can give you at the moment is that the new WebSDK is still under construction. That’s not to say that the hierarchy of controls is and what you will and will not be able to subclass, but rather the little bits and pieces that make it something we can turn over to our users to play with. We had a huge advantage the last time we created the WebSDK in that Web Framework 1.0 had existed for about a year and a half at that point which gave us a long time to “get it right” internally before making it public. This time, because we’re trying to release it at the same time, we’re having to be very careful so that it’s flexible and powerful, but so that you won’t inadvertently wreak havoc in your (and other people’s) projects.
I’d also like to hear from @Brock Nash to find out if this is what he’s describing before we dig any further into the weeds so I know if I’m answering one question or two separate ones.[/quote]
For my purposes, as long as we get some method to extend functionality via some SDK I will be happy, the rest can come with feature requests at a later date once we know what we need. Thanks again to you and all the hard-working folks at Xojo making this happen.
@Greg O’Lone pretty sure it’s as ‘simple’ as being able to raise js events to the server that the framewirk doesn’t raise and expose to the developer…
Yes, with a reference to the control or at least the session would be nice.
While it may be simple to code, its how such a feature is exposed that concerns me. For instance, Its unlikely that we would add an event for dealing with unhandled events because for most users, the way to deal with that is to implement the events that you do want and ignore the others… and as for events not exposed to the user at this point I dont see that happening. We have several events behind the scenes to keep things in sync and doing what youre asking would unnecessarily expose implementation details which dont concern even our most advanced users.
You can always get the session yourself and it wont be any more efficient than it would be for us.
[quote=482308:@Greg O’Lone]While it may be simple to code, its how such a feature is exposed that concerns me. For instance, Its unlikely that we would add an event for dealing with unhandled events because for most users, the way to deal with that is to implement the events that you do want and ignore the others… and as for events not exposed to the user at this point I dont see that happening. We have several events behind the scenes to keep things in sync and doing what youre asking would unnecessarily expose implementation details which dont concern even our most advanced users.
You can always get the session yourself and it wont be any more efficient than it would be for us.[/quote]
You are thinking via creating a session context in App.HandleURL?
No. In the context of this hypothetical event, the only way it would ever fire is in the context of a session, so you would not need to use something like a WebSessionContext.
Ohh, I see, you are talking about if we had the event on the control, then the context would already be there. Thought you were talking about how to do it now without such event.
@Greg O’Lone re: the way to deal with that is to implement the events that you do want and ignore the others
That assumes then that all the underlying events are implemented Xojo side correct ?
[quote=482339:@Stephen Pardoe]@Greg O’Lone re: the way to deal with that is to implement the events that you do want and ignore the others
That assumes then that all the underlying events are implemented Xojo side correct ?[/quote]
First lets get the terminology correct here. What were talking about is that Alex wants us to add a generic Event Definition (which looks like the one in the WebSDK) to be put on every built-in web control which would be raised whenever an event was sent from the JavaScript code on the browser which in turn does not correspond to one of the built-in events. So if a developer wanted to send data to an instance of WebListBox using an event name of Foo, there would be a way to catch it without creating a separate object.
With that in mind, this has nothing to do with what is implemented or not (although that would be a problem because there currently needs to be a corresponding identically named event definition for the framework to even send events right now) but for the fact that the event named Foo is not included in our internal event handling bridge. What is being described would be the responsibility of a subclassed control in the traditional sense, but currently theres no way for a developer to access the bridge and to add new event definitions to it.
[quote=482455:@Greg O’Lone]First lets get the terminology correct here. What were talking about is that Alex wants us to add a generic Event Definition (which looks like the one in the WebSDK) to be put on every built-in web control which would be raised whenever an event was sent from the JavaScript code on the browser which in turn does not correspond to one of the built-in events. So if a developer wanted to send data to an instance of WebListBox using an event name of Foo, there would be a way to catch it without creating a separate object.
With that in mind, this has nothing to do with what is implemented or not (although that would be a problem because there currently needs to be a corresponding identically named event definition for the framework to even send events right now) but for the fact that the event named Foo is not included in our internal event handling bridge. What is being described would be the responsibility of a subclassed control in the traditional sense, but currently theres no way for a developer to access the bridge and to add new event definitions to it.[/quote]
Yes this is what I’m asking for. A way to extend Xojo’s existing controls without having to completely re-invent them with the WebSDK. Just subclass and add some triggers and be able to pick up those events on the control in the backend. The WebSDK hack works but is a bit sloppy compared to exposing one event for us.
Since the only examples that have been given are WebListBox custom columns, let me describe whats been done.
Developers can define, in code, which Cell types are to be used for which cells (note that theyre no longer called Column types). This means that realistically, you could have a single checkbox at cell(53, 4) if you wanted, and nowhere else, but would be mainly helpful for styling specific cells I suspect.
Any cells which contain a control which can fire one or more actions of some sort through the CellAction event which will contain as parameters: row, column, action and optionally parameters (as JSON or Nil).
Im really looking forward to getting this into your hands to see what you think of what weve done.