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