¿Cuándo debo llamar al método de inicio() de los widgets instalados programáticamente?

Question

Creo instancias de dijit.layout.ContentPane, dijit.layout.StackContainer y dijit.layout.BorderContainer desde mi código JS.

Parece que tengo que llamar al método startup() de las instancias programadas. Sin embargo, no estoy seguro de tener que llamarlo para cada widget. Por ejemplo, cuando hago un 'new my.foo.widget()', el startup() se dispara automáticamente.

Gracias por ayudarme a entender cuándo llamar al método startup()!

Answer 1

startup() se define en _Widget, y es simplemente una "parte del ciclo de vida". Es el último paso en el ciclo de vida del widget, y no es requerido por todos los widgets. El caso más común donde es absolutamente necesario es cuando se crean programáticamente widgets de diseño. Se utiliza como una forma de evitar cálculos redundantes cuando los niños necesitan dimensionamiento. Por ejemplo, un BorderContainer.

var bc = new dijit.layout.BorderContainer({ 
    style:"height:200px; width:200px" 
}); 

// can call bc.startup() now, and the BorderContainer will resize 
// all children each time a new child is added. Or, we can add all 
// our children now, then trigger startup() and do it all at once. 

var top = new dijit.layout.ContentPane({ 
    region:"top", style:"height:100px" 
}).placeAt(bc); 
var mid = new dijit.layout.ContentPane({ region:"center" }).placeAt(bc); 

// now BC will do the calculations, rather than in between each 
// the above addChild/placeAt calls. 
bc.startup(); 

inicio es llamado automáticamente por el analizador en el caso de parseOnLoad: ejecución verdadera o manual. El analizador retrasa la invocación de inicio() hasta que todos los widgets secundarios encontrados se hayan instanciado correctamente.

dijit.Dialog es un caso extraño. También se debe llamar a startup() en este widget.

var dialog = new dijit.Dialog({ title:"Hmm", href:"foo.html" }); 
dialog.startup(); 
dialog.show(); 

mayoría de los widgets NO requieren startup llamada, pero en los casos en los que algo heredando de _Widget no anula el miembro de puesta en marcha, la llamada es esencialmente un entorno no-op this._started = true; Si crea su propia función de inicio(), debe llamar a this.heherited (arguments) o simplemente configurar el trigger _started manualmente.

En Dojo 1.4, el ciclo de vida aquí se ha ajustado ligeramente.Anteriormente, un widget con widgetsInTemplate: true llamaría a startup() en los widgets secundarios ANTES del inicio() en el elemento primario. En 1.4, el inicio de los niños() se llamará DESPUÉS del inicio padre(). Este comportamiento es recursivo para todos los niveles de widgets anidados con widgetsInTemplate: true se crean instancias.

Siempre es "seguro" llamar a .startup(), aunque si "sabe" (porque es un widget de punto final simple o su propio código _Widget personalizado) puede omitir la llamada.

Answer 2

¿Estás seguro de que se llama automáticamente o tienes un código en tu widget que lo llame?

Es una buena práctica llamarlo ya que establece _started en true, que es utilizado por bastantes widgets para determinar el comportamiento y/o el diseño. La mayoría de los widgets requieren que lo llames (como has visto).

startup es muy utilizado por widgets compuestos que necesitan controlar subwidgets.

Básicamente, todo lo que hereda de dijit._Widget debe llamar al inicio después de la creación de instancias.

EDITS:

hay una article on SitePen sobre el ciclo de vida dijit que analiza la puesta en marcha de un bit en el propio artículo y en los comentarios. Sin embargo, tengo más de dos años y creo que las cosas han cambiado.

El O'Reilly dojo book también habla sobre el inicio, pero dice que debe llamarse a los widgets de containiner. Tuve que llamarlo a la red, así que tampoco tiene sentido.

Realmente no duele nada al llamarlo (a menos que lo llame antes de que los niños se agreguen a su widget). Yo diría que siempre lo llames.

Answer 3

startup (originating from dijit._Widget) 

Para los widgets secundarios declarados en el marcado, este método se dispara automáticamente una vez que se han creado el widget y todos los widgets secundarios. Como tal, este es el primer lugar seguro que un widget hijo podría hacer referencia de forma segura a un niño. Tan simple como suena, esta tarea a menudo se intenta en postCreate, lo que puede conducir a un comportamiento incoherente que puede ser difícil de detectar y reparar. Para los widgets creados mediante programación que contienen otros widgets secundarios como parte de una relación has-a, deberá llamar manualmente al inicio usted mismo cuando esté seguro de que se han creado todos los widgets secundarios. La razón por la que debe llamarlo usted mismo para los widgets creados por programación que contienen elementos secundarios es porque no tendría sentido proceder con el tamaño y la representación, a menos que se hayan agregado todos los widgets secundarios. (De lo contrario, podría haber muchos inicios en falso). Este método es el último trozo de método que puede anular para que ocurra un comportamiento personalizado durante la construcción de dijit.