Install Community plug-in (Admin Setting)

Adam_Dzyacky

With the kind of awesome extensions that are getting released freely by members of the community, their organization feels a bit disconnected. What's more, these solutions are tested against specific versions of the portal, and require bulking up your custom.js file (not really isn't a criticism, more of a long-term maintenance task).

The list of customizations goes on and while the Community Uploads area is a great place to store these. It'd be even cooler if there was a more dedicated function within customer's deployments of the Cireson portal to either:

• Pull this content and deploy (i.e. Cireson hosts these in some central location)
• Allow some mechanism of "loading" plugins into the portal (i.e. nothing changes about the way we fetch plugins, just their mechanism for loading)

It goes without saying that the first point of mine is rendered a bit useless in air gapped environments and/or will make your security team flip tables if there isn't some kind of Cireson vetting process happening first (think SCOMs 2012 R2 Administration -> Partner Solutions)

The second point however I think really helps streamline the process. Furthermore, this could be built into an Admin GUI pane that allows the addition/removal/enabling of select plugins. In doing so, accidental changes to the custom.js are at the very least curbed. This could also be useful in load balanced environments where the changes could get distributed to all portal servers. Finally, it may in turn create the need to standardize what plugins look like (i.e. zip files contain some common folder structure)

Here's a quick sketch of what I'm getting at from a GUI perspective:

Leigh_Kilday

If I've understood you correctly...

We are modularizing custom.js and custom.css. This enables us to comment out add-ons we don't want to use and have each stored in its own file. I think the credit for custom.js method goes to @Martin_Blomgren.
In custom.css we're using:
@import url('/CustomSpace/css/filename.css');
and in custom.js, we're using a "Script Loader". It is a small script atop the file that allows us to separate the customisations by file references, like in custom.css. I'm sure somebody will recall this and post the code.

Joe_Burrows

Leigh_Kilday said:

If I've understood you correctly...

We are modularizing custom.js and custom.css. This enables us to comment out add-ons we don't want to use and have each stored in its own file. I think the credit for custom.js method goes to @Martin_Blomgren.
In custom.css we're using:
@import url('/CustomSpace/css/filename.css');
and in custom.js, we're using a "Script Loader". It is a small script atop the file that allows us to separate the customisations by file references, like in custom.css. I'm sure somebody will recall this and post the code.

This thread?

Martin_Blomgren

I'm not the author of "Script Loader". Seen it in works from @Geoff_Ross so either he is the author or like me "steals with pride"

The idea with Script Loader is to log if your custom script successfully loads or not using promises, not something I'm currently using as you probably know if you customizations are visible/working or not and in an end user perspective no one is using the console to see those logs anyway. Not saying that you shouldn't use this as there could be other effects which I'm not aware of and for non developer admins using all custom stuff uploaded here, pressing F12 and get some info is actually very nice!

One fundamental difference in Script Loader vs jQuery's $.getScript() is that Script Loader appends the custom js in DOM into a script element as a child to head where jQuery (if from same domain) downloads and executes in memory. As I'm new to frontend/client side stuff (usually only do backend) I cannot say which way to prefer or if it is any difference at all in for example performance etc. Another difference (need some small changes in Script Loader) is that Script Loader is (could be) a pure js solution not dependent on jQuery.

change:<br id="null">$("head")[0].appendChild(script); <br id="null">to:<br id="null">var head = document.getElementsByTagName('head')[0];
head.appendChild(script<span>);)</span>

What we could use promises for is to load libraries which your custom work is dependent on and the fire of your custom js when the promise is fulfilled, making sure that objects, variables and functions is initialized when needed.

Like the idea of simplifying custom script loading as a whole. One way of doing this could be to have a custom folder where you drop your js and inside the portal admin => custom settings all files is enumerated and you could easily with a checkbox enable or disable those. Here we could use promises so we can alert the user if something went wrong or if it loaded successfully!

UPDATE:
Did some research on pure js way (Script loader) vs jQuery and one BIG difference is that that jQuery disables cache where pure js alternative with script tag is cached. As Cireson mainly using a client side framework and view (AngularJS/Kendo) it's a lot of files to download and even though our custom stuff often is small we want to cache when possible!

Adam_Dzyacky

Update: Added a sketchup of what I'm getting at to the original feature request.

Leigh_Kilday

Joe_Burrows said:

Leigh_Kilday said:

If I've understood you correctly...

We are modularizing custom.js and custom.css. This enables us to comment out add-ons we don't want to use and have each stored in its own file. I think the credit for custom.js method goes to @Martin_Blomgren.
In custom.css we're using:
@import url('/CustomSpace/css/filename.css');
and in custom.js, we're using a "Script Loader". It is a small script atop the file that allows us to separate the customisations by file references, like in custom.css. I'm sure somebody will recall this and post the code.

This thread?

Yes, credit to @Geoff_Ross!

Geoff_Ross

Woah woah woah. Stop right there @Martin_Blomgren and @Leigh_Kilday. I am not Sparticus. I too stole the script loader code. From @Stefan_Henseler but I do have a sneaky suspicion he's not the original author either. Forgive me if I'm wrong Stefan.

Either way @Adam_Dzyacky, I love this idea. Agree that the awesome stuff already uploaded to Cireson Uploads is amazing but could be better organised. However, must object to your mock up. I wrote the 'Show Activity History' code and you give credit to @seth_coussens!!!

Adam_Dzyacky

In my defense @geoff_ross I was snapping back in my head to this thread.

Martin_Blomgren

@Geoff_Ross
I had my suspicions so to cover all my bases, quoting myself:

"either he is the author or like me steals with pride"

Geoff_Ross

@Martin_Blomgren Indeed, with pride.

Brian_Wiest

Good Idea. Upvoted. But don't think this would work for my as an Air gapped enviroment.