Question

Are there any advantages (other than clean code and the like) of using @UiFactory to construct widgets as opposed to declaring them in @UiField and then making additions/changes in the code after the initWidget()?

Was it helpful?

Solution

  • You can of course use @UiField to let UiBinder instantiate the fields for you during createAndBindUi(). You can then modify them afterwards.
  • You can of course use @UiField(provided=true), and instantiate the fields yourself, before calling createAndBindUi(). (This way, you can use any constructor you like, and it also allows for Dependency Injection.) And obviously, you can still modify them after createAndBindUi().

So what's the point of @UiFactory? Well, I use it sometimes, when I have many similar elements in the same ui.xml file. So e. g. I have a page that shows a keypad with digits 0-9. Instead of having ten @UiFields, I prefer to use @UiFactory, which constructs the widgets, and puts them in a java.util.Map (plus performs some common setup).

OTHER TIPS

There might be parameters to your UiBinder file that can not be constructed using a simple constructor (e.g. a CssResource to share styles across many UiBinder files). Using @UiFactory you can inject those resources into your UiBinder file.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top