Basic purpose of onEnsureDebugId

955 views
Skip to first unread message

Aditya

unread,
Jul 16, 2010, 12:26:43 AM7/16/10
to Google Web Toolkit
hello,

Can anyone has answer why is onEnsureDebugId() is used...?
how does it helps while creating custom widgets.

--
Aditya

Thomas Broyer

unread,
Jul 16, 2010, 5:14:33 AM7/16/10
to Google Web Toolkit
The whole notion of "debug ID" is only useful if you do run selenium
or webdriver (or similar) tests, and you therefore need widgets to
have an ID, and moreover a *stable* ID. But you generally don't want
that ID to be generated when deploying for production use.
So you'll call ensureDebugId in your code, which in turn will call the
onEnsureDebugId of the widget, but only if you <inherit
name='com.google.gwt.user.Debug' />, otherwise it's a no-op.
Widgets can then override onEnsureDebugId to set an ID not only to
their "root element" but also to child elements. See for instance how
CheckBox overrides onEnsureDebugId to set an ID on the checkbox and
label (remember, CheckBox is a <span> with a <input type=checkbox> and
<label> children).
Calling ensureDebugId("foo") on some CheckBox widget will set an
id="gwt-debug-foo" on the <span>, id="gwt-debug-foo-label" on the
<label> and id="gwt-debug-foo-input" on the <input type=checkbox>.
That way you can write selenium/webdriver/whatever tests that will
generate, say, click events on the document.getElementById("gwt-debug-
foo-input") (i.e. the <input type=checkbox> of your CheckBox widget)

Hilco Wijbenga

unread,
Sep 23, 2010, 1:54:37 PM9/23/10
to google-we...@googlegroups.com

I just found out about ensureDebugId precisely because I want to use
Selenium to test our GWT app. I don't clearly understand why this is a
debug only thing. What is the reason you don't want this in
production? Is it simply because all those ids take up a lot of space?

The consequence of only having a debug id is that I need to have two
versions of the app, a production version and a test version. I can do
that but I'd like to be clear on why the extra effort is worth it. :-)

Hilco Wijbenga

unread,
Sep 23, 2010, 2:03:21 PM9/23/10
to google-we...@googlegroups.com

It looks like it's up to the developer to make sure the ids are
unique. I don't get any complaints from GWT when I reuse an id (on the
same page). Is this something that I can ask the GWT compiler to check
for?

Thomas Broyer

unread,
Sep 24, 2010, 4:27:29 AM9/24/10
to Google Web Toolkit


On Sep 23, 7:54 pm, Hilco Wijbenga <hilco.wijbe...@gmail.com> wrote:
> On 16 July 2010 02:14, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > The whole notion of "debug ID" is only useful if you do run selenium
> > or webdriver (or similar) tests, and you therefore need widgets to
> > have an ID, and moreover a *stable* ID. But you generally don't want
> > that ID to be generated when deploying for production use.
> > So you'll call ensureDebugId in your code, which in turn will call the
> > onEnsureDebugId of the widget, but only if you <inherit
> > name='com.google.gwt.user.Debug' />, otherwise it's a no-op.
> > Widgets can then override onEnsureDebugId to set an ID not only to
> > their "root element" but also to child elements. See for instance how
> > CheckBox overrides onEnsureDebugId to set an ID on the checkbox and
> > label (remember, CheckBox is a <span> with a <input type=checkbox> and
> > <label> children).
> > Calling ensureDebugId("foo") on some CheckBox widget will set an
> > id="gwt-debug-foo" on the <span>, id="gwt-debug-foo-label" on the
> > <label> and id="gwt-debug-foo-input" on the <input type=checkbox>.
> > That way you can write selenium/webdriver/whatever tests that will
> > generate, say, click events on the document.getElementById("gwt-debug-
> > foo-input") (i.e. the <input type=checkbox> of your CheckBox widget)
>
> I just found out about ensureDebugId precisely because I want to use
> Selenium to test our GWT app. I don't clearly understand why this is a
> debug only thing. What is the reason you don't want this in
> production? Is it simply because all those ids take up a lot of space?

Yes (more code is generated, and it also has to run, and we all know
that the fastest code is the one that doesn't run ;-) )
On the performance side, browsers maintain lookup tables, so the more
IDs you have, the bigger those tables and the slower your app. For
instance, UiBinder uses IDs for your ui:field, and it takes care of
removing them after use: there must be a reason the GWT team has added
this line of code.

> The consequence of only having a debug id is that I need to have two
> versions of the app, a production version and a test version.

You mean you have to *deploy* two versions of the app, not *maintain*
them? (you just have to add another *.gwt.xml inheriting both your
production *.gwt.xml and com.google.gwt.debug.Debug, similar to how
you'd use such an additional module to only compile for a subset of
user-agents to speed compiles: see "Renaming modules" in
http://code.google.com/webtoolkit/doc/latest/DevGuideOrganizingProjects.html#DevGuideModules
)
Reply all
Reply to author
Forward
0 new messages