|
| Iniciado por EKoster, 09,abr. 2021 12:24 - 5 respuestas |
| |
| | | |
|
| |
Miembro registrado
16 mensajes |
|
Publicado el 09,abril 2021 - 12:24 |
I want to use an external file in my application to store specific configuration values. This is easier to maintain in specific situation later on in my project. The idea is to read it during initialization and store the content in a variable so you can do e.g. 'variable:key' in the project to use a specific setting
With 'fRead' you can read a file but you need to pass the number of bytes. You can also read per line. But is there something to read a complete file at once. These files aren't big and the number of bytes can change when you change the file content. In java for example you have 'readAllBytes'.
I'm thinking of these steps:
1. open file and catch error if there is on
2. read file
3. close file and catch if error
4. validate if it is json format
5. store in variable
An example for the content would be:
{
"key1": "value1",
"key2": 2,
"key3": [
{
"sub1": "value",
"sub2": "value",
}
]
"key4": [
"test",
"test2"
],
"key5": {
"sub1": "value"
},
}
So it's a json object containing keys if values of string, integer, array, objects etc. |
| |
| |
| | | |
|
| | |
| |
Publicado el 09,abril 2021 - 16:01 |
It's much simpler to use an ini file and the iniread/iniwrite functions, but if you want to reinvent the wheel, the answer to your question is the function fLoadText |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
16 mensajes |
|
Publicado el 09,abril 2021 - 18:47 |
Thanks Argus. You answered my question, and one I was looking into as well. I'm going to use the ini file for specific situations, and others use a json file for other reasons then just verifying a key etc. There are situations where that would fit better then an ini file. |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
18 mensajes
Popularité : +1 (1 vote) |
|
Publicado el 10,abril 2021 - 05:40 |
Ekoster-
I implemented a solution similar to what I think you are getting at; for REST API service documentation and usability. I wanted to have the the "External description" of the JSON serve as both the structural definition of the JSON assigned as the description to the JSON variable, but also serve as a dynamic reference containing documentation of API request and response object and the connection details for interacting with each REST Endpoint. It's a pretty simple method/workaround, but worth sharing. It's been a valuable, manageable, method we've used for a few years now.
The simple, but very valuable example, is having the REST Endpoint uri as a dynamic reference during the life of the application. Whenever a client need to use a REST service, the check the GUID of our published JSON and if changed the client pulls the updated reference JSON. So if we need to move a REST endpoint onto a new version or branch, we can update the reference and dynamically migrate clients. We can even control which clients get which reference JSON (valuable for corner case bug fixes, controlled feature releases, etc.)
We wrote all our JSON structures with documentation fields as well as reference structures, endpoint definitions, Authentication parameter requirements etc. The problem was we couldn't access all those prepopulated goodies when from the "external description" and assigning "Variable is JSON <description..." It loads the structure but didn't give us access to the dynamic fields.
Luckily the workaround is simple. We use the JSON files with all the dynamic reference data and update them in the External Descriptions, so they are usable for programming. We also include those json files in the Library when we compile and push an update to our REST servers. The service does an ExtractResource from the library whenever the Library version is new/changed, and writes the physical json file for each External Description. Clients reference the latest version for both the dynamic REST uri and data structures and documentation at the same time our REST code does and many updates, features, etc. are able to be rolled out without forcing clients and partners to deprecate their code ahead of "breaking changes".
I hope this is helpful for what your were looking for. It's been a clean solution for us, allowing documentation and API data/object models to be centrally maintained in the JSON. It provides for a lot more creative uses, like enabling third-party integrators (or our own integration of upstream API's) to dynamically inform our API of the data structure/model they send and/or want in response. It's kind of a hybrid of swift, Postman, xsd, yaml, wsdl and middleware-concepts; simplified in JSON without a lot of headaches.
Stephen Myers |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
18 mensajes
Popularité : +1 (1 vote) |
|
Publicado el 10,abril 2021 - 06:00 |
Here is a snippet of very simple example demonstrating REST endpoints; some for clients, some for upstream service integrations and callback entry points. This one is sanitized, but you can see the idea of providing documentation, API documentation, data structures all in the same single system of record used to cast JSON structures to variables in Windev. With a little creativity, this approach can inform the client code and enable implementing workflow and jit-webservices.
"flexuc": {
"sms_send": {
"api_desc": "Sends an SMS message from a client.",
"api_token_required": false,
"api_uri": "https://api.example.io/clouduc/smsg",
"api_method": "httppost",
"api_reqtype": "json",
"api_restype": "json",
"request": {
"from" : "",
"password" : "",
"callerid" : "",
"callerdisplayname" : "",
"to" : "",
"body" : "",
"smart" : "",
"content_type" : "",
"disposition_notification" : "",
"device": ""
},
"response": {
"sms_id": "",
"message": ""
}
},
"mms_filemsg_structure": {
"attachments": [
{
"id": 0,
"encryptedBlob": {},
"content-size": 0,
"encryption-key": "",
"filename": "",
"content-type": "",
"hash": 0,
"content-url": ""
}
],
"body": ""
},
"sms_fetch": {
"api_desc": "Checks for SMS messages waiting delivery to the client.",
"api_token_required": false,
"api_uri": "https://api.example.io/clouduc/rmsg",
"api_method": "httppost",
"api_reqtype": "json",
"api_restype": "json",
"request": {
"username" : "",
"password" : "",
"last_id" : "",
"last_sent_id" : "",
"device" : ""
},
"response": {
"date": "",
"unread_smss": [
{
"sms_id": "",
"sending_date": "",
"sender": "",
"content_type": "",
"sms_text": "",
"disposition_notification": ""
}
],
"sent_smss": [
{
"sms_id": "",
"sending_date": "",
"recipient": "",
"content_type": "",
"sms_text": "",
"disposition_notification": ""
}
]
}
},
"delivery_notifications": {
"receive_notification": {
"api_desc": "FlexUC API url called by Provider with POST of delivery notification details.",
"api_token_required": false,
"api_uri": "https://api.example.io/sms/deliveryconfirm",
"api_method": "httppost",
"api_reqtype": "json",
"api_restype": "201 No Content",
"request": {
"guid": "",
"account_id": "",
"source_did": "",
"destination_did": "",
"timestamp": "",
"send_status": "",
"status": "",
"error": ""
}
}
}
} |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
16 mensajes |
|
Publicado el 11,abril 2021 - 08:52 |
Thanks Stephan. I have what I want running. To read it dynamically I've a question (for a new post) |
| |
| |
| | | |
|
| | | | |
| | |
|