Webtags (preserving history): Difference between revisions

From Cumulus Wiki
Jump to navigationJump to search
m
→‎Where to use: update link
m (→‎Where to use: update link)
Line 138: Line 138:
This is meant for services either on the same computer as Cumulus or on your local network. It is not secure, and should not be available, nor requested, via any external network or the internet.
This is meant for services either on the same computer as Cumulus or on your local network. It is not secure, and should not be available, nor requested, via any external network or the internet.


The [[MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and another api to return the results of any edit made. If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you would edit that HTML page to have the extra sub-table you want (you cannot extend the existing rainfall table as that is dynamically created by existing api) and you would edit the associated JavaScript file '''CumulusMX/interface/js/todayyest.js''' to add a new api call seeking snowdepth, snowfalling, snowlying tags for today (unfortunately there are no tags for yesterday's snow) and to place the returned values into your new sub-table (probably using jQuery to make it easy). In a similar way, you could add anything where today and yesterday tags are available such as UV Index.
The [[Cumulus_MX_Local_API|MX Administrative Interface]] uses some application programming interface (api) calls to obtain the data each web page in that interface needs, and if you are making an edit, another api to return the results of any edit made.  


In earlier versions of Cumulus if you wanted to make use of values processed by Cumulus, you wrote a script file referencing the web tags you wanted to use, and let Cumulus process that file at an interval set in the settings, then you had to write something to process the results at the relevant interval. Now if you are running other software on your device that runs MX (or a computer or other device linked directly on your personal network), you can request web tags values on demand via an application programming interface (api hereafter) and don't need to worry about any timing issues.  
If you wanted your '''CumulusMX/interface/todayyest.html''' web page to include something else (e.g. snow falling/lying/depth) you could edit that HTML page to have the extra sub-table you want (you cannot edit the existing rainfall table as that is dynamically created by existing api). Then you could edit the associated JavaScript file '''CumulusMX/interface/js/todayyest.js''' to add a new api call seeking snowdepth, snowfalling, snowlying tags for today (unfortunately there are no tags for yesterday's snow) and to place the returned values into your new sub-table (probably using jQuery to make it easy). In a similar way, you could add anything where today and yesterday tags are available such as UV Index.
 
In earlier versions of Cumulus if you wanted to make use of values processed by Cumulus, you wrote a script file referencing the web tags you wanted to use, and let Cumulus process that file at an interval set in the settings, then you had to write something to process the results at the relevant interval. Now if you are running other software on your device that runs MX (or a computer or other device linked directly on your personal network), you can request web tags values on demand via an application programming interface ('''api''' hereafter) and don't need to worry about any timing issues.  


Obviously each api request creates a processing overhead on Cumulus so use this feature wisely (minimise the information you request and minimise the frequency of requesting it). You can use it for extra current information, but in that usage you might need to repeat the call. Consequently, maybe it is more likely that the api will be used to request information that does not keep changing, such as what units are being used for temperature, rainfall, and wind speed; or perhaps daily, monthly, or yearly, summary figures.  
Obviously each api request creates a processing overhead on Cumulus so use this feature wisely (minimise the information you request and minimise the frequency of requesting it). You can use it for extra current information, but in that usage you might need to repeat the call. Consequently, maybe it is more likely that the api will be used to request information that does not keep changing, such as what units are being used for temperature, rainfall, and wind speed; or perhaps daily, monthly, or yearly, summary figures.  
5,838

edits

Navigation menu