Hi Thomas,
I decided to put the library as you suggested in a separate project, and to
make it evolve to a state where it can be presented as an alternative to
UiBinder. Here's the link, all unit tests pass.
If any body wants to contribute, you're welcome
I created an
issuehttps://code.google.com/p/google-web-toolkit/issues/detail?id=8735where
I specify more clearly the change
proposal: https://code.google.com/p/google-web-toolkit/issues/detail?id=8735
I'm getting this message:
I'm just unable to push the code for review
Tue May 27
You have to push to the special reference refs/for/master to create a
review to be merged to the 'master' branch.
git push origin HEAD:refs/for/master
(replace HEAD with a local branch if you don't want to push the current
commit but another reference/commit)
Note, you also have to install
Hi Colin,
Thanks for your reply. I'm now convinced you have a pretty stable vision of
the rules of UiBinder, I wanted to let the community be able to have my
modificatio that I find very valuable, that's why I was spamming yesterdy
(sunday), before I leave this part of the project and get less
There's one big flaw with your proposal: it's not really “transparent”;
the code “using” it has to know it's there (i.e. it's not AOP as you
described it), because some @UiField could be 'null' or not visible
(depending on actual implementation).
I believe applying such a rule as “this
I forgot to say it's done and it works, I can submit the code under that
bug id, but since the bug was closed I'm trying to justify why I think this
feature is important
--
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from
This seems to be a pretty quiet discussion so far, with mostly Zied
responding to himself and Thomas’s one initial reply, but it is a holiday
weekend here in the US, so that might be contributing to the lack of
additional responses. I haven’t had the chance to even look at the initial
proposal
There's one big flaw with your proposal: it's not really “transparent”;
the code “using” it has to know it's there (i.e. it's not AOP as you
described it), because some @UiField could be 'null' or not visible
(depending on actual implementation).
I believe applying such a rule as “this
After doing the patch I can tell you the main points and benefits of the
change:
To be able to do the job, I had to change the signature
of AbstractFieldWriter.writeFieldDefinition() to make it aware of the
context of the field (the document that declares the field)
On Friday, May 23, 2014 3:59:35 PM UTC+2, Zied Hamdi OneView wrote:
Hi,
I want to talk about GWT authorizations to brainstorm an architecture that
supports it natively.
It's somehow surprising a framework that is in advance (adopted the Fog
computing more than 5 years ago) doesn't
10 matches
Mail list logo
