I'm arriving (very!!) late to this discussion, so I'll (try to) be brief.
This will look odd as it'll be the last post in the forum up till now, but I'm not done reading through all the previous comments.
So if this has already been laid to rest, or we're too far down the coding route, just ignore me....
In the specialised case of wishing to 'view' or 'edit' a SUBSET of a large file / database, etc, some kind of selective EXPORT is required to create the subset. Let's leave that outside the scope of our deliberations for a moment.
We arrived at the XFORM implementation thus far by starting with an Export-Transform-Load approach.
Perfectly logical, but subsequent comments makes me wonder if there's a simpler way to provide support for for such functionality.
Let's think of SPFLite as a 'Viewer' application, capable of being an 'Editor'.
We're left with a situation where we wish to view and/or edit a file containing mixed binary & textual data.
SPFLite already supports various different file and record formats, encoding standards, etc via PROFILE settings. That's a start.
And SPFLite can "READ" and "WRITE" any binary file.
What IF...
- We just allow SPFLite to read the file. Clearly, the display will be unhelpful, in extreme cases it may need to be suppressed. But the data only needs to be FORMATTED to be useful and intelligible.
- Rather like we have HEX ON/OFF now, we could have a XFORM <macroname> command. (Future Advanced option: perhaps a RELOAD/REIMPORT <macroname> command.)
- The macro routine rearranges the data as required and EITHER - replaces the current editing session data - OR - writes the output to a new TAB (like DIFF does now).
- The user views / edits as usual and retransforms the data with XFORMEND. Data returns to current/original TAB in correct format, ready for SAVE/SAVEAS/whatever as usual.
- In fact, because SPFLite 'knows' that it's dealing with transformed data, you could prefix any usual SAVE/END/etc with XFORMEND, but I'd prefer that, as the user had to request the transformation, they be required to request the reverse transformation before they can enter SAVE, etc. (Maybe the 'SAVE-in-PLace' functions could be disabled until XFORMEND).
Advantages:
- I wager that the changes required to SPFLite codebase to provide and integrate the XFORM and XFORMEND commands are less drastic.
- This eliminates the need for the XFORM macro to read and write the data.
- SPFLite still owns the relationship with the external file, reads a binary stream and writes a binary stream.
- Transformation is still handled by a user-provided routines. Macros can call programs written in other languages so no constraints there.
- By not using a PROFILE option to specify the XFORM routine, there's no worry about whether to use it every time or only selectively.
- By not using a PROFILE option to specify the XFORM routine, any file can be transformed into different 'views' for editing.
- If transformation is required every time - use a PROFILE IMACRO to invoke the XFORM command.
- The enforced use of the XFORMEND command means there's no need to provide for separate SAVE/END/CREATE/REPLACE, etc. methods.
- In fact, SAVEAS and CREATE/REPLACE could be allowed before XFORMEND, they would just write textual representations only.