My Startup.html file is getting cluttered. Shouldn't there be a better way to do this?

Jaymer

Assume you are still using the default \AwareIM directory path...
and assume that many of us run multiple apps/clients/BSVs from our Aware installation.

If, in one of your BSVs you use Highcharts, you will modify startup.html to include the source code/libraries.
If in your next BSV you DO NOT use Highcharts, all of those users are still loading the Highcharts libraries in when they launch your app.
Add in some more tools/widgets and the app load time increases (yes, cache kicks in)... usually unnecessarily because not of these big libraries are used by each of your BSVs.

There SHOULD be some way around this by now.

<script src="/AwareIM/highcharts/highcharts.js"></script>
<script src="/AwareIM/highcharts/data.js"></script>
<script src="/AwareIM/highcharts/annotations.js"></script>
<script src="/AwareIM/highcharts/exporting.js"></script>
<script src="/AwareIM/highcharts/export-data.js"></script>
<script src="/AwareIM/highcharts/accessibility.js"></script>
<script src="/AwareIM/highcharts/drilldown.js"></script>

hpl123

10000+ and you should see my typical startup.html lol, has a lot of stuff and all apps take a toll when starting up and is not a good design. I have tried various things and try to always get the source files and use the custom folders instead but is not ideal and not even possible in many scenarios.

Ideally we should have a BS specific solution for this and I intend to try to do this myself using custom JS IF possible (not sure it can be done). The way I thought about doing it is picking up BS name as part of a startup.html function and then load relevant stuff for each app. The absolute best thing IMO though is if we could configure a separate whole startup.html per app as there are other things on the startup.html page that can be app specific.

Jaymer

If you look at BASServer or uiconfig, you see there are things hardcoded in there specific to the implementation.
Likewise, why can’t the developer edit a config file to set variables for start up?.
An easy way to do it would be this:
Startup_BSVname = named_startup.html
Startup_Payroll = start_payroll.html
Startup_Repairs = start_repairs.html

I think you see the pattern.
Aware will scan for this props file as it is opening a BSV. Given the BSV name, it looks for that variable inside the props file.
Finding an exact match... if the payroll BSV is opened, then it sends start_payroll.HTML as defined above.
Not finding a match at all will send startup.HTML as usual.

I think this totally solves the problem, and it’s less than one hour of work.
If you want to make up a second hour of work, then you would use a base startup.HTML with a merge section. And only put the unique code in these HTML files that gets merged into the special section in the default startup.HTML. If not, then you would have the entire startup.HTML file duplicated multiple times. And if you ever needed to change something in the system wide configuration, then you have to edit it manually in each of those HTML files. Also, you have to accommodate two areas to merge… The script area and the CSS area.

And this could easily be in V9.
And if this was to catch on, it could be the solution to some of those config tool defaults that are being discussed currently in a different thread.

johntalbott

hpl123 wrote
Ideally we should have a BS specific solution for this and I intend to try to do this myself using custom JS IF possible (not sure it can be done). The way I thought about doing it is picking up BS name as part of a startup.html function and then load relevant stuff for each app.

This is the approach I've taken. In addition to providing for BSV specific custom files, it allows for Test specific & Operation specific versions of custom files for a BSV. This makes it so I can update a custom file being used by the app under Test without breaking the app under Operation mode. If I publish a new BSV, I just replace any custom files that have changed.

I use a directory structure similar to the below, I refer to "AIM Test" mode as Development and "AIM Operation" mode as Test. Production would be a separate instance of AwareIM with it's own directory structure. This gave me a way to have "logically isolated" Dev, Test, and Prod environments.

hpl123

johntalbott wrote
hpl123 wrote
Ideally we should have a BS specific solution for this and I intend to try to do this myself using custom JS IF possible (not sure it can be done). The way I thought about doing it is picking up BS name as part of a startup.html function and then load relevant stuff for each app.

This is the approach I've taken. In addition to providing for BSV specific custom files, it allows for Test specific & Operation specific versions of custom files for a BSV. This makes it so I can update a custom file being used by the app under Test without breaking the app under Operation mode. If I publish a new BSV, I just replace any custom files that have changed.

I use a directory structure similar to the below, I refer to "AIM Test" mode as Development and "AIM Operation" mode as Test. Production would be a separate instance of AwareIM with it's own directory structure. This gave me a way to have "logically isolated" Dev, Test, and Prod environments.

AIMDirStructure2.png

Good to know this is possible, whatever else you can share John about this solution would be appreciated and support, how about getting something like this in native Aware?

hpl123

johntalbott wrote
hpl123 wrote
Ideally we should have a BS specific solution for this and I intend to try to do this myself using custom JS IF possible (not sure it can be done). The way I thought about doing it is picking up BS name as part of a startup.html function and then load relevant stuff for each app.

This is the approach I've taken. In addition to providing for BSV specific custom files, it allows for Test specific & Operation specific versions of custom files for a BSV. This makes it so I can update a custom file being used by the app under Test without breaking the app under Operation mode. If I publish a new BSV, I just replace any custom files that have changed.

I use a directory structure similar to the below, I refer to "AIM Test" mode as Development and "AIM Operation" mode as Test. Production would be a separate instance of AwareIM with it's own directory structure. This gave me a way to have "logically isolated" Dev, Test, and Prod environments.

AIMDirStructure2.png

How do you get external URL´s loaded via this solution? Local files is one thing but external files is the most common scenario, at least for me.

aware_support

If you want to use custom Javascript then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS/BusinessSpaceName

If you want to use custom CSS then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS/BusinessSpaceName

Aware IM will automatically pick up the files from these folders without the need to modify startup.html

If you want to make the files available to all business spaces put them in the root folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS
or
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS

This is by far the preferred approach. The startup.html should only be modified if all else fails.

johntalbott

aware_support wrote
If you want to use custom Javascript then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS/BusinessSpaceName

If you want to use custom CSS then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS/BusinessSpaceName

Aware IM will automatically pick up the files from these folders without the need to modify startup.html

If you want to make the files available to all business spaces put them in the root folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS
or
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS

This is by far the preferred approach. The startup.html should only be modified if all else fails.

Using this approach how does one modify a custom file being used by the app under Test without impacting the app under Operation mode?

aware_support

Using this approach how does one modify a custom file being used by the app under Test without impacting the app under Operation mode?

Separate testing and production modes are not supported in these folders, so the answer is - you can't. You need to have a separate Aware IM installation and test it there.

Even so, this is the approach to be used rather than the startup.html (which has the same problem by the way)

Also, using the approach described - when you install a new Aware IM version it will NOT erase Custom/CSS and Custom/JS folders, so your custom Javascript and CSS files will remain (another benefit of using this approach)

hpl123

aware_support wrote
If you want to use custom Javascript then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS/BusinessSpaceName

If you want to use custom CSS then you should put it in this folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS/BusinessSpaceName

Aware IM will automatically pick up the files from these folders without the need to modify startup.html

If you want to make the files available to all business spaces put them in the root folder:
AwareIM/Tomcat/webapps/AwareIM/Custom/JS
or
AwareIM/Tomcat/webapps/AwareIM/Custom/CSS

This is by far the preferred approach. The startup.html should only be modified if all else fails.

I use this extensively and works but in many cases I only have an external url e.g <script src="http://code.jquery.com/ui/1.9.2/jquery-ui.js"></script>, do you know some way of using the current Aware way to pick up these external url´s?

PS: Another thing, I have experienced the custom folders getting deleted when installing new versions so do not rely fully on it not being deleted.

aware_support

do you know some way of using the current Aware way to pick up these external url´s?

You can download the file from the URL and put it in the custom folder

PS: Another thing, I have experienced the custom folders getting deleted when installing new versions so do not rely fully on it not being deleted.

They shouldn't be. There were some bugs there at some point but they have been fixed. We are not aware of any report of misbehaviour in this area.