If you have tried to load or persist Objects in traditional languages, you know how difficult it can be because of impedance mismatch between the Object and Flat/Relational Models. XML is bridging the Gap but XML is not human readable and there are a lot of boiler or framework code just to do the plumbing. Well, in Rebol, Object Persistence is so trivial it may not even be worth mentioning it for Rebol Veterans, but for you who are newcomer and maybe used to DataTable, DataSet, DataAdapter etc. you may have to un-learn and go back to down-to-earth simplicity 
As the best practice in programming is to store some parameters in an application configuration file, we’ll choose this as example. You can use ini file or xml file (we’ll see how to parse an XML file in a future lesson). But in Rebol, it’s better to use a specific format that is both easy to read by human and to interpret by the scripting engine that is Rebol’s object format. As it’s so easy to do so in Rebol that even a simple script should use it.
I have learned to do so by looking at 3Flex configuration file - 3flex.preferences - which contains:
inactive-node-color: 240.235.230
active-node-color: 255.250.250
workspace-color: 255.255.255
minimal-node-size: 100x35
most-recent-file: none
drawer-header-height: 20
drawer-color: 240.240.240
To read this file, the instruction is simply:
prefs: construct load %3flex.preferences
Construct creates an object, but without evaluating its specification. Load binds Words to Global Context.
To access a preference, write something similar to this
color: prefs/workspace-color
Update! forgot to tell you how to save back the preferences: you have to save the body of the prefs object (you have learnt how to in Rebol’s Reflection):
(pick to-block mold prefs 3)
test it with:
prefs/workspace-color: 0.0.255
save %3flex.preferences (pick to-block mold prefs 3)
In conclusion, Color is a Rebol’s Object that has been constructed dynamically from a persistent storage and which can be easily saved back to disk.
Note: save prefs also works but save under this format (which may be usefull for more complex hierarchical configuration needs):
make object! [
inactive-node-color: 240.235.230
active-node-color: 255.250.250
workspace-color: 255.255.255
minimal-node-size: 100x35
most-recent-file: none
drawer-header-height: 20
drawer-color: 240.240.240
]
Update September 3rd: Peter W A Wood (see comments section) advocates the use of blocks of name/value pairs for preference files.
I believe they are simpler, quicker and more elegant.
>> prefs: load %3flex.preferences
== [
inactive-node-color 240.235.230
active-node-color 255.250.250
workspace-color 255.255.255
minimal-node-size...
>> prefs/workspace-color
== 255.255.255
>> prefs/workspace-color: 254.254.254
== 254.254.254
>> save %3flex.preferences prefs
>> prefs: load %3flex.preferences
== [
inactive-node-color 240.235.230
active-node-color 255.250.250
workspace-color 254.254.254
minimal-node-size.
admin:
Edoc:
Interesting. But if I modify the preferences object, how do I go about re-saving it to a file?
Unfortunately, it looks like doing “save %3flex.preferences prefs
” by itself doesn’t work because it puts a ‘make object’ around the entire prefs object. This makes it so that it can’t be reloaded with a subsequent load command.
I know that it’s simple, but it is more or less like a serialization approach; the difference is that the rebol file is human readable. But Object-Relational Mapping is a large topic that addresses more complex task than simple loading and saving:
- querying: find all the objects with color property=red
- identity: ensure that there are no two different objects referring to the same identity
- change tracking: if you have thousands of objects is nearly impossible to saving them all every time
- lazy loading: also if you have many objects, you cannot load the whole object graph because it will take minutes or hours
And so on..
@Titus Barik Oops, corrected it
@Giorgio: there is no serialization since the format in storage and in memory is the same: plain old text
As for ORM, my opinion is it exists just because Object-Database is not mainstream yet.
I would like to advocate the use of blocks of name/value pairs for preference files. I believe they are simpler, quicker and more elegant.
>> prefs: load %3flex.preferences
== [
inactive-node-color 240.235.230
active-node-color 255.250.250
workspace-color 255.255.255
minimal-node-size...
>> prefs/workspace-color
== 255.255.255
>> prefs/workspace-color: 254.254.254
== 254.254.254
>> save %3flex.preferences prefs
>> prefs: load %3flex.preferences
== [
inactive-node-color 240.235.230
active-node-color 255.250.250
workspace-color 254.254.254
minimal-node-size.
Thanks Peter for suggestion, code is unreadable in comment, will try to find a solution but otherwise will put your snippet in the article.
@Peter W A Wood I have updated the article to include your suggestion, thanks again, I learn more everyday myself