CSV is the devil's playground. I could go on for pages as to why it is among the worst formats ever devised, but in short there is no single standard, and the myriad ad hoc variants that exist aren't even implemented consistently among products from a single vendor (e.g., Microsoft). Because it simply must die, I won't bother describing the horrors that go into parsing it. It's a favor to the user, and to the computing industry as a whole, to encourage them to use a saner format like tab-delimited instead.
A strong benefit of tab-delimited data in Rev is that you can just put the contents of the data set into a field for display, since Rev's multi-column list fields already use tabs as column delimiters.
As for properties, one could think of them like low-overhead fields that you never see. Indeed, the text of a field is just another property, so the syntax is similar:
Code: Select all
set the text of fld 1 to tMyData
set the uData of fld 1 to tMyData
But with properties you get both more and less than you do with fields: more flexibility, and less overhead.
On the overhead, this post to the use-rev list uses a metaphor no one but me finds humorous to describe the order-of-magnitude more work the engine has to do to store data in a field than it does for a property:
http://lists.runrev.com/pipermail/use-r ... 11477.html
On the flexibility, custom properties in Rev are implemented to mirror the syntax used for its associative arrays. This means you can slice and dice your data however best suits your retrieval needs.
If your data is well suited as a flat table, you could just dump a tab- and return-delimited chunk into a field with the line for uData above.*
But if your data is hierarchical by nature, you can use syntax like:
Code: Select all
set the uData["employee"]["startDate"] to "4/4/2004"
Efficient use of array syntax relative to "repeat for each line" in a return-delimited list is a deep topic, more than we want to get into here. In many cases array notation provides faster access to specific elements, but not in all cases, and the simplicity of tab-delimited data makes maintenance a breeze.
For the moment I'll assume tabbed data will be useful for you, and you're encouraged to experiment with arrays if you find yourself working with hierarchical data.
Some things to look up in the Dictionary for working with tab- and return-delimited data:
- lineoffset: lets you find the line number for a matching string
- itemOffset: does the same for items within a string
- itemDelimiter: can be set to any value; defaults to comma, but can be set to tab
- repeat for each: very fast way to traverse a list
- filter: this very flexible command makes one-liners of many filtering tasks
- hilitedLines: the numbers of the lines currently selected in a list field, delimited by commas
- hilitedText: the actual text of selected lines in a list field, delimited by returns.
Here's a simple handler as an example for filling in a form from the contents of a record associated with a selection in a list field. It assumes that your data is a list of contacts (like the Congress Contacts example included in your WebMerge installation, which I use for a lot of simple testing like this), which has eight fields for each record and the first field is a unique identifier, and that your form fields are in a group named "form":
Code: Select all
-- Script of list field:
on selectionChanged
set the itemdel to tab
-- Get the first item of our list:
put item 1 of the hilitedText of me into tRecordID
-- Get the data to work on:
put the uData of stack "MyData" into tData
-- Find the record; note that putting delimiters around the string we're
-- looking for prevents finding erroneous substrings:
put lineoffset(cr& tRecordID &tab, cr&tData) into tLineOffset
if tLineOffset = 0 then
answer "No record found for ID ""e& tRecordID "e&"."
exit to top
end if
-- Now that we know which line, get that line's data:
put line tLineOffset of tData into tRecord
-- Fill in the fields in our "Form" group:
put 0 into i
repeat for each item tItem in tRecord
add 1 to i
put tItem into fld i of grp "Form"
end repeat
end selectionChanged
(That's off the top of my head, so if it has a bug just consider that an "exercise for the reader" <g>)
In actual practice you'd probably want to put the form-filling stuff into a more generalized handler stored somewhere farther along in the message path so it could be used by other objects. But this will hopefully at least get you started on your own explorations of this sort of data management.
* What's with the "u"? Hungarian-lite:
http://www.fourthworld.com/embassy/arti ... style.html
