I am relatively new to Open OnDemand and I am trying to learn the best practices for modular styling and design for pages, specifically for the form.yml.erb. I noticed in the html there are predefined divs which I am able to access manually by calling a javascript function in a form.js file. For example, for the mb-3 divs (depicted in the attached image) I could select each div with document.querySelectorAll(“.mb-3”).forEach(el => … and then rearrange/change those elements in whatever way I want. However, this process is very slow and doesn’t lend itself to great customizability across forms. I am wondering where I can access the .html itself that is used to build form.yml.erb pages so I can then alter the structure of the page without having to rearrange existing elements with JavaScript.
Another aspect I am curious about is the best practice for styling. I have been able to style parts of the form by importing .css files but it seems as though some of the styles I attempt to apply to the default page elements (as described above) are overridden and thus not applied. Similarly, it seems like bad practice to remove default elements from the page by setting their style.display to ‘none’ rather than just removing them from the HTML. For example, if I wanted to remove the large sidebar that displays all of the available apps in a form.yml.erb file, how would I do that without using the strategy described before?
I believe they’re generated programmatically through the Ruby gem bootstrap_form, so it may not be so easy.
I’m pretty sure you define the order in the form.yml.erb. I.e., the order they’re defined in the form section of that file is the order they’ll appear in.
I think your best bet is to override that partial page, removing/adding what you’d like.
Thank you so much! This is very helpful – pointing me to the OOD GitHub has made it a lot clearer of how to best go about customization. Now, when I go to edit an existing partial, how can I ensure that making changes in the etc/ood/config/apps/dashboard route won’t affect other users on the cluster? My goal is to apply these form styling edits to apps in my local prod folder for now. Thanks!
It’ll affect all users. I guess you need a 2nd test instance for staff? You may be able to apply FACLs to the file so it isn’t loaded. For example you could chmod it to 640 so it’s not readable by regular users then chown root:staff or something similar so it’s only readable by staff members in the staff unix group.
That said, I’ve never applied FACLs to partials so I’m not 100% sure it’d work and not error out.
Thank you! Yes, I will definitely give that a shot! Before I try that out I’ve got a few questions about another possible way to go about this: Is there any configuration file that would let me point OOD to use a personal folder for partials, or is that kind of override only supported under /etc/ood/config/apps/dashboard/views? Would it be possible to set up something like this in the OOD architecture?
Also, I’m still getting familiar with Ruby on Rails, so I want to check my understanding of how the rendering works. From the docs:
“Open OnDemand is built with Ruby on Rails which uses partials to build the web pages that are ultimately served to the clients. All partials are held within dashboard’s views folder. These are the default partials that get distributed when you install the package.”
Am I right in thinking that Rails reads those partials, compiles them into a full HTML page, and then passes that back to Apache (via Passenger), which serves it over HTTPS to the browser?
Finally, just to confirm: there wouldn’t be a way to build a JS file that “reroutes” OOD to use partials from a local folder, right? That override mechanism only works through Rails’ normal view lookup, not client-side JS?
Unlikely. I mean this is sort of an admin privilege to be able provide new partials. I’m not sure I’d feel comfortable opening this up further than it already is.
Yes that’s right.
No because as you seem to know, it’s all server side.
Maybe what you want is to boot the dashboard in development mode and test out changes there before promoting them to production where others can see it? It takes a bit of work to setup, but that’s how we develop OnDemand (we use a production system to boot the development app).
