WebAccess
-
Dominik Batušić
Are there any plans for proper refactoring of WebAccess? I'd like to help with that, and as it stands now, everything(JS, HTML, CSS) is compiled as strings. What are the options? I did very raw kind of approach with pseudo-Javascript parser-generator which inserts needed data about widgets in an array and then made Javascript function replicas of on-fly generation of widgets (getFrameHTML, getWidgetHTML etc.), but while functional, there is more data transfer to do. I guess the right approach would be to have server-side(the app) language(like PHP) but lighter because the webserver also needs to run on Raspberry Pi (which is very limited on resources)... Any thoughts?
-
Massimo Callegari
Hello to you.
What's wrong with the current implementation of web access ?
I kept it simple thus hardcoding strings to avoid adding stuff like PHP as you suggested.
So what is the goal you have in mind ?
By the way, instead of proposing a refactoring, why don't you help to add the missing widgets like XYpad, speed dials and clock ?
What's wrong with the current implementation of web access ?
I kept it simple thus hardcoding strings to avoid adding stuff like PHP as you suggested.
So what is the goal you have in mind ?
By the way, instead of proposing a refactoring, why don't you help to add the missing widgets like XYpad, speed dials and clock ?
-
Dominik Batušić
Well the problem is in maintening it, and you also need to recompile WebAccess. Also I looked into it because I had plans to make XYpad and other missing widgets as you said. If you are interested in keeping it lightweight but not having it hardcoded perhaps my solution is not bad. On C++ side you only expose widget's properties and when the e.g. VC is requested the JS file is processed (widgets added with its properties) and rewrote, HTML fetched and forwarded to client just as usual. I am going to put it up on github, so you can see it.
Here is a VC test:
img:http://i57.tinypic.com/33trz1i.jpg
js:http://pastebin.com/PCZyUuCT
Here is a VC test:
img:http://i57.tinypic.com/33trz1i.jpg
js:http://pastebin.com/PCZyUuCT
-
Janosch Frank
I support the idea of Dominik, this could be a great improvement and ease development of widgets for the webaccess interface.
Currently I try to fix the HTML and the encoding of the webaccess:
- The HTML header says the content is utf but the code gives back latin1.
- The XHTML is not conform with the standard and I would suggest to move to HTML 5 anyway.
- The background color is inconsistent over all pages
- German translation doesn't work for the configuration page
- The German word for fader is to large for the fader div
- Configuration page is not translated
Have a look at: https://github.com/Babbsdrebbler/qlcplu ... ccess-utf8
Anyway, decoupling of the HTML,CSS and JS would make the webaccess a lot more maintainable. If the C++ part would provide only the data for the widgets and a way to process the responds, the frontend could be developed more easily.
Having the css and part of the js in files that can be retreived like on a normal webserver would be the first step forward.
Give it a tought.
Currently I try to fix the HTML and the encoding of the webaccess:
- The HTML header says the content is utf but the code gives back latin1.
- The XHTML is not conform with the standard and I would suggest to move to HTML 5 anyway.
- The background color is inconsistent over all pages
- German translation doesn't work for the configuration page
- The German word for fader is to large for the fader div
- Configuration page is not translated
Have a look at: https://github.com/Babbsdrebbler/qlcplu ... ccess-utf8
Anyway, decoupling of the HTML,CSS and JS would make the webaccess a lot more maintainable. If the C++ part would provide only the data for the widgets and a way to process the responds, the frontend could be developed more easily.
Having the css and part of the js in files that can be retreived like on a normal webserver would be the first step forward.
Give it a tought.
- Attachments
-
- Screenshot%20-%2012.10.2014%20-%2022%3A26%3A03.png (32.35 KiB) Viewed 2006 times
-
- Screenshot%20-%2012.10.2014%20-%2022%3A26%3A57.png (88.44 KiB) Viewed 2006 times
-
Stefan
as i have read your posts there came some ideas to my mind - and i want to share theme with you.
i dont have worked jet with qlc+ (have not get it to start on Win7) - so eventually my ideas are not pointing in the right direction..
the ideas are similar as Janoschs and Dominiks:
use as much static files as possible- so only have a nice api and a static file server on the qlc+ site.
if some Client is requesting the webview from qlc+ this is a two part process:
request: 192.168.178.42
--> retunrs a index.htm - this is a static html file - just served from a directory. (default or user-defined)
this html file links/loads to a js file and others...
these script then fires a get request with the option 'virtualconsole_config' or something similar.
qlc+ returns a json object/string that contains all configuration options and values.
then the website / js can parse this and create the widgets.
if the js finds a widget or option definition it don't know it can warn and skip the creation or create a simple value box replacement (example: if xy-widget is not a know type it uses the coordinates and sizes - draws a default widget box and puts some text fileds in to show raw value/data)
this can also be done for config pages.
so you can request a list of possible sites for a menu..
in this list there could be additional informations to every entry- as example if this site is 'user' or 'config' or 'admin' content....
the language translation also can be done from the javascript on the webpage. (use some json or js files as translation files - these can be generated from the qlc+ language files automatically) so you could switch language on the fly...
for the update process you can use polling or long-polling requests or web-sockets (that could be a heavier thing to add..)
with this approach you have a common api to access qlc+ from the web world - with this you can also simply build a app that accesses qlc+.
other options are to integrate it into bigger control systems...
with this approach you also can create new widgets that combine data from others - and you can easily change the style of the web-virtual-console.
so that are just raw concept ideas -
i hope they are of 'some' value to you
sunny greetings
stefan
i dont have worked jet with qlc+ (have not get it to start on Win7) - so eventually my ideas are not pointing in the right direction..
the ideas are similar as Janoschs and Dominiks:
use as much static files as possible- so only have a nice api and a static file server on the qlc+ site.
if some Client is requesting the webview from qlc+ this is a two part process:
request: 192.168.178.42
--> retunrs a index.htm - this is a static html file - just served from a directory. (default or user-defined)
this html file links/loads to a js file and others...
these script then fires a get request with the option 'virtualconsole_config' or something similar.
qlc+ returns a json object/string that contains all configuration options and values.
then the website / js can parse this and create the widgets.
if the js finds a widget or option definition it don't know it can warn and skip the creation or create a simple value box replacement (example: if xy-widget is not a know type it uses the coordinates and sizes - draws a default widget box and puts some text fileds in to show raw value/data)
this can also be done for config pages.
so you can request a list of possible sites for a menu..
in this list there could be additional informations to every entry- as example if this site is 'user' or 'config' or 'admin' content....
the language translation also can be done from the javascript on the webpage. (use some json or js files as translation files - these can be generated from the qlc+ language files automatically) so you could switch language on the fly...
for the update process you can use polling or long-polling requests or web-sockets (that could be a heavier thing to add..)
with this approach you have a common api to access qlc+ from the web world - with this you can also simply build a app that accesses qlc+.
other options are to integrate it into bigger control systems...
with this approach you also can create new widgets that combine data from others - and you can easily change the style of the web-virtual-console.
so that are just raw concept ideas -
i hope they are of 'some' value to you
sunny greetings
stefan
-
Massimo Callegari
Guys, I got your point but:
- the current solution is the fastest. Any change to it can cause a degradation of performances
- you need to think about all the cases. In particular the speed over a wifi network and the limited performances of the Raspberry Pi. The current solution provides exactly the needed data. Not one byte more.
- a predetermined CSS file can be done, but the browser on the other end would load useless styles in most cases. For example if your virtual console uses only buttons, there is no need for sliders and cue lists styles
- a predetermined javascript can be done but, like above, mostly inefficient. Moreover objects ID prefixes would be predetermined, thus the impossibility to write an arbitrary HTML code over them
- the virtual console HTML code cannot be predetermined. It has to be created dynamically. Using Javascript calls to retrieve each property of each widget can be much of data transferring and can be slow and inefficient.
- providing JSON or XML data for widgets ? No way. At this point do a javascript parse of the QLC+ project file, which is XML anyway. Good luck with that !
@Janosch: I had a look at your changes. They look OK to me. If you want, just send me a pull requests for them. Thanks
- the current solution is the fastest. Any change to it can cause a degradation of performances
- you need to think about all the cases. In particular the speed over a wifi network and the limited performances of the Raspberry Pi. The current solution provides exactly the needed data. Not one byte more.
- a predetermined CSS file can be done, but the browser on the other end would load useless styles in most cases. For example if your virtual console uses only buttons, there is no need for sliders and cue lists styles
- a predetermined javascript can be done but, like above, mostly inefficient. Moreover objects ID prefixes would be predetermined, thus the impossibility to write an arbitrary HTML code over them
- the virtual console HTML code cannot be predetermined. It has to be created dynamically. Using Javascript calls to retrieve each property of each widget can be much of data transferring and can be slow and inefficient.
- providing JSON or XML data for widgets ? No way. At this point do a javascript parse of the QLC+ project file, which is XML anyway. Good luck with that !
@Janosch: I had a look at your changes. They look OK to me. If you want, just send me a pull requests for them. Thanks
-
Janosch Frank
I get your points for the current solution but I think the reasons for your reservations are not all valid.
The problem is that there have been a lot of suggestions (which all differ) but no solution.
A combination of all of the suggestions is not wise, as you just stated!
I hope we can change your opinion with a prepared plan and some code.
Talk is cheap. Show me the code. - "Linus Torvalds"
About the pull...
I made some changes on my local branch which resulted in an incomplete html closing tag being transmitted even though it is defined in the string.
I'm currently trying to search the problem but wasn't able to find it till now.
Also I'm considering to switch the doctype to html5 and fix some CSS.
@Stefan
Do me a favor and use proper capitalization and punctuation.
It's hard to read your post.
If you want to help or if you have some suggestions send me a message (;
The problem is that there have been a lot of suggestions (which all differ) but no solution.
A combination of all of the suggestions is not wise, as you just stated!
I hope we can change your opinion with a prepared plan and some code.
Talk is cheap. Show me the code. - "Linus Torvalds"
About the pull...
I made some changes on my local branch which resulted in an incomplete html closing tag being transmitted even though it is defined in the string.
I'm currently trying to search the problem but wasn't able to find it till now.
Also I'm considering to switch the doctype to html5 and fix some CSS.
@Stefan
Do me a favor and use proper capitalization and punctuation.
It's hard to read your post.
If you want to help or if you have some suggestions send me a message (;
-
Massimo Callegari
Talk is cheap. Show me the code. - "Linus Torvalds"
Yeah, I didn't want to say that (cause otherwise it seems I am always an evil person) but I totally quote it
Yeah, I didn't want to say that (cause otherwise it seems I am always an evil person) but I totally quote it
-
Massimo Callegari
There you go:
https://github.com/mcallegari/qlcplus/c ... 7a7f0075c9
I was tempted to minify the JS files with http://jscompress.com/, but it sounded too much for now...
Please have a look if there is any syntax error or misplaced things.
Thanks
https://github.com/mcallegari/qlcplus/c ... 7a7f0075c9
I was tempted to minify the JS files with http://jscompress.com/, but it sounded too much for now...
Please have a look if there is any syntax error or misplaced things.
Thanks
-
Janosch Frank
Hey Massimo,
I had a quick glance through the changes, thanks for the work!
Tomorrow I will have a deeper look, do some testing and add an expires field for the HTTP header that gets sent for CSS, PNG and JS files.
With the caching enabled by the expires header, there should be no need for minifying the CSS or JS so please don't do that, it will make it unreadable.
I had a quick glance through the changes, thanks for the work!
Tomorrow I will have a deeper look, do some testing and add an expires field for the HTTP header that gets sent for CSS, PNG and JS files.
With the caching enabled by the expires header, there should be no need for minifying the CSS or JS so please don't do that, it will make it unreadable.
-
Janosch Frank
Had an experimental go on the testing and didn't experience any gain on modern systems. Doesn't matter, had fun.
Your commit looks solid, a favicon could be added and the empty script tag removed.
Experimental code is here:
https://github.com/Babbsdrebbler/qlcplu ... ss-caching
Your commit looks solid, a favicon could be added and the empty script tag removed.
Experimental code is here:
https://github.com/Babbsdrebbler/qlcplu ... ss-caching