Re: Possible RFE: Make UiBinder aware of IsWidget interfaces

2014-05-18 Thread Kay Pac
I've been trying to learn UiBinder with some success although I am at the 
beginning stages. I've been trying to embed one view inside another in a 
way similar to, or the same as, the original poster. I haven't had success 
at all because I don't understand how these classes work. My case certainly 
does not warrant the approach as everything is very simple at this point 
with just a few widgets, but this is mostly a learning exercise. I haven't 
had a lot of luck with documentation for this sort of approach.

I guess my question is how do I instantiate my own widget inside of a 
UiBinder template? I've been pointed in the direction of @UiChild, but all 
the example references a 'p' xml namespace that I don't have declared in my 
UiBinder template. 
From 
http://www.gwtproject.org/javadoc/latest/com/google/gwt/uibinder/client/UiChild.html

For example, @UiChild MyWidget#addCustomChild(Widget w) and

   p:MyWidget
 p:customchild
   g:SomeWidget /
 /p:customchild
   /p:MyWidget
 

I don't understand what this means. What is the 'Widget w' that is passed 
in as the first argument? What is SomeWidget verus MyWidget? What is the 
namespace uri for 'p'?  I'm sorry if these questions are simplistic or 
answered elsewhere, I simply haven't had luck tracking down answers.

Thanks,

Kay

On Friday, July 20, 2012 11:43:31 AM UTC-7, Thomas Broyer wrote:

 In the rare cases where a widget is complex enough to deserve an MVP 
 pattern, I generally use the XViewImpl directly in the UiBinder (YViewImpl) 
 of the other widget, and create the XPresenter from within the YPresenter 
 (asking the YView for an XView, similar to what Wave is doing –when 
 creating those things dynamically though in their case–, see 
 http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html
 )
 I only ever need it on a very few cases though, I don't use MVP as a 
 general rule on widgets, only on activities (or similar), that is, 
 coarse-grained. And I never needed to add specific styling or similar to 
 these widgets.

 For complex widgets that need to be reused easily and widely, I'd rather 
 follow the Cell widget's way: the presenter is internal to the widget; MVP 
 is an implementation detail, from the outside it's just a widget like any 
 other.

 Last but not least, there's still the idea of making UiBinder more 
 Guice-friendly, so you could provide a factory to the UiBinder rather (or 
 in addition) to @UiFactory methods. That would allow the use of a Ginjector 
 or an AssistedInject factory shared by several UiBinder throughout the app, 
 instead of having to duplicate trampoline @UiFactory methods in each and 
 every ViewImpl: 
 http://code.google.com/p/google-web-toolkit/issues/detail?id=6151
 The only issue for now (AFAICT) is to find the time to implement it.

 On Friday, July 20, 2012 6:42:02 PM UTC+2, Jens wrote:

 Hi,

 I am using GIN + MVP + UiBinder so I end up with having:

 - MyView.java (Interface, extends IsWidget)
 - MyViewImpl.java (UiBinder, implements MyView)

 Now when I want to use MyView inside a different UiBinder widget I inject 
 the interface and use it along with @UiField(provided = true). 

 That works great but as a little downside I have to re-declare Widget 
 methods in my MyView interface if I want to call them directly in UiBinder, 
 e.g. setWidth/setHeight/setStyleName. 

 For setter methods that also works, but now I need to add some styles to 
 MyView. In UiBinder you would normally do my:MyView addStyleNames=list of 
 styles/ but that fails in case of my view interface (error is: 
 setAddStyleNames() is not declared). Actually UiBinder special treats 
 addStyleNames for normal widgets (it works with my:MyViewImpl 
 addStyleNames=...) but it stops doing so when it sees something that does 
 not extend Widget I guess. To solve this I am forced to create an Interface 
 for my UiBinder inline CssResource just to be able to do: 
 myView.asWidget().addStyleName(..).

 How do you guys work with view interfaces in UiBinder? Are there better 
 ways than mine?

 My proposed RFE for UiBinder would be that UiBinder recognizes interfaces 
 that extend IsWidget and then generates code that delegates to 
 view.asWidget().method() as long as method() is available in Widget or 
 UiObject class. Any opinions?

 -- J.



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.


Re: Possible RFE: Make UiBinder aware of IsWidget interfaces

2012-10-08 Thread Mike
Thomas,

The issue described by Jens doesn't seem to inherently involve MVP -- I 
don't quite follow the first part of your response. It seems like any 
widget, no matter how dumb, could implement IsWidget directly rather than 
extend Composite or a more concrete Widget supertype.

Do you think his suggested approach is feasible, namely having UiBinder be 
able to correctly interpret Widget attributes/setters (like 
addStyleNames=..) for IsWidget types?

On Friday, July 20, 2012 2:43:31 PM UTC-4, Thomas Broyer wrote:

 In the rare cases where a widget is complex enough to deserve an MVP 
 pattern, I generally use the XViewImpl directly in the UiBinder (YViewImpl) 
 of the other widget, and create the XPresenter from within the YPresenter 
 (asking the YView for an XView, similar to what Wave is doing –when 
 creating those things dynamically though in their case–, see 
 http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html
 )
 I only ever need it on a very few cases though, I don't use MVP as a 
 general rule on widgets, only on activities (or similar), that is, 
 coarse-grained. And I never needed to add specific styling or similar to 
 these widgets.

 For complex widgets that need to be reused easily and widely, I'd rather 
 follow the Cell widget's way: the presenter is internal to the widget; MVP 
 is an implementation detail, from the outside it's just a widget like any 
 other.

 Last but not least, there's still the idea of making UiBinder more 
 Guice-friendly, so you could provide a factory to the UiBinder rather (or 
 in addition) to @UiFactory methods. That would allow the use of a Ginjector 
 or an AssistedInject factory shared by several UiBinder throughout the app, 
 instead of having to duplicate trampoline @UiFactory methods in each and 
 every ViewImpl: 
 http://code.google.com/p/google-web-toolkit/issues/detail?id=6151
 The only issue for now (AFAICT) is to find the time to implement it.

 On Friday, July 20, 2012 6:42:02 PM UTC+2, Jens wrote:

 Hi,

 I am using GIN + MVP + UiBinder so I end up with having:

 - MyView.java (Interface, extends IsWidget)
 - MyViewImpl.java (UiBinder, implements MyView)

 Now when I want to use MyView inside a different UiBinder widget I inject 
 the interface and use it along with @UiField(provided = true). 

 That works great but as a little downside I have to re-declare Widget 
 methods in my MyView interface if I want to call them directly in UiBinder, 
 e.g. setWidth/setHeight/setStyleName. 

 For setter methods that also works, but now I need to add some styles to 
 MyView. In UiBinder you would normally do my:MyView addStyleNames=list of 
 styles/ but that fails in case of my view interface (error is: 
 setAddStyleNames() is not declared). Actually UiBinder special treats 
 addStyleNames for normal widgets (it works with my:MyViewImpl 
 addStyleNames=...) but it stops doing so when it sees something that does 
 not extend Widget I guess. To solve this I am forced to create an Interface 
 for my UiBinder inline CssResource just to be able to do: 
 myView.asWidget().addStyleName(..).

 How do you guys work with view interfaces in UiBinder? Are there better 
 ways than mine?

 My proposed RFE for UiBinder would be that UiBinder recognizes interfaces 
 that extend IsWidget and then generates code that delegates to 
 view.asWidget().method() as long as method() is available in Widget or 
 UiObject class. Any opinions?

 -- J.



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/cHLF8qSMNLwJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Possible RFE: Make UiBinder aware of IsWidget interfaces

2012-10-08 Thread Chris Lercher
On Friday, July 20, 2012 6:42:02 PM UTC+2, Jens wrote:

 Actually UiBinder special treats addStyleNames for normal widgets (it 
 works with my:MyViewImpl addStyleNames=...) but it stops doing so when it 
 sees something that does not extend Widget I guess.


FYI, this is true, the special code is in

  com.google.gwt.uibinder.elementparsers.UIObjectParser

which is registered in 
com.google.gwt.uibinder.rebind.UiBinderWriter.registerParsers() 

That method already contains a code comment:

// TODO(rjrjr): Allow third-party parsers to register themselves
// automagically

Then again, if such a parser were registered, it probably shouldn't be 
registered for IsWidget, but instead for a new Interface that contains the 
addStyleName method.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/KD9538Bd7TwJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Possible RFE: Make UiBinder aware of IsWidget interfaces

2012-07-20 Thread Jens
Hi,

I am using GIN + MVP + UiBinder so I end up with having:

- MyView.java (Interface, extends IsWidget)
- MyViewImpl.java (UiBinder, implements MyView)

Now when I want to use MyView inside a different UiBinder widget I inject 
the interface and use it along with @UiField(provided = true). 

That works great but as a little downside I have to re-declare Widget 
methods in my MyView interface if I want to call them directly in UiBinder, 
e.g. setWidth/setHeight/setStyleName. 

For setter methods that also works, but now I need to add some styles to 
MyView. In UiBinder you would normally do my:MyView addStyleNames=list of 
styles/ but that fails in case of my view interface (error is: 
setAddStyleNames() is not declared). Actually UiBinder special treats 
addStyleNames for normal widgets (it works with my:MyViewImpl 
addStyleNames=...) but it stops doing so when it sees something that does 
not extend Widget I guess. To solve this I am forced to create an Interface 
for my UiBinder inline CssResource just to be able to do: 
myView.asWidget().addStyleName(..).

How do you guys work with view interfaces in UiBinder? Are there better 
ways than mine?

My proposed RFE for UiBinder would be that UiBinder recognizes interfaces 
that extend IsWidget and then generates code that delegates to 
view.asWidget().method() as long as method() is available in Widget or 
UiObject class. Any opinions?

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/RTfPijTD_xoJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.



Re: Possible RFE: Make UiBinder aware of IsWidget interfaces

2012-07-20 Thread Thomas Broyer
In the rare cases where a widget is complex enough to deserve an MVP 
pattern, I generally use the XViewImpl directly in the UiBinder (YViewImpl) 
of the other widget, and create the XPresenter from within the YPresenter 
(asking the YView for an XView, similar to what Wave is doing –when 
creating those things dynamically though in their case–, see 
http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html
)
I only ever need it on a very few cases though, I don't use MVP as a 
general rule on widgets, only on activities (or similar), that is, 
coarse-grained. And I never needed to add specific styling or similar to 
these widgets.

For complex widgets that need to be reused easily and widely, I'd rather 
follow the Cell widget's way: the presenter is internal to the widget; MVP 
is an implementation detail, from the outside it's just a widget like any 
other.

Last but not least, there's still the idea of making UiBinder more 
Guice-friendly, so you could provide a factory to the UiBinder rather (or 
in addition) to @UiFactory methods. That would allow the use of a Ginjector 
or an AssistedInject factory shared by several UiBinder throughout the app, 
instead of having to duplicate trampoline @UiFactory methods in each and 
every 
ViewImpl: http://code.google.com/p/google-web-toolkit/issues/detail?id=6151
The only issue for now (AFAICT) is to find the time to implement it.

On Friday, July 20, 2012 6:42:02 PM UTC+2, Jens wrote:

 Hi,

 I am using GIN + MVP + UiBinder so I end up with having:

 - MyView.java (Interface, extends IsWidget)
 - MyViewImpl.java (UiBinder, implements MyView)

 Now when I want to use MyView inside a different UiBinder widget I inject 
 the interface and use it along with @UiField(provided = true). 

 That works great but as a little downside I have to re-declare Widget 
 methods in my MyView interface if I want to call them directly in UiBinder, 
 e.g. setWidth/setHeight/setStyleName. 

 For setter methods that also works, but now I need to add some styles to 
 MyView. In UiBinder you would normally do my:MyView addStyleNames=list of 
 styles/ but that fails in case of my view interface (error is: 
 setAddStyleNames() is not declared). Actually UiBinder special treats 
 addStyleNames for normal widgets (it works with my:MyViewImpl 
 addStyleNames=...) but it stops doing so when it sees something that does 
 not extend Widget I guess. To solve this I am forced to create an Interface 
 for my UiBinder inline CssResource just to be able to do: 
 myView.asWidget().addStyleName(..).

 How do you guys work with view interfaces in UiBinder? Are there better 
 ways than mine?

 My proposed RFE for UiBinder would be that UiBinder recognizes interfaces 
 that extend IsWidget and then generates code that delegates to 
 view.asWidget().method() as long as method() is available in Widget or 
 UiObject class. Any opinions?

 -- J.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/W2jRF7u5zcMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.