[gwt-contrib] Re: uibinder/safehtml disagreement on xlink:href attribute
Well, three things: - There's an impedance mismatch between UiBinder (using XML with namespaces) and HTML. UiBinder has not been designed to output "namespaced HTML", and actually there's no such thing as "namespaced HTML" (SVG-in-HTML hardcodes the "xlink:href" name to translate to an "href" attribute in the XLink namespace in the InfoSet: https://html.spec.whatwg.org/multipage/syntax.html#adjust-foreign-attributes). To have UiBinder play well in those cases, it'd have to somehow follow the "InfoSet to HTML syntax" rules: https://html.spec.whatwg.org/multipage/syntax.html#serialising-html-fragments - UiBinder should probably converge to use jsilver's HtmlUtils.isAttributeUri and co. so we at least have the same rule everywhere. - JSilver should adjust to those special cases like "xhtml:href", and UiBinder should pass the appropriate name to JSilver (following the same "InfoSet to HTML syntax" mapping rules). That doesn't look like an big effort (though too late for 2.8 I'm afraid…) On Wednesday, November 18, 2015 at 3:49:03 PM UTC+1, Stephen Haberman wrote: > > I'm attempting to use icons in an svg file in a ui.xml file like: > > > > But with a variable, so: > > > > However, because of the xlink namespace (which the browser requires, > AFAICT), UiBinder and SafeHtml end up disagreeing on whether this is a > SafeUri-requiring attribute. > > E.g. here is the UiBinder logic, which ignores namespace because it uses > local name: > > > https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/uibinder/elementparsers/HtmlInterpreter.java#L48 > > And here is the SafeHtml logic, which does looks at namespace+attribute > due to the underlying jsilver implementation: > > > https://github.com/gwtproject/gwt/blob/master/user/src/com/google/gwt/safehtml/rebind/SafeHtmlTemplatesImplMethodCreator.java#L301 > > > https://code.google.com/p/jsilver/source/browse/trunk/src/com/google/streamhtmlparser/impl/HtmlParserImpl.java#237 > > So, it ends up failing because UiBinder generated SafeUri, but SafeHtml > says "this attribute shouldn't be a SafeUri, did you SafeHtml or String". > > I'm wondering how to make them agree...while in this scenario it is true > that xlink:href is a URI, so UiBinder was right, in theory there could be > other namespaces where that is not the case, and the heuristic of "any > attribute named href is a uri, regardless of namespace" could be wrong. > > Any great ideas? > > ...I suppose the other option is to just turn off safe html templates for > now. > > - Stephen > > > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/15c92aa1-5e1f-49f1-8997-2d60db6d6505%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
On Thursday, February 12, 2015 at 11:25:51 AM UTC+1, Thomas Broyer wrote: On Thursday, February 12, 2015 at 2:35:36 AM UTC+1, Ali Akhtar wrote: I have a maven layout, and the ui.xml file is in src/main/resources, in the same package as the Java class. So I don't think that's the case here. Also the file does get picked up, it just requires an SDM restart to pick up some of the changes. How do you launch SDM? If you're using the gwt-maven-plugin, it won't include src/main/resources (or other resource dirs) as resources could be filtered, and/or with inclusion/exclusion patterns and/or relocation. That means you have to run mvn process-resources to copy the resources to target/classes where they'll be picked up by GWT. Eclipse should do that automatically on file save IIRC. I had a similar problem with editing my webcomponents' html/css files which along with all other non-GWT files are located in src/main/webapp for my projects. When I tried changing Eclipse's output destination for the webapp sourcedir in the build-path dialog, it would loop and fail and eventually change it back on its own. Perhaps there's a way to configure eclipse properly, but I didn't find it and ended up writing a small C program (for Windows) to detect file-changes anywhere from a root directory and copy them over to the right place and that works like a charm. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9d405623-cab3-46d1-8ea3-8ba917145f60%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
On Thursday, February 12, 2015 at 2:35:36 AM UTC+1, Ali Akhtar wrote: I have a maven layout, and the ui.xml file is in src/main/resources, in the same package as the Java class. So I don't think that's the case here. Also the file does get picked up, it just requires an SDM restart to pick up some of the changes. How do you launch SDM? If you're using the gwt-maven-plugin, it won't include src/main/resources (or other resource dirs) as resources could be filtered, and/or with inclusion/exclusion patterns and/or relocation. That means you have to run mvn process-resources to copy the resources to target/classes where they'll be picked up by GWT. Eclipse should do that automatically on file save IIRC. Alternatively, you can put your ui.xml et al. in src/main/java. Maybe the gwt-maven-plugin could be enhanced to detect the common case where resources are neither filtered nor relocated and automatically add them to the DevMode/CodeServer classpath. Patches welcome. On Thu, Feb 12, 2015 at 3:52 AM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: In same cases, you can accidentally include of ui.xml files in your build that will make your regular compile work but SDM will not pick up the changes. This happens if the ui.xml file is in the classpath but not included as a resource in the gwt.xml file. I think if we notice that during compilation, we will print a warning about it. On Wed, Feb 11, 2015 at 4:12 AM, Ali Akhtar ali.rac...@gmail.com wrote: I'm using the snapshot build, so it might be a recent issue. I'm not sure if I could've done anything in my project to cause this, I just have a regular ui binder file / class. On Wed, Feb 11, 2015 at 4:50 PM, Jens jens.nehlme...@gmail.com wrote: We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com . To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc0e0f1e-fd91-40c5-82fc-d18d1f0debde%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
Thomas, As usual, you're right. I was using the maven plugin, and the resources weren't being updated. For the moment, I've just created a new run configuration in intellij for running process-resources , and when I get this error, I just run that config once, and it fixes the problem. Still, it would be a good idea for the mvn plugin to detect this, as you suggested. Thanks. On Thu, Feb 12, 2015 at 3:25 PM, Thomas Broyer t.bro...@gmail.com wrote: On Thursday, February 12, 2015 at 2:35:36 AM UTC+1, Ali Akhtar wrote: I have a maven layout, and the ui.xml file is in src/main/resources, in the same package as the Java class. So I don't think that's the case here. Also the file does get picked up, it just requires an SDM restart to pick up some of the changes. How do you launch SDM? If you're using the gwt-maven-plugin, it won't include src/main/resources (or other resource dirs) as resources could be filtered, and/or with inclusion/exclusion patterns and/or relocation. That means you have to run mvn process-resources to copy the resources to target/classes where they'll be picked up by GWT. Eclipse should do that automatically on file save IIRC. Alternatively, you can put your ui.xml et al. in src/main/java. Maybe the gwt-maven-plugin could be enhanced to detect the common case where resources are neither filtered nor relocated and automatically add them to the DevMode/CodeServer classpath. Patches welcome. On Thu, Feb 12, 2015 at 3:52 AM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: In same cases, you can accidentally include of ui.xml files in your build that will make your regular compile work but SDM will not pick up the changes. This happens if the ui.xml file is in the classpath but not included as a resource in the gwt.xml file. I think if we notice that during compilation, we will print a warning about it. On Wed, Feb 11, 2015 at 4:12 AM, Ali Akhtar ali.rac...@gmail.com wrote: I'm using the snapshot build, so it might be a recent issue. I'm not sure if I could've done anything in my project to cause this, I just have a regular ui binder file / class. On Wed, Feb 11, 2015 at 4:50 PM, Jens jens.nehlme...@gmail.com wrote: We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe. To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/google-web-toolkit-contributors/88b930b9-d875- 4d38-a8eb-c8ffda2d8243%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@ googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85- kgLSrxPOUTUM8NoEUg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe. To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/ msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_ vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
In same cases, you can accidentally include of ui.xml files in your build that will make your regular compile work but SDM will not pick up the changes. This happens if the ui.xml file is in the classpath but not included as a resource in the gwt.xml file. I think if we notice that during compilation, we will print a warning about it. On Wed, Feb 11, 2015 at 4:12 AM, Ali Akhtar ali.rac...@gmail.com wrote: I'm using the snapshot build, so it might be a recent issue. I'm not sure if I could've done anything in my project to cause this, I just have a regular ui binder file / class. On Wed, Feb 11, 2015 at 4:50 PM, Jens jens.nehlme...@gmail.com wrote: We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
I have a maven layout, and the ui.xml file is in src/main/resources, in the same package as the Java class. So I don't think that's the case here. Also the file does get picked up, it just requires an SDM restart to pick up some of the changes. On Thu, Feb 12, 2015 at 3:52 AM, 'Goktug Gokdogan' via GWT Contributors google-web-toolkit-contributors@googlegroups.com wrote: In same cases, you can accidentally include of ui.xml files in your build that will make your regular compile work but SDM will not pick up the changes. This happens if the ui.xml file is in the classpath but not included as a resource in the gwt.xml file. I think if we notice that during compilation, we will print a warning about it. On Wed, Feb 11, 2015 at 4:12 AM, Ali Akhtar ali.rac...@gmail.com wrote: I'm using the snapshot build, so it might be a recent issue. I'm not sure if I could've done anything in my project to cause this, I just have a regular ui binder file / class. On Wed, Feb 11, 2015 at 4:50 PM, Jens jens.nehlme...@gmail.com wrote: We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LTfZNq3%3DVMFFhE_vnSTmiWh3YvP9-nKFS2F7QSuHgQg%40mail.gmail.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbfvk4Ar0PrMwuzAJC39WJVVSXBLHDw6g%2Bu6tZs-zSXpyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
Update: Seems like this issue applies to all changes made to ui.xml files. If I have an existing foo.ui.xml file, and I made a change to it, such as adding the text 'foo' anywhere inside a HtmlPanel, reloading doesn't pick up the change. A full sdm restart is required. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/e403aeaa-c9c6-4191-a9ad-2bcfd5b296a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
I'm using the snapshot build, so it might be a recent issue. I'm not sure if I could've done anything in my project to cause this, I just have a regular ui binder file / class. On Wed, Feb 11, 2015 at 4:50 PM, Jens jens.nehlme...@gmail.com wrote: We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to a topic in the Google Groups GWT Contributors group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/K4_aFOc-RG4/unsubscribe . To unsubscribe from this group and all its topics, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAKiMtbcLP0s3gdfE-Uw3oEZfvTEZW85-kgLSrxPOUTUM8NoEUg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: UiBinder changes don't get picked up in SDM (trunk)
We are currently using a GWT trunk build from 5. Jan 2015 and don't see this issue. So either a recent commit causes that behavior or your project setup is broken. -- J. -- You received this message because you are subscribed to the Google Groups GWT Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/88b930b9-d875-4d38-a8eb-c8ffda2d8243%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[gwt-contrib] Re: UiBinder problem on WidgetBasedUi.ui.xml when building GWT from source
Thanks for your reply Thomas. Preparing a bug report for GPE. Bit puzzled
though cause according to
7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230
absolute
paths should start with a '/', whereas in this case it's
'com/google/gwt/uibinder/test/client/Menu.css' without the leading '/'.
On Friday, January 18, 2013 9:05:53 PM UTC+2, Thomas Broyer wrote:
I believe this is a bug in the Google Plugin for Eclipse; you can simply
ignore it (and/or report it in the GPE issue tracker).
Absolute paths weren't accepted in ui:style until recently in GWT: see
http://code.google.com/p/google-web-toolkit/issues/detail?id=7230
On Friday, January 18, 2013 6:18:50 PM UTC+1, n.gia...@gmail.com wrote:
Title says it all. I've set up an Eclipse workspace as explained
herehttp://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt.
After building the workspace I get this error:
Description Resource Path Location Type
CSS file com/google/gwt/uibinder/test/client/Menu.css is missing
WidgetBasedUi.ui.xml
/gwt-user/core/test/com/google/gwt/uibinder/test/client line 110 Google
Web Toolkit UiBinder Problem
*And this is the corresponding snippet in WidgetBasedUi.ui.xml*
ui:style field='myStyle' src='WidgetBasedUi.css
com/google/gwt/uibinder/test/client/Menu.css'
type='com.google.gwt.uibinder.test.client.WidgetBasedUi.Style'
.menuBar {
font-family: sans-serif;
}
/ui:style
When removing the package prefix from Menu.css, the problem goes away.
Any ideas why this is happening?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder problem on WidgetBasedUi.ui.xml when building GWT from source
On Saturday, January 19, 2013 8:57:59 PM UTC+1, n.gia...@gmail.com wrote: Thanks for your reply Thomas. Preparing a bug report for GPE. Bit puzzled though cause according to 7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230 absolute paths should start with a '/', whereas in this case it's 'com/google/gwt/uibinder/test/client/Menu.css' without the leading '/'. CssResource's @Source uses the value first as a relative path and then if necessary as an absolute path, the idea is to have the same behavior for ui:style (which does the same check before generating a @Source to have the error, if any, thrown closer to what the developer wrote: pointing at the ui:style, not the generated @Source) See the discussion in http://gwt-code-reviews.appspot.com/1660804 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder problem on WidgetBasedUi.ui.xml when building GWT from source
I believe this is a bug in the Google Plugin for Eclipse; you can simply
ignore it (and/or report it in the GPE issue tracker).
Absolute paths weren't accepted in ui:style until recently in GWT: see
http://code.google.com/p/google-web-toolkit/issues/detail?id=7230
On Friday, January 18, 2013 6:18:50 PM UTC+1, n.gia...@gmail.com wrote:
Title says it all. I've set up an Eclipse workspace as explained
herehttp://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/README.txt.
After building the workspace I get this error:
Description Resource Path Location Type
CSS file com/google/gwt/uibinder/test/client/Menu.css is missing
WidgetBasedUi.ui.xml
/gwt-user/core/test/com/google/gwt/uibinder/test/client line 110 Google
Web Toolkit UiBinder Problem
*And this is the corresponding snippet in WidgetBasedUi.ui.xml*
ui:style field='myStyle' src='WidgetBasedUi.css
com/google/gwt/uibinder/test/client/Menu.css'
type='com.google.gwt.uibinder.test.client.WidgetBasedUi.Style'
.menuBar {
font-family: sans-serif;
}
/ui:style
When removing the package prefix from Menu.css, the problem goes away. Any
ideas why this is happening?
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder - register custom ElementParser (issue1454804)
As soon as we have done that, we can't make changes to UiBinderWriter and all the other classes the parsers actually talk to, nor can we make sweeping changes to the code they generate. If the problem is retrofitting widgets you don't own, would a non-annotation alternative to UiChild get the job done? Perhaps a config file, perhaps a builder of some kind? On Thu, Jun 9, 2011 at 8:16 PM, jus...@jhickman.com wrote: Unfortunately @UiChild doesn't handle the flexibility I need, especially in cases where you are wanting to write parsers for a 3rd party widget library and do not have the ability to modify the source to include annotations. Is there any way of convincing you to make it more extendable? Even without providing an official mechanism for registering ElementParsers, doing small things such as the following would do wonders: * In UiBinderGenerator, extract the instantiation of the UiBinderWriter into a protected method so that developers can subclass the UiBinderGenerator and construct their own subclass of UiBinderWriter * In UiBinderWriter, make addElementParser() protected rather than private. http://gwt-code-reviews.**appspot.com/1454804/http://gwt-code-reviews.appspot.com/1454804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder - register custom ElementParser (issue1454804)
On Fri, Jun 10, 2011 at 7:22 PM, Ray Ryan rj...@google.com wrote: As soon as we have done that, we can't make changes to UiBinderWriter and all the other classes the parsers actually talk to, nor can we make sweeping changes to the code they generate. If the problem is retrofitting widgets you don't own, would a non-annotation alternative to UiChild get the job done? Perhaps a config file, perhaps a builder of some kind? Particularly as you should be able to make an IsWidget class with @UiChild methods as a lightweight wrapper around the widget, kind of a builder (similar to PotentialElement but at a Widget level). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder - register custom ElementParser (issue1454804)
Exactly. And I was thinking we could introduce something like BuildsWidgetW extends IsWidget extends IsWidget. UiBinder could learn to honor the setters and such of the underlying widget as well as the BuildsWidget. On Fri, Jun 10, 2011 at 10:41 AM, Thomas Broyer t.bro...@gmail.com wrote: On Fri, Jun 10, 2011 at 7:22 PM, Ray Ryan rj...@google.com wrote: As soon as we have done that, we can't make changes to UiBinderWriter and all the other classes the parsers actually talk to, nor can we make sweeping changes to the code they generate. If the problem is retrofitting widgets you don't own, would a non-annotation alternative to UiChild get the job done? Perhaps a config file, perhaps a builder of some kind? Particularly as you should be able to make an IsWidget class with @UiChild methods as a lightweight wrapper around the widget, kind of a builder (similar to PotentialElement but at a Widget level). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder - register custom ElementParser (issue1454804)
[+cc google-web-toolkit-contributors]
I don't know why I've been added as a reviewer here, but here are a few
comments. (beware, I'm not in the GWT Team)
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/elementparsers/AbsolutePanelParser.java
File
user/src/com/google/gwt/uibinder/elementparsers/AbsolutePanelParser.java
(right):
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/elementparsers/AbsolutePanelParser.java#newcode26
user/src/com/google/gwt/uibinder/elementparsers/AbsolutePanelParser.java:26:
* Parses {@link com.google.gwt.user.client.ui.AbsolutePanel
AbsolutePanel}
FQCN can be replaced with simple name now that there's an import for
AbsolutePanel.
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/ParseForType.java
File user/src/com/google/gwt/uibinder/rebind/ParseForType.java (right):
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/ParseForType.java#newcode13
user/src/com/google/gwt/uibinder/rebind/ParseForType.java:13: * Mark an
ElementParser to indicate the type to parse
Mark*s* an ElementParser…
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/ParseForType.java#newcode18
user/src/com/google/gwt/uibinder/rebind/ParseForType.java:18: public
@interface ParseForType {
Shouldn't it be Parse*r*ForType?
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
File user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java
(right):
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java#newcode1059
user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java:1059: throw
new RuntimeException(Unable to get UiBinder.elementParsers
configuration property, e);
Shouldn't it be an UnableToCompleteException?
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java#newcode1068
user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java:1068:
logger.warn(Declared ElementParser '%s' cannot be found. Skipping.,
propertyValue);
Should be a fatal error.
http://gwt-code-reviews.appspot.com/1454804/diff/7002/user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java#newcode1074
user/src/com/google/gwt/uibinder/rebind/UiBinderWriter.java:1074:
logger.warn(ElementParser '%s' exists, but is not annotated with %s.
Skipping., propertyValue,
Should be a fatal error.
http://gwt-code-reviews.appspot.com/1454804/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder - register custom ElementParser (issue1454804)
Justin, I really appreciate the contribution, and this is a nice mechanism. But the reason we haven't done something like this already is that we don't want to lock down the api to the parsers. In fact at the moment it's in a lot of flux as we add features to support Cell authors, and as we try to land the IsRenderable mechanism. If we had to maintain backward compatibility for third party parsers, innovation on UiBinder would be over. My hope was that the introduction of the @UiChild annotation had eliminated most of the need for writing custom parsers. Are there particular itches you can't scratch that way? Maybe we can find another way to address those. http://gwt-code-reviews.appspot.com/1454804/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
Very nice, as always.
http://gwt-code-reviews.appspot.com/1233803/diff/1/3
File user/src/com/google/gwt/uibinder/elementparsers/TreeItemParser.java
(right):
http://gwt-code-reviews.appspot.com/1233803/diff/1/3#newcode39
user/src/com/google/gwt/uibinder/elementparsers/TreeItemParser.java:39:
for (XMLElement child : elem.consumeChildElements()) {
How about introducing a HasTreeItems interface to be implemented by both
Tree and TreeItem, and combine these two parsers into a single
HasTreeItems parser? They're basically identical, right?
http://gwt-code-reviews.appspot.com/1233803/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
Taking this a bit further, if we're going to be playing with interfaces we
might as well go the whole nine yards:
interface IsTreeItem {
TreeItem asTreeItem();
}
interface HasTreeItems {
void addItem(IsTreeItem);
void addItem(Widget);
void addItem(SafeHtml);
/* No addItem(String), it's unsafe */
void removeItem(TreeItem);
void removeItem(IsTreeItem);
void removeItems();
}
class TreeItem implements IsTreeItem, HasTreeItems {
}
class Tree implements HasTreeItems {
}
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
On Wed, Jan 5, 2011 at 12:47 PM, Ray Ryan rj...@google.com wrote:
Taking this a bit further, if we're going to be playing with interfaces we
might as well go the whole nine yards:
interface IsTreeItem {
TreeItem asTreeItem();
}
interface HasTreeItems {
void addItem(IsTreeItem);
void addItem(Widget);
void addItem(SafeHtml);
/* No addItem(String), it's unsafe */
Taking a string is fine, but it should be interpreted as plain text not
HTML..
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
There is an existing overload that accepts a string and interprets it as
HTML, so that's not an option. And asking Konstantin to add a new
addItemText(String) method seems too far outside the scope of this patch.
On Wed, Jan 5, 2011 at 10:02 AM, John Tamplin j...@google.com wrote:
On Wed, Jan 5, 2011 at 12:47 PM, Ray Ryan rj...@google.com wrote:
Taking this a bit further, if we're going to be playing with interfaces we
might as well go the whole nine yards:
interface IsTreeItem {
TreeItem asTreeItem();
}
interface HasTreeItems {
void addItem(IsTreeItem);
void addItem(Widget);
void addItem(SafeHtml);
/* No addItem(String), it's unsafe */
Taking a string is fine, but it should be interpreted as plain text not
HTML..
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Support for TreeItems. (issue1233803)
On Wed, Jan 5, 2011 at 1:09 PM, Ray Ryan rj...@google.com wrote: There is an existing overload that accepts a string and interprets it as HTML, so that's not an option. And asking Konstantin to add a new addItemText(String) method seems too far outside the scope of this patch. Ok, we can always add it to the interface later after we remove the deprecated method that takes HTML. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Design time tweaks for @UiField(provided) and @UiFactory (issue1077802)
http://gwt-code-reviews.appspot.com/1077802/diff/1/3
File user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java
(right):
http://gwt-code-reviews.appspot.com/1077802/diff/1/3#newcode52
user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java:52:
w.write( void handle(String path, Object object););
OK
Hapax does not look as active, last commit was about 1-2 years ago. No
downloads.
http://gwt-code-reviews.appspot.com/1077802/diff/1/3#newcode79
user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java:79:
({0}) dtObjectHandler.provideFactory({0}.class, \{1}\, new Object[]
'{'{2}'}'),
Only reason is that Eclipse suggests to use MessageFormat and no
String.format() option. Fixed.
http://gwt-code-reviews.appspot.com/1077802/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Using negative values in LayoutPane layer.
We shouldn't get hung up on the fact that LengthAttributeParser is misnamed (ScalarAttributeParser?). Negative support sounds like the right thing to do. Element parsers that are concerned about negative values could do their own check for that, although it could be tricky to do correctly. Did you just volunteer? Yes, this looks as easy change. See http://gwt-code-reviews.appspot.com/1094801/show On Tue, Nov 9, 2010 at 7:41 AM, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: One of the users of GWT Designer found that code like this causes rendering failure. g:layer left=-34px width=109px top=70px height=20px g:CheckBox text=New CheckBox/ /g:layer As you can see, left attribute contains negative value. In Java version such value is not problem for left, right, top and bottom. As I can see, problem is in LengthAttributeParser which does not recognize negative values. I'm not sure what to do - we could add minus support, but is this correct ideologically? Negative _length_ is not valid, but negative _position_ is fine. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Using negative values in LayoutPanel. (issue1094801)
LGTM Nice! Thanks. http://gwt-code-reviews.appspot.com/1094801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Design time tweaks for @UiField(provided) and @UiFactory (issue1077802)
One nit, one point of curiosity. I can submit this as soon as you're
ready with a follow up.
http://gwt-code-reviews.appspot.com/1077802/diff/1/3
File user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java
(right):
http://gwt-code-reviews.appspot.com/1077802/diff/1/3#newcode52
user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java:52:
w.write( void handle(String path, Object object););
Just noticed all these hard coded leading spaces. Please use
IndentedWriter#indent and #outdent instead.
Next time I write a code generator, I'm going to use
hapax.http://code.google.com/p/hapax/
http://gwt-code-reviews.appspot.com/1077802/diff/1/3#newcode79
user/src/com/google/gwt/uibinder/rebind/DesignTimeUtilsImpl.java:79:
({0}) dtObjectHandler.provideFactory({0}.class, \{1}\, new Object[]
'{'{2}'}'),
Any particular reason to use MessageFormat rather than String.format
like we usually do?
http://gwt-code-reviews.appspot.com/1077802/show
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Design time tweaks for @UiField and @UiHandler (issue834802)
LGTM I'll submit it this weekend On 2010/09/07 19:02:03, Konstantin.Scheglov wrote: http://gwt-code-reviews.appspot.com/834802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Design time tweaks for @UiField and @UiHandler (issue834802)
r8814 http://gwt-code-reviews.appspot.com/834802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Uibinder parser api
On Sep 9, 1:45 pm, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: If anyone wants to submit a patch to make it possible to subclass UiBinderGenerator and tweak its parsers that way, s.t. you can provide an alternative replace-with rule for your custom subclass, I'd be in favor of that. Presuming Joel doesn't shoot me down. Hm... Replacing UiBinderGenerator means that at same time only one replacement can be used. So, for example if I use some widgets toolkit and it provides generator for its widgets, then I can not use generator of second toolkit. If you weren't dumbing down to Java 5, I'd suggest using java.util.ServiceLoader to simply load plugins from the classpath: http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html But sure it could be done with a new element in gwt.xml module descriptors. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Uibinder parser api
It's not about the lack of a plugin mechanism, it's about discomfort with an api that requires people to emit lines of java too much, and lack of time to clean it up. On Thu, Sep 9, 2010 at 9:22 AM, Thomas Broyer t.bro...@gmail.com wrote: On Sep 9, 1:45 pm, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: If anyone wants to submit a patch to make it possible to subclass UiBinderGenerator and tweak its parsers that way, s.t. you can provide an alternative replace-with rule for your custom subclass, I'd be in favor of that. Presuming Joel doesn't shoot me down. Hm... Replacing UiBinderGenerator means that at same time only one replacement can be used. So, for example if I use some widgets toolkit and it provides generator for its widgets, then I can not use generator of second toolkit. If you weren't dumbing down to Java 5, I'd suggest using java.util.ServiceLoader to simply load plugins from the classpath: http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html But sure it could be done with a new element in gwt.xml module descriptors. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Uibinder parser api
The 2.1 release branch will be cut from trunk. Trunk does not include a public api to add new parsers to UiBinder. If anyone wants to submit a patch to make it possible to subclass UiBinderGenerator and tweak its parsers that way, s.t. you can provide an alternative replace-with rule for your custom subclass, I'd be in favor of that. Presuming Joel doesn't shoot me down. rjrjr On Mon, Sep 6, 2010 at 3:54 AM, T tomek.maty...@gmail.com wrote: 2.1 GA is not going to be built from trunk? On Sep 3, 3:38 pm, Ray Ryan rj...@google.com wrote: We'd like it to, but we haven't set a date. On Sep 3, 2010 12:15 AM, Johan Rydberg johan.rydb...@edgeware.tv wrote: On 9/1/10 10:01 PM, Ray Ryan wrote: Sorry, still not public. However, we're landing a patch that will eliminate a lot of the need for it: OK. But will it become public at some point in time? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Design time tweaks for @UiField (issue792801)
I don't see this patch in SVN yet. Was it committed? http://gwt-code-reviews.appspot.com/792801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Parser for AbsolutePanel. (issue715802)
Thanks! Looks great, just a couple of nits. http://gwt-code-reviews.appspot.com/715802/diff/1/3 File user/test/com/google/gwt/uibinder/elementparsers/AbsolutePanelParserTest.java (right): http://gwt-code-reviews.appspot.com/715802/diff/1/3#newcode37 user/test/com/google/gwt/uibinder/elementparsers/AbsolutePanelParserTest.java:37: /// I didn't say anything in previous CLs, but we really don't do this type of method grouping. In most of our code we follow alphabetical sorting, for good or for ill, and folks frequently auto sort tests too (though that's not strictly required by our style guide). Would you mind dropping the groups? http://gwt-code-reviews.appspot.com/715802/diff/1/3#newcode114 user/test/com/google/gwt/uibinder/elementparsers/AbsolutePanelParserTest.java:114: b.append( g:position left='1' top='2'); Could you make this g:child? And could you test having several children? http://gwt-code-reviews.appspot.com/715802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Parser for AbsolutePanel. (issue715802)
1. Should I remove groups only from this AbsolutePanelParser test or from DesignTimeUtilsTest too? 2. I agree to use sorting methods with tests, however as with formatting I have one problem. I would like to do this automatically, i.e. just configure this in Save Actions. And this means that this would be applied to any file which I touch. For formatter I can convince myself that this is not bad, because formatting rules are described in configuring guide - so any code which was re-formatted was not fully correct. But if for tests there are not such strong rule, this means that I would need to to turn off save actions when I touch existing tests. Well, if I have to turn it on/off, I can do this. So, how to you want to have tests - sorted (with same rules as code) or not? Don't give me choice please, my preferences are different than required for GWT, so I have to adopt to them in any case, and it is better to follow best rules. :-) 3. I use position as more-less similar word to layer in LayoutPanel. But if you will confirm that child is better, I will use it. http://gwt-code-reviews.appspot.com/715802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Parser for AbsolutePanel. (issue715802)
On Tue, Jul 27, 2010 at 1:38 PM, konstantin.scheg...@gmail.com wrote: 1. Should I remove groups only from this AbsolutePanelParser test or from DesignTimeUtilsTest too? I guess you might as well do DesignTimeUtilsTest at the same time. Thanks. 2. I agree to use sorting methods with tests, however as with formatting I have one problem. I would like to do this automatically, i.e. just configure this in Save Actions. And this means that this would be applied to any file which I touch. For formatter I can convince myself that this is not bad, because formatting rules are described in configuring guide - so any code which was re-formatted was not fully correct. But if for tests there are not such strong rule, this means that I would need to to turn off save actions when I touch existing tests. Well, if I have to turn it on/off, I can do this. So, how to you want to have tests - sorted (with same rules as code) or not? Don't give me choice please, my preferences are different than required for GWT, so I have to adopt to them in any case, and it is better to follow best rules. :-) Sorting on save definitely will munge a lot of existing tests, including the big UiBinder test. Formatting on save is safer, but not guaranteed to do no harm. Why don't you just remove the banner comments and we'll call it even. 3. I use position as more-less similar word to layer in LayoutPanel. But if you will confirm that child is better, I will use it. Layer sounds less like an attribute of the view that is being added and more like an object that wraps it. Compare it with g:tab in TabLayoutPanel. Let's go with child. http://gwt-code-reviews.appspot.com/715802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
Any thoughts about new version of patch? I have AbsolutePanel support and custom MenuItem and separatorshttp://code.google.com/p/google-web-toolkit/issues/detail?id=4883support patches in the queue. But I can not post them until applying changes of this patch. Remember attributes values in XMLElement http://gwt-code-reviews.appspot.com/693801/show -- Konstantin Scheglov, Instantiations, Inc. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
r8384 On Fri, Jul 16, 2010 at 11:59 AM, Ray Ryan rj...@google.com wrote: Yup, the svn mirror broke. We're fixing it right now. On Thu, Jul 15, 2010 at 7:48 PM, Ray Ryan rj...@google.com wrote: It was committed, and should have hit svn by now. I can't check that system right now, but can look in the morning if it's still wonky. On Jul 15, 2010 5:41 PM, Konstantin Scheglov konstantin.scheg...@gmail.com wrote: The most natural spot to hook in would be com.google.gwt.uibinder.rebind.XMLElement.consumeAttributeWithDefault(String, String, JType[]), which I believe is the only way to get the value of an attribute from the parsed XML. Aha! Yes, using XMLElement.consumeX() methods also will work and even better, because of support all parsers, even custom ones (if/when they will be added into UiBinder). I've implemented such approach and it seems to work. So, I can post new patch (tomorrow). I'm only now sure how to do this. Should I wait to commit of previous patch (I don't see it yet in SVN)? Or you have not committed it yet? Should I post new patch as new patch set in same issue, or open new one? On Thu, Jul 15, 2010 at 10:29 AM, Ray Ryan rj...@google.com wrote: Konstantin, I just submitted this but I'm starting to wonder about it. There are lots of custom parsers that consume lots of attributes (e.g. the various layout panel parsers). Why don't they need to call putAttribute explicitly the way CellPanelParser did? If they do, and leaving them out was an oversight, we need a more general mechanism that will just keep working as new parsers are written, or this kind of mistake will plague us. On Thu, Jul 15, 2010 at 8:49 AM, rj...@google.com wrote: LGTM Thanks for the interface on UiBinderWriter, should have done that a long time ago. I'll probably tweak it's name while submitting. http://gwt-code-reviews.appspot.com/693801/show -- Konstantin Scheglov, Instantiations, Inc. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
Konstantin, I just submitted this but I'm starting to wonder about it. There are lots of custom parsers that consume lots of attributes (e.g. the various layout panel parsers). Why don't they need to call putAttribute explicitly the way CellPanelParser did? If they do, and leaving them out was an oversight, we need a more general mechanism that will just keep working as new parsers are written, or this kind of mistake will plague us. On Thu, Jul 15, 2010 at 8:49 AM, rj...@google.com wrote: LGTM Thanks for the interface on UiBinderWriter, should have done that a long time ago. I'll probably tweak it's name while submitting. http://gwt-code-reviews.appspot.com/693801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
The most natural spot to hook in would be com.google.gwt.uibinder.rebind.XMLElement.consumeAttributeWithDefault(String, String, JType[]), which I believe is the only way to get the value of an attribute from the parsed XML. On Thu, Jul 15, 2010 at 10:29 AM, Ray Ryan rj...@google.com wrote: Konstantin, I just submitted this but I'm starting to wonder about it. There are lots of custom parsers that consume lots of attributes (e.g. the various layout panel parsers). Why don't they need to call putAttribute explicitly the way CellPanelParser did? If they do, and leaving them out was an oversight, we need a more general mechanism that will just keep working as new parsers are written, or this kind of mistake will plague us. On Thu, Jul 15, 2010 at 8:49 AM, rj...@google.com wrote: LGTM Thanks for the interface on UiBinderWriter, should have done that a long time ago. I'll probably tweak it's name while submitting. http://gwt-code-reviews.appspot.com/693801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
The most natural spot to hook in would be com.google.gwt.uibinder.rebind.XMLElement.consumeAttributeWithDefault(String, String, JType[]), which I believe is the only way to get the value of an attribute from the parsed XML. Aha! Yes, using XMLElement.consumeX() methods also will work and even better, because of support all parsers, even custom ones (if/when they will be added into UiBinder). I've implemented such approach and it seems to work. So, I can post new patch (tomorrow). I'm only now sure how to do this. Should I wait to commit of previous patch (I don't see it yet in SVN)? Or you have not committed it yet? Should I post new patch as new patch set in same issue, or open new one? On Thu, Jul 15, 2010 at 10:29 AM, Ray Ryan rj...@google.com wrote: Konstantin, I just submitted this but I'm starting to wonder about it. There are lots of custom parsers that consume lots of attributes (e.g. the various layout panel parsers). Why don't they need to call putAttribute explicitly the way CellPanelParser did? If they do, and leaving them out was an oversight, we need a more general mechanism that will just keep working as new parsers are written, or this kind of mistake will plague us. On Thu, Jul 15, 2010 at 8:49 AM, rj...@google.com wrote: LGTM Thanks for the interface on UiBinderWriter, should have done that a long time ago. I'll probably tweak it's name while submitting. http://gwt-code-reviews.appspot.com/693801/show -- Konstantin Scheglov, Instantiations, Inc. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer (issue693801)
It was committed, and should have hit svn by now. I can't check that system right now, but can look in the morning if it's still wonky. On Jul 15, 2010 5:41 PM, Konstantin Scheglov konstantin.scheg...@gmail.com wrote: The most natural spot to hook in would be com.google.gwt.uibinder.rebind.XMLElement.consumeAttributeWithDefault(String, String, JType[]), which I believe is the only way to get the value of an attribute from the parsed XML. Aha! Yes, using XMLElement.consumeX() methods also will work and even better, because of support all parsers, even custom ones (if/when they will be added into UiBinder). I've implemented such approach and it seems to work. So, I can post new patch (tomorrow). I'm only now sure how to do this. Should I wait to commit of previous patch (I don't see it yet in SVN)? Or you have not committed it yet? Should I post new patch as new patch set in same issue, or open new one? On Thu, Jul 15, 2010 at 10:29 AM, Ray Ryan rj...@google.com wrote: Konstantin, I just submitted this but I'm starting to wonder about it. There are lots of custom parsers that consume lots of attributes (e.g. the various layout panel parsers). Why don't they need to call putAttribute explicitly the way CellPanelParser did? If they do, and leaving them out was an oversight, we need a more general mechanism that will just keep working as new parsers are written, or this kind of mistake will plague us. On Thu, Jul 15, 2010 at 8:49 AM, rj...@google.com wrote: LGTM Thanks for the interface on UiBinderWriter, should have done that a long time ago. I'll probably tweak it's name while submitting. http://gwt-code-reviews.appspot.com/693801/show -- Konstantin Scheglov, Instantiations, Inc. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder tweaks for GWT Designer
So... I don't understand what to do now. Should I prepare patch? Would be sad to miss GWT 2.1 release. I believe that UiBinder support in GWT Designer will be ready at the time when GWT 2.1 will be actual version, so would be good to allow them play nicely with each other. Why do you need this notice before the set calls? We need default values for properties. This allows us to remove attribute (or method invocation in case of Java version of GWTD) when user tries to set for property same value as default. Easiest example - flipping enabled between true/false. Default value is true, so only enabled=false is written into XML. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Parser for TextAlignConstant (issue612803)
@rjrjr: What say ye? Have you considered doing something like this before, and perhaps found a way to generalize it such that we don't have to create a separate attribute parser for every enum? Le 22 juin 2010 07:14, konstantin.scheg...@gmail.com a écrit : Reviewers: jgw, Description: It uses friendly names. I will post patch with adding support for names like this for horizontal/vertical alignments (in addition, not replace to keep compatibility with existing code) later. Please review this at http://gwt-code-reviews.appspot.com/612803/show Affected files: user/src/com/google/gwt/uibinder/attributeparsers/AttributeParsers.java user/src/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser.java user/test/com/google/gwt/uibinder/UiBinderJreSuite.java user/test/com/google/gwt/uibinder/attributeparsers/TextAlignConstantParser_Test.java user/test/com/google/gwt/uibinder/test/UiJavaResources.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: UiBinder. Code style for constant parsers.
Le 22 juin 2010 07:03, Konstantin.Scheglov konstantin.scheg...@gmail.com a écrit : Pretty much everything we've done so far has been limited to automatically exposing the Java-level APIs in all their ugliness. The h/v alignment values are implemented somewhat manually, but for things like enums I really like the idea that they can be exposed completely automatically. On the other hand, it would be nice to have prettier names. Perhaps we could find some sort of convention for exposing prettier names for [pseudo-]enums. What about a shortName() method on the enum itself? Hm... Yes, I think that it is possible to create some generic parser for enum-like constants. However because they are not real enums, following things come to mind: 1. During registration in AttributeParsers we will need to pass list of values; 2. To check for shortName() using reflection; 3. To test that each such constant parser instance works correctly, I would write special ui.xml file. Also one more thing worries me. Do you think that it is OK to add into GWT classes on this level information which is used only by some presentation of GWT? I mean that parsing ui.xml files is part of UiBinder, so it should be problem of UiBinder how to parse it. It *does* seem a little odd to have to add a UiBinder-specific short name to every enum (or enum-alike) used as a widget property (especially if they somehow end up in the compiled output). On the other hand, it would also kind of suck to have to put them in a completely separate place, which most widget authors would simply forget to do. On second thought, maybe we can actually get away with just convention. Most enums (e.g., Style.Unit) have names that are upper-case by convention, but we could allow UiBinder to specify them in a case-insensitive manner without ambiguity. That would leave only a handful of special cases (like the TextAlignmentParser patch you just sent). @rjrjr, konstantin: How does that sound to you both? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Code style for constant parsers.
Pretty much everything we've done so far has been limited to automatically exposing the Java-level APIs in all their ugliness. The h/v alignment values are implemented somewhat manually, but for things like enums I really like the idea that they can be exposed completely automatically. On the other hand, it would be nice to have prettier names. Perhaps we could find some sort of convention for exposing prettier names for [pseudo-]enums. What about a shortName() method on the enum itself? Hm... Yes, I think that it is possible to create some generic parser for enum-like constants. However because they are not real enums, following things come to mind: 1. During registration in AttributeParsers we will need to pass list of values; 2. To check for shortName() using reflection; 3. To test that each such constant parser instance works correctly, I would write special ui.xml file. Also one more thing worries me. Do you think that it is OK to add into GWT classes on this level information which is used only by some presentation of GWT? I mean that parsing ui.xml files is part of UiBinder, so it should be problem of UiBinder how to parse it. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder. Add tests for horizontal/vertical alignment parsers. (issue633801)
On 2010/06/17 08:52:37, Konstantin.Scheglov wrote: Thanks, LGTM. Submitted at r8281. http://gwt-code-reviews.appspot.com/633801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: uibinder : how to add a gwt:Button to html fragment ?
Weird. Can you send a sample?
One other thing to consider -- you haven't by any chance attached the widget
to the document body directly, like this, have you?
Document.get().getBody().appendChild(myWidget.getElement());
I know it sounds a bit strange, but this pops up fairly often. It will cause
events to break because the widgets all see themselves as unattached, and
thus never hook up their event handlers.
On Tue, Dec 22, 2009 at 2:46 AM, nicolas.deloof nicolas.del...@gmail.comwrote:
You're right, this works fine
just still can't have handlers working with my button, either using
@UiHandler( subscribe ) or a programmatic subscribe.addClickHandler
(...)
strange ... any suggestion to debug this ?
On 21 déc, 16:03, Joel Webber j...@google.com wrote:
To be precise, you don't actually need the g:HTML in this example. It
could be simply:
g:HTMLPanel tag=li styleName={style.event}
div
... static HTML code ...
g:ButtonYou can do this too/g:Button
/div
g:Button
ui:field=subscribe styleName={style.button}Inscription/g:Button
/g:HTMLPanel
The point of the HTMLPanel/Parser is that it allows you to mix static
HTML
and widgets more or less arbitrarily. We've also seen that many designs
can
end up with a lot fewer unnecessary widgets this way.
On Mon, Dec 21, 2009 at 3:34 AM, nicolas.deloof
nicolas.del...@gmail.comwrote:
Do you suggest that extending Widget woul allow to mix HTML and g:*
tags in the ui.xml file as I did first ? If I understand well what
happens in the Deferred binding any g:* is converted to gwt API
calls to assmble widgets and pannel together, and static HTML have to
be placed into g:HTML elements, isn't it ?
Anyway it would be cool to be able to mix pure HTML and g:*
component, something similar to Apache Wicket inside GWT :)
I fixed my widget using this layout :
g:HTMLPanel tag=li styleName={style.event}
g:HTML
... static HTML code ...
/g:HTML
g:Button ui:field=subscribe
styleName={style.button}Inscription/g:Button
/g:HTMLPanel
With @UiField Button subscribe;
the @UiHandler( subscribe ) public void handleClick( ClickEvent
e ) doesn't work anyway. Just not getting into code when the button is
clicked. Have to investigate more on that.
I tried to extend Widget as you suggested but makes no change.
Nicolas
On 20 déc, 21:34, Ray Ryan rj...@google.com wrote:
EventWidget must extend Widget, and it will have to be placed in a
panel
whose ultimate ancestor is either a RootPanel or a RootLayoutPanel
On Mon, Dec 21, 2009 at 5:24 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
Hi
I've migrated some nice HTML/CSS code to uibinder, and would like
now
to
listen to clickEvents on the button present in this HTML
fragment.
according to
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiBin..
.,
I need to use a gwt:Button as replacement for the html element to
support
GWT event handlers. I tried to use it as is, to wrap all my bloc
inside
gwt:HTML and other ideas, but allways fail with some
deferedBinding
errors
Any suggestion ?
Here is my widget ui.xml :
ui:UiBinder xmlns:ui=urn:ui:com.google.gwt.uibinder
xmlns:g=urn:import:com.google.gwt.user.client.ui
ui:style
...
/ui:style
li class={style.event}
... (some nice HTML code)
button ui:field=subscribe
class={style.button}Inscription/button
/li
/ui:UiBinder
and java :
public class EventWidget
extends UIObject
{
interface MyUiBinder
extends UiBinderLIElement, EventWidget
{
}
@UiField
//ButtonElement subscribe;
Button subscribe;
@UiHandler( subscribe )
public void handleClick( ClickEvent e )
{
...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: uibinder : how to add a gwt:Button to html fragment ?
code is opensource ;)
http://juggers.googlecode.com/svn/trunk
add log_level=DEBUG to URL string to enable gwt-log,
clicking on the [inscription] button has no effect. A popup was
expected, and a log tries to trace the handler method
On 22 déc, 14:34, Joel Webber j...@google.com wrote:
Weird. Can you send a sample?
One other thing to consider -- you haven't by any chance attached the widget
to the document body directly, like this, have you?
Document.get().getBody().appendChild(myWidget.getElement());
I know it sounds a bit strange, but this pops up fairly often. It will cause
events to break because the widgets all see themselves as unattached, and
thus never hook up their event handlers.
On Tue, Dec 22, 2009 at 2:46 AM, nicolas.deloof
nicolas.del...@gmail.comwrote:
You're right, this works fine
just still can't have handlers working with my button, either using
@UiHandler( subscribe ) or a programmatic subscribe.addClickHandler
(...)
strange ... any suggestion to debug this ?
On 21 déc, 16:03, Joel Webber j...@google.com wrote:
To be precise, you don't actually need the g:HTML in this example. It
could be simply:
g:HTMLPanel tag=li styleName={style.event}
div
... static HTML code ...
g:ButtonYou can do this too/g:Button
/div
g:Button
ui:field=subscribe styleName={style.button}Inscription/g:Button
/g:HTMLPanel
The point of the HTMLPanel/Parser is that it allows you to mix static
HTML
and widgets more or less arbitrarily. We've also seen that many designs
can
end up with a lot fewer unnecessary widgets this way.
On Mon, Dec 21, 2009 at 3:34 AM, nicolas.deloof
nicolas.del...@gmail.comwrote:
Do you suggest that extending Widget woul allow to mix HTML and g:*
tags in the ui.xml file as I did first ? If I understand well what
happens in the Deferred binding any g:* is converted to gwt API
calls to assmble widgets and pannel together, and static HTML have to
be placed into g:HTML elements, isn't it ?
Anyway it would be cool to be able to mix pure HTML and g:*
component, something similar to Apache Wicket inside GWT :)
I fixed my widget using this layout :
g:HTMLPanel tag=li styleName={style.event}
g:HTML
... static HTML code ...
/g:HTML
g:Button ui:field=subscribe
styleName={style.button}Inscription/g:Button
/g:HTMLPanel
With @UiField Button subscribe;
the �...@uihandler( subscribe ) public void handleClick( ClickEvent
e ) doesn't work anyway. Just not getting into code when the button is
clicked. Have to investigate more on that.
I tried to extend Widget as you suggested but makes no change.
Nicolas
On 20 déc, 21:34, Ray Ryan rj...@google.com wrote:
EventWidget must extend Widget, and it will have to be placed in a
panel
whose ultimate ancestor is either a RootPanel or a RootLayoutPanel
On Mon, Dec 21, 2009 at 5:24 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
Hi
I've migrated some nice HTML/CSS code to uibinder, and would like
now
to
listen to clickEvents on the button present in this HTML
fragment.
according to
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiBin..
.,
I need to use a gwt:Button as replacement for the html element to
support
GWT event handlers. I tried to use it as is, to wrap all my bloc
inside
gwt:HTML and other ideas, but allways fail with some
deferedBinding
errors
Any suggestion ?
Here is my widget ui.xml :
ui:UiBinder xmlns:ui=urn:ui:com.google.gwt.uibinder
xmlns:g=urn:import:com.google.gwt.user.client.ui
ui:style
...
/ui:style
li class={style.event}
... (some nice HTML code)
button ui:field=subscribe
class={style.button}Inscription/button
/li
/ui:UiBinder
and java :
public class EventWidget
extends UIObject
{
interface MyUiBinder
extends UiBinderLIElement, EventWidget
{
}
@UiField
// ButtonElement subscribe;
Button subscribe;
@UiHandler( subscribe )
public void handleClick( ClickEvent e )
{
...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: uibinder : how to add a gwt:Button to html fragment ?
To be precise, you don't actually need the g:HTML in this example. It
could be simply:
g:HTMLPanel tag=li styleName={style.event}
div
... static HTML code ...
g:ButtonYou can do this too/g:Button
/div
g:Button
ui:field=subscribe styleName={style.button}Inscription/g:Button
/g:HTMLPanel
The point of the HTMLPanel/Parser is that it allows you to mix static HTML
and widgets more or less arbitrarily. We've also seen that many designs can
end up with a lot fewer unnecessary widgets this way.
On Mon, Dec 21, 2009 at 3:34 AM, nicolas.deloof nicolas.del...@gmail.comwrote:
Do you suggest that extending Widget woul allow to mix HTML and g:*
tags in the ui.xml file as I did first ? If I understand well what
happens in the Deferred binding any g:* is converted to gwt API
calls to assmble widgets and pannel together, and static HTML have to
be placed into g:HTML elements, isn't it ?
Anyway it would be cool to be able to mix pure HTML and g:*
component, something similar to Apache Wicket inside GWT :)
I fixed my widget using this layout :
g:HTMLPanel tag=li styleName={style.event}
g:HTML
... static HTML code ...
/g:HTML
g:Button ui:field=subscribe
styleName={style.button}Inscription/g:Button
/g:HTMLPanel
With @UiField Button subscribe;
the @UiHandler( subscribe ) public void handleClick( ClickEvent
e ) doesn't work anyway. Just not getting into code when the button is
clicked. Have to investigate more on that.
I tried to extend Widget as you suggested but makes no change.
Nicolas
On 20 déc, 21:34, Ray Ryan rj...@google.com wrote:
EventWidget must extend Widget, and it will have to be placed in a panel
whose ultimate ancestor is either a RootPanel or a RootLayoutPanel
On Mon, Dec 21, 2009 at 5:24 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
Hi
I've migrated some nice HTML/CSS code to uibinder, and would like now
to
listen to clickEvents on the button present in this HTML fragment.
according to
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiBin..
.,
I need to use a gwt:Button as replacement for the html element to
support
GWT event handlers. I tried to use it as is, to wrap all my bloc inside
gwt:HTML and other ideas, but allways fail with some deferedBinding
errors
Any suggestion ?
Here is my widget ui.xml :
ui:UiBinder xmlns:ui=urn:ui:com.google.gwt.uibinder
xmlns:g=urn:import:com.google.gwt.user.client.ui
ui:style
...
/ui:style
li class={style.event}
... (some nice HTML code)
button ui:field=subscribe
class={style.button}Inscription/button
/li
/ui:UiBinder
and java :
public class EventWidget
extends UIObject
{
interface MyUiBinder
extends UiBinderLIElement, EventWidget
{
}
@UiField
//ButtonElement subscribe;
Button subscribe;
@UiHandler( subscribe )
public void handleClick( ClickEvent e )
{
...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: uibinder : how to add a gwt:Button to html fragment ?
You're right, this works fine
just still can't have handlers working with my button, either using
@UiHandler( subscribe ) or a programmatic subscribe.addClickHandler
(...)
strange ... any suggestion to debug this ?
On 21 déc, 16:03, Joel Webber j...@google.com wrote:
To be precise, you don't actually need the g:HTML in this example. It
could be simply:
g:HTMLPanel tag=li styleName={style.event}
div
... static HTML code ...
g:ButtonYou can do this too/g:Button
/div
g:Button
ui:field=subscribe styleName={style.button}Inscription/g:Button
/g:HTMLPanel
The point of the HTMLPanel/Parser is that it allows you to mix static HTML
and widgets more or less arbitrarily. We've also seen that many designs can
end up with a lot fewer unnecessary widgets this way.
On Mon, Dec 21, 2009 at 3:34 AM, nicolas.deloof
nicolas.del...@gmail.comwrote:
Do you suggest that extending Widget woul allow to mix HTML and g:*
tags in the ui.xml file as I did first ? If I understand well what
happens in the Deferred binding any g:* is converted to gwt API
calls to assmble widgets and pannel together, and static HTML have to
be placed into g:HTML elements, isn't it ?
Anyway it would be cool to be able to mix pure HTML and g:*
component, something similar to Apache Wicket inside GWT :)
I fixed my widget using this layout :
g:HTMLPanel tag=li styleName={style.event}
g:HTML
... static HTML code ...
/g:HTML
g:Button ui:field=subscribe
styleName={style.button}Inscription/g:Button
/g:HTMLPanel
With @UiField Button subscribe;
the �...@uihandler( subscribe ) public void handleClick( ClickEvent
e ) doesn't work anyway. Just not getting into code when the button is
clicked. Have to investigate more on that.
I tried to extend Widget as you suggested but makes no change.
Nicolas
On 20 déc, 21:34, Ray Ryan rj...@google.com wrote:
EventWidget must extend Widget, and it will have to be placed in a panel
whose ultimate ancestor is either a RootPanel or a RootLayoutPanel
On Mon, Dec 21, 2009 at 5:24 AM, nicolas de loof
nicolas.del...@gmail.comwrote:
Hi
I've migrated some nice HTML/CSS code to uibinder, and would like now
to
listen to clickEvents on the button present in this HTML fragment.
according to
http://code.google.com/intl/fr-FR/webtoolkit/doc/latest/DevGuideUiBin..
.,
I need to use a gwt:Button as replacement for the html element to
support
GWT event handlers. I tried to use it as is, to wrap all my bloc inside
gwt:HTML and other ideas, but allways fail with some deferedBinding
errors
Any suggestion ?
Here is my widget ui.xml :
ui:UiBinder xmlns:ui=urn:ui:com.google.gwt.uibinder
xmlns:g=urn:import:com.google.gwt.user.client.ui
ui:style
...
/ui:style
li class={style.event}
... (some nice HTML code)
button ui:field=subscribe
class={style.button}Inscription/button
/li
/ui:UiBinder
and java :
public class EventWidget
extends UIObject
{
interface MyUiBinder
extends UiBinderLIElement, EventWidget
{
}
@UiField
// ButtonElement subscribe;
Button subscribe;
@UiHandler( subscribe )
public void handleClick( ClickEvent e )
{
...
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: uibinder and bnudled CSS
Right, I got the warning but did not understand what it related to. Thanks a lot On 17 déc, 23:20, John Huss johnth...@gmail.com wrote: I think you have to escape the css attributes that start with a dash like this: \-moz-box-shadow: 2px 2px 5px #000; You should be getting a warning about it in dev mode if you are not - making sure you having logging on at a good level. John On Dec 17, 6:03 am, nicolas.deloof nicolas.del...@gmail.com wrote: Hi I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this is really easy and I get a nice result in few hours. I notice the uiBinder seems to rewrite the CSS rules according to browser support (I may be wrong) : my CSS uses CSS3 box-shadow : box-shadow: 2px 2px 5px #000; -moz-box-shadow: 2px 2px 5px #000; -webkit-box-shadow: 2px 2px 5px #000; This works fine on my Chrome browser, but when I use the uibinder version I dont' have shadows anymore. The CSS rule filter should not remove any -webkit* rule when targeting a webkit based browser, sould'it ? Also the box-shadow is supported by recent webkit browsers (it is on chrome 4, but this is in the dev channel) 2nd question : If my CSS uses background-image: url(...), can I include those images in my ClientBundle and still make references to them in my CSS fragement ? Cheers, Nicolas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: uibinder and bnudled CSS
I think you have to escape the css attributes that start with a dash like this: \-moz-box-shadow: 2px 2px 5px #000; You should be getting a warning about it in dev mode if you are not - making sure you having logging on at a good level. John On Dec 17, 6:03 am, nicolas.deloof nicolas.del...@gmail.com wrote: Hi I'm migrating some nice HTML-fragment to GWT. Thanks to UiBinder this is really easy and I get a nice result in few hours. I notice the uiBinder seems to rewrite the CSS rules according to browser support (I may be wrong) : my CSS uses CSS3 box-shadow : box-shadow: 2px 2px 5px #000; -moz-box-shadow: 2px 2px 5px #000; -webkit-box-shadow: 2px 2px 5px #000; This works fine on my Chrome browser, but when I use the uibinder version I dont' have shadows anymore. The CSS rule filter should not remove any -webkit* rule when targeting a webkit based browser, sould'it ? Also the box-shadow is supported by recent webkit browsers (it is on chrome 4, but this is in the dev channel) 2nd question : If my CSS uses background-image: url(...), can I include those images in my ClientBundle and still make references to them in my CSS fragement ? Cheers, Nicolas -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UiBinder adds spaces around CSS idents when they aren't needed
Good job on diagnosing the problem. Instead of hacking up IdentValue, introduce another Value subtype (call it TokenValue) that has this alternate printing behavior. http://gwt-code-reviews.appspot.com/87802 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder adds spaces around CSS idents when they aren't needed
Nice sleuthing John! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder adds spaces around CSS idents when they aren't needed
LGTM http://gwt-code-reviews.appspot.com/87802 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
On Tue, Oct 6, 2009 at 5:47 PM, Ray Ryan rj...@google.com wrote:
On Tue, Oct 6, 2009 at 8:43 AM, Thomas Broyer t.bro...@gmail.com wrote:
If I understand correctly how UiBinder works, for widgets, I'd still
have to inject the ID myself using
theWidget.getElement().setId(bundle.a().toString()) ?
That's a very bad idea. You're relying on the widget not to be using id for
its own purposes, now and in the future.
Is it really different from ensureDebugId?
That being said, I've thought a bit more about it and started reading
the UiBinder code to (try to) understand how it works. An IdResource
as implemented by Bob isn't what I want/need; actually, as I said in
the second part of my second message, the id resource would need to
be a distinct instance for each call to createAndBindUi.
It loks like I could do something similar using an ui:with and
providing my own IdResource implementation; but one of the goal of my
original proposal was also to reuse the IDs that are created by
UiBinder for its internal HTMLPanel implementation detail (UiBinder
mints IDs, but even if I use @UiField InputElement for instance, I
won't have the ID, as UiBinder also generates code that removes the
id= attribute when injecting a DOM element field; so I'd have to
generate new IDs in my own code; that's just wasted computations...)
I'll try to write a clear and detailed proposal *and* provide a patch.
In the mean time, here's another use case (hopefully self-explanatory,
yet not totally realistic wrt the markup; imagine how many times this
could be instantiated within the same app, IDs need to be unique for
each instance; note that in this case, I could very well use
SpanElement but that'd mean doing getElementById and comparing
element's identity where I could just compare IDs):
ui:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
ui:id-generator type='com.my.app.PanelButtons.MyIdentifiers' /
span
span aria-role=button id={id.minimize}'
class={style.minimizeSprite} /
span aria-role=button id={id.maximize}'
class={style.maximizeSprite} /
span aria-role=button id={id.close}' class={style.closeSprite} /
/span
/ui:UiBinder
class PanelButtons extends Widget {
interface MyIdentifiers extends IdGenerator {
String minimize();
String maximize();
String close();
}
interface MyUiBinder extends UiBinderSpanElement,PanelButton { }
private static MyUiBinder uiBinder = GWT.create(MyUiBinder.class);
@UiField MyIdentifiers id;
public PanelButtons() {
setElement(uiBinder.createAndBindUi(this));
sinkEvents(Event.ONCLICK);
}
public void onBrowserEvent(Event event) {
super.onBrowserevent(event);
if (event.getTypeInt() == Event.ONCLICK) {
Element target = event.getEventTarget();
if (target != getElement()) {
// TODO: check parent nodes until getElement(), à laisOrHasChild()
String id = target.getId();
if (this.id.minimize().equals(id)) {
// minimize clicked
} else if (this.id.maximize().equals(id)) {
// maximize clicked
} else if (this.id.close().equals(id)) {
// close clicked
}
}
}
}
...
}
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UIBinder bug with ensureCssInjected() missing ?
Not a bug. You're in charge of MyExternalBundle, including injecting it.
Note that there is no relationship between the bundle generated for the
ui:style block and your MyExternalBundle instance.
On Wed, Oct 7, 2009 at 3:10 PM, Sami Jaber sami.ja...@gmail.com wrote:
Hi gwitters,
Before filling any issue, just want to be sure that it's a bug.
Here is my ui.xml
gwt:UiBinder xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:gwt='urn:import:com.google.gwt.user.client.ui'
ui:with field='bundle' type='com.somewhere.client.MyExternalBundle'/
ui:style
.neverUsed { background-color:red;}
/ui:style
gwt:HorizontalPanel
gwt:Label ui:field='label' styleName={bundle.style.bold} text=is it a
bug ?/
/gwt:UIBinder
/gwt:HorizontalPanel
MyExternalBundle is pretty simple, it contains a style() method that
returns myCss type (with a bold() function)
When there is no ui:style tag in my ui.xml, the line
ensureCssInjected(clientBundleFieldNameUnlikelyToCollideWithUserSpecifiedFieldOkay.style());
is not generated at the end of createAndBindUI() in the Impl.
I have to explicitly call
com.google.gwt.dom.client.StyleInjector.injectStylesheet(bundle.style().getText())
after my initWidget() to get it working
If I add a dummy never used ui:style in the ui.xml, it works perfectly,
ensureCssInjected is added
I have quickly looked into UiBinderParser class, It is probably related to
the findStyles() method witch does not call createStyle() which won't add
ImplicitCssResource in bundleClass object.
any thought ?
Sami
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
The idea of an IdResource is interesting. I have been looking for a good
sample resource type for a tutorial on extending ClientBundle. I think that
I will work this up while I'm travelling today.
--Bob (Android)
On Oct 5, 2009 12:12 PM, Thomas Broyer t.bro...@gmail.com wrote:
On Mon, Oct 5, 2009 at 5:30 PM, Ray Ryan rj...@google.com wrote: Not
yet, and I'm torn about ho...
Wow! pretty reactive! (2 minutes between the question and answer!)
I don't know how it could be done at the generator/rebind level, but
maybe using i18n.client.Constants or rather introducing a new kind of
ClientBundle Resource?
For example:
ui:ids field=ids /
g:HTMLPanel
table
tr valign=top
tdlabel for={ids.text}Text/label/td
tdinput ui:field=textBox ui:id=ids.text //td
/tr
tr valign=top
tdlabel for={ids.list}/td
tdg:ListBox ui:field=list ui:id=ids.list //td
/tr
/table
/g:HTMLPanel
ui:id= names an ID variable that can then be used in {braces}; and
ui:ids/ gives the field name in the Java class where to inject the
resource (similar to ui:style/); just like ui:style/, it could
take a type= attribute, but unlike ui:style/ it couldn't be usable
within a ClientBundle (IDs are generated for each call to
createAndBindUi).
In this case, you'd have:
public interface MyIds extends IdResource {
String text();
String list();
}
@UiField MyIds ids;
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Too...
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
On Tue, Oct 6, 2009 at 4:16 PM, BobV b...@google.com wrote:
I've attached a very simple implementation (with source) of an
IdResource that can be used with ClientBundle. You're welcome to
adapt it to your needs, but I don't see any additional ClientBundle
API making it into GWT 2.0 at this time.
If I understand correctly, each IdResource declared in a ClientBundle
will generate an ID (in the form id1, id2, etc. unless @Prefix is
used); so I could use it in an ui.xml in, for instance label
for={res.a}foo/label...input id={res.a} / ?
If I understand correctly how UiBinder works, for widgets, I'd still
have to inject the ID myself using
theWidget.getElement().setId(bundle.a().toString()) ?
That's a step forward, thanks!
We haven't migrated to trunk and UiBinder yet (I'm waiting for an
official release, i.e. the first milestone; and we're only moving from
1.5 to 1.7 and from written in the rush spaghetti code to well
designed MVP+DI+EventBus+HTMLPanel+etc.), so I'll only test this
later rather than sooner, but thanks anyway!
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
On Tue, Oct 6, 2009 at 8:43 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Tue, Oct 6, 2009 at 4:16 PM, BobV b...@google.com wrote:
I've attached a very simple implementation (with source) of an
IdResource that can be used with ClientBundle. You're welcome to
adapt it to your needs, but I don't see any additional ClientBundle
API making it into GWT 2.0 at this time.
If I understand correctly, each IdResource declared in a ClientBundle
will generate an ID (in the form id1, id2, etc. unless @Prefix is
used); so I could use it in an ui.xml in, for instance label
for={res.a}foo/label...input id={res.a} / ?
If I understand correctly how UiBinder works, for widgets, I'd still
have to inject the ID myself using
theWidget.getElement().setId(bundle.a().toString()) ?
That's a very bad idea. You're relying on the widget not to be using id for
its own purposes, now and in the future.
I don't think you should count on the label element ever playing nice with
widgets, at least not soon.
That's a step forward, thanks!
We haven't migrated to trunk and UiBinder yet (I'm waiting for an
official release, i.e. the first milestone; and we're only moving from
1.5 to 1.7 and from written in the rush spaghetti code to well
designed MVP+DI+EventBus+HTMLPanel+etc.), so I'll only test this
later rather than sooner, but thanks anyway!
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ http://xn--nna.ma.xn--bwa-xxb.je/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
On 6 oct, 17:47, Ray Ryan rj...@google.com wrote: On Tue, Oct 6, 2009 at 8:43 AM, Thomas Broyer t.bro...@gmail.com wrote: If I understand correctly how UiBinder works, for widgets, I'd still have to inject the ID myself using theWidget.getElement().setId(bundle.a().toString()) ? That's a very bad idea. You're relying on the widget not to be using id for its own purposes, now and in the future. I don't think you should count on the label element ever playing nice with widgets, at least not soon. I think I'll do it anyway and count on my relatively good knowledge of the widgets I use to have it just work; but I take note (and add warnings in my code) that this not officially supported ;-) We haven't migrated to trunk and UiBinder yet (I'm waiting for an official release, i.e. the first milestone; and we're only moving from 1.5 to 1.7 and from written in the rush spaghetti code to well designed MVP+DI+EventBus+HTMLPanel+etc.), so I'll only test this later rather than sooner, but thanks anyway! Aha, looks like I missed the announcement by a few hours. Now wondering whether I switch or not (my co-worker finds it tempting too...) ;-) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and HTML's label for=
On Mon, Oct 5, 2009 at 5:30 PM, Ray Ryan rj...@google.com wrote:
Not yet, and I'm torn about how to do it.
Wow! pretty reactive! (2 minutes between the question and answer!)
I don't know how it could be done at the generator/rebind level, but
maybe using i18n.client.Constants or rather introducing a new kind of
ClientBundle Resource?
For example:
ui:ids field=ids /
g:HTMLPanel
table
tr valign=top
tdlabel for={ids.text}Text/label/td
tdinput ui:field=textBox ui:id=ids.text //td
/tr
tr valign=top
tdlabel for={ids.list}/td
tdg:ListBox ui:field=list ui:id=ids.list //td
/tr
/table
/g:HTMLPanel
ui:id= names an ID variable that can then be used in {braces}; and
ui:ids/ gives the field name in the Java class where to inject the
resource (similar to ui:style/); just like ui:style/, it could
take a type= attribute, but unlike ui:style/ it couldn't be usable
within a ClientBundle (IDs are generated for each call to
createAndBindUi).
In this case, you'd have:
public interface MyIds extends IdResource {
String text();
String list();
}
@UiField MyIds ids;
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder : provided=true and constructor with parameters
That's a flat out bug. Would you mind putting something on the issue
tracker?
On Thu, Sep 24, 2009 at 11:48 AM, Sripathi Krishnan
sripathi.krish...@gmail.com wrote:
I have a custom widget which has a constructor with some fields.
class HelpWidget extends Composite {
//usual interface declaration for UiBinder
public HelpWidget(HandlerManager eventBus) {
.
initWidget(uibinder.createAndBindUi(this);
}
}
Now, I have another widget which includes HelpWidget in its ui.xml
In PageLayout.ui.xml
--
gwt:HTMLPanel
custom:HelpWidget ui:field=helpWidget_ /
/gwt:HTMLPanel
In PageLayout.java
..
@UiField (provided = true)
HelpWidget helpWidget_;
public PageLayout() {
HandlerManager eventBus = new HandlerManager();
helpWidget_ = new HelpWidget(eventBus);
}
Note that I am instantiating the HelpWidget myself, and I am annotating it
with provided = true.
But when I compile, GWTC complains saying that HelpWidget must have a
default constructor, or must annotate the constructor with @UiConstructor.
If I annotate the constructor with @UiField, it complains that eventBus
parameter must be provided.
If I am taking care of object creation, then UiBinder shouldn't complain
about the constructor, right?
--Sri
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder : provided=true and constructor with parameters
Created issue
http://code.google.com/p/google-web-toolkit/issues/detail?id=4075
Thanks!
--Sri
2009/9/24 Ray Ryan rj...@google.com
That's a flat out bug. Would you mind putting something on the issue
tracker?
On Thu, Sep 24, 2009 at 11:48 AM, Sripathi Krishnan
sripathi.krish...@gmail.com wrote:
I have a custom widget which has a constructor with some fields.
class HelpWidget extends Composite {
//usual interface declaration for UiBinder
public HelpWidget(HandlerManager eventBus) {
.
initWidget(uibinder.createAndBindUi(this);
}
}
Now, I have another widget which includes HelpWidget in its ui.xml
In PageLayout.ui.xml
--
gwt:HTMLPanel
custom:HelpWidget ui:field=helpWidget_ /
/gwt:HTMLPanel
In PageLayout.java
..
@UiField (provided = true)
HelpWidget helpWidget_;
public PageLayout() {
HandlerManager eventBus = new HandlerManager();
helpWidget_ = new HelpWidget(eventBus);
}
Note that I am instantiating the HelpWidget myself, and I am annotating it
with provided = true.
But when I compile, GWTC complains saying that HelpWidget must have a
default constructor, or must annotate the constructor with @UiConstructor.
If I annotate the constructor with @UiField, it complains that eventBus
parameter must be provided.
If I am taking care of object creation, then UiBinder shouldn't complain
about the constructor, right?
--Sri
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder Contributions
Brett, I think something like what you propose below would be about what we'd need for FlexTables, but you're also right to suggest that it would be easier (and faster at runtime) just to throw all of it directly into HTML. Whenever that's easy to do, it's almost invariably the *right* thing to do. In general (and we still need to write a lot of this up), one of the things I'm most excited about with UiBinder is that it makes it *easy* to use HTML where that's the right thing, and use widgets only when you actually need them. I think this will make designers a lot happier, and will lead to faster code. The only case I can think of where you might actually want to specify both a FlexTable and its children in a .ui.xml file would be if you wanted to specify part of its structure statically (a header, say), but then add and remove rows at runtime using the FlexTable API. But I think that's probably a lot less common in practice. Cheers, joel. On Wed, Sep 16, 2009 at 11:59 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Actually, after I fired off the email, I thought Hey, I can just just HTMLPanel with tables and rows and cells with colspans. Is that the usage pattern you guys were thinking of anyway? Certainly I can write a parser for FlexTable, but it seems it would largely duplicate tables, yes? With respect to FlexTable and markup, off the top of my head (assuming the formatting gods are with me): g:FlexTable g:FlexColumn col='0' width='50px'/ g:FlexRow g:FlexCell colspan='2' align='center' g:HTMLimg src='img/loginBanner.gif'//g:HTML /g:FlexCell /g:FlexRow g:FlexRow valign='middle' g:FlexCell styleName='form-label' wrap='false' g:Label text=Username/ g:FlexCell g:FlexCell g:TextBox maxLength='32' ui:field='txUsername'Username/ g:TextBox /g:FlexCell /g:FlexRow /g:/FlexTable The parser would implicitly use getRowFormatter(), getColumnFormatter () and getFlexCellFormatter(). As noted, this largely duplicates what can be done with tables, except being able to cleaning bind to FlexTable fields, etc. Brett On Sep 17, 12:03 pm, Ray Ryan rj...@google.com wrote: Yes, most widgets won't need custom parsers. They'll be covered by combinations of BeanParser, HasWidgetsParser, etc. Custom parsers come into play for widgets with no default constructor, or need custom code generated for their add methods...that kind of thing. I'm pretty sure HorizontalPanel and VerticalPanel already work. They're nasty widgets, though, and likely to be deprecated soon in favor of the new LayoutPanel family. Anyway, are you sure you need them at all rather than simple divs in an HTMLPanel? Re: FlexTable, what exactly to you have in mind? Could you sketch out the ui.xml file you wish you could write? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
Hi Bruce,
The goals you stated have been long sought by developers everywhere
(including me) and I hope you guys achieve it. In fact our last-gen
web tool/framework choice was based on this principle of roles
separation - but in all my years I have just never seen this work
(yet) - I am curious to know if your team or anyone has effectively
achieved this.
We finally rested on the following separation - allow UI designers to
use their favorite tool (e.g. Dreamweaver) to create full-fledged
mockups, then let the developers work off those to recreate the UI.
Attempting to share the underlying artifacts just lead to a lot of
complexity especially with several cycles of modifications - and -
both sides had to settle for tools syntax neither were comfortable
with. Now with GWT - the UI designers use their tools and syntax and
the developers use their IDE and Java.
Now within developers, further role separation occurs between the UI
coders and the Service coders and so on (perhaps this is the
separation you were referring to) - but this is transitional at best
(as they switch around) - we do this now - some work on Panels (views)
exclusively for a while and so on. Even here separation using XML
likely means the same last-gen dev style - such as expression bindings
to Java variables and pretty soon Loop / If-then-else (and other
language constructs) in your XML to accommodate the dynamic behavior
expected from a view. The UI developer is restricted by XML rather
than having the full flexibility of OO at their finger-tips.
Regarding tooling:
Java can be statically analyzed - an IDE is the best example of a tool
that can analyze it.
Regarding performance:
The GWT compiler analyzes Java for optimization now - you could
provide APIs like panel.freeze() to allow static pre-generation of
HTML of frozen Panels (just throwing out ideas - not thought out
yet)..
An example of using a Table with Java rich goodness using Fluent
APIs...
public class DrugPricePanel extends SimplePanel {
public DrugPricePanel() {
AxisTable table = new AxisTable()
//main header
.nextRow()
.place(DrugPrices: An AxisTable Demo:
buildRowByRowPlaceDirectDemo)
//drug costs header
.nextRow()
.place(Drug Name) //place content directly
into cell.
.place(--)
.place(Specialty)
.place(90 Day Mail)
.place(90 Day Retail)
.place(30 Day Retail)
//drug info + total costs
.nextRow()
.y() //Nest an
AxisPanel as cell content
.x(widgets.drugName).q()//(see AxisPanel info -
layout in x or y axis).
.x(widgets.drugDesc1).q()
.x(widgets.drugDesc2).q()
.q()
.place(Total Costs)
.place(widgets.drugTotalCosts.specialtyCost)
.place(widgets.drugTotalCosts.ninetyDayMail)
.place(widgets.drugTotalCosts.ninetyDayRetail)
.place(widgets.drugTotalCosts.thirtyDayRetail)
//your costs
.nextRow()
.place(Your Costs)
.place(widgets.drugYourCosts.specialtyCost)
.place(widgets.drugYourCosts.ninetyDayMail)
.place(widgets.drugYourCosts.ninetyDayRetail)
.place(widgets.drugYourCosts.thirtyDayRetail)
//main header //span across all columns
.cell(0,0).span(1,7)
//drug header //span 2 columns
.cell(1,0).span(1,2)
//drug info //span 3 rows and 2 columns.
.cell(2,0).span(3,2)
;//end-table
this.setWidget(table);
}
class DrugCostWidgets {
Label specialtyCost = new Label();
Label ninetyDayMailCost = new Label();
Label ninetyDayRetailCost = new Label();
Label thirtyDayRetailCost = new Label();
}
class Widgets {
Label drugName = new Label();
Label drugDesc1 = new Label();
Label drugDesc2 = new Label();
DrugCostWidgets drugTotalCosts = new DrugCostWidgets();
DrugCostWidgets drugYourCosts = new DrugCostWidgets();
}
private Widgets widgets = new Widgets();
}//end-class
On Aug 25, 11:14 am, Bruce Johnson br...@google.com wrote:
Hi Sony,
I just wanted to clarify that UiBinder is based on XHTML not merely to make
coding more succinct vs. Java code. I agree that we could in theory provide
fluent APIs that could make Java imperative UI code much more succinct than
it is now. But there are three other big motivations for UiBinder
[gwt-contrib] Re: UiBinder Contributions
Yes, most widgets won't need custom parsers. They'll be covered by combinations of BeanParser, HasWidgetsParser, etc. Custom parsers come into play for widgets with no default constructor, or need custom code generated for their add methods...that kind of thing. I'm pretty sure HorizontalPanel and VerticalPanel already work. They're nasty widgets, though, and likely to be deprecated soon in favor of the new LayoutPanel family. Anyway, are you sure you need them at all rather than simple divs in an HTMLPanel? Re: FlexTable, what exactly to you have in mind? Could you sketch out the ui.xml file you wish you could write? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder Contributions
Actually, after I fired off the email, I thought Hey, I can just just HTMLPanel with tables and rows and cells with colspans. Is that the usage pattern you guys were thinking of anyway? Certainly I can write a parser for FlexTable, but it seems it would largely duplicate tables, yes? With respect to FlexTable and markup, off the top of my head (assuming the formatting gods are with me): g:FlexTable g:FlexColumn col='0' width='50px'/ g:FlexRow g:FlexCell colspan='2' align='center' g:HTMLimg src='img/loginBanner.gif'//g:HTML /g:FlexCell /g:FlexRow g:FlexRow valign='middle' g:FlexCell styleName='form-label' wrap='false' g:Label text=Username/ g:FlexCell g:FlexCell g:TextBox maxLength='32' ui:field='txUsername'Username/ g:TextBox /g:FlexCell /g:FlexRow /g:/FlexTable The parser would implicitly use getRowFormatter(), getColumnFormatter () and getFlexCellFormatter(). As noted, this largely duplicates what can be done with tables, except being able to cleaning bind to FlexTable fields, etc. Brett On Sep 17, 12:03 pm, Ray Ryan rj...@google.com wrote: Yes, most widgets won't need custom parsers. They'll be covered by combinations of BeanParser, HasWidgetsParser, etc. Custom parsers come into play for widgets with no default constructor, or need custom code generated for their add methods...that kind of thing. I'm pretty sure HorizontalPanel and VerticalPanel already work. They're nasty widgets, though, and likely to be deprecated soon in favor of the new LayoutPanel family. Anyway, are you sure you need them at all rather than simple divs in an HTMLPanel? Re: FlexTable, what exactly to you have in mind? Could you sketch out the ui.xml file you wish you could write? rjrjr --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[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 first impressions
Ray, I take it back, it doesn't work. Not for me anyway: gwt:UiBinder ... xmlns:res='urn:with:my.package.Bundle' ... gwt:Button res:addStyleNames=formCss.error / Results in [ERROR] In gwt:Button res:addStyleNames='formCss.error', class Button has no appropriate setAddStyleNames() method If I remove the res prefix, it works as expected. FWIW, I use res all over the template without any issues. I haven't tried the new syntax to see if it works any differently. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
I think you've found a bug with addStyleNames, which gets special handling. Do you mind filing an issue? The new syntax hasn't been committed yet, it's in review. Although now that I think about it, it just might accidentally fix this problem. Which is nice. On Fri, Aug 28, 2009 at 9:34 AM, Amir Kashani amirkash...@gmail.com wrote: Ray, I take it back, it doesn't work. Not for me anyway: gwt:UiBinder ... xmlns:res='urn:with:my.package.Bundle' ... gwt:Button res:addStyleNames=formCss.error / Results in [ERROR] In gwt:Button res:addStyleNames='formCss.error', class Button has no appropriate setAddStyleNames() method If I remove the res prefix, it works as expected. FWIW, I use res all over the template without any issues. I haven't tried the new syntax to see if it works any differently. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
Accidental bug fixes are always welcome! Issue 3994http://code.google.com/p/google-web-toolkit/issues/detail?id=3994 * * http://code.google.com/p/google-web-toolkit/issues/detail?id=3994*- Amir * On Fri, Aug 28, 2009 at 7:07 AM, Ray Ryan rj...@google.com wrote: I think you've found a bug with addStyleNames, which gets special handling. Do you mind filing an issue? The new syntax hasn't been committed yet, it's in review. Although now that I think about it, it just might accidentally fix this problem. Which is nice. On Fri, Aug 28, 2009 at 9:34 AM, Amir Kashani amirkash...@gmail.comwrote: Ray, I take it back, it doesn't work. Not for me anyway: gwt:UiBinder ... xmlns:res='urn:with:my.package.Bundle' ... gwt:Button res:addStyleNames=formCss.error / Results in [ERROR] In gwt:Button res:addStyleNames='formCss.error', class Button has no appropriate setAddStyleNames() method If I remove the res prefix, it works as expected. FWIW, I use res all over the template without any issues. I haven't tried the new syntax to see if it works any differently. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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
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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
Finally, GWT is all about finding coding patterns with which tools (IDEs in particular) are useful. UiBinder's XHTML syntax makes it easier to write good tools because it isn't as expressive as full-blown code: more restrictive language means more ability to analyze it statically, which is what tools are all about. Fluent APIs that would encourage people to write UIs with Java code are less amenable to creating good tools for them. For example, the Google Plugin is already working on tools to make editing UiBinder templates easy breezy, and we hope other IDEs will do the same. Will Google Plugin provide text editor for *.ui.xml files? Is there any place where I can ask to make this editor embeddable into MultiPageEditorPart? This would allow us to compose corresponding Java, ui.xml and WYSIWYG Design pages into single editor. For example Eclipse Java editor can not be embedded, because there are several dependencies in it and its actions, so we have to inherit from it to add Design and other pages in WindowBuilder. But if Google Plugin editor also will have such limitation, we will not able to include it in same way. I use MultiPageEditorPart just as example, most probably we will use our own multi-page editor implementation (inherited from Java editor). -- Bruce On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew xsonymat...@gmail.com wrote: One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having code completion, refactoring support and error messages right in Eclipse. This would be something like the Spring IDE plugin that one you configure Spring XML files with all the above features. Thanks again for the UiBinder, we'll definitely have to spend more time with it. Best regards, -- Arthur Kalmenson --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
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 first impressions
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.comwrote: 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 first impressions
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 first impressions
On Wed, Aug 26, 2009 at 5:21 AM, Konstantin.Scheglov konstantin.scheg...@gmail.com wrote: Finally, GWT is all about finding coding patterns with which tools (IDEs in particular) are useful. UiBinder's XHTML syntax makes it easier to write good tools because it isn't as expressive as full-blown code: more restrictive language means more ability to analyze it statically, which is what tools are all about. Fluent APIs that would encourage people to write UIs with Java code are less amenable to creating good tools for them. For example, the Google Plugin is already working on tools to make editing UiBinder templates easy breezy, and we hope other IDEs will do the same. Will Google Plugin provide text editor for *.ui.xml files? Is there any place where I can ask to make this editor embeddable into MultiPageEditorPart? This would allow us to compose corresponding Java, ui.xml and WYSIWYG Design pages into single editor. For example Eclipse Java editor can not be embedded, because there are several dependencies in it and its actions, so we have to inherit from it to add Design and other pages in WindowBuilder. But if Google Plugin editor also will have such limitation, we will not able to include it in same way. I use MultiPageEditorPart just as example, most probably we will use our own multi-page editor implementation (inherited from Java editor). Hi Konstantin, That sounds great! We'll definitely keep this in mind while developing UI Binder support in our plugin. The current plan is to hook into SSE extension points for the XML editor. We haven't yet had a need to create our own XML editor, but if this changes, we'll definitely aim to keep it embeddable in e.g. MultiPageEditorParts. If you don't mind, could you file this as a feature request in the GWT issue tracker? Thanks, jason -- Bruce On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew xsonymat...@gmail.com wrote: One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having code completion, refactoring support and error messages right in Eclipse. This would be something like the Spring IDE plugin that one you configure Spring XML files with all the above
[gwt-contrib] Re: UiBinder first impressions
While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
Will Google Plugin provide text editor for *.ui.xml files? Is there any place where I can ask to make this editor embeddable into MultiPageEditorPart? This would allow us to compose corresponding Java, ui.xml and WYSIWYG Design pages into single editor. For example Eclipse Java editor can not be embedded, because there are several dependencies in it and its actions, so we have to inherit from it to add Design and other pages in WindowBuilder. But if Google Plugin editor also will have such limitation, we will not able to include it in same way. I use MultiPageEditorPart just as example, most probably we will use our own multi-page editor implementation (inherited from Java editor). Hi Konstantin, That sounds great! We'll definitely keep this in mind while developing UI Binder support in our plugin. The current plan is to hook into SSE extension points for the XML editor. We haven't yet had a need to create our own XML editor, but if this changes, we'll definitely aim to keep it embeddable in e.g. MultiPageEditorParts. Thank you. If you don't mind, could you file this as a feature request in the GWT issue tracker? Done. http://code.google.com/p/google-web-toolkit/issues/detail?id=3986 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.com wrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
Hmm, I don't have it handy but it's the name xmlns I use for all other resource injection, and those work fine. I'll give it another shot later today. I'm sure you're right and I just messed something up. +1 for the expression language. Will res be required to be a subclass of one of the resource types, or will it work for any class? If the latter, it's a first step towards basic data-access from the template, which would be nice. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
On Wed, Aug 26, 2009 at 5:23 PM, Amir Kashani amirkash...@gmail.com wrote: Hmm, I don't have it handy but it's the name xmlns I use for all other resource injection, and those work fine. I'll give it another shot later today. I'm sure you're right and I just messed something up. +1 for the expression language. Will res be required to be a subclass of one of the resource types, or will it work for any class? If the latter, it's a first step towards basic data-access from the template, which would be nice. The existing res stuff is already type agnostic, so we've already taken that first step--just nobody noticed. The change will be purely a syntactic one. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
Oh, carry on then. Good show! - Amir On Wed, Aug 26, 2009 at 3:13 PM, Ray Ryan rj...@google.com wrote: On Wed, Aug 26, 2009 at 5:23 PM, Amir Kashani amirkash...@gmail.comwrote: Hmm, I don't have it handy but it's the name xmlns I use for all other resource injection, and those work fine. I'll give it another shot later today. I'm sure you're right and I just messed something up. +1 for the expression language. Will res be required to be a subclass of one of the resource types, or will it work for any class? If the latter, it's a first step towards basic data-access from the template, which would be nice. The existing res stuff is already type agnostic, so we've already taken that first step--just nobody noticed. The change will be purely a syntactic one. - Amir On Wed, Aug 26, 2009 at 12:22 PM, Ray Ryan rj...@google.com wrote: It works. What does your xmlns line look like? BTW, this is about to change. I'm implementing the expression language stuff mentioned in the wiki entry ( http://code.google.com/p/google-web-toolkit-incubator/wiki/UiBinder). So that line will become something like: gwt:Button addStyleNames=res.css.myCssClass / rjrjr On Wed, Aug 26, 2009 at 3:18 PM, Amir Kashani amirkash...@gmail.comwrote: While we're on the topic, it doesn't seem that the BundleAttributeParser catches these special attributes. Specifically, gwt:Button res:addStyleNames=css.myCssClass / doesn't seem to work. - Amir On Wed, Aug 26, 2009 at 8: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 first impressions
Hi Sony, I just wanted to clarify that UiBinder is based on XHTML not merely to make coding more succinct vs. Java code. I agree that we could in theory provide fluent APIs that could make Java imperative UI code much more succinct than it is now. But there are three other big motivations for UiBinder that wouldn't be address by fluent APIs that I wanted to share. First, specifying layouts in XHTML encouages developers (by making it easier) to use HTML rather than widgets/panels where the two are effectively equivalent anyway. For example, it's just as easy to use div instead of FlowPanel when you're already working in XHTML, yet div is much, much better. Browsers can parse and render HTML string fragments much faster than they can executing JavaScript that builds DOM structures programmatically. So, really, UiBinder is a trojan horse to get people to write apps that are smaller and run faster :-) Secondly, many teams we've worked with at Google really like that UiBinder creates a firm wall between the aesthetics of the UI vs. its programatic behavior, which supports well the MVP pattern that is becoming increasingly recognizes as The Right Way to architect internet-based client/server apps. It's also a good way to divide work in teams that have designers and developers; designers can mess with the XHTML, developers can mess with the code and if they ever diverge, you'll get a compile-time error. This seems to really facilitate the kind of workflow in which a lot of people have expressed interest since GWT 1.0. We're excited to finally be getting there. Finally, GWT is all about finding coding patterns with which tools (IDEs in particular) are useful. UiBinder's XHTML syntax makes it easier to write good tools because it isn't as expressive as full-blown code: more restrictive language means more ability to analyze it statically, which is what tools are all about. Fluent APIs that would encourage people to write UIs with Java code are less amenable to creating good tools for them. For example, the Google Plugin is already working on tools to make editing UiBinder templates easy breezy, and we hope other IDEs will do the same. -- Bruce On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew xsonymat...@gmail.com wrote: One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having
[gwt-contrib] Re: UiBinder first impressions
Extras... Are there any plans to build a ui tool (maybe in swing) so designers can drag n drop available widgets and have the view instantly updated? Other kool features might include save the file etc. Some of the extra features in interface builder. Thoughts...? On 26/08/2009, at 2:14 AM, Bruce Johnson br...@google.com wrote: Hi Sony, I just wanted to clarify that UiBinder is based on XHTML not merely to make coding more succinct vs. Java code. I agree that we could in theory provide fluent APIs that could make Java imperative UI code much more succinct than it is now. But there are three other big motivations for UiBinder that wouldn't be address by fluent APIs that I wanted to share. First, specifying layouts in XHTML encouages developers (by making it easier) to use HTML rather than widgets/panels where the two are effectively equivalent anyway. For example, it's just as easy to use div instead of FlowPanel when you're already working in XHTML, yet div is much, much better. Browsers can parse and render HTML string fragments much faster than they can executing JavaScript that builds DOM structures programmatically. So, really, UiBinder is a trojan horse to get people to write apps that are smaller and run faster :-) Secondly, many teams we've worked with at Google really like that UiBinder creates a firm wall between the aesthetics of the UI vs. its programatic behavior, which supports well the MVP pattern that is becoming increasingly recognizes as The Right Way to architect internet-based client/server apps. It's also a good way to divide work in teams that have designers and developers; designers can mess with the XHTML, developers can mess with the code and if they ever diverge, you'll get a compile-time error. This seems to really facilitate the kind of workflow in which a lot of people have expressed interest since GWT 1.0. We're excited to finally be getting there. Finally, GWT is all about finding coding patterns with which tools (IDEs in particular) are useful. UiBinder's XHTML syntax makes it easier to write good tools because it isn't as expressive as full- blown code: more restrictive language means more ability to analyze it statically, which is what tools are all about. Fluent APIs that would encourage people to write UIs with Java code are less amenable to creating good tools for them. For example, the Google Plugin is already working on tools to make editing UiBinder templates easy breezy, and we hope other IDEs will do the same. -- Bruce On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew xsonymat...@gmail.com wrote: One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when
[gwt-contrib] Re: UiBinder first impressions
No plans to do drag-n-drop or anything wysiwyg. We'll probably continue to focus on the basics. On Tuesday, August 25, 2009, Miroslav Pokorny miroslav.poko...@gmail.com wrote: Extras... Are there any plans to build a ui tool (maybe in swing) so designers can drag n drop available widgets and have the view instantly updated? Other kool features might include save the file etc.Some of the extra features in interface builder. Thoughts...? On 26/08/2009, at 2:14 AM, Bruce Johnson br...@google.com wrote: Hi Sony, I just wanted to clarify that UiBinder is based on XHTML not merely to make coding more succinct vs. Java code. I agree that we could in theory provide fluent APIs that could make Java imperative UI code much more succinct than it is now. But there are three other big motivations for UiBinder that wouldn't be address by fluent APIs that I wanted to share. First, specifying layouts in XHTML encouages developers (by making it easier) to use HTML rather than widgets/panels where the two are effectively equivalent anyway. For example, it's just as easy to use div instead of FlowPanel when you're already working in XHTML, yet div is much, much better. Browsers can parse and render HTML string fragments much faster than they can executing JavaScript that builds DOM structures programmatically. So, really, UiBinder is a trojan horse to get people to write apps that are smaller and run faster :-) Secondly, many teams we've worked with at Google really like that UiBinder creates a firm wall between the aesthetics of the UI vs. its programatic behavior, which supports well the MVP pattern that is becoming increasingly recognizes as The Right Way to architect internet-based client/server apps. It's also a good way to divide work in teams that have designers and developers; designers can mess with the XHTML, developers can mess with the code and if they ever diverge, you'll get a compile-time error. This seems to really facilitate the kind of workflow in which a lot of people have expressed interest since GWT 1.0. We're excited to finally be getting there. Finally, GWT is all about finding coding patterns with which tools (IDEs in particular) are useful. UiBinder's XHTML syntax makes it easier to write good tools because it isn't as expressive as full-blown code: more restrictive language means more ability to analyze it statically, which is what tools are all about. Fluent APIs that would encourage people to write UIs with Java code are less amenable to creating good tools for them. For example, the Google Plugin is already working on tools to make editing UiBinder templates easy breezy, and we hope other IDEs will do the same. -- Bruce On Mon, Aug 17, 2009 at 11:32 AM, SonyMathew xsonymat...@gmail.com wrote: One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN t --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UIBinder and the new Layout system
Brett, You should be able to use the already-checked-in LayoutPanel to do anything you could have done with AbsolutePanel before. And it should be the case that you can get rid of all of your manual resize code (that's the intention, anyway). Also, if you run into any problems embedding other widgets (like the aforementioned FlexTable or FormPanle), please let me know as well. Thanks, joel. On Thu, Aug 20, 2009 at 1:06 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: Joel, Will be happy to test new layouts and review API. Unfortunately, I don't use Dock, Stack, or Split in my app. I do use Absolute. And because of an interior scrolling area that fills the client, a sprinkling of resize code (after beating my head against CSS for a few days). I do use FormPanel and FlexTable, but I would expect both of those to be minimally affected or not affected by your layout as they are somewhat micro-level layouts not needing resize/reflow behaviors. -Brett On Aug 18, 12:32 am, Joel Webber j...@google.com wrote: The situation as I see it is this. The old layout system has two huge problems:1. Some widgets (e.g., StackPanel) *cannot* be made to work as expected in standards mode, because of changes to table rendering behavior. 2. It's not really a system, in the sense that it can be highly unpredictable. I am quite convinced it is impossible to fix these issues in any fundamental way, without taking an entirely different approach. See the design doc ( http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign) for my justification of this particular approach. In particular, I think it's worth noting that while Google Wave uses different actual code (they wrote their implementation before I did, but they didn't have to support IE6, which drastically simplified the problem), it's philosophically the same thing. This works quite well for them. As for reimplementing widgets like StackPanel, I mention in the design-doc that several such widgets will need to be replaced, and I'm working on that right now. The APIs won't be identical, because they need a bit more explicit size information in some cases, but I don't believe it will be too much trouble (I'm rewriting some of the samples to be sure). I'm hoping to have initial implementations of Dock, Stack, and Split widgets checked in over the next couple of days. If you could try using them and give me API and behavior feedback, that would be really helpful. Thanks, joel. On Sat, Aug 15, 2009 at 2:13 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Cool. Then another question about the future of the new layout system. Is the current thinking that eventually it *will* replace all of the older panels? I mean, is there buy-in at Google that that is a desired track for this project. Or will the new layout system remain parallel to the original? Also, is it possible to re-write StackPanel etc. to be compatible with the new system so that people have a migration? I don't personally care about migration, because I'm starting nearly from scratch, but I don't want to adopt a side-car layout system that doesn't have a track into the mainline of GWT. Thanks for your answers and your efforts. If there is anything I can do to help, let me know, I will be glad to pitch in a hand with some layouts or UIBinder parsers etc. if you are willing to give direction. Brett On Aug 15, 12:44 am, Joel Webber j...@google.com wrote: Brett, I am going to be writing adding custom parsers for the new layout panels sometime soon. And the new layout system will be de facto in the sense that I'm updating all the samples to use it (and possibly adding another sample). We obviously won't be removing the old widgets (e.g., StackPanel) that won't play nice in standards mode until a later release, so we don't break anyone's existing projects. Cheers, joel. On Fri, Aug 14, 2009 at 11:17 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: I have been tracking the process of the UIBinder and the new pure CSS- based layout system being driven by Joel at google. I assume these two will play nicely together in 2.0? Or will custom parsers be needed to use UIBinder with the new layout system? Sounds like the UIBinder parsers API won't be ready for public consumption in the first release. Lastly, will the new layout system be the *defacto* layout system in 2.0? Please say yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and Model View Presenter
Brett, We did code splitting across the four major sections of our applications. Assume we have section A-D, each with their own mediator. We then have an ApplicationMediator, which is responsible for loading / unloading the four major sections and sticking them into the viewport. When ApplicationMediator receives a notification to load A, for example, it calls a method loadA() that constructs the AMediator, gets its view component, and sticks it in the viewport. The trick is that loadA() is wrapped in a runAsyc() block and nowhere else do we ever construct an AMediator or even reference it, since communication is all through notifications. You could certainly do the same thing with a LoadACommand(). We just felt that since the command would have to work intimately with ApplicationMediator, it's best to just stick the logic in there. Our history management is pretty intense as our app is quite large and requires maintaining quite a bit of state (searches with up to 20-30 criteria). But, we did basically what you suggested. A HistoryManger class is responsible for serializing and deserializing history state. The rest of the application registers a certain token (say, search), providing a serializer and a Command. When it a history event is fired for that token, the entire state is serialized using the provided serializer then passed as an argument to the command. This works really well, because if you have a PerformSearch command that takes a SearchRequest as the body, it can be used for the history mechanism AND through normal user actions. The only bit about this I don't like, is that we use the third type parameter to signify whether the command is being called as a result of a user action or a history state change. If it's a user action, the command calls HistoryManager, allowing it to do it's History.addToken call. It's a bit hackish, but works. Hope that makes sense. - Amir On Wed, Aug 19, 2009 at 9:43 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Amir, After your post, I have been investigating PureMVC a bit. Since you used it, I have a question. In PureMVC, in the typical ApplicationFacade class there is an initializeController() override which registers all the commands. How does this fit with code- splitting? Currently our application is not PureMVC, and we highly leverage the new code-splitting features of GWT. Do you leverage code- splitting? If so, did you just register all the commands up front, but then in the execute() of the commands use runAsync() to allow splitting? Where are the best points to apply runAsync() in the PureMVC architecture? Also, while I have your attention, how did you (or did you) fit browser history into the PureMVC model? Did some sort of history management class receive notifications from the framework and manage history that way? Did that class post notifications into the PureMVC framework in response to back/forward navigation? Thanks. On Aug 14, 6:36 am, Amir Kashani amirkash...@gmail.com wrote: For my last work project, we used Kiyaa!, a GWT library that offers its own declarative UI system (and data-binding). In addition, we used PureMVC as a very lightweight MVC-framework. If you're familiar with PureMVC, you'll know that it's much closer to MVP, as described by Ray Ryan, than it is a traditional MVC framework. They worked beautifully together. Here's our basic setup: - *Views *- these are the plain UI components represented with Kyiaa! templates. They're smart enough to display Model data and handle any UI interactions, but delegate all business logic to their Mediators. They have a Listener interface that is implemented by the Mediator, which has high-level callback methods, such as onRegister, onNewCustomer, etc rather than onClick. - *Mediator *- responsible for managing the views by facilitating communication between the View and the rest of the system. They send and receive Notifications that are handled by other Mediators or by Commands. More specifically, they provide model data to the View as it's available and handle user-triggered events from the view, etc. The mediators have NO references to any Widgets or other UI components. Their only interaction with the View is from callbacks through the defined interface and through the View's public API, which is generally fairly-high level as well. Because of this, it's easy to re-use UI components by having a different Mediator controlling the UI. - *Model* - these are your basic domain objects. They should be POJOs and have no concept of the rest of the system. Period. - *Proxy* - a Proxy's basic role is to provide a high-level API for managing the Model. Depending on the complexity of your domain object, it could be as simple as having methods such as addUser, deleteUser, etc. Or, for complex Models, such as a Word
[gwt-contrib] Re: UiBinder and Model View Presenter
Amir, After your post, I have been investigating PureMVC a bit. Since you used it, I have a question. In PureMVC, in the typical ApplicationFacade class there is an initializeController() override which registers all the commands. How does this fit with code- splitting? Currently our application is not PureMVC, and we highly leverage the new code-splitting features of GWT. Do you leverage code- splitting? If so, did you just register all the commands up front, but then in the execute() of the commands use runAsync() to allow splitting? Where are the best points to apply runAsync() in the PureMVC architecture? Also, while I have your attention, how did you (or did you) fit browser history into the PureMVC model? Did some sort of history management class receive notifications from the framework and manage history that way? Did that class post notifications into the PureMVC framework in response to back/forward navigation? Thanks. On Aug 14, 6:36 am, Amir Kashani amirkash...@gmail.com wrote: For my last work project, we used Kiyaa!, a GWT library that offers its own declarative UI system (and data-binding). In addition, we used PureMVC as a very lightweight MVC-framework. If you're familiar with PureMVC, you'll know that it's much closer to MVP, as described by Ray Ryan, than it is a traditional MVC framework. They worked beautifully together. Here's our basic setup: - *Views *- these are the plain UI components represented with Kyiaa! templates. They're smart enough to display Model data and handle any UI interactions, but delegate all business logic to their Mediators. They have a Listener interface that is implemented by the Mediator, which has high-level callback methods, such as onRegister, onNewCustomer, etc rather than onClick. - *Mediator *- responsible for managing the views by facilitating communication between the View and the rest of the system. They send and receive Notifications that are handled by other Mediators or by Commands. More specifically, they provide model data to the View as it's available and handle user-triggered events from the view, etc. The mediators have NO references to any Widgets or other UI components. Their only interaction with the View is from callbacks through the defined interface and through the View's public API, which is generally fairly-high level as well. Because of this, it's easy to re-use UI components by having a different Mediator controlling the UI. - *Model* - these are your basic domain objects. They should be POJOs and have no concept of the rest of the system. Period. - *Proxy* - a Proxy's basic role is to provide a high-level API for managing the Model. Depending on the complexity of your domain object, it could be as simple as having methods such as addUser, deleteUser, etc. Or, for complex Models, such as a Word Document object, can have methods such as setTitle(), etc. In our setup, Proxys take the former role, basically encapsulating all RPC logic, implementing client-side caching, etc. You call methods on a Proxy, such as saveUser, and it sends Notifications to the rest of the system when something interesting happens. Proxy's NEVER receive notifications, however. They are not interested in the rest of the system, including the UI (or even that there is a UI), and theoretically, along with the models, should function completely on their own, making them highly reusable. - *Command* - a Command is a place where you encode complex interactions. For example, if your application has a search function, you may have a SearchCommand that 1. Receives the search query 2. Calls the appropriate Proxy to do the RPC hit 3. Loads the Mediator that will be interested in the Proxy's response, if not already loaded The SearchCommand would be triggered by a notification sent from some Mediator. The idea is to stick the logic into a re-usable Command rather than encoding it into a Mediator directly, as it may be needed from multiple places. The great part about this design and MVP is, that if we want to switch to UIBinder, all we have to do is modify the View classes. No other part of the system would have to change one-bit. Another quick note on PureMVC: it's kind of a disservice to it to call it an MVC framework, as there's very little code involved in the framework. Rather, it's a set of concepts and principles that have been very well defined, that if followed correctly, lead to highly-reusable and easily testable components. Even if you don't use the framework, I highly recommend reading their best practices:http://puremvc.org/component/option,com_wrapper/Itemid,174/ - Amir On Thu, Aug 13, 2009 at 2:27 AM, Andrés Testi andres.a.te...@gmail.comwrote: How the UiBinder fits in the MVP architecture proposed at the google I/ O talks?
[gwt-contrib] Re: UIBinder and the new Layout system
Joel, Will be happy to test new layouts and review API. Unfortunately, I don't use Dock, Stack, or Split in my app. I do use Absolute. And because of an interior scrolling area that fills the client, a sprinkling of resize code (after beating my head against CSS for a few days). I do use FormPanel and FlexTable, but I would expect both of those to be minimally affected or not affected by your layout as they are somewhat micro-level layouts not needing resize/reflow behaviors. -Brett On Aug 18, 12:32 am, Joel Webber j...@google.com wrote: The situation as I see it is this. The old layout system has two huge problems:1. Some widgets (e.g., StackPanel) *cannot* be made to work as expected in standards mode, because of changes to table rendering behavior. 2. It's not really a system, in the sense that it can be highly unpredictable. I am quite convinced it is impossible to fix these issues in any fundamental way, without taking an entirely different approach. See the design doc (http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign) for my justification of this particular approach. In particular, I think it's worth noting that while Google Wave uses different actual code (they wrote their implementation before I did, but they didn't have to support IE6, which drastically simplified the problem), it's philosophically the same thing. This works quite well for them. As for reimplementing widgets like StackPanel, I mention in the design-doc that several such widgets will need to be replaced, and I'm working on that right now. The APIs won't be identical, because they need a bit more explicit size information in some cases, but I don't believe it will be too much trouble (I'm rewriting some of the samples to be sure). I'm hoping to have initial implementations of Dock, Stack, and Split widgets checked in over the next couple of days. If you could try using them and give me API and behavior feedback, that would be really helpful. Thanks, joel. On Sat, Aug 15, 2009 at 2:13 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Cool. Then another question about the future of the new layout system. Is the current thinking that eventually it *will* replace all of the older panels? I mean, is there buy-in at Google that that is a desired track for this project. Or will the new layout system remain parallel to the original? Also, is it possible to re-write StackPanel etc. to be compatible with the new system so that people have a migration? I don't personally care about migration, because I'm starting nearly from scratch, but I don't want to adopt a side-car layout system that doesn't have a track into the mainline of GWT. Thanks for your answers and your efforts. If there is anything I can do to help, let me know, I will be glad to pitch in a hand with some layouts or UIBinder parsers etc. if you are willing to give direction. Brett On Aug 15, 12:44 am, Joel Webber j...@google.com wrote: Brett, I am going to be writing adding custom parsers for the new layout panels sometime soon. And the new layout system will be de facto in the sense that I'm updating all the samples to use it (and possibly adding another sample). We obviously won't be removing the old widgets (e.g., StackPanel) that won't play nice in standards mode until a later release, so we don't break anyone's existing projects. Cheers, joel. On Fri, Aug 14, 2009 at 11:17 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: I have been tracking the process of the UIBinder and the new pure CSS- based layout system being driven by Joel at google. I assume these two will play nicely together in 2.0? Or will custom parsers be needed to use UIBinder with the new layout system? Sounds like the UIBinder parsers API won't be ready for public consumption in the first release. Lastly, will the new layout system be the *defacto* layout system in 2.0? Please say yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UIBinder and the new Layout system
The situation as I see it is this. The old layout system has two huge problems:1. Some widgets (e.g., StackPanel) *cannot* be made to work as expected in standards mode, because of changes to table rendering behavior. 2. It's not really a system, in the sense that it can be highly unpredictable. I am quite convinced it is impossible to fix these issues in any fundamental way, without taking an entirely different approach. See the design doc ( http://code.google.com/p/google-web-toolkit/wiki/LayoutDesign) for my justification of this particular approach. In particular, I think it's worth noting that while Google Wave uses different actual code (they wrote their implementation before I did, but they didn't have to support IE6, which drastically simplified the problem), it's philosophically the same thing. This works quite well for them. As for reimplementing widgets like StackPanel, I mention in the design-doc that several such widgets will need to be replaced, and I'm working on that right now. The APIs won't be identical, because they need a bit more explicit size information in some cases, but I don't believe it will be too much trouble (I'm rewriting some of the samples to be sure). I'm hoping to have initial implementations of Dock, Stack, and Split widgets checked in over the next couple of days. If you could try using them and give me API and behavior feedback, that would be really helpful. Thanks, joel. On Sat, Aug 15, 2009 at 2:13 PM, brett.wooldridge brett.wooldri...@gmail.com wrote: Cool. Then another question about the future of the new layout system. Is the current thinking that eventually it *will* replace all of the older panels? I mean, is there buy-in at Google that that is a desired track for this project. Or will the new layout system remain parallel to the original? Also, is it possible to re-write StackPanel etc. to be compatible with the new system so that people have a migration? I don't personally care about migration, because I'm starting nearly from scratch, but I don't want to adopt a side-car layout system that doesn't have a track into the mainline of GWT. Thanks for your answers and your efforts. If there is anything I can do to help, let me know, I will be glad to pitch in a hand with some layouts or UIBinder parsers etc. if you are willing to give direction. Brett On Aug 15, 12:44 am, Joel Webber j...@google.com wrote: Brett, I am going to be writing adding custom parsers for the new layout panels sometime soon. And the new layout system will be de facto in the sense that I'm updating all the samples to use it (and possibly adding another sample). We obviously won't be removing the old widgets (e.g., StackPanel) that won't play nice in standards mode until a later release, so we don't break anyone's existing projects. Cheers, joel. On Fri, Aug 14, 2009 at 11:17 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: I have been tracking the process of the UIBinder and the new pure CSS- based layout system being driven by Joel at google. I assume these two will play nicely together in 2.0? Or will custom parsers be needed to use UIBinder with the new layout system? Sounds like the UIBinder parsers API won't be ready for public consumption in the first release. Lastly, will the new layout system be the *defacto* layout system in 2.0? Please say yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder first impressions
One point I have tried injecting into the GWT community is the importance of fluent APIs. GWT's Java API is currently quite cumbersome for layouts and it seems folks immediately jumped to the conclusion that Java doesn't work and have gone the route of using XML for layouts. I am not against folks that want XML layouts but there are many that feel fluent APIs in Java for layouts will be even more productive Even if you layout your initial UI in XML you are still going to need to modify it dynamically in Java based on various events - so you end up having a eye sore mix. I put out an example of a fluent API called AxisPanel (search for it) - its not a great implementation - but it pretty much let me layout everything pretty quickly and changed the pace of my GWT development drastically - especially when it came to modifying layouts with new requirements. Speaking for myself - I would like to see more such APIs (and better implementations than my AxisPanel) that folks can rely on as part of the Core GWT. I don't think developers starting a new GWT project would adopt XML layouts if they could fluently layout in Java right alongside the rest of their coding (at-least thats my theory).. Sony On Aug 10, 8:59 am, Arthur Kalmenson arthur.k...@gmail.com wrote: Hello everyone, We've been playing with UiBinder and I thought it'd be a good idea to share what we've seen so far (and ask some questions). Some of the apps we write are used by more then one hospital and this requires a tailored UI depending on the user's preferences and to store additional information that a particular hospital needs to keep track of. At the moment, writing UI in a swing style, we program to interfaces and use GIN to bind everything together. Using different AbstractGinModules and Ginjectors, we can tie the application together in different ways using different UI implementations. What would be the way to do this with UiBinder? From what we could tell, one would use UiTemplate, but there doesn't seem to be a way to configure the String in UiTemplate easily through a GIN module. Are there alternatives? Following the programming to interfaces theme, we've been doing that with UiBinder, but have run into an issue when trying to build a larger UI page out of smaller ui.xml classes. It seems that referring to interfaces in ui.xml doesn't work, so you need to work with direct concrete classes. But this would force you to use a particular implementation when we'd like to keep it generic. Lastly, I guess this is something just for consideration for the future, but having the GEP work with UiBinder would make using it a lot easier. For example, having code completion, refactoring support and error messages right in Eclipse. This would be something like the Spring IDE plugin that one you configure Spring XML files with all the above features. Thanks again for the UiBinder, we'll definitely have to spend more time with it. Best regards, -- Arthur Kalmenson --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UIBinder and the new Layout system
Cool. Then another question about the future of the new layout system. Is the current thinking that eventually it *will* replace all of the older panels? I mean, is there buy-in at Google that that is a desired track for this project. Or will the new layout system remain parallel to the original? Also, is it possible to re-write StackPanel etc. to be compatible with the new system so that people have a migration? I don't personally care about migration, because I'm starting nearly from scratch, but I don't want to adopt a side-car layout system that doesn't have a track into the mainline of GWT. Thanks for your answers and your efforts. If there is anything I can do to help, let me know, I will be glad to pitch in a hand with some layouts or UIBinder parsers etc. if you are willing to give direction. Brett On Aug 15, 12:44 am, Joel Webber j...@google.com wrote: Brett, I am going to be writing adding custom parsers for the new layout panels sometime soon. And the new layout system will be de facto in the sense that I'm updating all the samples to use it (and possibly adding another sample). We obviously won't be removing the old widgets (e.g., StackPanel) that won't play nice in standards mode until a later release, so we don't break anyone's existing projects. Cheers, joel. On Fri, Aug 14, 2009 at 11:17 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: I have been tracking the process of the UIBinder and the new pure CSS- based layout system being driven by Joel at google. I assume these two will play nicely together in 2.0? Or will custom parsers be needed to use UIBinder with the new layout system? Sounds like the UIBinder parsers API won't be ready for public consumption in the first release. Lastly, will the new layout system be the *defacto* layout system in 2.0? Please say yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UiBinder and Model View Presenter
Amir: Your answer is very interesting and detailed. Thank you very much for taking your time to answer my question. I will take a look in PureMVC. One of my big concerns is the translation of JSR 303 validations to client side. Regards. - Andrés On 13 ago, 18:36, Amir Kashani amirkash...@gmail.com wrote: For my last work project, we used Kiyaa!, a GWT library that offers its own declarative UI system (and data-binding). In addition, we used PureMVC as a very lightweight MVC-framework. If you're familiar with PureMVC, you'll know that it's much closer to MVP, as described by Ray Ryan, than it is a traditional MVC framework. They worked beautifully together. Here's our basic setup: - *Views *- these are the plain UI components represented with Kyiaa! templates. They're smart enough to display Model data and handle any UI interactions, but delegate all business logic to their Mediators. They have a Listener interface that is implemented by the Mediator, which has high-level callback methods, such as onRegister, onNewCustomer, etc rather than onClick. - *Mediator *- responsible for managing the views by facilitating communication between the View and the rest of the system. They send and receive Notifications that are handled by other Mediators or by Commands. More specifically, they provide model data to the View as it's available and handle user-triggered events from the view, etc. The mediators have NO references to any Widgets or other UI components. Their only interaction with the View is from callbacks through the defined interface and through the View's public API, which is generally fairly-high level as well. Because of this, it's easy to re-use UI components by having a different Mediator controlling the UI. - *Model* - these are your basic domain objects. They should be POJOs and have no concept of the rest of the system. Period. - *Proxy* - a Proxy's basic role is to provide a high-level API for managing the Model. Depending on the complexity of your domain object, it could be as simple as having methods such as addUser, deleteUser, etc. Or, for complex Models, such as a Word Document object, can have methods such as setTitle(), etc. In our setup, Proxys take the former role, basically encapsulating all RPC logic, implementing client-side caching, etc. You call methods on a Proxy, such as saveUser, and it sends Notifications to the rest of the system when something interesting happens. Proxy's NEVER receive notifications, however. They are not interested in the rest of the system, including the UI (or even that there is a UI), and theoretically, along with the models, should function completely on their own, making them highly reusable. - *Command* - a Command is a place where you encode complex interactions. For example, if your application has a search function, you may have a SearchCommand that 1. Receives the search query 2. Calls the appropriate Proxy to do the RPC hit 3. Loads the Mediator that will be interested in the Proxy's response, if not already loaded The SearchCommand would be triggered by a notification sent from some Mediator. The idea is to stick the logic into a re-usable Command rather than encoding it into a Mediator directly, as it may be needed from multiple places. The great part about this design and MVP is, that if we want to switch to UIBinder, all we have to do is modify the View classes. No other part of the system would have to change one-bit. Another quick note on PureMVC: it's kind of a disservice to it to call it an MVC framework, as there's very little code involved in the framework. Rather, it's a set of concepts and principles that have been very well defined, that if followed correctly, lead to highly-reusable and easily testable components. Even if you don't use the framework, I highly recommend reading their best practices:http://puremvc.org/component/option,com_wrapper/Itemid,174/ - Amir On Thu, Aug 13, 2009 at 2:27 AM, Andrés Testi andres.a.te...@gmail.comwrote: How the UiBinder fits in the MVP architecture proposed at the google I/ O talks? (http://code.google.com/intl/es-AR/events/io/sessions/ GoogleWebToolkitBestPractices.html) Regards. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: UIBinder and the new Layout system
Brett, I am going to be writing adding custom parsers for the new layout panels sometime soon. And the new layout system will be de facto in the sense that I'm updating all the samples to use it (and possibly adding another sample). We obviously won't be removing the old widgets (e.g., StackPanel) that won't play nice in standards mode until a later release, so we don't break anyone's existing projects. Cheers, joel. On Fri, Aug 14, 2009 at 11:17 AM, brett.wooldridge brett.wooldri...@gmail.com wrote: I have been tracking the process of the UIBinder and the new pure CSS- based layout system being driven by Joel at google. I assume these two will play nicely together in 2.0? Or will custom parsers be needed to use UIBinder with the new layout system? Sounds like the UIBinder parsers API won't be ready for public consumption in the first release. Lastly, will the new layout system be the *defacto* layout system in 2.0? Please say yes. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
