Creando elementos de formulario usando Zend_Form_Element
Un formulario esta compuesto de elementos, que normalmente corresponden
al elemento HTML input. Zend_Form_Element encapsula
elementos de formulario individualmente, con las siguientes áreas de
responsabilidad:
validación (¿los datos enviados son válidos?)
captura de códigos y mensajes de error
filtrado (¿cómo es escapado y normalizado el elemento para su
validación y/o salida?
generación (¿cómo es mostrado el elemento?)
metadatos y atributos (¿qué información amplía la definición del
elemento?)
La clase base, Zend_Form_Element, funciona por defecto para
varios casos, pero es mejor extender la clase para elementos con fines
especiales de uso común. Adicionalmente, Zend Framework contiene un
número de elementos XHTML estándar; puede leer de ellos en el capítulo Elementos
Estándares
Cargadores de PluginZend_Form_Element hace uso de Zend_Loader_PluginLoader
para permitir a los desarrolladores especificar ubicaciones de
validadores, filtros y decoradores alternos. Cada uno tiene su
propio cargador de plugin asociado a él y métodos de acceso
generales usados para su recuperación y modificación.
Los siguientes tipos de cargadores son usados con los varios métodos
del cargador de plugin: 'validate', 'filter', y 'decorator'. Los
nombres son sensibles a mayúsculas y minúsculas.
Los métodos usados para interactuar con los cargadores de plugin son
los siguientes:
setPluginLoader($loader, $type):
$loader es el propio objeto cargador, mientras
$type es uno de los tipos arriba mencionados. Esto
establece el cargador de plugin para el tipo dado en el objeto
cargador recién especificado.
getPluginLoader($type): obtiene el cargador de
plugin asociado con $type.
addPrefixPath($prefix, $path, $type = null): agrega
una asociación prefijo/ruta para el cargador especificado por
$type. Si $type es null, se intentará
agregar la ruta a todos los cargadores, añadiendo el prefijo a
cada "_Validate", "_Filter" y "_Decorator"; y agregandole
"Validate/", "Filter/" y "Decorator/" a la ruta. Si tiene todas
sus clases extras para elementos de formulario dentro de
una jerarquía común, este método es conveniente para establecer
el prefijo para todas ellas.
addPrefixPaths(array $spec): le permite añadir
varias rutas de una sola vez a uno o más cargadores de plugin.
Se espera cada elemento de la matriz sea un array con claves
'path', 'prefix', y 'type'.
Validadores, filtros y decoradores personalizados son una manera
simple de compartir funcionalidad entre formularios y encapsular
funcionalidad personalizada.
Etiqueta personalizada
Un uso común de los plugins es proveer reemplazos para las
clases estándares. Por ejemplo, si desea proveer una implementación diferente
del decorador 'Label' -- por ejemplo, para
añadir siempre dos puntos -- puede crear su propio decorador
'Label' con su propio prefijo de clase, y entonces añadirlo a su
prefijo de ruta.
Comencemos con un decorador de etiqueta personalizado. Le
daremos el prefijo "My_Decorator", y la clase estará en el
archivo "My/Decorator/Label.php".
getElement())) {
return $content;
}
if (!method_exists($element, 'getLabel')) {
return $content;
}
$label = $element->getLabel() . ':';
if (null === ($view = $element->getView())) {
return $this->renderLabel($content, $label);
}
$label = $view->formLabel($element->getName(), $label);
return $this->renderLabel($content, $label);
}
public function renderLabel($content, $label)
{
$placement = $this->getPlacement();
$separator = $this->getSeparator();
switch ($placement) {
case 'APPEND':
return $content . $separator . $label;
case 'PREPEND':
default:
return $label . $separator . $content;
}
}
}
]]>
Ahora diremos al elemento que use esta ruta cuando busque por
decoradores:
addPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');
]]>
Alternativamente, podemos hacerlo en el formulario para asegurar
que todos los decoradores usen esta ruta:
addElementPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');
]]>
Con esta ruta añadida, cuando agregue un decorador, la ruta
'My/Decorator' será consultada primero en búsqueda de la
existencia del decorador en este lugar. Como resultado,
'My_Decorator_Label' ahora será utilizado cuando el decorador
'Label' sea requerido.
Filters
A menudo es útil y/o necesario realizar alguna normalización en la
entrada antes de la validación – por ejemplo, puede querer eliminar
todo el HTML, pero realizar las validaciones sobre lo restante para
asegurarse que el envío es válido. O puede eliminar los espacios en
blanco al inicio o fin de la entrada para asegurarse de que un validador
StringLenth (longitud de la cadena) no regrese un positivo falso. Estas
operaciones pueden realizarse usando Zend_Filter, y
Zend_Form_Element que soportan cadenas de filtros,
permitiéndole especificar múltiples filtros secuenciales a utilizar.
El filtrado sucede tanto en la validación como cuando recupera el
valor del elemento vía getValue():
getValue();
]]>
Los filtros pueden ser agregados a la pila de dos maneras:
pasándolo en una instancia de filtro específica
proveyendo un nombre de filtro – el correspondiente nombre
corto o completo de la clase
Veamos algunos ejemplos:
addFilter(new Zend_Filter_Alnum());
// El correspondiente nombre completo de la clase:
$element->addFilter('Zend_Filter_Alnum');
// Nombre corto del filtro:
$element->addFilter('Alnum');
$element->addFilter('alnum');
]]>
Los nombres cortos son típicamente el nombre del filtro sin el
prefijo. En el caso predeterminado, esto se refiere a sin el prefijo
'Zend_Filter_'. Además, la primera letra no necesita estar en
mayúscula.
Usando clases de filtros personalizados
Si tiene su propio conjunto de clases de filtro, puede
informarle de ellas a Zend_Form_Element usando
addPrefixPath(). Por ejemplo, si tiene filtros
con el prefijo 'My_Filter', puede indicárselo a
Zend_Form_Element de la siguiente manera:
addPrefixPath('My_Filter', 'My/Filter/', 'filter');
]]>
(Recuerde que el tercer argumento indica el cargador de plugin
sobre el cual ha de ejecutarse la acción.)
Si en algún momento necesita un valor no filtrado, use el método
getUnfilteredValue():
getUnfilteredValue();
]]>
Para mayor información sobre filtros, vea la documentación de
Zend_Filter.
Métodos asociados con filtros incluyen:
addFilter($nameOfFilter, array $options = null)addFilters(array $filters)setFilters(array $filters) (sobreescribe todos los
filtros)
getFilter($name) (recupera un objeto filtro por su
nombre)
getFilters() (recupera todos los filtros)
removeFilter($name) (elimina un filtro por su
nombre)
clearFilters() (elimina todos los filtros)
Validadores
Si sigue el mantra de seguridad "filtrar la entrada, escapar la
salida" querrá validar ("filtrar la entrada") los datos de los
formularios. En Zend_Form cada elemento contiene su
propia cadena de validadores, consistente en validadores
Zend_Validate_*.
Los validadores pueden ser agregados de dos maneras:
pasándolo en una instancia de validador específica
proveyendo un nombre de validador – el correspondiente nombre
corto o completo de clase
Veamos algunos ejemplos:
addValidator(new Zend_Validate_Alnum());
// El correspondiente nombre completo de la clase:
$element->addValidator('Zend_Validate_Alnum');
// Nombre corto del validador:
$element->addValidator('Alnum');
$element->addValidator('alnum');
]]>
Los nombres cortos son típicamente el nombre del validador sin el
prefijo. En el caso predeterminado, esto se refiere a sin el prefijo
'Zend_Validate_'. Además, la primera letra no necesita estar en
mayúscula.
Usando clases de validación personalizadas
Si tiene su propio conjunto de clases de validación, puede
informarle de ellas a Zend_Form_Element usando
addPrefixPath(). Por ejemplo, si tiene validadores
con el prefijo 'My_Validator', puede indicárselo a
Zend_Form_Element de la siguiente manera:
addPrefixPath('My_Validator', 'My/Validator/', 'validate');
]]>
(Recuerde que el tercer argumento indica el cargador de plugin
sobre el cual ha de ejecutarse la acción.)
Si el fallo de un validador debe evitar validaciones posteriores,
pase el boleano true como segundo parámetro:
addValidator('alnum', true);
]]>
Si está usando la cadena nombre para añadir el validador, y la clase
del validador acepta argumentos para su constructor, puede pasarlos
a el tercer parámetro de addValidator() como un
array:
addValidator('StringLength', false, array(6, 20));
]]>
Los argumentos pasados de esta manera deben estar en el orden en el
cual son definidos en el constructor. El ejemplo de arriba
instanciará la clase Zend_Validate_StringLenth con los
parámetros $min y $max:
Estipulando mensajes de error de validación personalizados
Algunos desarrolladores querrán estipular mensajes de error
personalizados para un validador. El argumento
$options de
Zend_Form_Element::addValidator() le permite
hacerlo proporcionando la clave 'messages' y estableciendolos en
un array de pares clave/valor para especificar las plantillas
de mensaje. Necesitará conocer los códigos de error de los
diferentes tipos de error de un validador en particular.
Una opción mejor es usar Zend_Translate_Adapter
con su formulario. Los códigos de error son automáticamente
pasados al adaptador por el decorador Errors por defecto; puede
especificar su propias cadenas de mensaje de error mediante la
creación de traducciones para los varios códigos de error de
sus validadores.
Puede también establecer varios validadores a la vez, usando
addValidators(). Su uso básico es pasar una matriz de
arrays, donde cada array contenga de 1 a 3 valores,
correspondientes al constructor de addValidator():
addValidators(array(
array('NotEmpty', true),
array('alnum'),
array('stringLength', false, array(6, 20)),
));
]]>
Si quiere ser más detallado o explícito, puede utilizar las claves
'validator', 'breakChainOnFailure', y 'options' en el array:
addValidators(array(
array(
'validator' => 'NotEmpty',
'breakChainOnFailure' => true),
array('validator' => 'alnum'),
array(
'validator' => 'stringLength',
'options' => array(6, 20)),
));
]]>
Este uso es bueno para ilustrar cómo puede configurar validadores
en un archivo de configuración:
Note que cada elemento tiene una clave, la necesite o no; esta es
una limitación del uso de archivos de configuración -- pero también
ayuda a hacer más explicito el para qué son usados los argumentos.
Sólo recuerde que cualesquiera opciones del validador deben ser
especificadas en orden.
Para validar un elemento, pase el valor a
isValid():
isValid($value)) {
// válido
} else {
// no válido
}
]]>Validación operando en valores filtradosZend_Form_Element::isValid()> siempre filtra los
valores antes de la validación a través de la cadena de filtros.
Vea la sección de
filtros para más información.
Contexto de validaciónZend_Form_Element::isValid()> soporta un argumento
adicional, $context.
Zend_Form::isValid() pasa todo el conjunto de datos
procesados a $context cuando valida un formulario,
y Zend_Form_Element::isValid()>, a su vez, lo pasa a
cada validador. Esto significa que puede escribir validadores
que son conscientes de los datos pasados a otros elementos del
formulario. Como ejemplo, considere un formulario de registro
estándar que tiene campos para la contraseña y la confirmación
de la contraseña; una validación sería que los dos campos
coincidan. Este validador puede tener un aspecto como el
siguiente:
'Password confirmation does not match'
);
public function isValid($value, $context = null)
{
$value = (string) $value;
$this->_setValue($value);
if (is_array($context)) {
if (isset($context['password_confirm'])
&& ($value == $context['password_confirm']))
{
return true;
}
} elseif (is_string($context) && ($value == $context)) {
return true;
}
$this->_error(self::NOT_MATCH);
return false;
}
}
]]>
Los validadores son procesados en orden. Cada validador es
procesado, a menos que un validador creado con un valor true para
breakChainOnFailure falle su validación. Asegúrese de
especificar sus validadores en un orden razonable.
Después de una validación fallida, puede recuperar los códigos y
mensajes de error de la cadena del validador:
getErrors();
$messages = $element->getMessages();
]]>
(Nota: los mensajes de error retornados son un array asociativo de
pares código / mensaje de error.)
En adición a los validadores, puede especificar que un elemento es
necesario, usando setRequired(true). Por defecto, esta
bandera es false, lo que significa que pasará su cadena de
validadores si ningún valor es pasado a isValid().
Puede modificar este comportamiento en un número de maneras:
Por defecto, cuando un elemento es requerido, una bandera,
'allowEmpty', también es true. Esto quiere decir que si un
valor empty es evaluado pasándolo a isValid(),
los validadores serán saltados. Puede intercalar esta
bandera usando el método de acceso
setAllowEmpty($flag); cuando la bandera es
false, si un valor es pasado, los validadores seguirán
ejecutándose.
Por defecto, si un elemento es requerido, pero no contiene
un validador 'NotEmpty', isValid() añadirá uno
en la cima de la pila, con la bandera
breakChainOnFailure establecido. Esto hace que
la bandera requerida tenga un significado semántico: si
ningún valor es pasado, inmediatamente invalidamos el envío
y se le notifica al usuario, e impedimos que otros
validadores se ejecuten en lo que ya sabemos son datos
inválidos.
Si no quiere este comportamiento, puede desactivarlo pasando
un valor false a
setAutoInsertNotEmptyValidator($flag); esto
prevendrá a isValid() de colocar un validador
'NotEmpty' en la cadena de validaciones.
Para mayor información sobre validadores, vea la documentación de
Zend_Validate.
Usando Zend_Form_Elements como validador de propósito generalZend_Form_Element implementa
Zend_Validate_Interface, significando un elemento
puede también usarse como un validador en otro, cadenas de
validación no relacionadas al formulario.
Métodos asociados con validación incluyen:
setRequired($flag) y
isRequired() permiten establecer y recuperar el
estado de la bandera 'required'. Cuando se le asigna un
booleano true, esta bandera requiere que el
elemento esté presente en la información procesada por
Zend_Form.
setAllowEmpty($flag) y
getAllowEmpty() permiten modificar el
comportamiento de elementos opcionales (p.e., elementos
donde la bandera required es false). Cuando la bandera
'allow empty' es true, valores vacíos no pasarán la cadena
de validadores.
setAutoInsertNotEmptyValidator($flag) permite
especificar si realmente un validador 'NotEmpty' será
añadido el inicio de la cadena de validaciones cuando un
elemento es requerido. Por defecto, esta bandera es true.
addValidator($nameOrValidator, $breakChainOnFailure = false, array $options = null)addValidators(array $validators)setValidators(array $validators) (sobreescribe todos los validadores)
getValidator($name) (recupera un objeto validador por nombre)
getValidators() (recupera todos los validadores)
removeValidator($name) (elimina un validador por nombre)
clearValidators() (elimina todos los validadores)
Errores de mensaje personalizados
Alguna veces, querrá especificar uno o más mensajes de error para
usarlos en lugar de los mensajes de error generados por los
validadores adjuntos a los elementos. Adicionalmente, algunas
veces usted mismo querrá marcar al elemento como inválido. A
partir de 1.6.0, esta funcionalidad es posible vía los
siguientes métodos.
addErrorMessage($message): añade un mensaje de
error para mostrarlos en forma de errores de validación. Puede
llamarlo más de una vez, y los nuevos mensajes nuevos son
añadidos a la pila.
addErrorMessages(array $messages): añade
múltiples mensajes de error para mostrarlos en forma de errores de
validación.
setErrorMessages(array $messages): añade
múltiples mensajes de error para mostrarlos en forma de errores de
validación, sobreescribiendo todos los mensajes de error
previamente establecidos.
getErrorMessages(): recupera la lista de
mensajes de error personalizados que fueron definidos.
clearErrorMessages(): remueve todos los
mensajes de error personalizados que hayan sido definidos.
markAsError(): marca al elemento como que falló
la validación.
hasErrors(): determina si el elemento ha
fallado la validación o ha sido marcado como inválido.
addError($message): añade un mensaje a la pila
de mensaje de error personalizados y marca al elemento como
inválido.
addErrors(array $messages): añade varios
mensajes a la pila de mensajes de error personalizados y
marca al elemento como inválido.
setErrors(array $messages): sobreescribe el
mensaje de error personalizado en la pila con los mensajes
previstos y marca al elemento como inválido.
Todos los errores establecidos de este modo pueden ser
traducidos. Adicionalmente, puede insertar el marcador "%value%"
para representar el valor del elemento; este valor actual del
elemento será sustituido cuando el mensaje de error sea
recuperado.
Decoradores
Una dolencia particular para muchos desarrolladores web es la creación
del XHTML para formularios por ellos mismos. Para cada elemento, el
desarrollador necesita crear la marcación para el elemento mismo,
comúnmente una etiqueta (label), y, si son amables con sus usuarios,
la marcación para mostrar mensajes de errores de validación. Cuanto
más elementos en una página, menos trivial se convierte esta tarea.
Zend_Form_Element intenta resolver este problema mediante
el uso de "decoradores". Los decoradores son clases simples que tienen
métodos de acceso al elemento y métodos para generar el contenido. Para
obtener mayor información sobre cómo trabajan los decoradores, consulte
por favor la sección sobre
Zend_Form_Decorator.
Los decoradores usados por defecto por
Zend_Form_Element son:
ViewHelper: especifica un view helper que
usar para general el elemento. El atributo 'helper' del elemento
puede usarse para especificar qué auxiliar vista usar. Por
defecto, Zend_Form_Element especifica el auxiliar
vista 'formText', pero cada subclase especifica diferentes
auxiliares.
Errors: añade mensajes de error al elemento
usando Zend_View_Helper_FormErrors. Si no está
presente, no se añade nada.
Description: añade la descripción del
elemento. Si no está presente, no se añade nada. Por defecto, la
descripción es generada dentro de una etiqueta <p> con un
class 'description'.
HtmlTag: envuelve el elemento y los errores
en una etiqueta HTML <dd>.
Label: añade al comienzo una etiqueta al
elemento usando Zend_View_Helper_FormLabel, y
envolviéndola en una etiqueta <dt>. Si ninguna etiqueta es
provista, solo la etiqueta de la definición es generada.
Decoradores por defecto no necesitan ser cargados
Por defecto, los decoradores por defecto son cargados durante la
inicialización del objeto. Puede deshabilitar esto pasando la
opción 'disableLoadDefaultDecorators' al constructor:
true)
);
]]>
Esta opción puede ser combinada junto con cualquier otra opción que
pase, ya sea como un array de opciones o en un objeto
Zend_Config.
Ya que el orden en el cual los decoradores son registrados importa
-- el primer decorador registrado es ejecutado primero -- necesitará
estar seguro de registrar sus decoradores en el orden apropiado, o
asegurarse de que estableció las opciones de colocación en el modo apropiado. Por
dar un ejemplo, aquí esta el código que registran los decoradores
por defecto:
addDecorators(array(
array('ViewHelper'),
array('Errors'),
array('Description', array('tag' => 'p', 'class' => 'description')),
array('HtmlTag', array('tag' => 'dd')),
array('Label', array('tag' => 'dt')),
));
]]>
El contenido inicial es creado por el decorador 'ViewHelper', que
crea el propio elemento. En seguida, el decorador 'Errors' consulta
los mensajes de error del elemento, y, si hay alguno presente, los
pasa al auxiliar vista 'FormErrors' para mostrarlos. Si una
descripción está presente, el decorador 'Description' añadirá
un párrafo con class 'description' conteniendo el texto descriptivo
para el contenido agregado. El siguiente decorador, 'HtmlTag',
envuelve al elemento, los errores, y la descripción en una etiqueta
HTML <dd>. Finalmente, el último decorador, 'label', recupera
la etiqueta del elemento y la pasa al auxiliar vista 'FormLabel',
envolviéndolo en una etiqueta <dt>; por default el valor es
añadido al inicio del contenido. El resultado de la salida
básicamente se ve así:
"123" is not an alphanumeric value
This is some descriptive text regarding the element.
]]>
Para más información sobre decoradores, lea la sección de Zend_Form_Decorator.
Usando múltiples decoradores al mismo tiempo
Internamente, Zend_Form_Element utiliza una clase
decorador como mecanismo de búsqueda para la recuperación de
decoradores. Como resultado, no puede registrar múltiples
decoradores del mismo tipo; decoradores subsecuentes
simplemente sobreescribirán aquellos que ya existían.
Para evitar esto, puede usar alias. En
lugar de pasar un decorador o nombre de decorador como primer
argumento a addDecorator(), pase una matriz con un
solo elemento, con el alias apuntando al nombre o objeto
decorador:
addDecorator(array('FooBar' => 'HtmlTag'),
array('tag' => 'div'));
// Y recuperandolo posteriormente:
$decorator = $element->getDecorator('FooBar');
]]>
En los métodos addDecorators() y
setDecorators(), necesitará pasar la opción
'decorator' en la matriz representando el decorador:
addDecorators(
array('HtmlTag', array('tag' => 'div')),
array(
'decorator' => array('FooBar' => 'HtmlTag'),
'options' => array('tag' => 'dd')
),
);
// Y recuperándolos posteriormente:
$htmlTag = $element->getDecorator('HtmlTag');
$fooBar = $element->getDecorator('FooBar');
]]>
Métodos asociados con decoradores incluyen:
addDecorator($nameOrDecorator, array $options = null)addDecorators(array $decorators)setDecorators(array $decorators) (sobreescribe
todos los decoradores)
getDecorator($name) (recupera un objeto decorador
por su nombre)
getDecorators() (recupera todos los decoradores)
removeDecorator($name) (elimina un decorador por su
nombre)
clearDecorators() (elimina todos los decoradores)
Zend_Form_Element también utiliza la sobrecarga para
permitir generar decoradores específicos. __call()
interceptará métodos que comiencen con el texto 'render' y utilizará
el resto del nombre del método para buscar un decorador; si se
encuentra, entonces será generado sólo ese
decorador. Cualquier argumento pasado al llamado del método será
usado como contenido para pasar al método render() del
decorador. Como ejemplo:
renderViewHelper();
// Genera solo el decorador HtmlTag, pasándole contenido:
echo $element->renderHtmlTag("This is the html tag content");
]]>
Si el decorador no existe, una excepción es lanzada.
Metadatos y atributosZend_Form_Element manipula una variedad de atributos y
medatados del elemento. Atributos básicos incluyen:
name: el nombre del elemento. Emplea los
métodos de acceso setName() y getName().
label: la etiqueta del elemento. Emplea los
métodos de acceso setLabel() y getLabel().
order: el índice en el cual los elementos
deben ir mostrándose en el formulario. Emplea los métodos de
acceso setOrder() y getOrder().
value: El valor del elemento actual. Emplea
los métodos de acceso setValue() y
getValue().
description: una descripción del elemento;
a menudo utilizada para proveer un tooltip o ayuda contextual
con javascript describiendo el propósito del elemento. Emplea
los métodos de acceso setDescription() y
getDescription().
required: bandera que indica si un elemento
es requerido o no cuando se efectúa la validación del
formulario. Emplea los métodos de acceso
setRequired() y getRequired(). Esta
bandera es false por defecto.
allowEmpty: bandera indicando si un
elemento no-requerido (opcional) debe intentar validar o no
valores vacíos. Cuando es true, y la bandera required es false,
valores vacíos no pasarán la cadena de validación, y se supone
verdadero. Emplea los métodos de acceso
setAllowEmpty() y getAllowEmpty().
Esta bandera es true por defecto.
autoInsertNotEmptyValidator: bandera
indicando insertar o no un validador 'NotEmpty' cuando un
elemento es requerido. Por defecto, esta bandera es true.
Establezca la bandera con
setAutoInsertNotEmptyValidator($flag) y determine
el valor con autoInsertNotEmptyValidator().
Los elementos del formulario pueden requerir metainformación
adicional. Para elementos XHTML del formuladio, por ejemplo, puede
querer especificar atributos como el class o id. Para facilitar esto
hay un conjunto de métodos de acceso:
setAttrib($name, $value): añade un atributo
setAttribs(array $attribs): como
addAttribs(), pero sobreescribiendo
getAttrib($name): recupera el valor de solo
un atributo
getAttribs(): recupera todos los atributos
como pares clave/valor
La mayoría de las veces, como sea, puede simplemente acceder a ellos
como propiedades de objeto, ya que Zend_Form_Element
utiliza la sobrecarga para facilitar el acceso a ellos:
setAttrib('class', 'text'):
$element->class = 'text;
]]>
Por defecto, todos los atributos son pasados al auxiliar vista usado
por el elemento durante la generación, y generados como atributos de
la etiqueta del elemento.
Elementos EstándarZend_Form contiene un buen número de elementos
estándar; por favor lea el capítulo Elementos Estándar para
todos los detalles.
Métodos de Zend_Form_ElementZend_Form_Element tiene muchos, muchos métodos. Lo que
sigue es un sumario de sus funciones, agrupados por tipo:
Configuración:setOptions(array $options)setConfig(Zend_Config $config)I18n:setTranslator(Zend_Translate_Adapter $translator = null)getTranslator()setDisableTranslator($flag)translatorIsDisabled()Propiedades:setName($name)getName()setValue($value)getValue()getUnfilteredValue()setLabel($label)getLabel()setDescription($description)getDescription()setOrder($order)getOrder()setRequired($flag)getRequired()setAllowEmpty($flag)getAllowEmpty()setAutoInsertNotEmptyValidator($flag)autoInsertNotEmptyValidator()setIgnore($flag)getIgnore()getType()setAttrib($name, $value)setAttribs(array $attribs)getAttrib($name)getAttribs()Cargadores y rutas de plugin:setPluginLoader(Zend_Loader_PluginLoader_Interface $loader, $type)getPluginLoader($type)addPrefixPath($prefix, $path, $type = null)addPrefixPaths(array $spec)Validación:addValidator($validator, $breakChainOnFailure = false, $options = array())addValidators(array $validators)setValidators(array $validators)getValidator($name)getValidators()removeValidator($name)clearValidators()isValid($value, $context = null)getErrors()getMessages()Filtros:addFilter($filter, $options = array())addFilters(array $filters)setFilters(array $filters)getFilter($name)getFilters()removeFilter($name)clearFilters()Generación:setView(Zend_View_Interface $view = null)getView()addDecorator($decorator, $options = null)addDecorators(array $decorators)setDecorators(array $decorators)getDecorator($name)getDecorators()removeDecorator($name)clearDecorators()render(Zend_View_Interface $view = null)Configuración
El constructor de Zend_Form_Element acepta tanto una
matriz de opciones como un objeto Zend_Config
conteniendo opciones, y esto puede configurarse usando
setOptions() o setConfig(). Hablando de
manera general, las claves son nombradas de la siguiente manera:
Si 'set' + clave se refiere a un método de
Zend_Form_Element, entonces el valor provisto será
pasado a el método.
De otra manera, el valor será usado para establecer un atributo.
Excepciones a la regla incluyen las siguientes:
prefixPath será pasado a
addPrefixPaths()
Los siguientes setters no pueden establecerse de esta manera:
setAttrib (aunque
setAttribsfuncionarásetConfigsetOptionssetPluginLoadersetTranslatorsetView
Como ejemplo, aquí esta un archivo de configuración pasado para
cada tipo de dato configurable:
Elementos personalizados
Usted puede crear sus propios elementos personalizados simplemente
extendiendo la clase Zend_Form_Element. Las razones
comunes para hacer esto incluyen:
Elementos que comparten validadores y/o filtros comunes
Elementos que tienen decoradores con funcionalidad personalizada
Hay dos métodos típicamente usados para extender un elemento:
init(), el cual puede usarse para añadir una lógica de
inicialización personalizada a su elemento, y
loadDefaultDecorators(), el cual puede usarse para
establecer una lista de decoradores usados por su elemento de manera
predeterminada.
Como un ejemplo, digamos que todos los elementos de tipo texto en un
formulario que está creando, necesitan ser filtrados con
StringTrim, validados con una expresión regular, y que
quiere usar un decorador personalizado que ha creado para
mostrarlos, 'My_Decorator_TextItem'; adicionalmente, tiene un número
de atributos estándars, incluyendo 'size', 'maxLength', y 'class'
que quisiera especificar. Puede definir un elemento tal como sigue:
addPrefixPath('My_Decorator', 'My/Decorator/', 'decorator')
->addFilters('StringTrim')
->addValidator('Regex', false, array('/^[a-z0-9]{6,}$/i'))
->addDecorator('TextItem')
->setAttrib('size', 30)
->setAttrib('maxLength', 45)
->setAttrib('class', 'text');
}
}
]]>
Entonces puede informar a su objeto formulario acerca del prefijo de
ruta para elementos de ese tipo, y comenzar creando elementos:
addPrefixPath('My_Element', 'My/Element/', 'element')
->addElement('foo', 'text');
]]>
El elemento 'foo' será ahora del tipo My_Element_Text,
y mostrará el comportamiento que ha especificado.
Otro método que puede querer sobreescribir cuando extienda
Zend_Form_Element es el método
loadDefaultDecorators(). Este método carga
condicionalmente un grupo de decoradores predefinidos para su
elemento; puede querer sustituir su propio decorador en su clase
extendida:
addDecorator('ViewHelper')
->addDecorator('DisplayError')
->addDecorator('Label')
->addDecorator('HtmlTag',
array('tag' => 'div', 'class' => 'element'));
}
}
]]>
Hay muchas maneras de personalizar elementos; asegúrese de leer la
documentación de la API de Zend_Form_Element para
conocer todos los métodos disponibles.