htmlunit-develop — General discussion of the development of HtmlUnit

[HtmlUnit] ANN: New mailing list

[Mike B. <mb...@Ga...>]

I have created a new mailing list for users of HtmlUnit.  Ideally, the 
new list would be for developers so people just using HtmlUnit wouldn't 
have to switch to a different list but I hadn't thought far enough ahead 
when naming this one. :-(

To subscribe or unsubscribe from either list then follow this link -> 
https://sourceforge.net/mail/?group_id=47038

List: htm...@li...

This list is for people wishing to use HtmlUnit but not particularly 
interested in the ongoing development.  This is expected to remain a low 
traffic list.  General "how do I do..." questions are welcome here. 
Release announcements will also be posted to this list.

List: htm...@li...

This list is for people who are contributing to HtmlUnit or just wish to 
follow development.  This list is going to become busier as cvs commit 
messages and new bug reports are going to be redirected here.

Both lists are open to anyone who is interested.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

Re: [HtmlUnit] Mailing list proposals

[Mike B. <mbr...@vi...>]

Sounds like a great idea to me.

Mike Bresnahan
----- Original Message ----- 
From: "Mike Bowler" <mb...@Ga...>
To: <htm...@li...>
Sent: Friday, May 30, 2003 2:34 PM
Subject: [HtmlUnit] Mailing list proposals


> Instead of manually notifying the list on changes, it would probably be 
> worthwhile to have cvs commit messages sent directly to the mailing list 
> (sourceforge supports this - I just checked).  This is the way that the 
> apache mailing lists work and it's very successful for them.
> 
> Additionally, if there is going to be more discussion of ongoing 
> development (and cvs commit messages) then it's probably a good idea to 
> split off a seperate list for people who just want to use HtmlUnit and 
> aren't interested in hearing about the ongoing changes.
> 
> Thoughts?  Opinions?
> 
> -- 
> Mike Bowler
> Principal, Gargoyle Software Inc.
> Voice: (416) 822-0973 | Email  : mb...@Ga...
> Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: eBay
> Get office equipment for less on eBay!
> http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
> _______________________________________________
> HtmlUnit-develop mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/htmlunit-develop

Re: [HtmlUnit] Mailing list proposals

[Barnaby C. <Ba...@ac...>]

I definitely think that 2 lists would be a good thing.  One for people developing using HtmlUnit and the other for people actively working on the HtmlUnit code itself.  Possibly keep htmlunit-develop for developers and create htmlunit-user for people that have questions about using HtmlUnit.  It would make it much easier to keep everyone that is interested in contributing up to date without annoying everybody else.  

Barnaby Court
---------- Original Message ----------------------------------
From: Mike Bowler <mb...@Ga...>
Date:  Fri, 30 May 2003 15:34:53 -0400

>Instead of manually notifying the list on changes, it would probably be 
>worthwhile to have cvs commit messages sent directly to the mailing list 
>(sourceforge supports this - I just checked).  This is the way that the 
>apache mailing lists work and it's very successful for them.
>
>Additionally, if there is going to be more discussion of ongoing 
>development (and cvs commit messages) then it's probably a good idea to 
>split off a seperate list for people who just want to use HtmlUnit and 
>aren't interested in hearing about the ongoing changes.
>
>Thoughts?  Opinions?
>
>-- 
>Mike Bowler
>Principal, Gargoyle Software Inc.
>Voice: (416) 822-0973 | Email  : mb...@Ga...
>Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: eBay
>Get office equipment for less on eBay!
>http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
>_______________________________________________
>HtmlUnit-develop mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/htmlunit-develop
>
                 

[HtmlUnit] Mailing list proposals

[Mike B. <mb...@Ga...>]

Instead of manually notifying the list on changes, it would probably be 
worthwhile to have cvs commit messages sent directly to the mailing list 
(sourceforge supports this - I just checked).  This is the way that the 
apache mailing lists work and it's very successful for them.

Additionally, if there is going to be more discussion of ongoing 
development (and cvs commit messages) then it's probably a good idea to 
split off a seperate list for people who just want to use HtmlUnit and 
aren't interested in hearing about the ongoing changes.

Thoughts?  Opinions?

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] HtmlInputElement proposed change

[Mike B. <mb...@Ga...>]

Barnaby Court wrote:
> I propose that the input elements be simplified to 2 elements, 
 > the HtmlInputElement and the HTMLInputElement class.  For
> backward compatibility all the sub classes of these 2 classes 
> could be kept as interfaces so existing test cases will not be
> broken.  If this move is supported I will submit a patch to 
> support these changes by next week.  The principal effect that
> this has on our current bug list is to eliminate bug 730915 
> as it would eliminate the one-to-n mapping that currently 
 > exists for input elements.  Let me know what you think.

+1

My initial idea was to keep the various types as seperate classes 
because they all have distinct behaviour.  In retrospect however, this 
introduces a bunch of casting that is undesirable.  Your proposal makes 
sense.

I assume btw that you really meant to have the existing subclasses 
turned into empty classes rather than interfaces.  If this isn't what 
you mean then please elaborate.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] Added Support for HTMLElement.parentNode

[David T. <dt...@ac...>]

SSBqdXN0IGNvbW1pdHRlZCB0aGlzIGNoYW5nZSB0byBDVlMuDQotRGF2aWQNCiANCkFkZCBzdXBw
b3J0IGZvciBnZXR0aW5nIEhUTUxFbGVtZW50LnBhcmVudE5vZGUuICBIVE1MRWxlbWVudC5wYXJl
bnROb2RlDQpyZXR1cm5zIHRoZSBub2RlIGFib3ZlIHRoZSBjdXJyZW50IG5vZGUuICBJdCByZXR1
cm5zIG51bGwgaWYgdGhlcmUgaXMgbm8NCnBhcmVudCBvciB0aGUgcGFyZW50IG5vZGUgdHlwZSBp
cyBub3Qgc3VwcG9ydGVkIChub3QgSFRNTCkuDQogDQotIGFkZCBwYXJlbnROb2RlIHRvIGNvbmZp
ZyBmaWxlLg0KLSBhZGQganNHZXRfcGFyZW50Tm9kZSB0byBIVE1MRWxlbWVudC4gIFRoaXMgbWV0
aG9kIGJhc2ljYWxseSBtYXBzIGJhY2sNCnRvIHRoZSBYTUwgZWxlbWVudCwgZ2V0cyB0aGUgWE1M
IG5vZGUgcGFyZW50LCBhbmQgbWFwcyBiYWNrIHRvIGENCnNjcmlwdGFibGUuDQotIGFkZCB0ZXN0
IGNhc2VzIGZvciBwYXJlbnROb2RlLCBpbmNsdWRpbmcgYSBjYXNlIHRoYXQgaXNuJ3Qgc3VwcG9y
dGVkDQpmb3IgdGhlIHJvb3QgZG9jdW1lbnQuDQotIHJlY29yZCB0aGUgY2FobmdlcyBpbiB0aGUg
Y2hhbmdlIGxvZy4NCiANCkNoZWNraW5nIGluDQpzcmMvamF2YS9jb20vZ2FyZ295bGVzb2Z0d2Fy
ZS9odG1sdW5pdC9qYXZhc2NyaXB0L0phdmFTY3JpcHRDb25maWd1cmF0aW8NCm4ueG1sOw0KL2N2
c3Jvb3QvaHRtbHVuaXQvaHRtbHVuaXQvc3JjL2phdmEvY29tL2dhcmdveWxlc29mdHdhcmUvaHRt
bHVuaXQvamF2YXNjDQpyaXB0L0phdmFTY3JpcHRDb25maWd1cmF0aW9uLnhtbCx2ICA8LS0gIEph
dmFTY3JpcHRDb25maWd1cmF0aW9uLnhtbA0KbmV3IHJldmlzaW9uOiAxLjIyOyBwcmV2aW91cyBy
ZXZpc2lvbjogMS4yMQ0KZG9uZQ0KQ2hlY2tpbmcgaW4NCnNyYy9qYXZhL2NvbS9nYXJnb3lsZXNv
ZnR3YXJlL2h0bWx1bml0L2phdmFzY3JpcHQvaG9zdC9IVE1MRWxlbWVudC5qYXZhOw0KL2N2c3Jv
b3QvaHRtbHVuaXQvaHRtbHVuaXQvc3JjL2phdmEvY29tL2dhcmdveWxlc29mdHdhcmUvaHRtbHVu
aXQvamF2YXNjDQpyaXB0L2hvc3QvSFRNTEVsZW1lbnQuamF2YSx2ICA8LS0gIEhUTUxFbGVtZW50
LmphdmENCm5ldyByZXZpc2lvbjogMS4xMDsgcHJldmlvdXMgcmV2aXNpb246IDEuOQ0KZG9uZQ0K
Q2hlY2tpbmcgaW4NCnNyYy9qYXZhL2NvbS9nYXJnb3lsZXNvZnR3YXJlL2h0bWx1bml0L2phdmFz
Y3JpcHQvaG9zdC9XaW5kb3cuamF2YTsNCi9jdnNyb290L2h0bWx1bml0L2h0bWx1bml0L3NyYy9q
YXZhL2NvbS9nYXJnb3lsZXNvZnR3YXJlL2h0bWx1bml0L2phdmFzYw0KcmlwdC9ob3N0L1dpbmRv
dy5qYXZhLHYgIDwtLSAgV2luZG93LmphdmENCm5ldyByZXZpc2lvbjogMS4xODsgcHJldmlvdXMg
cmV2aXNpb246IDEuMTcNCmRvbmUNCkNoZWNraW5nIGluDQpzcmMvdGVzdC9qYXZhL2NvbS9nYXJn
b3lsZXNvZnR3YXJlL2h0bWx1bml0L2phdmFzY3JpcHQvaG9zdC9Eb2N1bWVudFRlc3QNCi5qYXZh
Ow0KL2N2c3Jvb3QvaHRtbHVuaXQvaHRtbHVuaXQvc3JjL3Rlc3QvamF2YS9jb20vZ2FyZ295bGVz
b2Z0d2FyZS9odG1sdW5pdC9qDQphdmFzY3JpcHQvaG9zdC9Eb2N1bWVudFRlc3QuamF2YSx2ICA8
LS0gIERvY3VtZW50VGVzdC5qYXZhDQpuZXcgcmV2aXNpb246IDEuMTA7IHByZXZpb3VzIHJldmlz
aW9uOiAxLjkNCmRvbmUNCkNoZWNraW5nIGluIHNyYy94ZG9jcy9jaGFuZ2VzLnhtbDsNCi9jdnNy
b290L2h0bWx1bml0L2h0bWx1bml0L3NyYy94ZG9jcy9jaGFuZ2VzLnhtbCx2ICA8LS0gIGNoYW5n
ZXMueG1sDQpuZXcgcmV2aXNpb246IDEuMTA3OyBwcmV2aW91cyByZXZpc2lvbjogMS4xMDYNCmRv
bmUNCiANCiANCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCiANCkRJU0NMQUlNRVI6ICAgVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l
ZCBpbiB0aGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIHNvbGVseSBm
b3IgdGhlIHJldmlldyBvZiB0aGUgbmFtZWQgYWRkcmVzc2VlLCBhbmQgaW4gY29uanVuY3Rpb24g
d2l0aCBzcGVjaWZpYyBBY29waWEgTmV0d29ya3MgYnVzaW5lc3MuICBBbnkgcmV2aWV3LCByZXRy
YW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1c2Ugb2YsIG9yIHRha2luZyBvZiBh
bnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRoaXMgaW5mb3JtYXRpb24gYnkgcGVyc29ucyBv
ciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRl
ZC4gSWYgeW91IGFyZSB1bmFibGUgdG8gdHJlYXQgdGhpcyBpbmZvcm1hdGlvbiBhY2NvcmRpbmds
eSwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHVzIGlt
bWVkaWF0ZWx5IGJ5IHJldHVybmluZyB0aGUgZS1tYWlsIHRvIHRoZSBvcmlnaW5hdG9yLiANCiAN
Cg==

Re: [HtmlUnit] DOM Level 0 Limitations

[Barnaby C. <Ba...@ac...>]

I am (overall) very happy with the current structure.  Almost all information is maintained in the XML DOM and pretty much all the other classes are used as utilities that act on the DOM.  This provides a very flexible structure for the future.  There are still some places that I could see room for improvement.  

I propose that the input elements be simplified to 2 elements, the HtmlInputElement and the HTMLInputElement class.  For backward compatibility all the sub classes of these 2 classes could be kept as interfaces so existing test cases will not be broken.  If this move is supported I will submit a patch to support these changes by next week.  The principal effect that this has on our current bug list is to eliminate bug 730915 as it would eliminate the one-to-n mapping that currently exists for input elements.  Let me know what you think.  Thanks,

-Barnaby

---------- Original Message ----------------------------------
From: "David Taylor" <dt...@ac...>
Date:  Wed, 28 May 2003 10:47:10 -0400

>I am working on adding support for some DOM Level 1 Core features like
>Document.createElement (), Node.parentNode, Node.childNodes, and
>Node.appendChild (the last with help from Barnaby Court).  All of these
>return DOM Level 1 objects like Node or HTMLInputElement.
> 
>Basically, HtmlUnit currently implements DOM Level 0.  This causes
>problems because there is no non-HTML node class (besides Window) so all
>elements are assumed to be HTML.  For the root document and even text
>nodes, this assumption breaks (and causes class cast exceptions).  The
>problem with HTMLInputElement is captured in bug 730915: you can't
>create an input element because the DOM Level 0 classes need an
>attribute value to know what class to create and createElement just
>gives the tag name.
> 
>Internally, HtmlUnit has 3 sets of objects representing a web page: the
>XML DOM returned from the CyberNeko HTML parser, the HTML elements, and
>the scriptable objects.  The XML DOM provides the tree structure and the
>other 2 kinds of objects are lazily constructed as needed.  The
>scriptable objects and HTML elements each have a reference to each
>other.  The HTML elements have a reference to their XML node and their
>HTML page where there is a map from XML nodes to HTML elements.  The key
>point here is that the HTML element is the glue that ties these sets of
>objects together.
> 
>For non-HTML nodes in the XML DOM and non-HTML scriptable objects there
>is no corresponding HTML element.  So, there is nothing to glue non-HTML
>nodes with non-HTML scriptable objects.
> 
>Since fixing this opens design level questions, I thought we should
>discuss the alternatives first.  Some alternatives include: 1) extending
>the HTML elements to include non-HTML nodes like Node, Document, and
>Text, 2) using the XML nodes to glue the objects together, perhaps using
>the user data to avoid map lookups on every dereference, 3)
>consolidating the HTML elements and scriptable objects into a single set
>of classes that support both sets of interfaces.  An extreme alternative
>would be to consolidate the HTML elements, scriptable objects and XML
>DOM objects by extending the XML DOM classes with subclasses that
>implement Scriptable.
> 
>Anyway, before I spend much time exploring alternatives in much detail,
>I'd appreciate your comments.
>Thanks,
>-David                 

Re: [HtmlUnit] DOM Level 0 Limitations

[Mike B. <mb...@Ga...>]

I'm about to head into a meeting so I'll have to be brief for now.

One of my assumptions all along is that javascript would not be the only 
possible scripting language.  IE supports vbscript and possibly other 
languages and at some point HtmlUnit may want to support those as well. 
  This is one of the reasons for keeping all the javascript objects as a 
completely seperate class hierarchy.  The other reason (which may not 
make sense anymore) is that I didn't want a dependancy on the rhino 
engine.  I wanted HtmlUnit to continue to work if js.jar wasn't in the 
classpath.  If the HtmlElement hierarchy and the javascript hierarchy 
were intertwined then this wouldn't be possible.

Another assumuption I've been working with is that all data about the 
document is stored in the xml dom model.  The HtmlElement hierarchy does 
not store any data itself (except in the rare case of faking out values) 
so that it is possible to directly modify the xml dom and not have to 
worry about the two trees being out of sync.

I hope this helps you understand why things have ended up the way they 
are right now.  I'm not particularly tied to the current implementation 
so if there's a better way then I'm all for it :-)

Back later....

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] DOM Level 0 Limitations

[David T. <dt...@ac...>]

SSBhbSB3b3JraW5nIG9uIGFkZGluZyBzdXBwb3J0IGZvciBzb21lIERPTSBMZXZlbCAxIENvcmUg
ZmVhdHVyZXMgbGlrZQ0KRG9jdW1lbnQuY3JlYXRlRWxlbWVudCAoKSwgTm9kZS5wYXJlbnROb2Rl
LCBOb2RlLmNoaWxkTm9kZXMsIGFuZA0KTm9kZS5hcHBlbmRDaGlsZCAodGhlIGxhc3Qgd2l0aCBo
ZWxwIGZyb20gQmFybmFieSBDb3VydCkuICBBbGwgb2YgdGhlc2UNCnJldHVybiBET00gTGV2ZWwg
MSBvYmplY3RzIGxpa2UgTm9kZSBvciBIVE1MSW5wdXRFbGVtZW50Lg0KIA0KQmFzaWNhbGx5LCBI
dG1sVW5pdCBjdXJyZW50bHkgaW1wbGVtZW50cyBET00gTGV2ZWwgMC4gIFRoaXMgY2F1c2VzDQpw
cm9ibGVtcyBiZWNhdXNlIHRoZXJlIGlzIG5vIG5vbi1IVE1MIG5vZGUgY2xhc3MgKGJlc2lkZXMg
V2luZG93KSBzbyBhbGwNCmVsZW1lbnRzIGFyZSBhc3N1bWVkIHRvIGJlIEhUTUwuICBGb3IgdGhl
IHJvb3QgZG9jdW1lbnQgYW5kIGV2ZW4gdGV4dA0Kbm9kZXMsIHRoaXMgYXNzdW1wdGlvbiBicmVh
a3MgKGFuZCBjYXVzZXMgY2xhc3MgY2FzdCBleGNlcHRpb25zKS4gIFRoZQ0KcHJvYmxlbSB3aXRo
IEhUTUxJbnB1dEVsZW1lbnQgaXMgY2FwdHVyZWQgaW4gYnVnIDczMDkxNTogeW91IGNhbid0DQpj
cmVhdGUgYW4gaW5wdXQgZWxlbWVudCBiZWNhdXNlIHRoZSBET00gTGV2ZWwgMCBjbGFzc2VzIG5l
ZWQgYW4NCmF0dHJpYnV0ZSB2YWx1ZSB0byBrbm93IHdoYXQgY2xhc3MgdG8gY3JlYXRlIGFuZCBj
cmVhdGVFbGVtZW50IGp1c3QNCmdpdmVzIHRoZSB0YWcgbmFtZS4NCiANCkludGVybmFsbHksIEh0
bWxVbml0IGhhcyAzIHNldHMgb2Ygb2JqZWN0cyByZXByZXNlbnRpbmcgYSB3ZWIgcGFnZTogdGhl
DQpYTUwgRE9NIHJldHVybmVkIGZyb20gdGhlIEN5YmVyTmVrbyBIVE1MIHBhcnNlciwgdGhlIEhU
TUwgZWxlbWVudHMsIGFuZA0KdGhlIHNjcmlwdGFibGUgb2JqZWN0cy4gIFRoZSBYTUwgRE9NIHBy
b3ZpZGVzIHRoZSB0cmVlIHN0cnVjdHVyZSBhbmQgdGhlDQpvdGhlciAyIGtpbmRzIG9mIG9iamVj
dHMgYXJlIGxhemlseSBjb25zdHJ1Y3RlZCBhcyBuZWVkZWQuICBUaGUNCnNjcmlwdGFibGUgb2Jq
ZWN0cyBhbmQgSFRNTCBlbGVtZW50cyBlYWNoIGhhdmUgYSByZWZlcmVuY2UgdG8gZWFjaA0Kb3Ro
ZXIuICBUaGUgSFRNTCBlbGVtZW50cyBoYXZlIGEgcmVmZXJlbmNlIHRvIHRoZWlyIFhNTCBub2Rl
IGFuZCB0aGVpcg0KSFRNTCBwYWdlIHdoZXJlIHRoZXJlIGlzIGEgbWFwIGZyb20gWE1MIG5vZGVz
IHRvIEhUTUwgZWxlbWVudHMuICBUaGUga2V5DQpwb2ludCBoZXJlIGlzIHRoYXQgdGhlIEhUTUwg
ZWxlbWVudCBpcyB0aGUgZ2x1ZSB0aGF0IHRpZXMgdGhlc2Ugc2V0cyBvZg0Kb2JqZWN0cyB0b2dl
dGhlci4NCiANCkZvciBub24tSFRNTCBub2RlcyBpbiB0aGUgWE1MIERPTSBhbmQgbm9uLUhUTUwg
c2NyaXB0YWJsZSBvYmplY3RzIHRoZXJlDQppcyBubyBjb3JyZXNwb25kaW5nIEhUTUwgZWxlbWVu
dC4gIFNvLCB0aGVyZSBpcyBub3RoaW5nIHRvIGdsdWUgbm9uLUhUTUwNCm5vZGVzIHdpdGggbm9u
LUhUTUwgc2NyaXB0YWJsZSBvYmplY3RzLg0KIA0KU2luY2UgZml4aW5nIHRoaXMgb3BlbnMgZGVz
aWduIGxldmVsIHF1ZXN0aW9ucywgSSB0aG91Z2h0IHdlIHNob3VsZA0KZGlzY3VzcyB0aGUgYWx0
ZXJuYXRpdmVzIGZpcnN0LiAgU29tZSBhbHRlcm5hdGl2ZXMgaW5jbHVkZTogMSkgZXh0ZW5kaW5n
DQp0aGUgSFRNTCBlbGVtZW50cyB0byBpbmNsdWRlIG5vbi1IVE1MIG5vZGVzIGxpa2UgTm9kZSwg
RG9jdW1lbnQsIGFuZA0KVGV4dCwgMikgdXNpbmcgdGhlIFhNTCBub2RlcyB0byBnbHVlIHRoZSBv
YmplY3RzIHRvZ2V0aGVyLCBwZXJoYXBzIHVzaW5nDQp0aGUgdXNlciBkYXRhIHRvIGF2b2lkIG1h
cCBsb29rdXBzIG9uIGV2ZXJ5IGRlcmVmZXJlbmNlLCAzKQ0KY29uc29saWRhdGluZyB0aGUgSFRN
TCBlbGVtZW50cyBhbmQgc2NyaXB0YWJsZSBvYmplY3RzIGludG8gYSBzaW5nbGUgc2V0DQpvZiBj
bGFzc2VzIHRoYXQgc3VwcG9ydCBib3RoIHNldHMgb2YgaW50ZXJmYWNlcy4gIEFuIGV4dHJlbWUg
YWx0ZXJuYXRpdmUNCndvdWxkIGJlIHRvIGNvbnNvbGlkYXRlIHRoZSBIVE1MIGVsZW1lbnRzLCBz
Y3JpcHRhYmxlIG9iamVjdHMgYW5kIFhNTA0KRE9NIG9iamVjdHMgYnkgZXh0ZW5kaW5nIHRoZSBY
TUwgRE9NIGNsYXNzZXMgd2l0aCBzdWJjbGFzc2VzIHRoYXQNCmltcGxlbWVudCBTY3JpcHRhYmxl
Lg0KIA0KQW55d2F5LCBiZWZvcmUgSSBzcGVuZCBtdWNoIHRpbWUgZXhwbG9yaW5nIGFsdGVybmF0
aXZlcyBpbiBtdWNoIGRldGFpbCwNCkknZCBhcHByZWNpYXRlIHlvdXIgY29tbWVudHMuDQpUaGFu
a3MsDQotRGF2aWQNCiANCiANCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiANCkRJU0NMQUlNRVI6ICAgVGhlIGluZm9ybWF0aW9u
IGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVk
IHNvbGVseSBmb3IgdGhlIHJldmlldyBvZiB0aGUgbmFtZWQgYWRkcmVzc2VlLCBhbmQgaW4gY29u
anVuY3Rpb24gd2l0aCBzcGVjaWZpYyBBY29waWEgTmV0d29ya3MgYnVzaW5lc3MuICBBbnkgcmV2
aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1c2Ugb2YsIG9yIHRh
a2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRoaXMgaW5mb3JtYXRpb24gYnkg
cGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMg
cHJvaGliaXRlZC4gSWYgeW91IGFyZSB1bmFibGUgdG8gdHJlYXQgdGhpcyBpbmZvcm1hdGlvbiBh
Y2NvcmRpbmdseSwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90
aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJldHVybmluZyB0aGUgZS1tYWlsIHRvIHRoZSBvcmlnaW5h
dG9yLiANCiANCg==

[HtmlUnit] New committer: David K. Taylor

[Mike B. <mb...@Ga...>]

I'd like to announce a new committer on HtmlUnit.

David K. Taylor has been submitting a flood of excellent patches 
recently which will all be in the next release.  He has now been granted 
commit access and is working through the existing backlog of bugs.

Welcome aboard David.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] Added Support for Window.onload

[David T. <dt...@ac...>]

SSBqdXN0IGNvbW1pdGVkIHRoaXMgY2hhbmdlIHRvIENWUy4NCi1EYXZpZCBLLiBUYXlsb3INCiAN
CkFkZCBzdXBwb3J0IGZvciBzZXR0aW5nIHdpbmRvdy5vbmxvYWQgd2l0aGluIGEgc2NyaXB0LiAg
V2luZG93Lm9ubG9hZA0KbWF5IGJlIHNldCB0byB0aGUgbmFtZSBvZiBhIGZ1bmN0aW9uLCBlLmcu
LCB3aW5kb3cub25sb2FkPWluaXRGdW5jOw0KIA0KVG8gaW1wbGVtZW50IHRoaXMsIGFuIG9uTG9h
ZF8gbWVtYmVyIHdhcyBhZGRlZCB0byBIdG1sUGFnZSBmb3Igc3RvcmluZw0KdGhlIG5ldyB2YWx1
ZS4gIFRoaXMgdmFsdWUgaXMgdXNlZCBpZiBzZXQsIG90aGVyd2lzZSB0aGUgYm9keSBhdHRyaWJ1
dGUNCnZhbHVlIGlzIHVzZWQgYXMgYmVmb3JlLiAgV2hlbiB0aGlzIHZhbHVlIGlzIHNldCB3aXRo
aW4gdGhlIHNjcmlwdCwgaXQNCmlzIGEgSmF2YVNjcmlwdCBpbnRlcnByZXRlZCBmdW5jdGlvbiBv
YmplY3QsIG5vdCBhIHN0cmluZy4gIFRvIGhhbmRsZQ0KdGhpcyBmdW5jdGlvbiBvYmplY3QsIHRo
ZSBTY3JpcHRFbmdpbmUgaW50ZXJmYWNlIChhbmQgdGVzdCBjbGFzcykgYXMNCndlbGwgYXMgdGhl
IEphdmFTY3JpcHRFbmdpbmUgY2xhc3Mgd2VyZSBleHRlbmRlZCB0byBiZSBhYmxlIHRvIGNhbGwN
CmZ1bmN0aW9uIG9iamVjdHMuICBGb3IgZGVidWdnaW5nIHRoZXNlIHdlcmUgYWxzbyBleHRlbmRl
ZCB0byBjb252ZXJ0IGENCkphdmFTY3JpcHQgb2JqZWN0IHRvIGEgc3RyaW5nLiAgVGhlIGdldFNj
b3BlIG1ldGhvZCB3YXMgZmFjdG9yZWQgb3V0IHRvDQptYWtlIGl0IHJldXNhYmxlIGFjcm9zcyB0
aGUgbmV3IG1ldGhvZHMuDQogDQpXaW5kb3cgd2FzIGV4dGVuZGVkIHRvIGFsbG93IHRoZSBvbmxv
YWQgcHJvcGVydHkgdG8gYmUgc2V0IGFuZCByZWFkDQp1c2luZyB0aGUgSHRtbFBhZ2UgbWV0aG9k
cy4NCiANCk5ldyB0ZXN0IGNhc2VzIHdlcmUgYWRkZWQgZm9yIHJlYWRpbmcgYW5kIHNldHRpbmcg
dGhlIG9ubG9hZCBwcm9wZXJ0eQ0KYW5kIHRoZSBjaGFuZ2UgbG9nIHdhcyB1cGRhdGVkIHRvIGRl
c2NyaWJlIHRoaXMgZml4Lg0KIA0KQSBmZXcgbWlzc2luZyBjb25maWd1cmF0aW9uIGZpbGUgaXRl
bXMgd2VyZSBhZGRlZCB0byBlbGltaW5hdGUgc3B1cmlvdXMNCm1lc3NhZ2VzIGZyb20gdGhlIGpV
bml0IHRlc3RzLg0KIA0KQ2hlY2tpbmcgaW4gc3JjL2phdmEvY29tL2dhcmdveWxlc29mdHdhcmUv
aHRtbHVuaXQvU2NyaXB0RW5naW5lLmphdmE7DQovY3Zzcm9vdC9odG1sdW5pdC9odG1sdW5pdC9z
cmMvamF2YS9jb20vZ2FyZ295bGVzb2Z0d2FyZS9odG1sdW5pdC9TY3JpcHQNCkVuZ2luZS5qYXZh
LHYgIDwtLSAgU2NyaXB0RW5naW5lLmphdmENCm5ldyByZXZpc2lvbjogMS45OyBwcmV2aW91cyBy
ZXZpc2lvbjogMS44DQpkb25lDQpDaGVja2luZyBpbiBzcmMvamF2YS9jb20vZ2FyZ295bGVzb2Z0
d2FyZS9odG1sdW5pdC9odG1sL0h0bWxQYWdlLmphdmE7DQovY3Zzcm9vdC9odG1sdW5pdC9odG1s
dW5pdC9zcmMvamF2YS9jb20vZ2FyZ295bGVzb2Z0d2FyZS9odG1sdW5pdC9odG1sL0gNCnRtbFBh
Z2UuamF2YSx2ICA8LS0gIEh0bWxQYWdlLmphdmENCm5ldyByZXZpc2lvbjogMS40NDsgcHJldmlv
dXMgcmV2aXNpb246IDEuNDMNCmRvbmUNCkNoZWNraW5nIGluDQpzcmMvamF2YS9jb20vZ2FyZ295
bGVzb2Z0d2FyZS9odG1sdW5pdC9qYXZhc2NyaXB0L0phdmFTY3JpcHRDb25maWd1cmF0aW8NCm4u
eG1sOw0KL2N2c3Jvb3QvaHRtbHVuaXQvaHRtbHVuaXQvc3JjL2phdmEvY29tL2dhcmdveWxlc29m
dHdhcmUvaHRtbHVuaXQvamF2YXNjDQpyaXB0L0phdmFTY3JpcHRDb25maWd1cmF0aW9uLnhtbCx2
ICA8LS0gIEphdmFTY3JpcHRDb25maWd1cmF0aW9uLnhtbA0KbmV3IHJldmlzaW9uOiAxLjIwOyBw
cmV2aW91cyByZXZpc2lvbjogMS4xOQ0KZG9uZQ0KQ2hlY2tpbmcgaW4NCnNyYy9qYXZhL2NvbS9n
YXJnb3lsZXNvZnR3YXJlL2h0bWx1bml0L2phdmFzY3JpcHQvSmF2YVNjcmlwdEVuZ2luZS5qYXZh
Ow0KL2N2c3Jvb3QvaHRtbHVuaXQvaHRtbHVuaXQvc3JjL2phdmEvY29tL2dhcmdveWxlc29mdHdh
cmUvaHRtbHVuaXQvamF2YXNjDQpyaXB0L0phdmFTY3JpcHRFbmdpbmUuamF2YSx2ICA8LS0gIEph
dmFTY3JpcHRFbmdpbmUuamF2YQ0KbmV3IHJldmlzaW9uOiAxLjE1OyBwcmV2aW91cyByZXZpc2lv
bjogMS4xNA0KZG9uZQ0KQ2hlY2tpbmcgaW4NCnNyYy9qYXZhL2NvbS9nYXJnb3lsZXNvZnR3YXJl
L2h0bWx1bml0L2phdmFzY3JpcHQvaG9zdC9XaW5kb3cuamF2YTsNCi9jdnNyb290L2h0bWx1bml0
L2h0bWx1bml0L3NyYy9qYXZhL2NvbS9nYXJnb3lsZXNvZnR3YXJlL2h0bWx1bml0L2phdmFzYw0K
cmlwdC9ob3N0L1dpbmRvdy5qYXZhLHYgIDwtLSAgV2luZG93LmphdmENCm5ldyByZXZpc2lvbjog
MS4xNzsgcHJldmlvdXMgcmV2aXNpb246IDEuMTYNCmRvbmUNCkNoZWNraW5nIGluDQpzcmMvdGVz
dC9qYXZhL2NvbS9nYXJnb3lsZXNvZnR3YXJlL2h0bWx1bml0L1NjcmlwdEVuZ2luZVRlc3QuamF2
YTsNCi9jdnNyb290L2h0bWx1bml0L2h0bWx1bml0L3NyYy90ZXN0L2phdmEvY29tL2dhcmdveWxl
c29mdHdhcmUvaHRtbHVuaXQvUw0KY3JpcHRFbmdpbmVUZXN0LmphdmEsdiAgPC0tICBTY3JpcHRF
bmdpbmVUZXN0LmphdmENCm5ldyByZXZpc2lvbjogMS4yOyBwcmV2aW91cyByZXZpc2lvbjogMS4x
DQpkb25lDQpDaGVja2luZyBpbg0Kc3JjL3Rlc3QvamF2YS9jb20vZ2FyZ295bGVzb2Z0d2FyZS9o
dG1sdW5pdC9odG1sL0h0bWxQYWdlVGVzdC5qYXZhOw0KL2N2c3Jvb3QvaHRtbHVuaXQvaHRtbHVu
aXQvc3JjL3Rlc3QvamF2YS9jb20vZ2FyZ295bGVzb2Z0d2FyZS9odG1sdW5pdC9oDQp0bWwvSHRt
bFBhZ2VUZXN0LmphdmEsdiAgPC0tICBIdG1sUGFnZVRlc3QuamF2YQ0KbmV3IHJldmlzaW9uOiAx
LjM7IHByZXZpb3VzIHJldmlzaW9uOiAxLjINCmRvbmUNCkNoZWNraW5nIGluIHNyYy94ZG9jcy9j
aGFuZ2VzLnhtbDsNCi9jdnNyb290L2h0bWx1bml0L2h0bWx1bml0L3NyYy94ZG9jcy9jaGFuZ2Vz
LnhtbCx2ICA8LS0gIGNoYW5nZXMueG1sDQpuZXcgcmV2aXNpb246IDEuMTA1OyBwcmV2aW91cyBy
ZXZpc2lvbjogMS4xMDQNCmRvbmUNCiANCiANCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiANCkRJU0NMQUlNRVI6ICAgVGhlIGlu
Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBpcyBjb25maWRlbnRpYWwgYW5kIGlz
IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHJldmlldyBvZiB0aGUgbmFtZWQgYWRkcmVzc2VlLCBh
bmQgaW4gY29uanVuY3Rpb24gd2l0aCBzcGVjaWZpYyBBY29waWEgTmV0d29ya3MgYnVzaW5lc3Mu
ICBBbnkgcmV2aWV3LCByZXRyYW5zbWlzc2lvbiwgZGlzc2VtaW5hdGlvbiBvciBvdGhlciB1c2Ug
b2YsIG9yIHRha2luZyBvZiBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIHVwb24sIHRoaXMgaW5mb3Jt
YXRpb24gYnkgcGVyc29ucyBvciBlbnRpdGllcyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNp
cGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSB1bmFibGUgdG8gdHJlYXQgdGhpcyBpbmZv
cm1hdGlvbiBhY2NvcmRpbmdseSwgb3IgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw
bGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IHJldHVybmluZyB0aGUgZS1tYWlsIHRvIHRo
ZSBvcmlnaW5hdG9yLiANCiANCg==

[HtmlUnit] Contributing to HtmlUnit

[Mike B. <mb...@Ga...>]

A number of people have asked me recently if I accept patches or if I 
could use help so I thought I'd make an official response here :-)

Yes, I will gladly accept patches.  I would be overjoyed to have people 
help with this project.  HtmlUnit is maintained in my spare time and I 
don't always have a lot of that.

There's a gotcha though (you knew this was coming didn't you), having 
had to maintain far too much bad code over the years, I'm somewhat anal 
retentive about the code remaining maintainable.  I insist on certain 
rules such as the code following a specified coding standard and all 
code having automated unit tests.  The full details are written up at 
http://htmlunit.sourceforge.net/submittingPatches.html

The intent is to keep the code maintainable, not to make life difficult 
for contributers.

There have already been a number of people who have contributed patches 
and their work is greatly appreciated.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

Re: [HtmlUnit] Issues with submitting a FORM

[Mike B. <mb...@Ga...>]

santhi velayudhan wrote:
> 
> Hi,
> 
> I am having problem with htmlunit when I submit a form. (View Source of 
> the page containing this form is attached)
> 
> The problems:
> 1. When I tried to set value as follows in the text field, I got the 
> javascript exception (ScriptException: undefined is not a function).

This means that you are trying to use a javascript host object that I 
haven't provided support for yet.  Please open a bug for this and 
include the html that causes the exception.

I'm on course today and tomorrow and won't have time to look at this 
right away.


-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] Issues with submitting a FORM

[santhi v. <san...@ho...>]

Hi,

I am having problem with htmlunit when I submit a form. (View Source of the 
page containing this form is attached)

The problems:
1. When I tried to set value as follows in the text field, I got the 
javascript exception (ScriptException: undefined is not a function).


HtmlForm htmlform = page.getFormByName("myForm");
HtmlTextInput fileName = 
(HtmlTextInput)htmlform.getInputByName("file_name");
fileName.setValueAttribute("ffff");
System.out.println("fileName = " +fileName.getValueAttribute() );

(So I tried to disable the javacsript using
webClient.setJavaScriptEnabled(false); before calling setValueAttribute() 
and that worked and getValueAttribute() showed that the value is set to 
"ffff")

com.gargoylesoftware.htmlunit.ScriptException: undefined is not a function.
	at 
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:199)
	at 
com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptIfPossible(HtmlPage.java:767)
	at 
com.gargoylesoftware.htmlunit.html.HtmlInput.setValueAttribute(HtmlInput.java:50)
	at com.interwoven.clientTest.TestLeo.bizUI_testCopyFile(TestLeo.java:311)
	at java.lang.reflect.Method.invoke(Native Method)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
	at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
	at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536)

2. Now I enabled the javascript
webClient.setJavaScriptEnabled(true); abd then submit the form.
htmlform.submit();

I get simillar Exception:

  <system-err><![CDATA[com.gargoylesoftware.htmlunit.ScriptException: 
undefined is not a function.
	at 
com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.execute(JavaScriptEngine.java:199)
	at 
com.gargoylesoftware.htmlunit.html.HtmlPage.executeJavaScriptIfPossible(HtmlPage.java:770)
	at 
com.gargoylesoftware.htmlunit.ScriptFilter.executeScript(ScriptFilter.java:188)
	at 
com.gargoylesoftware.htmlunit.ScriptFilter.endElement(ScriptFilter.java:165)
	at org.cyberneko.html.HTMLTagBalancer.endElement(Unknown Source)
	at org.cyberneko.html.HTMLScanner$SpecialScanner.scan(Unknown Source)
	at org.cyberneko.html.HTMLScanner.scanDocument(Unknown Source)
	at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source)
	at org.cyberneko.html.HTMLConfiguration.parse(Unknown Source)
	at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
	at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
	at 
com.gargoylesoftware.htmlunit.html.HtmlPage.createDocument(HtmlPage.java:250)
	at 
com.gargoylesoftware.htmlunit.html.HtmlPage.initialize(HtmlPage.java:129)
	at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:322)
	at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:242)
	at com.gargoylesoftware.htmlunit.html.HtmlForm.submit(HtmlForm.java:137)
	at com.gargoylesoftware.htmlunit.html.HtmlForm.submit(HtmlForm.java:88)
	at com.interwoven.clientTest.TestLeo.bizUI_testCopyFile(TestLeo.java:323)
	at java.lang.reflect.Method.invoke(Native Method)
	at junit.framework.TestCase.runTest(TestCase.java:154)
	at junit.framework.TestCase.runBare(TestCase.java:127)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:118)
	at junit.framework.TestSuite.runTest(TestSuite.java:208)
	at junit.framework.TestSuite.run(TestSuite.java:203)
	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.extensions.TestSetup.run(TestSetup.java:23)
	at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
	at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:536)


Does anyone know/seen this before?

Thanks,
Santhi.

_________________________________________________________________
Attention NRI! Send money home easily. 
http://server1.msn.co.in/msnleads/citibankrca/citibankrca2.asp Just sign up!

Re: [HtmlUnit] HttpUnit

[Rick B. <no...@ya...>]

Mike,

I've tracked HttpUnit for a while and just started
looking seriously at HtmlUnit.  The application I've
worked most with has a fair bit of JavaScript (most of
the buttons) so I couldn't use HttpUnit until that was
incorporated.  HtmlUnit wasn't on my radar screen
until recently so I hadn't even considered it.  A few
weeks ago I had the opportunity to revisit the test
automation topic and have been spending little bits of
time on it here and there (a dedicated block would be
nice but it just hasn't fit yet).

I've been building the same tests with both tools to
help decide if either has a real advantage or if there
is anything about my application that is beyond the
current level of support in either.  I started out
with an assumed "difference" between the two based on
the following text from the first paragraph of the
HtmlUnit home page on SourceForge (with which I
presume you are familiar).

"Which one is better for you depends on how you like
to write your tests. HttpUnit models the http protocol
so you deal with request and response objects.
HtmlUnit on the other hand, models the returned
document so that you deal with pages and form and
tables."

I'm not sure that the difference is quite as distinct
any more.  Their respective vocabularies are
definitely more HTML-centric and HTTP-centric, but in
either case I still find myself thinking about getting
the page, getting a form or table out of the page,
operating on what I've got, and submitting the result
(in the case of a form submit) or clicking on a button
or link.

Various people, at least in the HttpUnit community
where I've been on the mailing list longer, talk about
the fact that they end up refactoring common elements
out of their test code and into framework or helper
class code that simplifies the code flow in the test
itself.  I've been doing the same thing.

What I've found is that at the level I prefer to write
my test scripts, I've hidden the differences between
HtmlUnit and HttpUnit (except in cases where one only
supports "...ByID" and the other only supports
"...ByName").  My tests are built out of calls to
application-specific methods like login, logout, and
clickToNextWizardPage or more generic methods like
clickLinkWithName, selectFormByName, and setFormField.
 Implicit in my structure is a concept of "current"
for various things like page and form.

Much of my early test writing time has gone into the
discovery of these common features or the refining of
them.  When I had reached the point of being able to
navigate through one of the more complicated page
sequences in my application, I switched to the other
tool.  While I had to change class and method names, I
found that even the structure of my helper classes was
essentially the same.  I've also been able to evolve
them essentially in lock step so far.

There are certainly differences between the two at a
very nit-picky level.  Neither tool supports the
ability to operate uniformly by name, id, or label
text (i.e. not all variants of element reference are
supported in all cases where HTML defines them).  Both
are getting close but I suspect have been driven by
what has been requested (or via code submissions
adopted by their respective developers) in their
communities rather than specifically trying to be
uniform.  Since both are open source, I have no fear
that I would be unable add features I really need (and
submit them for incorporation if appropriate).

Right now, HtmlUnit has more built-in testing support
with methods like
HtmlPage.assertAllIdAttributesUnique.  HttpUnit seems
to have concentrated more on providing the engine that
gets the information back and forth and makes it
accessible to the test program than on capturing what
are likely to be common assertions about the content. 
My evaluation hasn't gotten to the point where these
differences have been drawn out enough to make a
critical difference.

As I get time to bring the evaluation to the point of
picking a tool I think I'll end up looking at somewhat
more subjective criteria like whether I think either
tool has greater momentum.  I'd have to give HttpUnit
the nod on greater visibility at this point (maybe I
stopped paying as much attention once I had found
HttpUnit but I suspect that HtmlUnit is still behind).
 I may have a look at whether either has a big
performance advantage over the other.  I guess I'd be
surprised to find such a difference but I may
ultimately be interested in using the same test
expression environment to write tests that stress the
application.

While this list is a good place to look for people
with cross-over experience, I suggest maybe you should
consider posting to the httpunit list as well.  You
might also try the JUnit YahooGroup.  There has been
at least a little bit of traffic on the matter of
examples for HttpUnit w/Javascript (and the most
recent JUnit post as of this writing was a plug for
HtmlUnit by J.B. Rainsberger).

Rick Berman
Ancilla SF LLC
ric...@ac...

Re: [HtmlUnit] HttpUnit

[Mike B. <mb...@Ga...>]

th...@cy... wrote:
 > Here is another interesting link for software testing. Gives you some
 > overview about testing tools. Question to Mike B.: Why doesn't
 > HtmlUnit appear in this list? ;)
 >
 >   http://www.softwareqatest.com/

I'd never heard of this site before.  I've sent a note to the maintainer.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

Re: [HtmlUnit] HttpUnit

[<th...@cy...>]

Mike Bresnahan <mbr...@vi...> schrieb am 15.05.2003, 17:51:23:
> I'm giving a presentation next week on HtmlUnit and I just know that 
> someone is going to ask about HttpUnit.  However, I have no experience 
> with it, nor did a google search turn up anything comparing HttpUnit and 
> HtmlUnit.  Has anyone used both APIs?  If so, do they care to share their 
> thoughts?

Personnaly I have no experience with HttpUnit. But there turned up a
nice book here at our company, which might give some impressions on
HttpUnit and how to use it. Just flipping through the HttpUnit-related
pages made me decide, that I like HtmlUnit much more ;)

The book is called "Java Extreme Programming Cookbook" and it's written
by Eric M. Burke & Brian M. Coyner. Oh, and it's published by O'Reilly.
I can recommand this book very much, because it covers some interesting
test-related topics from a nice practical oriented point of view. There
are nice recipes on how using ant, junit, HttpUnit and some tools more
and how to combine them. 

Oh, by the way, there might be questions on you presentation, that ask
for other APIs to test web based user interfaces. Recently I found this
one here:

   https://sourceforge.net/projects/jwebunit/

Just by flipping through the java documentation I decided, that I don't
like it. Have a look yourself ;) 
Besides that, there is not as much activity on the project like it is
with HtmlUnit. 

Here is another interesting link for software testing. Gives you some
overview about testing tools. Question to Mike B.: Why doesn't HtmlUnit
appear in this list? ;)

  http://www.softwareqatest.com/


And another project I just discovered, which might be interesting: 

  http://xmltestsuite.sourceforge.net


Hope this helps


Best regards, 
Thomas Bartz
Berlin

[HtmlUnit] HttpUnit

[Mike B. <mbr...@vi...>]

I'm giving a presentation next week on HtmlUnit and I just know that someone
is going to ask about HttpUnit.  However, I have no experience with it, nor
did a google search turn up anything comparing HttpUnit and HtmlUnit.  Has
anyone used both APIs?  If so, do they care to share their thoughts?

Mike

Re: [HtmlUnit] DbUnit and HtmlUnit Presentation

[Mike B. <mb...@Ga...>]

Mike Bresnahan wrote:
 > I am going to be giving a presentation to the Twin
 > Cities Java User's Group in St. Paul, MN about testing
 > web applications with DbUnit and HtmlUnit on July 16.

Very cool!

 > For others, as I have never spoken on the topic, I
 > would appreciate any tips, presentation materials,
 > encouragement, or anything else helpful to my
 > presentation that list members could provide.

Encouragement I can provide :-)

As strange as it sounds, I may not be the best person to give ideas for 
the presentation.  I spend so much time these days in the low level 
details of javascript support that I lose sight of the overall package. 
(Can't see the forest for the trees).

Despite that, I'd be happy to help if I can. :-)

Feel free to use any samples/information from the website.  If you end 
up writing more samples for the presentation and are willing to donate 
them back to the HtmlUnit documentation, they would be gratefully 
appreciated :-)


-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

[HtmlUnit] DbUnit and HtmlUnit Presentation

[Mike B. <MBr...@go...>]

I am going to be giving a presentation to the Twin Cities Java User's =
Group in St. Paul, MN about testing web applications with DbUnit and =
HtmlUnit on July 16.  Details are at the following URL:

http://www.intertech-inc.com/userGroup/javaUserGroup.asp?loc=3Dusergroups=


For those in the Twin Cities area looking for help with the subject, you =
are welcome to come to the presentation.  It doesn't cost anything and =
it is open to anyone.

For others, as I have never spoken on the topic, I would appreciate any =
tips, presentation materials, encouragement, or anything else helpful to =
my presentation that list members could provide.=20

Mike Bresnahan =20

Re: [HtmlUnit] HtmlElment.asText() enhancement

[Mike B. <mb...@Ga...>]

Mike Bresnahan wrote:
 >>Is it safe to assume that 160 is always a non-breakable
 >>space?  I know
 >>that some encodings don't use 160 (I've been burned by that
 >>on some unix
 >>machines) but by the time the string has been converted into unicode
 >>within java, this may have already been adjusted.
 >
 >
 > That's a very good question, which I don't know the answer to.  I'm
 > pretty clueless when it comes to character sets and
 > internationalization.    I think it is part of what it means to be a
 > US citizen.

:-)

I'll leave it as-is for now.  Perhaps someone who is using an encoding 
other than ISO-8859-1 can let us know if non-breaking spaces are working 
correctly.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

RE: [HtmlUnit] junit target broken

[Mike B. <MBr...@go...>]

Yes I do.  I'll look into it further.

Mike
> -----Original Message-----
> From: htm...@li...
> [mailto:htm...@li...]On Behalf Of Mike
> Bowler
> Sent: Tuesday, April 22, 2003 2:09 PM
> To: htm...@so...
> Subject: Re: [HtmlUnit] junit target broken
>=20
>=20
> Mike Bresnahan wrote:
> > The junit Ant target appears to be broken.
> <snipped>
> > junit:
> >      [java] Class not found
> > "com.gargoylesoftware.htmlunit.test.MainTestSuite"
> >      [java] Java Result: -1
>=20
> Strange - it works fine on two different machines here.  Do=20
> you have a=20
> MainTestSuite.java?
>=20
> --=20
> Mike Bowler
> Principal, Gargoyle Software Inc.
> Voice: (416) 822-0973 | Email  : mb...@Ga...
> Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com
>=20

Re: [HtmlUnit] junit target broken

[Mike B. <mb...@Ga...>]

Mike Bresnahan wrote:
> The junit Ant target appears to be broken.
<snipped>
> junit:
>      [java] Class not found
> "com.gargoylesoftware.htmlunit.test.MainTestSuite"
>      [java] Java Result: -1

Strange - it works fine on two different machines here.  Do you have a 
MainTestSuite.java?

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com

RE: [HtmlUnit] HtmlElment.asText() enhancement

[Mike B. <MBr...@go...>]

> Is it safe to assume that 160 is always a non-breakable=20
> space?  I know=20
> that some encodings don't use 160 (I've been burned by that=20
> on some unix=20
> machines) but by the time the string has been converted into unicode=20
> within java, this may have already been adjusted.

That's a very good question, which I don't know the answer to.  I'm
pretty clueless when it comes to character sets and
internationalization.    I think it is part of what it means to be a US
citizen.

Mike

Re: [HtmlUnit] HtmlElment.asText() enhancement

[Mike B. <mb...@Ga...>]

Mike Bresnahan wrote:
> Attached is a patch that enhances the HtmlElment.asText() function to
> produce results that are both closer to what a real web browser produces
> and easier to write tests against.

I've applied your patch - thanks.

I made a couple of minor changes like adding the final keyword in a 
couple of places and adding an author tag for you.

Is it safe to assume that 160 is always a non-breakable space?  I know 
that some encodings don't use 160 (I've been burned by that on some unix 
machines) but by the time the string has been converted into unicode 
within java, this may have already been adjusted.

-- 
Mike Bowler
Principal, Gargoyle Software Inc.
Voice: (416) 822-0973 | Email  : mb...@Ga...
Fax  : (416) 822-0975 | Website: http://www.GargoyleSoftware.com