[RFC] Ginger Sidebar and conflicts

[sguima...@gmail.com]

Hi team,

I was about to port the mockups to the HTML pages and I'm concerned about three things regarding Ginger sidebar:

1) The sidebar widget:

I'm going to create a widget that appends the sidebar on each page but the menu items will have to be built based on the capabilities object. This is what I currently have on my machine:

1. Archive:true
2. Archives:true
3. Audit:true
4. Backup:true
5. Cfginterface:true
6. Cfginterfaces:true
7. Conf:true
8. Config:true
9. DASDPartition:true
10. DASDPartitions:false
11. DASDdev:true
12. DASDdevs:false
13. DiscoveredISCSIQN:true
14. DiscoveredISCSIQNs:true
15. FileSystem:true
16. FileSystems:true
17. Firmware:false
18. Ginger:true
19. Graphs:true
20. ISCSITargets:true
21. Interface:true
22. Interfaces:true
23. LogicalVolume:true
24. LogicalVolumes:true
25. Logs:true
26. NFSShares:true
27. Network:true
28. OVSBridge:true
29. OVSBridges:false
30. Partition:true
31. Partitions:true
32. PhysicalVolume:true
33. PhysicalVolumes:true
34. PowerProfile:true
35. PowerProfiles:false
36. Reports:true
37. Rule:true
38. Rules:true
39. SanAdapter:true
40. SanAdapters:true
41. Sel:true
42. Sels:true
43. Sensors:false
44. Sep:false
45. Server:true
46. ServerSensors:true
47. Servers:true
48. Service:true
49. Services:true
50. StgServer:true
51. StgServers:true
52. StorageDevs:true
53. Subscribers:true
54. Subscription:true
55. Swap:true
56. Swaps:true
57. SysModule:true
58. SysModules:true
59. Syscall:true
60. User:true
61. Users:true
62. VolumeGroup:true
63. VolumeGroups:true

I'm not sure I'm seeing all Ginger panels besides Firmware and Sensors that I know they're hidden because I'm running a VM. Is this object response the same as Ginger 390 but with different values?

Also, since we're removing the pages from tab-ext.xml and keeping just the "Administration" tab, how the user access roles are going to play with the sidebar and, most importantly, can't we get the menu item names and links from a dynamic object from the back-end or from a config file?

2) Managing conflicts:

I'll have to separate each panel in an exclusive HTML page. Ginger JS files are not minified (and for now I thank this because otherwise this job would be harder having to recompile after every JS change) but the functions are grouped based on their tabs. i.e network code goes to host-network.js, system services and system modules are in different files but ginger.loadSysmodules(); is called from host-system-services.js etc.

I'll have to separate the function blocks representing each panel in different files. In some cases I'll have to duplicate code, in other cases I'll have to write new functions. How can I do this safely? I'm pretty sure unless I finish this in less than one day (and I know it won't happen) and no one submits and/or apply a new patch on master it will have conflicts or someone will have to rebase and rework some lines of code.

Based on this, I'm proposing to keep these old functions that are used to build more than one panel and create the new functions that will be calling each panel on each page. This way we won't have conflicts with the JS files but we'll probably have some with HTML.

3) Some JS already checks for capabilities and I think this would be good to avoid hot-linking. For instance, suppose the user has the link for firmware update and this page/panel is hidden based on the capabilities on his environment but he paste it on the browser and goes anyway. Should the panel be hidden? Should I display error messages? If we go for the latter option and show a custom message saying that the user is not allowed / authorized, then we could face some conflicts with JS and upstream code.

FYI, attaching the final design in case you didn't remember.

Regards,

Samuel

[Lucio Correia]

Hi Samuel,

On 01-09-2016 17:37, sguima...@gmail.com wrote:
> Hi team,
>
> I was about to port the mockups to the HTML pages and I'm concerned
> about three things regarding Ginger sidebar:
>
> 1) The sidebar widget:
>
> I'm going to create a widget that appends the sidebar on each page but
> the menu items will have to be built based on the capabilities object.
> This is what I currently have on my machine:
>

> 1. Archive:true
> 2. Archives:true
> 3. Audit:true
> 4. Backup:true
> 5. Cfginterface:true
> 6. Cfginterfaces:true
> 7. Conf:true
> 8. Config:true
> 9. DASDPartition:true
> 10. DASDPartitions:false
> 11. DASDdev:true
> 12. DASDdevs:false
> 13. DiscoveredISCSIQN:true
> 14. DiscoveredISCSIQNs:true
> 15. FileSystem:true
> 16. FileSystems:true
> 17. Firmware:false
> 18. Ginger:true
> 19. Graphs:true
> 20. ISCSITargets:true
> 21. Interface:true
> 22. Interfaces:true
> 23. LogicalVolume:true
> 24. LogicalVolumes:true
> 25. Logs:true
> 26. NFSShares:true
> 27. Network:true
> 28. OVSBridge:true
> 29. OVSBridges:false
> 30. Partition:true
> 31. Partitions:true
> 32. PhysicalVolume:true
> 33. PhysicalVolumes:true
> 34. PowerProfile:true
> 35. PowerProfiles:false
> 36. Reports:true
> 37. Rule:true
> 38. Rules:true
> 39. SanAdapter:true
> 40. SanAdapters:true
> 41. Sel:true
> 42. Sels:true
> 43. Sensors:false
> 44. Sep:false
> 45. Server:true
> 46. ServerSensors:true
> 47. Servers:true
> 48. Service:true
> 49. Services:true
> 50. StgServer:true
> 51. StgServers:true
> 52. StorageDevs:true
> 53. Subscribers:true
> 54. Subscription:true
> 55. Swap:true
> 56. Swaps:true
> 57. SysModule:true
> 58. SysModules:true
> 59. Syscall:true
> 60. User:true
> 61. Users:true
> 62. VolumeGroup:true
> 63. VolumeGroups:true

>
>
> I'm not sure I'm seeing all Ginger panels besides Firmware and Sensors
> that I know they're hidden because I'm running a VM. Is this object
> response the same as Ginger 390 but with different values?

I don't see capabilities API in Gingerbase and Gingers390x. But it would
not be the same. It is listing all models contained in Ginger, so it
would be different for Gingerbase and Gingers390x.

> Also, since we're removing the pages from tab-ext.xml and keeping just
> the "Administration" tab, how the user access roles are going to play
> with the sidebar and, most importantly, can't we get the menu item names
> and links from a dynamic object from the back-end or from a config file?
>

IMO we should not create an API ginger/sidebar to GET this info, since
sidebar is UI-only stuff, but we may think in a way to provide that
information from backend. (i.e. improve capabilities or other api)

> 2) Managing conflicts:
>
> I'll have to separate each panel in an exclusive HTML page. Ginger JS
> files are not minified (and for now I thank this because otherwise this
> job would be harder having to recompile after every JS change) but the
> functions are grouped based on their tabs. i.e network code goes to
> host-network.js, system services and system modules are in different
> files but ginger.loadSysmodules(); is called from
> host-system-services.js etc.
> I'll have to separate the function blocks representing each panel in
> different files. In some cases I'll have to duplicate code, in other
> cases I'll have to write new functions. How can I do this safely? I'm
> pretty sure unless I finish this in less than one day (and I know it
> won't happen) and no one submits and/or apply a new patch on master it
> will have conflicts or someone will have to rebase and rework some lines
> of code.
> Based on this, I'm proposing to keep these old functions that are used
> to build more than one panel and create the new functions that will be
> calling each panel on each page. This way we won't have conflicts with
> the JS files but we'll probably have some with HTML.

That's an approach focused on solving conflicts, but the new code will
start to be different from master and perhaps it will require you to
apply those patches manually in the new code afterwards? Conflicts would
help to keep the code synced between old and new code.

I would say you will have to constantly rebase your code with master,
since the conflicts are inherent to this kind of huge work. Furthermore,
I would say you should pay attention to UI changes coming to ML, because
there may be such a change that creates a design conflict with your work
and better you recommend it to be implemented a different way since
beginning.

>
> 3) Some JS already checks for capabilities and I think this would be
> good to avoid hot-linking. For instance, suppose the user has the link
> for firmware update and this page/panel is hidden based on the
> capabilities on his environment but he paste it on the browser and goes
> anyway. Should the panel be hidden? Should I display error messages? If
> we go for the latter option and show a custom message saying that the
> user is not allowed / authorized, then we could face some conflicts with
> JS and upstream code.

IMO the error message is the best approach in that case.

>
> FYI, attaching the final design in case you didn't remember.
>
> Regards,
> Samuel
>

Thanks,

--
Lucio Correia
Software Engineer
IBM LTC Brazil

[sguima...@gmail.com]

Thanks Lucio,

For now I'm still managing the UI stuff and the menu is working fine. I think the most troublesome work will be on the main Administration page that has at least 3 hidden panels that I've counted. Like I've said, if the changes in the ML are only on the JS files then it probably won't have conflicts at all. I'm not removing the legacy pages but hiding some panels and creating new pages with a readable name, something like "host-network-config" and "host-global-config" while ovsbridges remains as "host-network" because it is the first panel that is appended.

Instead of appending the sidebar object on each page, I'm creating a new home page that builds two panels, one is the sidebar that is dynamically created (in case in the future we decide to move this widget to Wok or Gingerbase too) by a JS object (for now it is a static object but once the backend can deal with this, we can change it) and the other one is the content panel that will be loaded by JS. 

Samuel

[sguima...@gmail.com]

I'm having a hard time with the asynchronous calls to several dynamic elements on different pages. If the user changes from one page to another sometimes it calls functions twice. It includes calling multiple modal windows at the same time, some warning from Bootgrid and DataTabels saying that they were unable to reinitialize the elements, mouse events working X times each option was clicked on the menu etc...

I've tried some things to improve this but now I'm blocked and I would like some inputs from the community. I'm not sure if i'm missing something but I can only see the following options:

1) Change the way that the panels are dynamically loaded on each JS function and make them interact with the sidebar using JavaScript Promises. To fix this it would take huge impact on all JS files, probably would have to revisit all JS functions that are working just fine by now. The current workflow goes like this: If I select an option from the menu it will load the html using jQuery .load() function. It does load the HTML and show the "success" status code but that doesn't mean that the GET API calls were finished inside this page and in some of them the APIs calls must be completed in order to render the panels so the "sucess" status code on the sidebar alone wouldn't work. Some panels loads faster than others because I probably don't have enough data to show but the navigation goes like this: user click -> loading icon/mask on the right panel -> loading/mask disappears -> blank page on the right panel -> suddenly panels are rendered on the screen. Keeping this approach would also represent a failed point in accessibility because it would seem that the user is not changing from page to page if he/she is using a screen reader software, it also doesn't change the address bar location.

2) Instead of making the host-admin.html.tmpl page a single page with a sidebar that loads all the other pages/panels within the right/middle column, when the user clicks on the top navigation bar in "Administration" it would go to "host-audit-roles.html.tmpl". This and all the other pages would load the sidebar instead of the sidebar loading the pages. This approach would keep the changes on the browser address bar so it would not impact accessibility. We also wouldn't have to worry about asynchronous and synchronous calls happening at the same time.

Regards,

Samuel

[Aline Manera]

Hi Samuel,

On 09/06/2016 12:42 PM, sguima...@gmail.com wrote:

Thanks Lucio,

For now I'm still managing the UI stuff and the menu is working fine. I think the most troublesome work will be on the main Administration page that has at least 3 hidden panels that I've counted. Like I've said, if the changes in the ML are only on the JS files then it probably won't have conflicts at all. I'm not removing the legacy pages but hiding some panels and creating new pages with a readable name, something like "host-network-config" and "host-global-config" while ovsbridges remains as "host-network" because it is the first panel that is appended.

Instead of appending the sidebar object on each page, I'm creating a new home page that builds two panels, one is the sidebar that is dynamically created (in case in the future we decide to move this widget to Wok or Gingerbase too) by a JS object (for now it is a static object but once the backend can deal with this, we can change it) and the other one is the content panel that will be loaded by JS. 

+1 for that. Keep one HTML file with the sidebar and a content area where the JS will built the structure according to each option selected in the sidebar.

--
You received this message because you are subscribed to the Google Groups "Ginger Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ginger-dev-li...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[sguima...@gmail.com]

Hi Aline, I did this but it didn't worked as I expected. Check my questions above.

Samuel

To unsubscribe from this group and stop receiving emails from it, send an email to ginger-dev-list+unsubscribe@googlegroups.com.