Website Generator

From Cumulus Wiki
Jump to navigationJump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Introduction

Website Example Wolfshagen

While CumulusUtils started as a collection of modules to be used at will in the creation of a weather website - for the site of the author - after several modules it became clear that generation of a complete website would not be too difficult. It required a HTML framework within which the modules would fit, a menu, a runtime system to handle the realtime data, loading of files, clocks, sun and moon and an adaptation of mcrossley's gauges.

The work set out on a scratch board where the site was drafted and the runtime was coded. The choice was made to split the screen in two in a 5/7 ratio which never changed since. The right pane became the ReportView where the user chooses the report he wishes to see while the realtime data are always visible in the left pane, the Dashboard. The contents of the Dashboard can be toggled between two sets of twelve panes and the lunar disc can be replaced by the lunar image produced by CMX (see DashBoard).

In the example on the image on the right you see Holgers' fully translated site with expanded user menu and even multilingual by his own design to show off the things possible with the CumulusUtils framework.

Operation

The website generation includes in principle all modules. It is created with the following command:

  utils/bin/cumulusutils.exe Website

Output

The output of the website generation is the output of all individual modules and in addition:

  1. index.html => is the Bootstrap formatted start page of the site
  2. cumulusutils.js => is the javascript runtime system
  3. cumuluscharts.txt => contains the charts for the Home page and is originally based on the CumulusMX recent charts. This file is produced by the ChartsCompiler but if the compiler is not used, the original charts as present in the old standard CumulusMX website will be presented.
  4. HighchartsLanguage.js => contains the language definitions for the charts. Not many possibilities are used but that may change. It is generated each run.

These files will be generated by the Website command. If you did not change anything, apart from the index.html they do NOT need to be uploaded (see the Thrifty qualifier)

The following files are not generated but are required. If not present a message is logged on the console.

  1. CUserAbout.txt => The menu choice About=>This Site uses the contents of a file named CUserAbout.txt to be displayed in a popup window. As you can imagine, the user has to create this file himself. The contents of this file must be text with HTML tags for formatting.
  2. CUsermenu.txt => The user menu can be added to the standard menu using the file CUsermenu.txt which is explained elsewhere in this wiki.

Inifile parameters

NOTE: The Website Generator works closely together with the Internal FTP facility. You have to setup that first or upload the output manually. It's user preference.

The Website section is the largest parameters section. Not all parameters will be reproduced here, see the Cumulusutils.ini article. Only the important individual parameters will be discussed, the others are discussed as a group.

 [Website]
 // The statistics parameters are currently either for Google or Matomo 
 // If the corresponding ID's and or Url are not filled in, invalid code is generated. If you do not want
 // statistics than set StatisticsType without value
 
 StatisticsType= [Google || Matomo] default is empty 
 GoogleStatsId=                        => When not empty, a google stats code fragment will be generated with this code as the user Id, default is empty
 MatomoTrackerUrl=
 MatomoSiteId=
 PermitGoogleOptout=false (default)    => Permits to generate code so the users own access to the site will not be measured, default=false
 CumulusRealTimeLocation=              => see below, default is empty
 ShowInsideMeasurements=true | false   => when true, inside temperature and humidity will be shown on the website (when available in the datafile), default=false
 CumulusRealTimeInterval=30            => The refresh cycle time of the runtime system to update the values on the dashboard and gauges, default=15
 ShowUV=true                           => Show the UV values (if there is a sensor), default=true
 ShowSolar=true                        => Show the solar radiation values (if there is a sensor), default=true
 HeaderLeftText=                       => A free plain or HTML formatted text destined at the left side of the header, default is empty
 HeaderRightText=                      => A free plain or HTML formatted text destined at the right side of the header, default is empty
 SiteTitleAddition=                    => A free text addition to the title, default is empty
 UseCMXMoonImage=false                 => When true the CMX generated moon image is used i.s.o. the CUtils native abstracted image 
 MoonImageLocation=                    => The full URL for the moon image, used when UseCMXMoonImage=true, ignored otherwise
 PwsfwiButtonInHeader=true             => When true the direct access pwsFWI button will show in the header, when false it shows in the menu bar

All parameters starting with Panel affect what you actually see in that panel See Dashboard for more information.
All parameters starting with Color affect the Bootstrap elements relevant for the interface and give the user the possibility to create a personal touch to the presentation.
All parameters starting with Steelseries affect the presentation of the gauges. You may find examples here and here [1]. See also the SteelSeries FAQ.
All parameters starting with Threshold give a definition in pairs for a red led within a gauge to start flashing when the given boundary has surpassed.
All parameters starting with Home apply to the Home page graphs and give the user the possibility to explicitly set non-default colours [2].
When colours go in three they are gradient colours. If only the first colour is used, no gradient effect is seen.

  1. See the site of Mark Crossley if you wish to see more and create gauges yourself: lineair, extras, stopwatch, lightbulb, LCD and trafficlight
  2. When use is made of the CutilsCharts.def definition of charts for the ChartsCompiler, then these colours have no meaning and either the colours from the CutilsCharts.def or from the theme (if none specified) are used

Header Background Images

(v6.8.4 and up) Special attention must be given to the Header Background Images parameters, meant to make user specific artwork to the site possible. The perception of the site changes dramatically when the header image changes in colour, brightness and what is actually depicted.

ColorTitleBackGroundImage=                 (this image represents the DAY, for historical reasons the name of the parameter has not been modified)
ColorTitleBackGroundImageCivil=
ColorTitleBackGroundImageNautical=
ColorTitleBackGroundImageAstronomical=
ColorTitleBackGroundImageNight=

These parameters may contain the name of an imagefile which the user has placed on the website. The path must be relative to the webroot or a full URL specification. The images correspond to the respective phases of the day: DAY, CIVIL twilight, NAUTICAL twilight, ASTRONOMICAL twilight and NIGHT - see the solar disc in the dashboard - and are displayed when that corresponding phase starts. If an image is not specified, the image of the preceding phase is used where the order is: DAY, CIVIL, NAUTICAL, ASTRONOMICAL and NIGHT. So, when only DAY is specified, all phases have the DAY image displayed. When DAY and CIVIL are specified, DAY gets the DAY image and all other phases get the CIVIL image etc...

Chart Background Images

(v6.9.6 and up) It is possible to define a background image for the chart as a whole (so not only the plot area but also the axis and titles). For this a general parameter exists (general because it is valid for all modules carrying charts):

ChartBackgroundImage=

If this parameter contains a filename, that file is used as background image of the charts. Note that the specification may also be a url which must be accessible by the user running the website.

CumulusRealTimeLocation

The parameter CumulusRealTimeLocation gives the user the possibility to setup the CumulusUtils website beside a main website and share the realtime and datafiles with the other site.

If there is a directory structure like:

 \                              as webroot
 |
 - cutils\                       as directory where the CumulusUtils site is located
     |--- lib\
     |--- css\ 
     |--- CUicons\

then, when CumulusMX sends the realtime and datafiles to the webroot, you can set the CumulusRealTimeLocation to ..\ and it will automatically find the realtime and datafiles it needs.

Javascript libraries

When using the Website Generator, all modules are used implicitly. Modules, with some exceptions, can be used standalone in any website by including the output of CumulusUtils in that website. When using the standalone mode you need to be aware of the inifile parameters (section general) GeneratejQueryInclude and DoLibraryIncludes.

  1. GeneratejQueryInclude will - if true - generate the required jQuery library reference line on top of the module.
  2. DoLibraryIncludes will - if true - generate the required library references (e.g. HighCharts, Leaflet etc...) on top of the module.

If you manage these libraries in your website yourself set these parameter values to false. If the modules don't work and you have no idea what this is about, set these values to true.

If you use the Website Generator, set both parameters to false.

On top of the above use of these parameters, if you wish to run the ChartsCompiler as a module i.e. explicit activation (command CompileOnly) but for use inside the CUtils environment then both library parameters must be false.

Other remarks

In this section some special subjects and questions and answers from the forum will be summarized

The Clocks

The clocks panel of the website shows three clocks:

  1. Station which is the actual time at the location of the station corrected for DST of the station location
  2. Browser which is the time on the computer of the viewer corrected for the browser location DST
  3. UTC

It is important for the automatic DST switch to understand that the generation of the daily website needs to take place after the switch time. So in spring that would be at 2 o'clock and in autumn that would be after 3 o'clock. If run before those hours the DST correction will obviously take place one day later.