[Tfug] Poor man's GUI

[Freeman, Don]

I take it the "little application" is yours also and that you are the one
who will teach it how to parse the saved file. If that is true, then doing
it right the first time within the web page should be a whole lot easier.
That way you won't have to worry about what the various browsers may or may
not do both now and in the future. <grin>

Good luck.

- Don


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

Hi Don,

On 3/10/2014 5:10 PM, Freeman, Don wrote:
> 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>

Remember, *I* create the original file.  This places constraints on what the
browser can do to it when it "saves" it.

E.g., if my options were A, B, C, D and listed in *that* order, the
browser-saved version can't change them to fred, barney, wilma, pebbles!

I suspect it can't even change the "option values" assigned to each of them
-- nor should it have reason to do so!

> 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

Same way *any* library parses HTML.  I.e., the "3" applies to the choice for
*this* "menu control" -- not some other menu control on the page.

If the browser can't rename the control, then I won't care where it has
moved this control "physically" in the file that it saves -- it will still
have to be present in the form of a "menu control" (I call controls
"widgets").

> 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.

That's just an added step.  I.e., the same information is present in the
saved HTML file.

You want:

browser.saveas -> vbscript -> textfile -> application

I'm folding "vbscript -> textfile" *into* "application".  I.e., let
application parse the saved HTML file (instead of your vbscript doing that)
and extracting the settings for each option.

E.g., when it encounters the "DriveAlone_DLL" menu widget in the HTML, it
KNOWS what a menu widget looks like, syntactically.
So, it knows how to find the "selected" entry and store that in:

int DriveAlone_DLL;

(or whatever the application decided to call that "setting", internally)

I'm pretty sure this should work -- *if* the browser (ALL practical
browsers) save files in a known format (so I can craft a parser to extract
the relevant fields:  "control" values).

If a particular browser wants to clutter up the file with lots of
syntactically inert cruft, that's just more characters my parser will have
to "skip over".

Likewise, I am *assuming* the above mentioned issues are invariant...
that the browser can't arbitrarily change stuff from the original file that
would meaningfully alter its *interpretation*.

But, I don't know what contractual agreements the browser(s) *must* observe.
I'd hate to find each handles this in a very different manner (e.g.,
replacing the *invisible* "option value"s in your example with ROMAN
NUMERALS... "Heck, the user doesn't see these so we can change them at
will!")

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