Pregunta

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()?

¿Fue útil?

Solución

  • 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).

Otros consejos

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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top