[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
No - more like (for example), when it hits a label it always creates a Google LabelElement - say I want to create a MyLabelElement instead (which does some extra thing, which in my case it does). I can't do it without hacking it (which I have done). Happy to file an Issue on this... On Aug 27, 11:49 pm, Joel Webber j...@google.com wrote: I'm not entirely certain I understand the problem here -- is the issue that you want to use an element for which there's no Element subtype in the .dom package? We didn't go to great lengths to make this extensible, because the set of legal HTML DOM elements changes at a glacial pace. But if there's one we missed, please let us know! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
It may not be a perfect solution to what you want to do, but because those
are native DOM Elements, which subtype JavaScriptObject, you can cast them
to any other JSO subtype you like. For example:
@UiField Element elem;
MyWidget() {
// ...
// If your element subclasses Element:
((MyLabelElement)elem).goCrazy();
// If not, then:
MyLabelElement lbl = elem.cast();
lbl.goCrazy();
}
IOW, the generated code doesn't create an element, it just wraps the
native element in a particular JSO interface, which you're free to change
later.
On Fri, Aug 28, 2009 at 6:34 AM, Richard Vowles richard.vow...@gmail.comwrote:
No - more like (for example), when it hits a label it always creates
a Google LabelElement - say I want to create a MyLabelElement instead
(which does some extra thing, which in my case it does). I can't do it
without hacking it (which I have done). Happy to file an Issue on
this...
On Aug 27, 11:49 pm, Joel Webber j...@google.com wrote:
I'm not entirely certain I understand the problem here -- is the issue
that
you want to use an element for which there's no Element subtype in the
.dom
package? We didn't go to great lengths to make this extensible, because
the
set of legal HTML DOM elements changes at a glacial pace. But if there's
one
we missed, please let us know!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
Also, have you noticed the @UiField(provided=true) and @UiFactory
annotations? They allow you to take charge of factory duties, instead of
relying on the default GWT.create() behavior.
On Fri, Aug 28, 2009 at 7:30 AM, Joel Webber j...@google.com wrote:
It may not be a perfect solution to what you want to do, but because those
are native DOM Elements, which subtype JavaScriptObject, you can cast them
to any other JSO subtype you like. For example:
@UiField Element elem;
MyWidget() {
// ...
// If your element subclasses Element:
((MyLabelElement)elem).goCrazy();
// If not, then:
MyLabelElement lbl = elem.cast();
lbl.goCrazy();
}
IOW, the generated code doesn't create an element, it just wraps the
native element in a particular JSO interface, which you're free to change
later.
On Fri, Aug 28, 2009 at 6:34 AM, Richard Vowles
richard.vow...@gmail.comwrote:
No - more like (for example), when it hits a label it always creates
a Google LabelElement - say I want to create a MyLabelElement instead
(which does some extra thing, which in my case it does). I can't do it
without hacking it (which I have done). Happy to file an Issue on
this...
On Aug 27, 11:49 pm, Joel Webber j...@google.com wrote:
I'm not entirely certain I understand the problem here -- is the issue
that
you want to use an element for which there's no Element subtype in the
.dom
package? We didn't go to great lengths to make this extensible, because
the
set of legal HTML DOM elements changes at a glacial pace. But if there's
one
we missed, please let us know!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
I wouldn't mind some convincing urls to backup this viewpoint if you have any :-) The entire rest of the team here is saying id id id, class bad, id good. Searching for html id brittle wasn't very enlightening :-) I have also found that there seems to be no way of overriding the class that is created when hitting HTML elements - it is hard coded in UiBinderWriter to look only in the Google classes for elements with TAG. Descending and fixing it for UiBinderWriter was relatively straight forward (even tho I had to put the replacement class in com.google...), but because all of the important methods are private in UiBinderGenerator, I had to replace that and copy the methods, which was triple yuk. Good to have the source though :-) Solving the problem would be easy (i.e. allowing people to override and replace their own classes only if they wanted to) by the UiBinderGenerator asking for the UiBinderWriter through the GWT.create mechanism and the right methods being protected in the Writer instead of package private... You guys may already have a different solution so it that is more elegant though. Ta Richard On Aug 27, 3:56 am, Ray Ryan rj...@google.com wrote: And you can set the debug id via ui.xml: gwt:Label debugId='joe'Hiya, pal./gwt:Label If you're not going to use CssResource, there is nothing you can do with an id selector that you can't do with a class selector. I really discourage the use of id selectors, they're brittle. rjrjr On Wed, Aug 26, 2009 at 11:53 AM, Joel Webber j...@google.com wrote: The biggest problem here is that ids have to be unique within a document, and UiBinder has no way of enforcing this. If you want to use it for styling, you're probably better off with CssResource (we're working on updating the samples to reflect what we believe to be the best pattern for doing this). As for testing, I assume you mean using something like Selenium. This is actually why we created the UIObject.ensureDebugId() stuff -- especially so that you can turn it off in deployment. But if you're using GWTTestCase, you can just bind the elements to fields and grab those directly. Cheers, joel. On Tue, Aug 25, 2009 at 10:38 PM, Richard Vowles richard.vow...@gmail.com wrote: One of the things I have noticed with the UIBinder is that you can't set the id on the fields - which is pretty important for css styling and testing. I seem to have to set them in code. g:TextBox ui:field=tbWhatever id=some-name/ causes it to fail to compile. I know id is an attribute of getElement () but since this is a very common thing to do, I'd have expected ui:id or some such (or just id being acceptable). Am I missing something? Ta Richard On Aug 26, 12:49 pm, Bruce Johnson br...@google.com wrote: No plans to do drag-n-drop or anything wysiwyg. We'll probably continue to focus on the basics. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
On Thu, Aug 27, 2009 at 5:29 AM, Richard Vowles richard.vow...@gmail.comwrote: I wouldn't mind some convincing urls to backup this viewpoint if you have any :-) The entire rest of the team here is saying id id id, class bad, id good. Searching for html id brittle wasn't very enlightening :-) It's fairly easy to arrive at this conclusion from first principles. Element ids *must* be unique within a document. The fact that getElementById() can only return a single element makes this pretty clear and unavoidable (whether or not it was a good idea in [HT X]ML is another question altogether). If you have a .ui.xml with an id in it, you can *never* use more than one in an app at the same time. While there are sometimes cases where one is pretty sure this constraint will be satisfied, there's no way for UiBinder to know this. It also turns out that .class selectors aren't particularly different in performance from #id selectors. *descendant* selectors are pure evil, because they create an oft-unoptimizable case for the selector engine, but that's not what we're talking about here. So absent compelling evidence that .class selectors are problematic, I would say the onus is on the id id id team to make their case :) I have also found that there seems to be no way of overriding the class that is created when hitting HTML elements - it is hard coded in UiBinderWriter to look only in the Google classes for elements with TAG. Descending and fixing it for UiBinderWriter was relatively straight forward (even tho I had to put the replacement class in com.google...), but because all of the important methods are private in UiBinderGenerator, I had to replace that and copy the methods, which was triple yuk. Good to have the source though :-) I'm not entirely certain I understand the problem here -- is the issue that you want to use an element for which there's no Element subtype in the .dom package? We didn't go to great lengths to make this extensible, because the set of legal HTML DOM elements changes at a glacial pace. But if there's one we missed, please let us know! Cheers, joel. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder - ids vs classes and html element binding
On Thu, Aug 27, 2009 at 7:49 AM, Joel Webber j...@google.com wrote: On Thu, Aug 27, 2009 at 5:29 AM, Richard Vowles richard.vow...@gmail.comwrote: I wouldn't mind some convincing urls to backup this viewpoint if you have any :-) The entire rest of the team here is saying id id id, class bad, id good. Searching for html id brittle wasn't very enlightening :-) It's fairly easy to arrive at this conclusion from first principles. Element ids *must* be unique within a document. The fact that getElementById() can only return a single element makes this pretty clear and unavoidable (whether or not it was a good idea in [HT X]ML is another question altogether). If you have a .ui.xml with an id in it, you can *never* use more than one in an app at the same time. While there are sometimes cases where one is pretty sure this constraint will be satisfied, there's no way for UiBinder to know this. It also turns out that .class selectors aren't particularly different in performance from #id selectors. *descendant* selectors are pure evil, because they create an oft-unoptimizable case for the selector engine, but that's not what we're talking about here. So absent compelling evidence that .class selectors are problematic, I would say the onus is on the id id id team to make their case :) I have also found that there seems to be no way of overriding the class that is created when hitting HTML elements - it is hard coded in UiBinderWriter to look only in the Google classes for elements with TAG. Descending and fixing it for UiBinderWriter was relatively straight forward (even tho I had to put the replacement class in com.google...), but because all of the important methods are private in UiBinderGenerator, I had to replace that and copy the methods, which was triple yuk. Good to have the source though :-) I'm not entirely certain I understand the problem here -- is the issue that you want to use an element for which there's no Element subtype in the .dom package? We didn't go to great lengths to make this extensible, because the set of legal HTML DOM elements changes at a glacial pace. But if there's one we missed, please let us know! It's a fair point though, now that HTMLPanel allows you to set override its preferred div tag with any old thing. The lack of parallelism there is pretty arbitrary. Richard, would you mind filling a ticket on that issue? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
