UiBinder

[Grzegorz Kossakowski]

Hi,

I just did a cursory look into UiBinder and I think I get basic idea on how it works.

It's been said multiple times (by many people) on this list that we have problem with supporting UiBinder (or UiBinder supporting Scala) because UiBinder requires fields to be non-private. As you know Scala always makes fields private and generates accessor methods for them. I would be pretty scared to mess up with it and try to change it.

This leads me to conclusion that it would be probably the easiest to modify UiBinder a little bit so it can also use getters and setters. I don't know if this going to be difficult to implement.

Is there anything else we need to have UiBinder working?

--
Grzegorz Kossakowski

[Nate Bauernfeind]

I have ported a portion of the CellWidget demo over to scala. It uses UiBinder, and as far as I could tell everything would work if it could find the appropriate setter.

Here is an example error message: "The field CwCellList.pagerPanel is not visible"

It uses annotations in many convenient ways. The @UiField annotation links a particular widget on the UI to a specific member variable of the class.

GWT was actually finding these annotations on fields. I thought that I heard that jribble does not support annotations. I could not find any mention of the annotations in the jribbletxt. So, what is the story with annotations?

I've decompiled an annotated field and only the field retains the annotation (the methods contain none). Case classes are a corner case where the field is not annotated but the constructor parameter is; luckily though case classes don't make any sense in a UiBinder setter-injection context (yet worth mentioning).

So, if we could use un-annotated setters in GWT then I think that it would be a great solution. If the implementation requires annotations on the setter then we'll have to change the current contract between annotations on fields and their helper methods (read: this is probably a bad idea).

[Stefan Endrullis]

Am 31.01.2012 01:02, schrieb Nate Bauernfeind:
> Case classes are a corner case where the field is not annotated but the constructor parameter is;

If you annotate your constructor parameter annotation with @annotation.target.field your parameter annotation will be assigned to the field as well. The same principle can be applied to getters and setters by using appropriate annotations in annotation.target. In order to avoid having to double annotate each parameter you can also use type definitions to keep the syntax concise, e.g.

type Index = org.hibernate.annotations.Index @field
case class(@Index id: Int)

Thus case classes should not be a handicap regarding this concern.

PS: Thanks to all of you for your great work on this project. I'm currently writing my Scala web 2.0 apps with Vaadin, but having the opportunity to write GWT components or whole GWT projects in Scala would be great.

Cheers,
Stefan

[Grzegorz Kossakowski]

On 31 January 2012 01:02, Nate Bauernfeind <nate.bau...@gmail.com> wrote:

I have ported a portion of the CellWidget demo over to scala. It uses UiBinder, and as far as I could tell everything would work if it could find the appropriate setter.

Here is an example error message: "The field CwCellList.pagerPanel is not visible"

It uses annotations in many convenient ways. The @UiField annotation links a particular widget on the UI to a specific member variable of the class.

GWT was actually finding these annotations on fields. I thought that I heard that jribble does not support annotations. I could not find any mention of the annotations in the jribbletxt. So, what is the story with annotations?

Jribble doesn't support annotations gut you should remember that we both compile to dribble and to byte code and we supply both to GWT. It looks like GWT uses byte code to find out about annotations. Actually, that was motivation for not adding annotation support to dribble as it seemed not necessary.

 

I've decompiled an annotated field and only the field retains the annotation (the methods contain none). Case classes are a corner case where the field is not annotated but the constructor parameter is; luckily though case classes don't make any sense in a UiBinder setter-injection context (yet worth mentioning).

So, if we could use un-annotated setters in GWT then I think that it would be a great solution. If the implementation requires annotations on the setter then we'll have to change the current contract between annotations on fields and their helper methods (read: this is probably a bad idea).

I'm not sure if I follow the last paragraph. Do you mean we would alter GWT implementation so it could resolve field access through accessor methods?

--
Grzegorz Kossakowski

[Lex Spoon]

On Tue, Jan 31, 2012 at 7:55 AM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> I'm not sure if I follow the last paragraph. Do you mean we would alter GWT
> implementation so it could resolve field access through accessor methods?

That sounds like a good strategy to me. It is hopefully a simple
update to UIBinder, and it will allow Scala code, written in normal
Scala style, to reliably work. -Lex

[Nate Bauernfeind]

Yes that was what I was hoping to be able to do. I'd definitely want it contained inside of UiBinder to start with. I hadn't had a chance to chase down a solution as my quick-and-dirty search of "is not visible" came up empty.

If someone else isn't already planning on jumping on this I could make it a priority; UiBinder is a must-have for me.

[Grzegorz Kossakowski]

On 31 January 2012 18:40, Nate Bauernfeind <nate.bau...@gmail.com> wrote:

Yes that was what I was hoping to be able to do. I'd definitely want it contained inside of UiBinder to start with. I hadn't had a chance to chase down a solution as my quick-and-dirty search of "is not visible" came up empty.

If someone else isn't already planning on jumping on this I could make it a priority; UiBinder is a must-have for me.

I don't think anybody is planning to work on it so feel free to take it!

Also, it came to my mind that there is a bit of difference between accessing fields directly or through getter in Java. In the first case field access is dispatched statically and in the second one it's being dispatched dynamically. I don't know if UiBinder implementation relies on static dispatch but I'd check it upfront. Maybe asking GWT devs is a good idea. This is the only issue I can think of that might be problematic/tricky.

--
Grzegorz Kossakowski

[Nate Bauernfeind]

"ant test" fails on the current master of scalagwt-gwt. It first fails on the style check and then if commented out of the build.xml file it fails compiling tests. First compilation failure is a discrepancy between MockCompilationUnit and CompilationUnit which seems to have resulted from Lex Spoon's latest pull request; though I don't know if they were passing before that pull request anyways.

I've implemented (or hacked together really... since, again, I'm not familiar with the code base) setter support for UiBinder. I tossed together two simple tests, but I don't really know if the tests themselves pass. I've built and used the gwt jars successfully in altered versions of the current scalagwt-sample.

Pull Request is here:

https://github.com/scalagwt/scalagwt-gwt/pull/29

I'm completely open to any better ideas (like increasing the restrictions on what methods are considered setters).

[Grzegorz Kossakowski]

Hi Nate,

FYI: I'm offline these days (skiing, I'm having well-deserved break) but I'll have a look once I'm back to work. This should happen by Sunday.

-- 

Grzegorz

--
Grzegorz Kossakowski

[Lex Spoon]

Great news about the UiBinder progress! A couple of little notes:

On Wed, Feb 8, 2012 at 2:21 AM, Nate Bauernfeind
<nate.bau...@gmail.com> wrote:
> "ant test" fails on the current master of scalagwt-gwt. It first fails on
> the style check and then if commented out of the build.xml file it fails
> compiling tests. First compilation failure is a discrepancy between
> MockCompilationUnit and CompilationUnit which seems to have resulted from
> Lex Spoon's latest pull request; though I don't know if they were passing
> before that pull request anyways.

We need to get this stuff working.

The style check passed for me before I put out the pull request, so
there must be some kind of merge issue. It should be something simple,
whatever the problem is.

Regarding MockCompilationUnit, I didn't try running "ant test". Crud.
This particular problem should be very easy to fix. It's just a mock,
and the missing method should return 0 or null or the like.

>
> I've implemented (or hacked together really... since, again, I'm not
> familiar with the code base) setter support for UiBinder. I tossed together
> two simple tests, but I don't really know if the tests themselves pass. I've
> built and used the gwt jars successfully in altered versions of the current
> scalagwt-sample.
>
> Pull Request is here:
> https://github.com/scalagwt/scalagwt-gwt/pull/29

Organizationally, let's put this on a branch, or possibly as an issue
filed directly with the GWT project.

I expect the GWT team will really like this patch, but I don't want to
muddy the waters around the core Jribble patch. A lot is riding on
whether the core patch goes in or not.

Lex

[Nate Bauernfeind]

On Wed, Feb 8, 2012 at 4:48 PM, Lex Spoon <l...@lexspoon.org> wrote:

Great news about the UiBinder progress!  A couple of little notes:

On Wed, Feb 8, 2012 at 2:21 AM, Nate Bauernfeind
<nate.bau...@gmail.com> wrote:
> "ant test" fails on the current master of scalagwt-gwt. It first fails on
> the style check and then if commented out of the build.xml file it fails
> compiling tests. First compilation failure is a discrepancy between
> MockCompilationUnit and CompilationUnit which seems to have resulted from
> Lex Spoon's latest pull request; though I don't know if they were passing
> before that pull request anyways.

We need to get this stuff working.

I'll try and get the GWT build going -- just wanted to make sure it was an oversight and not intentional =).

 

The style check passed for me before I put out the pull request, so
there must be some kind of merge issue. It should be something simple,
whatever the problem is.

Regarding MockCompilationUnit, I didn't try running "ant test". Crud.
This particular problem should be very easy to fix. It's just a mock,
and the missing method should return 0 or null or the like.

>
> I've implemented (or hacked together really... since, again, I'm not
> familiar with the code base) setter support for UiBinder. I tossed together
> two simple tests, but I don't really know if the tests themselves pass. I've
> built and used the gwt jars successfully in altered versions of the current
> scalagwt-sample.
>
> Pull Request is here:
> https://github.com/scalagwt/scalagwt-gwt/pull/29

Organizationally, let's put this on a branch, or possibly as an issue
filed directly with the GWT project.

I expect the GWT team will really like this patch, but I don't want to
muddy the waters around the core Jribble patch. A lot is riding on
whether the core patch goes in or not.

That's a fantastic idea! Thanks! I'll file the issue directly on the main branch. Do you think this solution is reasonable to propose to the GWT team or do you think the definition of a setter should be more strict?

Nate

[Lex Spoon]

Okay I have looked at the patch now.

It looks quite good to me. Like you say, it is possible to quibble
around about what counts as a setter method. In practice, though, any
definition will suffice so long as it supports the usual Java idiom as
well as the usual Scala idiom.

The test cases are particularly good. One is for a Java bean kind of
setter, the other for a Scala setter.

Lex

[Lex Spoon]

On Thu, Feb 9, 2012 at 12:09 AM, Lex Spoon <l...@lexspoon.org> wrote:
> Okay I have looked at the patch now.
>
> It looks quite good to me.

Also, I meant to say, it looks great for submission to the GWT project
directly. I am sure "ant test" will pass for you if you do a fresh
checkout. One of the Scala+GWT edits must have made them regress.
-Lex

[Grzegorz Kossakowski]

(I'm back from Jfokus and I'll more responsive again)

On 8 February 2012 23:48, Lex Spoon <l...@lexspoon.org> wrote:

Organizationally, let's put this on a branch, or possibly as an issue

filed directly with the GWT project.

What about having the following structure of branches:

• gwtpatch - based on current contents of scalagwt, intended to be clean and small patch that adds jribble support
• uibinder - work on supportin UiBinder for Scala
• ... - all other topic branches
• scalagwt - branch that merges all other branches and from which we cut our releases (I really want 0.1 release to happen soon).

The idea behind this structure is that we will have minimal, core jribble patch ready for submission but at the same time we'll have an option to work on exciting additional features like UiBinder support. Also, we'll have an option to cut releases easily so users can try our work easily.

WDYT?

 

I expect the GWT team will really like this patch, but I don't want to
muddy the waters around the core Jribble patch. A lot is riding on
whether the core patch goes in or not.

I talked to several people about this and I think we have an window of opportunity now. Also, it appears like I'll have some more spare time in upcoming weeks so I'll work on polishing our patch. Any help is welcome.

--
Grzegorz

[Lex Spoon]

On Fri, Feb 17, 2012 at 12:31 PM, Grzegorz Kossakowski
<grzegorz.k...@gmail.com> wrote:
> What about having the following structure of branches:
>
> gwtpatch - based on current contents of scalagwt, intended to be clean and
> small patch that adds jribble support
> uibinder - work on supportin UiBinder for Scala
> ... - all other topic branches
> scalagwt - branch that merges all other branches and from which we cut our
> releases (I really want 0.1 release to happen soon).

Sounds great to me. -Lex