[RFC] profile editing within nALFS: how much do you really want it?

Hui Zhou zhouhui at wam.umd.edu
Sun Mar 14 12:11:57 PST 2004


Sorry if you find I am replying actually to Kevin's post. It just
happened that James' reply made me read the original message a second
time (and good for me :-)).

On Sun, Mar 14, 2004 at 01:27:18PM -0600, James Robertson wrote:
> Kevin P. Fleming wrote:
> 
> >The general direction that nALFS is going in will make it nearly 
> >impossible to provide any useful profile editing within nALFS. As it 
> >stands right now, once the profile is parsed nearly all knowledge of the 
> >original XML structure is gone; what's left is whatever information the 
> >handlers decided to store to be able to do their jobs when the profile 
Sorry if you find me too lazy to go to the source. Could you give some
more detailed info on how the profile is actually stored in the
hadlers? I would appreciate it if you will use a simple example.

> >a better job. The only possible advantage to the current scheme is that 
> >the editing can be done within nALFS without having to exit to reload 
> >the profile, but I see very little benefit to that.

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.)
Another benefit may be the program can tell user the editing error
right away. My experience is when I am writing custom profiles, I
almost wasted more than half of the time just restarting nALFS,
navigating the profiles, eliminating syntax errors. But I didn't use
any proper xml editor or validating tool, so it may not apply to
others. 

Here is repetition of my suggestions from my last reply (sorry) : 
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.

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.

3. Ignore me. I am the one make noise but not representing the
mojority of users. :-) and I will understand.

Both 1 and 2 are trivia. But I see it, they can live with what ever
the new program structure it is heading.
> >
> >Anyone out there who really, really, _really_ wants to be able to edit 
> >profiles from within nALFS please speak up...
Only one `realy' (with side notes) applies to me :-)

-Hui Zhou



More information about the alfs-discuss mailing list