[Tfug] Poor man's GUI

[Freeman, Don]

Suppose you have a dropdown with possible choices. Your user makes a choice
and then does a saveas and saves it as an htm file. The result files will
show this:

	<select name="ctl00$MainContent$DriveAlone_DDL" id="DriveAlone_DDL">
	<option value="0">0</option>
	<option value="1">1</option>
	<option value="2">2</option>
	<option selected="selected" value="3">3</option>
	<option value="4">4</option>
	<option value="5">5</option>
	<option value="6">6</option>
	<option value="7">7</option>
	</select>

Which indicates 3 was the selected value. I find it difficult to imagine how
your application could make sense of this without another step to parse it
out. Another choice would be to write some vbscript that would look at the
controls and their values and then generate a string that could be saved as
a text file unencumbered with all the additional clutter.

-Don

-----Original Message-----
From: tfug [mailto:tfug-bounces at tfug.org] On Behalf Of Bexley Hall
Sent: Monday, March 10, 2014 4:38 PM
To: Tucson Free Unix Group
Subject: Re: [Tfug] Poor man's GUI

Hi Don,

On 3/10/2014 3:40 PM, Freeman, Don wrote:
> Sorry, it's not clear to me what the end game is here. How do the new 
> settings get sent to the application?

I am *speculating* (I have no experience writing HTML) that the "Save As"
causes the *created* .html file to encode the current state of each
"setting" as modified by the user while *viewing* that original HTML file.

So, if the initial file contains a fragment to the effect:

<HR><H2>Indicate which output files you would like the compiler to
generate<\H2> <INPUT TYPE="checkbox" NAME="files" VALUE="asm">.s <INPUT
TYPE="checkbox" NAME="files" VALUE="object" CHECKED>.o <INPUT
TYPE="checkbox" NAME="files" VALUE="symbols">.b </HR>

This would initially appear as a set of three checkboxes labeled ".s", ".o"
and ".b".  Only the ".o" checkbox would be enabled
("checked") when the user first views this file.

Now, assume the user decides he wants the .s and .b files to be generated
and NOT the .o.  He would have used the mouse (etc) to click on the
corresponding checkboxes to toggle their respective states to indicate his
wishes.

ONCE DONE WITH ALL HIS CHOICES, he tells the *browser* to "File | Save As"
this form as "mychoices.html".

[He could, conceivably, save it using the same name as the original file...]

I am *hoping* that the saved file now looks like:

<HR><H2>Indicate which output files you would like the compiler to
generate<\H2> <INPUT TYPE="checkbox" NAME="files" VALUE="asm" CHECKED>.s
<INPUT TYPE="checkbox" NAME="files" VALUE="object">.o <INPUT TYPE="checkbox"
NAME="files" VALUE="symbols" CHECKED>.b </HR>

I.e., the .o choice has been UNchecked while the other two have been
checked.

Now, the application reads this "mychoices.html" file looking for the
widgets/controls having the previously determined, recognizable names "asm",
"object", "symbols", etc. and determines if they are "CHECKED" or not.
I.e., if the options corresponding to those "switches" have been enabled, or
not.

> What form of config file does the
> "little application" want to see?

The "mychoices.html" could suffice as that configuration file.
It would just "coincidentally" have lots of other cruft in it (e.g., the
heading "Indicate which output files you would like the compiler to
generate")

> Can you run it with command line options?

You would be significantly taxed trying to sort out which command line
switches to add.  Unlike GCC (which was just an example I chose thinking
folks would have some familiarity with it), there are literally *scores*
(100+) of "options" that could be independantly enabled/disabled.  Trying to
make sure you had all of them individually specified on the command line
would be a Rx for screwup.

OTOH, a (scrollable!) form that presents all these options -- with textual
annotations alongside each -- is a lot easier to interact with.  Having
*saved* the form (required to actuate the application!), you can also more
readily review what you did/did not specify without having to decode dozens
of command line switches.

> Do you need to save a text file with old and new settings?

I think saving the "most recent settings" would suffice.  This would
eliminate the need to specify an "output/save_as" file name (and,
communicate that to the application so the application knows which file to
parse to determine the settings *requested*.

I.e. I am replacing "submit" (which would post the form back to the SERVER)
with "save as" (which just updates it on the local media where the
application can directly examine it).

I want to leverage the browser's ability to present "pretty forms" -- and in
a structured manner (that makes it easy for the application to parse the
saved results!) without having to incur the cost of serving the form via a
genuine server!

> Seems like it
> would be easy enough to scan the controls on the webpage and save 
> whatever you need into a text file or xml, etc.

I was just going to let the application parse it directly and "save" it
internally -- as if the html file was just a messy set of command line
switches...

_______________________________________________
Tucson Free Unix Group - tfug at tfug.org
Subscription Options:
http://www.tfug.org/mailman/listinfo/tfug_tfug.org