Move SearchableFormData over to the WebKit API.

Move SearchableFormData over to the WebKit API.

BUG=24621
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29941

[Peter Kasting, 2009-10-22 19:43:01]

I don't know if this is the right way to do this, in particular the way I have
the SearchableFormData wrapper object in the glue layer and how object creation
works.

[Peter Kasting, 2009-10-22 20:30:14]

Added dglazkov as a reviewer in case Darin is super-flooded.  My concerns about
the glue-side wrapper object and the construction flow still apply.

[darin (slow to review), 2009-10-23 17:22:02]

lot's of webkit style errors.  i didn't indicate them all.

http://codereview.chromium.org/306057/diff/1/4
File webkit/api/public/WebSearchableFormData.h (right):

http://codereview.chromium.org/306057/diff/1/4#newcode31
Line 31: #ifndef WebSearchableFormArea_h
...FormData_h

http://codereview.chromium.org/306057/diff/1/4#newcode37
Line 37: namespace WebCore { class HTMLFormElement; }
please delete this line

http://codereview.chromium.org/306057/diff/1/4#newcode42
Line 42: // SearchableFormData encapsulates a URL and encoding of an INPUT field
that
nit: "an URL"

http://codereview.chromium.org/306057/diff/1/4#newcode44
Line 44: class WebSearchableFormData {
the webkit style guide changed recently.  now, the contents of a namespace
should not be indented when they appear in a header.

http://codereview.chromium.org/306057/diff/1/4#newcode48
Line 48: static WebSearchableFormData* Create(const WebForm& form);
s/Create/create/

nit: webkit style says to not name parameters when the name doesn't add
information.  in this case, the name "form" should be dropped.

http://codereview.chromium.org/306057/diff/1/4#newcode59
Line 59: encoding_(encoding) {
please use webkit style for the brackets

http://codereview.chromium.org/306057/diff/1/4#newcode62
Line 62: const WebURL url_;
m_url
m_encoding

http://codereview.chromium.org/306057/diff/1/4#newcode68
Line 68: #endif // WebSearchableFormArea_h
...FormData_h

but i have been using the convention of not adding this comment to the include
guard #ifdef because that seems more consistent with existing webkit code

http://codereview.chromium.org/306057/diff/1/3
File webkit/api/src/WebSearchableFormData.cpp (right):

http://codereview.chromium.org/306057/diff/1/3#newcode53
Line 53: void GetFormEncoding(const HTMLFormElement* form, TextEncoding*
encoding) {
please use webkit style for function brackets (ditto elsewhere)

http://codereview.chromium.org/306057/diff/1/3#newcode61
Line 61: return;
indent by 4

http://codereview.chromium.org/306057/diff/1/3#newcode124
Line 124: bool IsInDefaultState(const HTMLFormControlElement* form_element) {
formElement

http://codereview.chromium.org/306057/diff/1/3#newcode126
Line 126: const HTMLInputElement* input_element = static_cast<const
HTMLInputElement*>(form_element);
inputElement

http://codereview.chromium.org/306057/diff/1/3#newcode233
Line 233: bool has_element = HasSuitableTextElement(form_element.get(),
&enc_string, &encoding);
formElement
enc_string -> encString?

http://codereview.chromium.org/306057/diff/1/5
File webkit/glue/searchable_form_data.cc (right):

http://codereview.chromium.org/306057/diff/1/5#newcode15
Line 15:
web_searchable_form_data(WebKit::WebSearchableFormData::Create(webform));
it seems like it would be nice if WebSearchableFormData could just be allocated
on the stack.  we could just have WebSearchableFormData have a constructor that
takes a WebForm.  the validity of its URL could be used to indicate errors.

[Peter Kasting, 2009-10-23 18:25:33]

Fixed the style errors and changed the create() function to just be a
constructor.  After some reflection I decided that the SearchableFormData
wrapper object was worthless at this point, so I removed it entirely, without
needing to do much except change one member variable on the NavigationState into
two.

[darin (slow to review), 2009-10-23 20:50:31]

LGTM