Re: General question about what is possible re: AS driving JavaScript
Re: General question about what is possible re: AS driving JavaScript
- Subject: Re: General question about what is possible re: AS driving JavaScript
- From: Bill Planey <email@hidden>
- Date: Wed, 13 Jul 2005 00:37:06 -0500
Thanks Gary and Malcolm,
I'll be keeping your latest posts to refer to as I dig deeper. Thanks for
the quick education on what I'm dealing with!
Bill
On 7/12/05 7:05 PM, "Gary (Lists)" <email@hidden> wrote:
> "Bill Planey" wrote:
>
>> The trick of number two is: the SEARCH button is part of a "floating"
>> element that repositions itself whenever the user scrolls down the page.
>
> No matter. That's not the way to go anyway.
>
> Using AS to generate strings which you then try to insert into forms on
> screen is a dead end. Or at least a painful and inefficient end. It depends
> on a browser's 'do JavaScript' ability, on the proper structure of the page
> elements (the DOM) and so on. Better to just build a query string from the
> ground up.
>
> The goal you should have is essentially what someone else mentioned a couple
> of days ago: construct the full URL, with the HTML query part appended by
> you (from your data) and then request the URL be fetched by anything that
> can fetch it: curl, a web browser, the Finder, and so on, depending on the
> URL.
>
> Okay, so that's the overall plan. Now how?
>
> First, dissect the target form, as you have begun to do. You now have the
> <form>'s source HTML. Forms that use GET are easier to deal with than POST,
> and are the most common, so this example uses GET.
>
> An example of dissecting the parts (form example courtesy of PageSpinner):
>
> GIVEN: This form is displayed at a web page with
> URL of "http://somedomain.tld/forms/coffee.php
>
> ==================================================
> <p><b>Order a cup of coffe:</b></p>
> <form action="coffeeprocess.php" method="GET" enctype="text/plain">
>
> <p>Name: <input name="name" type="text" value="Your name" size="25"
> maxlength="25"/></p>
>
> <p>
> Select flavour: <select name="product" size="1">
> <option>Cappuccino</option>
> <option selected="selected">Java</option>
> <option>Medium roasted</option>
> </select></p>
>
> <p>
> <input name="cbSugar" type="checkbox" value="sugar" checked="checked" />
> Include sugar</p>
>
> <p>
> <input type="submit" value="Order now!"/> <input type="reset" value="Reset
> form" /></p>
> </form>
> ==================================================
>
> What you need to grab from here is:
>
> 1. The form's action: coffeeprocess.php
>
> Now, this is obviously relative, so you would need the whole URL, like
> http://somedomain.tld/forms/coffeeprocess.php
>
> 2. The form's fields:
>
> 'name', 'product', 'cbSugar'
>
> That's it.
>
> To construct a URL to submit to the 'action=' destination, I just put all
> the strings together. (I've separated out some elements to draw attention to
> them.)
>
> --=====
> set myVarWithName to "Rupert Giles"
> set myVarWithProduct to "Medium roasted"
>
> set formURL to "http://somedomain.tld/forms/coffeeprocess.php"; & "?" &
> "name=" & myVarWithName & "&" & "product=" & myVarWithProduct & "&" &
> "cbSugar=" & "sugar"
>
> --> "http://somedomain.tld/forms/coffeeprocess.php?name=Rupert
> Giles&product=Medium roasted&cbSugar=sugar"
> --=====
>
> Now, you will have to turn that string in the variable 'formURL' into a
> properly encoded string. The <form ...> element tag tells you some about
> this, but you will still likely need to URL encode your string.
>
> Smile (a script editor and app building tool) has a built-in command. (I
> don't know if it's in the Smile dictionary or the Satimage dictionary. If
> it's the later, then you can use the command in other-than-smile-run
> scripts.) There are other tools. (And 'curl' may do it for you...I don't
> know.)
>
> Once you have the AS variable 'formURL' read to go, then you can "send" your
> URL ("send for" the result, more accurately) using whatever tool you want --
> depending on what you want back.
>
> If you want to view the form's result page to show in your browser after
> submitting the form, then just use your default browser to "open" the form
> URL (submit the form).
>
> open location formURL
>
> If you want the source of the result of submitting the form to come back to
> you in another AppleScript variable, then you can 'curl' it.
>
> set sh to "curl " & formURL
> -- set sh to "curl -i " & formURL -- if you want headers, too
> set formResultHTML to (do shell script sh)
>
> Now you can split up the form result HTML however you would like. (Could be
> nasty work, depending on how much HTML is sent back as the result.) [1]
>
> I hope that helps you along.
> --
> Gary
>
> [1] The result of submission is not always another page. A <form...>'s
> action can be: ... action="mailto:email@hidden";. Then, you would not use
> 'curl' but rather just: open location formURL -- to launch your email
> client, for instance.
>
> P.S.
>
> I know your original message, and the subject, is about JavaScript.
> However, that is very browser-dependent. Some browsers have a 'do script'
> or 'do JavaScript' command, which will let you ask the browser's JS engine
> to handle JS code. However, in practical usage, this is tedious to
> construct. If you can control the _form construction_ AND the _AS<->JS form
> access_ then you are better off. This makes the AS<->JS approach great for
> managing your blog or connecting to some other well-known form. And when
> the browser is well know. (Safari is probably the best bet going for
> AppleScripting a browser. IE is very useful for this also, and merits
> keeping it around as a "web front end". The others just haven't made much
> headway in AS capability. Mozilla 1.2 for OS 9 had _the best_ AS support of
> any browser I've every seen. OS X Mozilla is back to square zero.)
>
> So, if the form is simple or very well known (in structure) and uses
> DOM-level naming, then you have a better chance of interacting well with the
> form via AppleScript.
>
> If you can still find it, JJ (of this list) wrote a very useful IE Library
> for OS 9. That is a good model to study for building your own handlers.
>
> Not for the weak, but JSOSA is still a useful tool and significantly helps
> speak AppleScript with a JavaScript accent.
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Applescript-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> net
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden