OK I'm going to go through this one more time...
The way the LC Team setup the Browser Widget version of the Dictionary is probably more complicated than it needs to be but here it is:
1) In the 'Engine' Repo (
https://github.com/OpenXTalk-org/OpenXT ... 963.1/docs) there's category folders full of .lcdocs that contain one (can contain more) entry destined for the Dictionary. LCDOC is a MARKDOWN format, a system similar to what can be used in place of HTML on sites like GitHub INSTEAD of using HTML. The lcdoc markdown a very simple format, readable as a plain-text document.
Here is the source .lcdoc for 'the machine' from here
https://github.com/OpenXTalk-org/OpenXT ... hine.lcdoc:
Code: Select all
Name: machine
Type: function
Syntax: the machine
Syntax: machine()
Summary:
<return|Returns> the type of hardware the <application> is running on.
Introduced: 1.0
OS: mac, windows, linux, ios, android
Platforms: desktop, server, mobile
Example:
the machine
Example:
if the machine contains "Powerbook" then checkBattery
Returns (enum):
The <machine> <function> <return|returns> a <string>.
- x86: windows 32 bit based system
- x86_64: windows 64 bit based system
- iPod Touch: the device is one of the iPod Touch models
- iPhone: the device is one of the iPhone models
- iPhone Simulator: the device is a simulated iPhone
- iPad: the device is the iPad
- iPad Simulator: the device is a simulator iPad
Description:
Use the <machine> function to detect what type of system your
application is running on.
On Mac OS systems, the <machine> <function> uses the Gestalt() system
call to determine the machine type.
On Unix systems, the <machine> <function> uses the uname() system
function.
On Android devices, the <machine> <function> returns the manufacturer's
name for the device. For example, if running on a Google Nexus One, the
string is "Nexus One".
References: function (control structure), processor (function),
application (glossary), return (glossary), string (keyword)
2) The Markdown (which often have a '.md' filename extension) simple-tagged texts are then typically converted into normal HTML by some sort of tooling. In the case of our inherited IDE that tool is the revDocParser (I can't check the exact filename at the moment) IDE script.
3) At first revDocParser converts the contents of those .lcdoc files into keyed entries in an sqlite DB that it creates. The 'keys' of those entrees are the first word in a line that has a colon after it. So "Type:" is going to have something like 'function', command, message, property, glossary, etc. after it, and that will become the value for the key/value pair. I made a list somewhere of the valid keys that
can be used (I don't think any of them are
required), the keys are like Syntax:, Summary:, Parameters:, Description:, etc. Some with some inline entrees such as Name: or Parameters:
If the key is missing the revDocsParser is smart enough to try to guess what parameters a function expects (based on the handler it documents) and may automatically add that info to the entree in the database when parsing inline docs.
4) That database is then used to generate javascript, entrees re-encoded as JSON data that is then used to format and display as HTML in the Browser Widget.
5) The IDE includes a library for getting entries from the Dictionary Database.
I used the revDocsParser to extract the inline- documentation from the IDE Docs library, here is a list of functions that it includes:
ideDocsFetchExtensionData function ideDocsFetchExtensionData(pID,pEntryName)
ideDocsFetchExtensionDataOfType function ideDocsFetchExtensionDataOfType(pID,pEntryName,pType)
ideDocsFetchExtensionElementOfType function ideDocsFetchExtensionElementOfType(pID,pEntryName,pType,pElement)
ideDocsFetchExtensionElementsOfType function ideDocsFetchExtensionElementsOfType(pID,pType)
ideDocsFetchExtensionEntries function ideDocsFetchExtensionEntries(pID)
ideDocsFetchLCBData function ideDocsFetchLCBData(pEntryName)
ideDocsFetchLCBDataOfType function ideDocsFetchLCBDataOfType(pEntryName,pType)
ideDocsFetchLCBElementOfType function ideDocsFetchLCBElementOfType(pEntryName,pType,pElement)
ideDocsFetchLCBElementsOfType function ideDocsFetchLCBElementsOfType(pType)
ideDocsFetchLCBEntries function ideDocsFetchLCBEntries()
ideDocsFetchLCSData function ideDocsFetchLCSData(pEntryName)
ideDocsFetchLCSDataOfType function ideDocsFetchLCSDataOfType(pEntryName,pType)
ideDocsFetchLCSElementOfType function ideDocsFetchLCSElementOfType(pEntryName,pType,pElement)
ideDocsFetchLCSElementsOfType function ideDocsFetchLCSElementsOfType(pType)
ideDocsFetchLCSEntries function ideDocsFetchLCSEntries()
ideDocsFetchLibraryEntries function ideDocsFetchLibraryEntries(pLibraryName)
ideDocsFetchLibraryNames function ideDocsFetchLibraryNames()
ideDocsFetchScriptData function ideDocsFetchScriptData(pEntryName)
Functions like ideDocsFetchScriptData(pEntryName) are used in the scriptEditor for that 'mini-docs' display in the lower pane. If I recall correctly these handlers return a keyed Array that can then be used to format THE style and then you can display the data anyway you like.
I suspect that Tom's conversion missed some keys like Parameters: or is missing some things the revDocs parser infers from the handler it's documenting (if it's 'inline' Docs). Or perhaps he didn't realize some of more nuanced issues about parsing those .lcdoc files, like that an entree can have multiple 'sub-keys', for example if a function takes multiple parameters each parameter is it's own sub-key of the 'Parameters:' key , like other keys it should be separated by a line-break and full empty line before the next line that starts with a key.
This system seems a bit convoluted to me, but that's the way it was setup when we got the thing.
The modified dictionary that includes extra docs for things like the IDE library is here:
https://openxtalk-org.github.io/OpenXTa ... ictionary/