Premise 100% customizeable browser UI
- Thread starter Timoh
- Start date
Motorola Premise
I've been mulling over an architecture to html5 enable Premise. Much of it comes from my learning on my HB UI project. Since there is a chance one day I will move off HB and maybe onto Premise, this is somewhat of a x-post to my thoughts on a HB html5 UI.
On the client side...
Every classt in Premise will have a HTML5 widget. There are plenty of html design tools out there that allow you to use your own widgets. The widget will be derived from a javascript framework such as jquery or dojo or ???. The widgets will also be required to work with other components of the selected framework. This will enable all sorts of goodies on the selected framework such as websockets, subscribe/publish changes, push technology, cross platform, + + +.
On the server side...
A websocket server will need to be built for delivering the data, the current server will probably work for delivering the html5 and css. There seem to be plenty of .net or C websocket libraries out there could help out in this area.
The key to it all is Premise widgets. If a widget is created for every class, even new classes that people create, it makes for a nice pluggable experience on the UI. Of course module creators will have to write or adapt their own widget for any new classes they create, but as long as the Premise widget is compatible with dojo, yui, jquery, openajax, or whatever framework is selected, it should work with the underlying framework that would tie it into Premise. I suspect most folks would be 99% covered with "stock widgets" that would corrspond to stock classes in Premise.
It's a "cocktail napkin" idea right now, but I think all the components are there... HTML5, design/layout, websocket push, subcribe/publish, pluggable, extensable.
Thoughts?
Tim
On the client side...
Every classt in Premise will have a HTML5 widget. There are plenty of html design tools out there that allow you to use your own widgets. The widget will be derived from a javascript framework such as jquery or dojo or ???. The widgets will also be required to work with other components of the selected framework. This will enable all sorts of goodies on the selected framework such as websockets, subscribe/publish changes, push technology, cross platform, + + +.
On the server side...
A websocket server will need to be built for delivering the data, the current server will probably work for delivering the html5 and css. There seem to be plenty of .net or C websocket libraries out there could help out in this area.
The key to it all is Premise widgets. If a widget is created for every class, even new classes that people create, it makes for a nice pluggable experience on the UI. Of course module creators will have to write or adapt their own widget for any new classes they create, but as long as the Premise widget is compatible with dojo, yui, jquery, openajax, or whatever framework is selected, it should work with the underlying framework that would tie it into Premise. I suspect most folks would be 99% covered with "stock widgets" that would corrspond to stock classes in Premise.
It's a "cocktail napkin" idea right now, but I think all the components are there... HTML5, design/layout, websocket push, subcribe/publish, pluggable, extensable.
Thoughts?
Tim
C
chucklyons
Guest
I guess I have to ask...if I can use JS in Premise, what is the VB interpreter issue..I simply don't know.
I am WAY on-board with the widget concept. I see that type of framework as the leap frog into the next paradigm.
I am also focused entirely on MB. 123 taught me I need to remember the AB version.., so I have..
HTML5 - I'm using it for Audio and Video. So far, so good.
jQuery - I'm using it for Audio, Video, multi-frame UI. I also use Ajaxify for selected data in the mb.
Press the envelope. And welcome aboard!
I am WAY on-board with the widget concept. I see that type of framework as the leap frog into the next paradigm.
I am also focused entirely on MB. 123 taught me I need to remember the AB version.., so I have..
HTML5 - I'm using it for Audio and Video. So far, so good.
jQuery - I'm using it for Audio, Video, multi-frame UI. I also use Ajaxify for selected data in the mb.
Press the envelope. And welcome aboard!
123
Senior Member
All the Javascript code I've seen in Premise is delivered by its Web server to a browser where it is executed. Locate a sample of Javascript, in AutomationBrowser or MiniBrowser, and it will be sitting between HTML Head tags, waiting to be interpreted by a browser. I have never seen any examples where Premise Server executes Javascript code.
The JSON classes I have found resort to using Javascript, not VBScript, to perform the data transformations. Premise Server cannot execute Javascript code so the JSON classes I've found won't work.
The JSON classes I have found resort to using Javascript, not VBScript, to perform the data transformations. Premise Server cannot execute Javascript code so the JSON classes I've found won't work.
123
Senior Member
I doubt Premise's interpreter relies on Windows Script Host. For example, it does not support statements like wscript.echo and sleep. It also understands the concept of "this" which WSH does not. All Premise scripting runs in a single thread so you cannot have anything that blocks it (like WSH's sleep statement).
If you have a class method called SetVolume() which accepts an argument called VolLevel, the method's code would use method.VolLevel to access the argument's value. That doesn't look anything like scripting in WSH.
Another differentiator: Premise's scripting language allows you to call and use any COM object's synchronous functions and properties but none of its callback functions (i.e. asynchronous functions). In other words, if the COM object raises an event, you can't define a function within Premise to handle the event.
Premise knows how to handle asynchronous events but only its own like when data arrives on a serial port or a timer expires and calls a function, etc but not a COM object's events.
If you have a class method called SetVolume() which accepts an argument called VolLevel, the method's code would use method.VolLevel to access the argument's value. That doesn't look anything like scripting in WSH.
Another differentiator: Premise's scripting language allows you to call and use any COM object's synchronous functions and properties but none of its callback functions (i.e. asynchronous functions). In other words, if the COM object raises an event, you can't define a function within Premise to handle the event.
Premise knows how to handle asynchronous events but only its own like when data arrives on a serial port or a timer expires and calls a function, etc but not a COM object's events.
