Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > listing all form variables in javascript with a bookmarklet withoutxpath

Reply
Thread Tools

listing all form variables in javascript with a bookmarklet withoutxpath

 
 
yawnmoth
Guest
Posts: n/a
 
      01-24-2009
I'm trying to make a bookmarklet that'll tell you all the variables
associated with a particular form. XPath, unfortunately, doesn't
work. Never mind the fact that the elements that can constitute form
variables are varied (input, textarea, select, etc), there's also the
fact that on malformed HTML, it's simply not going to match. For
instance,

<div>
<form action="">
<input type="text" name="a" />
</div>
<div>
<input type="text" name="b" />
</div>
<div>
<input type="submit" />
</form>
</div>

<script>
var headings = document.evaluate('//form//input', document, null,
XPathResult.ANY_TYPE, null);

var thisHeading = headings.iterateNext();
alertText = "";
while (thisHeading) {
alertText += thisHeading.getAttribute("name") + "\n"
thisHeading = headings.iterateNext();
}
alert(alertText);
</script>

If you hit the submit button, you'll get, as GET parameters, both 'a'
and 'b'. This is true in both Internet Explorer and Firefox. In
contrast, with XPath (the above is for Firefox, specifically; not sure
how to do XPath in Internet Explorer), you get only 'a'.

Any ideas?
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-24-2009
yawnmoth wrote:

> [...] there's also the fact that on malformed HTML, it's simply not going
> to match.


Works as designed. Behavior is not supposed to be different with other DOM
accessors.

> For instance,
>
> <div>
> <form action="">
> <input type="text" name="a" />


HTML or XHTML? `type="text"' is redundant.

> </div>
> <div>
> <input type="text" name="b" />
> </div>
> <div>
> <input type="submit" />
> </form>
> </div>
>
> <script>


<script type="text/javascript">

> var headings = document.evaluate('//form//input', document, null,
> XPathResult.ANY_TYPE, null);
>
> var thisHeading = headings.iterateNext();
> alertText = "";
> while (thisHeading) {


Consider this instead:

var thisHeading;
while ((thisHeading = headings.iterateNext()))
{

> alertText += thisHeading.getAttribute("name") + "\n"


Consider pushing and joining an array instead. Use .name instead
of .getAttribute("name") to get the actual name.

> thisHeading = headings.iterateNext();


Unnecessary/wrong then.

> }
> alert(alertText);


window.alert(alertText);

> </script>
>
> If you hit the submit button, you'll get, as GET parameters, both 'a'
> and 'b'. This is true in both Internet Explorer and Firefox. In
> contrast, with XPath (the above is for Firefox, specifically; not sure
> how to do XPath in Internet Explorer), you get only 'a'.
>
> Any ideas?


As the underlying markup is completely invalid, you should be glad that
XPath finds anything at all.

BTW: <http://chrispederick.com/work/web-developer/> has this feature
already, and IIRC it started on <https://www.squarefree.com/bookmarklets/>.


PointedEars
 
Reply With Quote
 
 
 
 
yawnmoth
Guest
Posts: n/a
 
      01-25-2009
On Jan 24, 5:52*pm, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
wrote:
> yawnmoth wrote:
> > [...] there's also the fact that on malformed HTML, it's simply not going
> > to match.

>
> Works as designed. *Behavior is not supposed to be different with otherDOM
> accessors.


I agree - that's why I said "without xpath" in the subject line.

> As the underlying markup is completely invalid, you should be glad that
> XPath finds anything at all.


Definitely. That, however, doesn't change the fact that document.form
['whatever'].submit() can, with malformed HTML, yield form variables
that you'd never be able to find with XPath. That's why I'm curious
to know if it can be done /without/ XPath. I want to see what
document.form['whatever'].submit() thinks the form variables are for a
given form - not what XPath thinks they are.
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-25-2009
yawnmoth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> yawnmoth wrote:
>> > [...] there's also the fact that on malformed HTML, it's simply not
>> > [going
>> > to match.

>>
>> Works as designed. *Behavior is not supposed to be different with other
>> DOM accessors.

>
> I agree - that's why I said "without xpath" in the subject line.


"Other DOM accessors" include those not using XPath.

>> As the underlying markup is completely invalid, you should be glad that
>> XPath finds anything at all.

>
> Definitely. That, however, doesn't change the fact that document.form
> ['whatever'].submit() can, with malformed HTML, yield form variables
> that you'd never be able to find with XPath. That's why I'm curious
> to know if it can be done /without/ XPath. I want to see what
> document.form['whatever'].submit() thinks the form variables are for a
> given form - not what XPath thinks they are.


You are falsely ascribing thinking to XPath when it can do nothing but
operate on the document tree for which the user agent's markup parser is
ultimately responsible. With invalid markup, outcomes are known to be
inconsistent among user agents, and there is no point in trying to work
around that, given the possibilities.


PointedEars
 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      01-25-2009
yawnmoth <(E-Mail Removed)> writes:

> Definitely. That, however, doesn't change the fact that document.form
> ['whatever'].submit() can, with malformed HTML, yield form variables
> that you'd never be able to find with XPath. That's why I'm curious
> to know if it can be done /without/ XPath. I want to see what
> document.form['whatever'].submit() thinks the form variables are for a
> given form - not what XPath thinks they are.


I'm not entirely sure what you mean by "form variables". I'm assuming
you are talking about the names (and possibly values) of form controls.

Finding those are easy:

var elems = document.forms['myform'].elements;
var text = "";
for (var i = 0; i < elems.length; i++) {
var name = elements[i].name;
if (name) {
// There can be form controls without a name. They will
// not be submitted, but they are still there.
text += name + "\n";
}
}
alert(text);

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

 
Reply With Quote
 
yawnmoth
Guest
Posts: n/a
 
      01-25-2009
On Jan 24, 6:42*pm, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
wrote:
> yawnmoth wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> yawnmoth wrote:
> >> > [...] there's also the fact that on malformed HTML, it's simply not
> >> > [going
> >> > to match.

>
> >> Works as designed. *Behavior is not supposed to be different with other
> >> DOM accessors.

>
> > I agree - that's why I said "without xpath" in the subject line.

>
> "Other DOM accessors" include those not using XPath.
>
> >> As the underlying markup is completely invalid, you should be glad that
> >> XPath finds anything at all.

>
> > Definitely. *That, however, doesn't change the fact that document.form
> > ['whatever'].submit() can, with malformed HTML, yield form variables
> > that you'd never be able to find with XPath. *That's why I'm curious
> > to know if it can be done /without/ XPath. *I want to see what
> > document.form['whatever'].submit() thinks the form variables are for a
> > given form - not what XPath thinks they are.

>
> You are falsely ascribing thinking to XPath when it can do nothing but
> operate on the document tree for which the user agent's markup parser is
> ultimately responsible.

No ****. Describing the deterministic processes of a computer,
metaphorically, as "thinking" is hardly without precedent. A few
examples:

http://www.google.com/search?q="website+think+you're"

But what do I know? Maybe all those people really do think that
behind every website is an AI capable of fully conscious thought.
Maybe some of them even think that Skynet is actually a website that's
waiting until the time is right to destroy the world!

> *With invalid markup, outcomes are known to be
> inconsistent among user agents, and there is no point in trying to work
> around that, given the possibilities.


I'm not talking about different user agents. I'm talking about the
same user agents. /One/ user-agent will give you /two/ different
results for the /same/ HTML. The above suggests that there's /one/
form field. Clicking on the 'Submit' button suggests that there's /
two/. Since document.forms[0].submit() does the same thing as
clicking on the 'Submit' button*, replace the javascript in my first
example with this:

<script>
if (window.location.search.indexOf("&") == -1) {
document.forms[0].submit();
} else {
alert(window.location.search.split("&").length);
}
</script>

Why do you suppose that that yields a popup showing the number 2 as
opposed to 1, even though that's how many elements the first
javascript suggests exist? What I suppose is this: that document.forms
[0].submit() doesn't traverse the DOM tree to get its list of form
fields - it does something else. I want to know what that something
else "thinks" (<sarcasm>because, obviously, the "user agent" is
capable of fully conscious thought</sarcasm>) the form fields are -
not what DOM tree traversal would suggest they are.

* Okay, okay - to satisfy you're literal mindedness, I'll concede -
they're not EXACTLY the same thing. The onclick event doesn't fire,
for one. However, as nitpicky as you are, I believe that for the
purposes of this discussion, describing them as being the same is
sufficient.
 
Reply With Quote
 
yawnmoth
Guest
Posts: n/a
 
      01-25-2009
On Jan 24, 7:47*pm, Lasse Reichstein Nielsen <(E-Mail Removed)>
wrote:
> yawnmoth <(E-Mail Removed)> writes:
> > Definitely. *That, however, doesn't change the fact that document.form
> > ['whatever'].submit() can, with malformed HTML, yield form variables
> > that you'd never be able to find with XPath. *That's why I'm curious
> > to know if it can be done /without/ XPath. *I want to see what
> > document.form['whatever'].submit() thinks the form variables are for a
> > given form - not what XPath thinks they are.

>
> I'm not entirely sure what you mean by "form variables". I'm assuming
> you are talking about the names (and possibly values) of form controls.
>
> Finding those are easy:
>
> var elems = document.forms['myform'].elements;
> var text = "";
> for (var i = 0; i < elems.length; i++) {
> * var name = elements[i].name;
> * if (name) {
> * * // There can be form controls without a name. They will
> * * // not be submitted, but they are still there.
> * * text += name + "\n";
> * }}
>
> alert(text);


That's exactly what I was looking for - thanks!!
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-25-2009
yawnmoth wrote:

> Thomas 'PointedEars' Lahn wrote:
>> yawnmoth wrote:
>> > Thomas 'PointedEars' Lahn wrote:
>> >> yawnmoth wrote:
>> >> > [...] there's also the fact that on malformed HTML, it's simply not
>> >> > [going
>> >> > to match.

>>
>> >> Works as designed. *Behavior is not supposed to be different with

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> >> other DOM accessors.

^^^^^^^^^^^^^^^^^^^^
>> > I agree - that's why I said "without xpath" in the subject line.

>>
>> "Other DOM accessors" include those not using XPath.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^
>> >> As the underlying markup is completely invalid, you should be glad
>> >> that XPath finds anything at all.

>>
>> > Definitely. *That, however, doesn't change the fact that document.form
>> > ['whatever'].submit() can, with malformed HTML, yield form variables

^^^^^^^^^^^^^
>> > that you'd never be able to find with XPath. *That's why I'm curious
>> > to know if it can be done /without/ XPath. *I want to see what
>> > document.form['whatever'].submit() thinks the form variables are for a
>> > given form - not what XPath thinks they are.

>>
>> You are falsely ascribing thinking to XPath when it can do nothing but
>> operate on the document tree for which the user agent's markup parser is

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^
>> ultimately responsible.

^^^^^^^^^^^^^^^^^^^^^^^
> No ****. Describing the deterministic processes of a computer,
> metaphorically, as "thinking" is hardly without precedent. A few
> examples:
> [...]


Why, why I'm even replying to anonymous googlodytes?

*PLONK*

PointedEars
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-25-2009
Lasse Reichstein Nielsen wrote:

> yawnmoth <(E-Mail Removed)> writes:
>> Definitely. That, however, doesn't change the fact that document.form
>> ['whatever'].submit() can, with malformed HTML, yield form variables
>> that you'd never be able to find with XPath. That's why I'm curious
>> to know if it can be done /without/ XPath. I want to see what
>> document.form['whatever'].submit() thinks the form variables are for a
>> given form - not what XPath thinks they are.

>
> I'm not entirely sure what you mean by "form variables". I'm assuming
> you are talking about the names (and possibly values) of form controls.
>
> Finding those are easy:
>
> var elems = document.forms['myform'].elements;
> [...]


That *may* work if error-correction can make a form out of this mess.

It does _not_ need to work.


PointedEars
 
Reply With Quote
 
yawnmoth
Guest
Posts: n/a
 
      01-26-2009
On Jan 25, 3:58 am, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
wrote:
> Lasse Reichstein Nielsen wrote:
> > yawnmoth <(E-Mail Removed)> writes:
> >> Definitely. That, however, doesn't change the fact that document.form
> >> ['whatever'].submit() can, with malformed HTML, yield form variables
> >> that you'd never be able to find with XPath. That's why I'm curious
> >> to know if it can be done /without/ XPath. I want to see what
> >> document.form['whatever'].submit() thinks the form variables are for a
> >> given form - not what XPath thinks they are.

>
> > I'm not entirely sure what you mean by "form variables". I'm assuming
> > you are talking about the names (and possibly values) of form controls.

>
> > Finding those are easy:

>
> > var elems = document.forms['myform'].elements;
> > [...]

>
> That *may* work if error-correction can make a form out of this mess.
>
> It does _not_ need to work.


I realize I'm now in your killfile (just as well - I could do without
your comments, anyway), but, what you've been failing to understand is
that, although it doesn't /need/ to work to be fully compliant with
the standards, it /does/ work.

What's next? If someone asks for help with CSS Expressions, even
though they only work on Internet Explorer, are you going to respond,
to every comment, "that *may* work, but it does _not_ need to work"
simply because the standards make no mention of them?

To say that, even though it does work, that the browser is under no
obligation for it to work, is rather academic and redundant. Browsers
aren't even under any obligation to implement HTML support. They
might not get a lot of use without implementing it, but certainly
there's no requirement that they do so.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
listing all property variables of a class instance =?iso-8859-1?B?QW5kcuk=?= Python 5 06-25-2007 09:14 PM
Convenient way for Windows XP Internet Explorers to add my Javascript Bookmarklet? Robert Oschler Javascript 1 08-14-2005 11:10 AM
Listing all variables of a source code rusttree@gmail.com C++ 4 06-23-2005 02:12 PM
Javascript Bookmarklet crondude@gmail.com Javascript 0 03-16-2005 11:05 AM
Bookmarklet for random url Martin Javascript 5 12-09-2003 10:33 AM



Advertisments