veo que hay mucho de la de los ejemplos en extjs donde en vez de en realidad la creación de objetos ExtJS, un literal de objeto con una propiedad xtype se pasa enextjs: lo que es bueno para xtype
¿Qué es esto bueno para.? ¿Dónde está la ganancia de rendimiento (si ese es el motivo) si el objeto se va a crear de todos modos?
xtype es una forma abreviada para identificar los componentes particulares: 'Panel' = Ext.Panel, 'campo de texto' = Ext.form.TextField, etc. Cuando crea una página o un formulario, puede usar estos xtypes en lugar de crear objetos. Por ejemplo,
items: [{
xtype: 'textfield',
autoWidth: true,
fieldLabel: 'something'
}]
Además, la creación de páginas de esta manera permite ExtJS to render lazily the page. Aquí es donde ves una "ganancia de rendimiento". En lugar de crear una gran cantidad de componentes cuando se carga la aplicación, ExtJS representa componentes cuando el usuario necesita verlos. No es un gran problema si tiene una página, pero si explota pestañas o un acordeón, muchas páginas se ocultan inicialmente y, por lo tanto, la aplicación se cargará más rápidamente.
Además, puede crear y registrar nuevos componentes creando los tipos de letra que desee. ExtJS procesará sus componentes de forma similar.
También puede recuperar componentes por ID. Dado que su componente (así como los componentes ExtJS) pueden proporcionar un buen comportamiento, a veces es conveniente buscar y recuperar un componente en lugar de un simple elemento o nodo DOM.
En resumen, los componentes xtypes identifican componentes y componentes son un aspecto clave de ExtJS.
Creo que puede haber creado una dicotomía falsa cuando dice que "en lugar de crear una gran cantidad de componentes cuando se carga la aplicación". Tengo mucha curiosidad por saber si crees o no que no hay otra forma de instanciar un componente cuando es necesario y luego destruirlo cuando no es así. – RibaldEddie
es posible que desee mencionar cómo se refiere a un alias usando widget() o ComponentQuery() –
. Vale la pena mencionar que al usar xtypes, la clase debe cargarse por adelantado, no puede usar la carga de clase dinámica de ext. En ese caso, tiene que 'Ext.create' ('full.clazz.Name', {}) 'que realmente crea una llamada AJAX síncrona (si aún no está cargada). –
xtypes in ext no es para el rendimiento. Es fácil de codificar. Con la ayuda del código xtype se hace más corto, fácil de leer y comprender, especialmente si está creando un Ext.form.FormPanel y tiene muchos textareas, datefields, combos, etc. ... Por ejemplo: es útil cuando cada campo de fecha de la forma debe tener un formato como 'dmY', no necesita escribir separadamente format: 'dmY' para cada campo de fecha, solo debe escribir en los valores predeterminados de los objetos de configuración: {format: 'dmY'} ... hay muchos casos cuando xtype Shorters el código ...
En conclusión: es fácil de código ...
se olvidó de la representación vaga. "Etapa superior" lo explicó bien. – Zango
xtypes son más sobre el rendimiento y menos sobre la facilidad de codificación: pero * lo hacen * conducen a un ensamblaje de componentes más basado en configuración, en lugar del enfoque explícito (y feo) "crear un objeto en una var". –
Sí, la afirmación "xtype no es para el rendimiento" es simplemente incorrecta. Ese es uno de los propósitos principales de esto. –
Hice la misma pregunta que Joe, pero encontré la respuesta. Si utiliza xtype, un enfoque es también especificar un itemId en el mismo objeto:
{ itemId: 'myObject', xtype: '' myClass ... }
entonces usted puede encontrar con 'getComponent()', como en
this.getComponent('myObject');
Si usa Ext.ComponenQuery.query ('myClass') [0], entonces ni siquiera tiene que agregar el itemId. El índice [0] es necesario porque la consulta del componente siempre devuelve una matriz. –
Un xtype es simplemente un nombre dado para representar una clase. Es un objeto de definición que no necesita crearse una instancia cuando se usa en en cualquier parte de la aplicación.
Al registrar un xtype, simplemente usamos esta sintaxis: Ext.reg (,). Pero no usamos la palabra clave 'nueva' con el nombre de la clase porque el Component Mgr creará automáticamente una instancia de esta clase solo si es necesario, por ejemplo. en respuesta a un evento como hacer clic.
No es necesario obtener una instancia de forma manual porque después de registrar un xtype, el 'Component Mgr' creará automáticamente una instancia para la clase representada por ese xtype solo si se usa en cualquier lugar de la aplicación o simplemente don No cree una instancia de esa clase si no se usa en otro lugar. Mons componente se ejecuta este código:
create : function(config, defaultType){
return new types[config.xtype || defaultType](config);
}
xtype no una instancia de la clase cuando se ejecuta Ext.Ready. Sin embargo, el nuevo Ext.Container() creará todas las instancias cuando se ejecute Ext.Ready. Entonces, usar xtype es inteligente para aplicaciones grandes para deshacerse de objetos basura.
Soy nuevo en Sencha/Ext JS pero creo que en este punto la extraña noción de tener una cadena de identificador de definición abreviada solo para los componentes de UI debe ser para satisfacer a los usuarios heredados.
mirada a la "Lista de xtypes" aquí: http://docs.sencha.com/touch/2-0/#!/guide/components
¿Hay alguna buena razón para usar uno similar, pero no del todo-el-mismo identificador de cadena como el nombre de "clase" como la definición de taquigrafía identificador? No lo creo.
Comprobar la siguiente muestra de algunos xtype a asignaciones de nombre de clase para Sencha táctil:
video - Ext.Video carousel - Ext.carousel.Carousel carouselindicator - Ext.carousel.Indicator navigationview - Ext.navigation.View datepicker - Ext.picker.Date Algunos de los argumentos anteriores para xtype eran que permitió instanciación diferido de componentes. Creo que eso es completamente irrelevante: lo que permite la instanciación diferida es el hecho de que Sencha/Ext JS admite la especificación de un identificador de cadena en lugar de un componente instanciado en una jerarquía de vista.
El mapeo de una cadena en particular a un componente en particular que podría ser instanciado posteriormente es completamente arbitrario, y en el caso de Sencha/Ext JS, desafortunadamente tonto (ver ejemplos más arriba).
Al menos simplemente siga un patrón razonable, por ejemplo, ¿por qué una Ext.Label no podría tener un "xtype" de Label? Demasiado simple?
En realidad, sé por qué, es porque hicieron x tipos de nombres que leen bien, hay muchos nombres de clases repetidos que no funcionarían (Ext.Panel y Ext.tab.Panel) y pickerDate sonarían estúpidos.
Pero todavía no me gusta, es un atajo pequeño e irregular que ofusca más de lo que ayuda.
Si se declara una clase y darle un xtype, se puede consultar posteriormente con Ext.ComponentQuery.query()
Por ejemplo:
Ext.create('MyApp.view.MyButton', {
xtype: 'mybutton',
.....
});
adelante en el código, si lo hace:
var buttonArray = Ext.ComponentQuery.query('mybutton');
luego buttonArray contendrá una matriz de componentes de ese tipo de clase. Si crea componentes en línea, la consulta de su componente será más compleja.
Otra ventaja de xtypes es que si mueve sus clases (digamos que agrega otro subdirectorio bajo "vista": MyApp.view.button.MyButton), las consultas de sus componentes pueden seguir siendo las mismas, ya que su xtype no cambia. Una vez que su proyecto sea grande, comenzará a crear subdirectorios y mover las clases.
http://www.sencha.com/learn/legacy/Tutorial:Xtype_defined –