Expanding Dashboard Functionality

Get Help
1

Hi all,

I’ve been looking at adding a new feature to our OnDemand dashboard (that I plan to share with the community when I’ve worked out some bugs with it). I want this feature to be accessible from anywhere in the dashboard app (home, interactive apps, but not necessarily places like the files app, job composer, etc because those are separate apps from the dashboard). To start, I’ve added code to 4 files

.../var/apps/sys/dashboard/public/assets/application-2892928d592ea7a524d987c85a5e6b8bc2786aa8fd5a4bffe6c4158ea39020a9.js
.../var/apps/sys/dashboard/app/views/layouts/_feature.html.erb
.../var/apps/sys/dashboard/public/assets/application-5a71c15dc32e52ce12816788532d4913b76b0ddb742b75f7c58bfce4e8555966.css

And at the bottom of .../var/apps/sys/dashboard/app/views/layouts/application.html.erb

I added

<%= render "layouts/feature" %>

Here are my questions:

  1. Is there any documentation on extending the dashboard functionality/appearance beyond just a basic theme? I looked through the documentation but I couldn’t find anything, which makes sense with this being kind of a unique case.
  2. Are the characters in the .css and .js after application- random for each installation?
  3. If I need to add javascript and css, are those the best files to use? I’ve added code to both of those files and it seems to work just fine, but I wanted to make sure I was putting my code in the right place.
  4. I would like to set some variables on the server side rather than requiring variables to be changed in javascript so that if this was shared with others, I could say “add x to your config file” rather than ask people to edit the javascript. What is the best way to add configuration parameters that propagate into html/js. It seems like this should be possible with the erb syntax?
  5. I don’t want to break the main functionality of OnDemand. What kinds of things should I be on the lookout for? Any tips/lessons learned from anyone who has done “core” OOD development?
  6. My .css additions are just default css, but my javascript (mostly jquery and one other small library) are wrapped in a $(document).ready(function() {. Is that how it should be setup in application-2892928d592ea7a524d987c85a5e6b8bc2786aa8fd5a4bffe6c4158ea39020a9.js?
2

You seem to be editing production deployed files. You shouldn’t do that. Depending on what you do, you may need to rebuild the assets and that could get tricky as it’s already been deployed to filesystems owned by root.

You should instead do what we do - develop the dashboard in your local $HOME directory

  1. The link above may be the only docs we have on extending/developing the dashboard.
  2. They are random for each version/build. It’s a mechanism to cache bust. That is, if 3.1 has new assets - they have a new unique id so they’ll get pulled by browsers and the 3.0 assets that have been cached won’t be used.
  3. CSS is compiled into a global/single file. So separation for it is really only for developers organization of files. JS compilation is a little more involved, but is basically the same convention.
  4. You can see how we do this for file uploads. We embed the configuration in the HTML so that javascript libraries can pull the values from the same.
    <%= content_for?(:title) ? yield(:title) : \"Dashboard - #{@user_configuration.dashboard_title}\" %>
  5. I rely on the CI (continuous integration) on github to catch any mistakes. You can run the same tests locally, though you don’t need to do e2e (end to end) tests, unit tests are good, system tests are better.
  6. We use document ready a lot, I think that’s fine depending on what you’re trying to do.

All that said - if you opened a pull request against the main OnDemand repository, even if it’s draft/work in progress I’m happy to take a look and provide feedback. Even if you don’t want to provide it upstream I can help you manage it so that you can merge it to your fork and build a new RPM for your site.

1 Like
3

Awesome, thank you Jeff! I’m going to go over your responses and update what I’m doing. I’ll follow up if I have any questions.

if you opened a pull request against the main OnDemand repository, even if it’s draft/work in progress I’m happy to take a look and provide feedback. Even if you don’t want to provide it upstream I can help you manage it so that you can merge it to your fork and build a new RPM for your site.

I have to get all code approved before I can release it (even for draft work unfortunately). We’re very close to being able to release all of our previous apps, but this one will take a little longer as it’s more involved than the default interactive apps. I do plan on starting the release process for this one soon so hopefully I can make a pull request in the next month or two.

4

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.