[RFC] profile editing within nALFS: how much do you really want it?
zhouhui at wam.umd.edu
Mon Mar 15 07:54:28 PST 2004
On Mon, Mar 15, 2004 at 08:41:14AM -0700, Kevin P. Fleming wrote:
> Hui Zhou wrote:
> Sure, as an example, src/handlers/stage.c, the variable_attribute()
> function. In the past, when the profile was being executed, the
> <variable> element's attribute were inspected to see if there was a
> "mode" attribute, and if it consisted of "append" or "prepend" then the
> appropriate action was taken. If it existed but was not one of those two
> choices an error was generated and the profile stopped executing.
> >Indeed, that is the only advantage. The benefit is the program can
> >remember all the flags, to save a user a lot of resetting the marks
> >during a try-and-error test run. (When the profile is huge, navigating
> >the tree is quite some labor if one have to do it again and again.)
> This stuff (saving run-marks and such) will be happening in the nALFS
> frontend at some point in the near future.
> This is very important: usage of xmllint can help you greatly, because
> the majority of the syntax errors will be caught before you ever start
> nALFS at all. With nALFS' new semantic error checking, another group of
> errors will be caught when you load the profile. These two changes will
> drastically reduce the amount of time you spend getting your profile to
> parse properly before trying to execute it.
I will try it. Thanks.
> >1. Reimplement the simple edit function. It doesn't need to edit the
> >xml source directly, but there must be some way to save all the
> >changes so user can have some record. It can save in any custom format
> >as long as it is documented properly (so the lost of xml structure is
> >not a real problem). Later, some one with time and skill may implement
> >a helper program to ease the change incorporation.
> This won't happen; we don't want the profile to ever be in a non-XML format.
No, the profile is still in XML. Just save the changes in a custom
format so one can used to incorporate the changes into main XML
I always have doubt in XML. If you don't mind, could you list the
reasons (sort my priority) that the profile has to be in XML, in short?
> >2. Delete the editing function, but implement the reload function. The
> >key is not to discard the old profile during the reload, so the
> >program can compare the profiles to just update the changes; or refuse
> >the reload if the change is too much and the program can't handle it
> >and ask the user politely to restart the program.
> Something like this will occur; you'll be able to reload the profiles
> that you have already loaded and nALFS will attempt to preserve your
> marks and run-status flags.
That will be very nice.
More information about the alfs-discuss