I am still exploring the possibilities. I very much like Livecode. It deserves some industrial strength well-known applications that speak for this language. I believe that Livecode should have the power and potential to do the same or better than any Javascript application (with HTML5, CSS3) or any native Window application written in whatever language - with the exception of system specific and low-level functions.
Ultimately, is must create a very rich and pleasant user experience.
And thanks all for those very kind replies and your knowledge. Currently, I am still only good in asking questions ).
Actual data binding question
One new question is how to best accomplish what is called "data binding". This means that, for example, in a bi-directional binding any change in the data source would reflect in a user-level object, a field or button or list, and any changes in the field would reflect in the data source.
Let us assume the data source is SQLite and a field formatted as table field is representing the data.
The user would enter data into the field, and the change would automatically reflect in changing the associated column value or values in the database. This seems to be easy to do programmatically. But what happens the other way around? From outside, someone would change the database field, and now - usually using a database trigger - this change on the database level will automatically reflect in the user level field.
Now, let us assume there are all kinds of data, including sound, images, videos, text lists, etc. Leaving data in the data source untouched, just retrieving it, on the user interface data would be displayed according to Livecode controls available or created (LC objects, now widgets).
But already we might use an intermediary function to create different data views through grouping and sorting and filtering before presenting. We could even store the original data as different views as properties of the card, or in global variables, or intermediary text files... or create them at runtime. (This does not mean that a new query would to possibly better to achieve the same result, but I am trying to explain for demonstration purpose only.)
Then, on the presentation layer, we may want to present dates and numbers formatted in user- or culture-specific ways using localization functions: number formatting, color coding, date- and time formatting, etc.
Livecode keeps track of many events which would trigger updating the database whenever any change appears on the user level.
Yet, I do not know how to make a Livecode stack aware of changes that appear in a data source such as SQLite (or MySQL or whatever).
Would there be some kind of a function frequently checking for any changes that might have occurred? Or how can Livecode be notified from outside itself (or from an outside database, or even from an outside text file)? Could that be a service running separately checking for changes all the time? Could there be another second LC instance doing this?
And what would be best practice to build a framework around that would support more quickly building the components of such a system and would just require faceless stack files (script-only stacks) and keep all the logic completely distinct from the presentation layer?
I see a scenaratio such as:
======================================================
DATASOURCE <-> VIEWS <-> LOCALIZATION <-> PRESENTATION
======================================================
PRESENTATION ./. LOGIC ./. DATA ----> kept separate from each-other as much as possible.
One database query can result in many views, and a selected view would be formatted to represent localized data.
Let us take a simple field as an example. I would user custom properties to define the way how this field displays data, for example, decimal numbers with thousand separators. Even the decimal point or comma would be displayed according to such local setting. This means that such field would turn into a number field. Another field would be a date field and so on.
The field could have the same name as the column in the associated database source. Therefore, it would automatically know from where to fetch data. Another property would define which table it is associated with.
Through some trigger (messages caught) mechanism, the field would present the data of currently selected value of a column (field) in the database. The user would be able to move through all the records, or he would simply use another query. The field "knows" from where to take data and how to present it. If the user changes data in the field, also automatically the value in the associated record in the database will be updated (or deleted or created).
But then again, how would the field know about changes in the database and automatically reflect the latest value?
---
Maybe then also a mechanism could be established whereby specific field types would automatically be created when the user selects a database field. If defined to contain numerical values, the Livecode field would be numerical as well using local formatting and be bound to the database field.
Or would there be an intermediary array where we bind the field to the array and the array to the database?
And/or is there a possibility to define a field which would also have the same name (binding it to the same database field as well) but would present another type of formatting, or a calculated value based on the field value where the calculation is dynamically updating when the original value is updating? Since two fields with the same name are not a good solution, the database name may be better reflected as a custom property of the field. The id on the other side would not survive when changing the stack, when rebuilding user interface items dynamically, etc. Or there would have to be a mapping table mapping whatever current ids are present with the names and other specifications of a control.
---
I hope my questions are not too far fetched... ). I am thinking aloud without wishing to be annoying doing that.
