Hi Jim, > Looking at the current UI in BlueOnyx > it uses a frame approach which removes the need for refreshing much of the > page and provides a reasonable experience. I would like to see the new UI > either use an asynchronous JavaScript approach or cheat and use the frameset > approach otherwise. > > Might be too late in the game to make this type of change but I wanted to > provide you the feedback.
Hehehe ... it is a bit late for that now, considering that the work is more or less done. :-) But yeah: Speed is a concern and reloading the entire page and not just parts of it is slower than the old GUI. I looked at both the frameset approach and the AJAX approach early on. As you can see in the demo: There are parts where the content area is an IFrame. For example for phpMyAdmin or "System Settings" / "Hardware Information". But also in a few other parts like installing / removing PKGs or deleting Sites and Users. This is a bit of cheating, but speeds up the handling experience. As for AJAX: Very early on I worked on a "proof of concept" demonstrator that was using AJAX to update the content area. It didn't take care of the menus yet, which would have been another problem. The demonstrator handled basic stuff very well and made it clear that I can use AJAX to push certain elements into the content area. But a lot of what we use in the content area uses jQuery and some of that needs to be in the page's headers or needs to be initialized via DocumentReadyFunction() during initial loading of the page. Especially for the getScrollList() stuff, which uses DataTables. That then quite limits the number of useful elements that can be pushed via AJAX. The menus would have been another problem. Sure, you can push menus via AJAX as well. But our case with the menus is a bit special. Our toplevel menu has seven branches. Each of which have up to three levels of sub-branches. However, Access Control Rights need to be figured in. Only "admin" users can see the entire menu. There is a complex logic going on in the background that checks each leaf on the branch if the user in question has privileges to see this. If not, the leaf is removed. If a branch therefore ends up without any leaves left, it will be removed as well. That is done entirely in PHP and the results of that could be pushed via AJAX, too. But alone and by itself that wouldn't speed up things one millisecond, as the problem is rather the content area. But all in all there is some heavy duty scripting going on to make things as dynamic as sensible. Aside from the core of the GUI that's written in PHP we rely very heavily on jQuery now, with a bit of JavaScript sprinkled in wherever it can't be avoided. There are also usage cases where the new GUI is a lot faster and more usable. Just the other day I was on a box under support contract. Supposedly the auto-responder for the user with the email alias u...@box.net wasn't working. So I went to the (old) GUI on that box. Went to "Site Management". Great, 200 sites. So I used the search box to search for www.box.net. No results. Searched for mail.box.net. Ah, there we go. Clicked on the edit icon. Great, 176 users! Entered the alias part into the search box. No results. Ended up clicking through the pulldown menu for "show next 20 results" a few times, wasting precious minutes locating the user. In the new GUI this would have taken 10 seconds max. 5 seconds locating the Vsite, another 5 for the User. Page loads already figured in. Because the ScrollList tables have all the data already in it and paginate them to just 10 results. But the search field works without page reloads and starts limiting the shown results even after typing the first character into the search field. That is a great help and saves oodles of time in day to day operations. Still: I am concerned about page load times and am looking into ways to improve that further. As is the demo isn't yet optimized. We carry some jQuery baggage around that we don't need on every page and I'm currently in the process of trimming down on that. > I would like to offer my help any way I can but would need some hand > holding likely, but willing if you are. I have built a few web > based applications using .NET MVC and UI interaction > with libraries like jQuery and have gotten reasonably good at writing > JavaScript. That jQuery experience would indeed be useful. Here is a particular jQuery related problem that I still need a solution for. Example: http://demo.blueonyx.it:444/vsite/vsiteAdd There are certain fields (marked by the red star in the right upper corner) that *need* input. In that page here it's things like IP, host name, domain name and a few others. Input is validated in two occasions: While you type into a field and when you hit the save button. Try to change the filled in IP address to "hello kitty" and see how it complains "Please fix this field" below it. If you hit save and have missing data in a field that requires input, it'll show a similar red marker under the field in question saying "This field requires input." When you look at the HTML source code of the GUI page, you can see that it's done here via the jQuery Validation Plugin: <!-- Start: Overrides for Adminica functions:--> <script src="/gui/validation?update"></script> <!-- End: Overrides for Adminica functions:--> I'm just using a slightly customized version of it to show the error messages in the language the user has chosen. And our modified version has oodles of additional data types it validates for. That validation itself works perfectly. No problem there. But ... I broke one part of it which needs fixing: Some page save transaction take a bit longer due to all the things that need to be stuffed into CODB and the handlers that then run may take a few seconds. Think of creating a Vsite, for example. When you hit Save on that form (and it wouldn't be in demo-mode), it would take 8-12 seconds for the site creation to finish. On which you'd get redirected to the Virtual Site List again. To prevent people from aborting this transaction I added an overlay image that shows up in the middle of the screen when the save button is clicked. That's there to encourage the user to wait for the transaction to finish. For that I use this code near the top of the page: <!-- Start: Wait overlay --> <script> $(document).ready(function() { $('#fade_overlay').popup({ blur: false }); }); </script> <!-- End: Wait overlay --> <!-- Start: Wait overlay --> <div id="fade_overlay" class="display_none"> <img src="/.adm/images/wait/loading_bar.gif" id="loading_image" height="75" width="450"> </div> <!-- End: Wait overlay --> An this here neear the bottom of the page: <!-- Start: Wait overlay --> <script> $('button.waiter').click(function() { $('#fade_overlay').removeClass("display_none"); $('#fade_overlay').popup('show'); }); </script> <!-- End: Wait overlay --> The problem: If there are fields that are missing their required input, the valiadation plugin does deactivate the save button. That still works fine. But the wait overlay still starts showing merrily, although the form is NOT saving. Ideally the error raised by the validation plugin should also prevent the wait overlay from initializing. Any idea how to fiddle that one in? The relevant section in http://ng.blueonyx.it:444/gui/validation?update starts at line 14 and goes to line 97, or 212 to 279. -- With best regards Michael Stauber _______________________________________________ Blueonyx mailing list Blueonyx@mail.blueonyx.it http://mail.blueonyx.it/mailman/listinfo/blueonyx