Formularz składa się z elementów, które zazwyczaj odpowiadają elementom formularzy HTML. Klasa Zend_Form_Element obsługuje pojedyncze elementy formularza w takich zakresach:
weryfikacja (czy wysłane dane są poprawne?)
przechowywanie kodów i komunikatów o błędach jakie wystąpiły podczas weryfikacji
filtrowanie (w jaki sposób element jest przygotowany do weryfikacji i wyświetlenia?)
renderowanie (jak element jest wyświetlany?)
dane meta i atrybuty (jakie dodatkowe informacje opisują element?)
Klasa bazowa Zend_Form_Element jest domyślnie skonfigurowana
dla wielu przypadków użycia, jednak najlepiej jest rozszerzyć tę klasę
aby utworzyć najczęściej używane elementy. Dodatkowo Zend Framework
zawiera pewną ilość standardowych elementów XHTML; możesz o nich przeczytać w rozdziale Standardowe Elementy.
Klasa Zend_Form_Element używa klasy Zend_Loader_PluginLoader
aby umożliwić programistom określenie ścieżek, w których znajdują
się alternatywne weryfikatory, filtry i dekoratory. Każda z tych wtyczek
ma przypisaną własną klasę ładującą je, a do ich modyfikacji
używany jest zestaw metod dostępowych.
W metodach obsługujących ładowanie wtyczek używane są następujące typy: 'validate', 'filter' oraz 'decorator'. Wielkość liter w nazwach typów nie jest istotna.
Metody używane do obsługi ładowania wtyczek to:
setPluginLoader($loader, $type):
$loader jest obiektem klasy ładującej wtyczki, a
$type jest jednym z typów określonych wyżej. Metoda
ustawia obiekt ładujący wtyczki dla danego typu.
getPluginLoader($type): zwraca klasę ładującą wtyczkę
powiązaną z typem $type.
addPrefixPath($prefix, $path, $type = null): dodaje
przedrostek oznaczający ścieżkę dla klasy ładującej elementy
typu zdefiniowanego w parametrze $type.
Jeśli zmienna $type ma wartość null, przedrostek
zostanie dodany dla wszystkich typów elementów, poprzez dodanie
dodatkowej częśći przedrostka w postaci "_Validate", "_Filter",
i "_Decorator"; dodane zostaną ścieżki "Validate/", "Filter/", i
"Decorator/". Jeśli wszystkie dodatkowe klasy elementów
formularza trzymasz w tej samej hierchii, to będzie wygodnym
sposobem ustawia przedrostka.
addPrefixPaths(array $spec): allows you to add
many paths at once to one or more plugin loaders. It expects
each array item to be an array with the keys 'path', 'prefix',
and 'type'.
Własne weryfikatory, filtry i dekoratory są łatwym sposobem na użycie pewnej własnej funkcjonalności w wielu formularzach.
Przykład 18.1. Własna etykieta
One common use case for plugins is to provide replacements for standard classes. For instance, if you want to provide a different implementation of the 'Label' decorator -- for instance, to always append a colon -- you could create your own 'Label' decorator with your own class prefix, and then add it to your prefix path.
Spróbujmy stworzyć własny dekorator dla etykiety. Damy jego klasie przedrostek "My_Decorator", a sama klasa będzie znajdować się w pliku "My/Decorator/Label.php".
class My_Decorator_Label extends Zend_Form_Decorator_Abstract
{
protected $_placement = 'PREPEND';
public function render($content)
{
if (null === ($element = $this->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;
}
}
}
Now we can tell the element to use this plugin path when looking for decorators:
$element->addPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');
Alternately, we can do that at the form level to ensure all decorators use this path:
$form->addElementPrefixPath('My_Decorator', 'My/Decorator/', 'decorator');
With this path added, when you add a decorator, the 'My/Decorator/' path will be searched first to see if the decorator exists there. As a result, 'My_Decorator_Label' will now be used when the 'Label' decorator is requested.
It's often useful and/or necessary to perform some normalization on
input prior to validation – for instance, you may want to strip out
all HTML, but run your validations on what remains to ensure the
submission is valid. Or you may want to trim empty space surrounding
input so that a StringLength validator will not return a false
positive. These operations may be performed using
Zend_Filter, and Zend_Form_Element has
support for filter chains, allowing you to specify multiple,
sequential filters to utilize. Filtering happens both during
validation and when you retrieve the element value via
getValue():
$filtered = $element->getValue();
Filtry mogą być dodane na dwa sposoby:
przekazanie konkretnego egzemplarza obiektu filtra
przekazanie nazwy filtra – krótkiej lub pełnej nazwy
Zobaczmy kilka przykładów:
// Konkretny egzemplarz obiektu filtra:
$element->addFilter(new Zend_Filter_Alnum());
// Pełna nazwa filtra:
$element->addFilter('Zend_Filter_Alnum');
// Krótka nazwa filtra:
$element->addFilter('Alnum');
$element->addFilter('alnum');
Krótkie nazwy są zazwyczaj nazwą klasy filtra pozbawioną przedrostka. W domyślnym przypadku, będzie to oznaczało że pomijamy przedrostek 'Zend_Filter_'. Nie jest też konieczne aby pierwsza litera była wielka.
![]() |
Użycie własnych klas filtrów |
|---|---|
|
Jeśli posiadasz własny zestaw klas filtrów, możesz przekazać
klasie
$element->addPrefixPath('My_Filter', 'My/Filter/', 'filter');
(Zauważ że trzeci argument oznacza typ wtyczek dla którego określamy przedrostek) |
Jęśli w potrzebujesz niefiltrowaną wartość użyj metody
getUnfilteredValue():
$unfiltered = $element->getUnfilteredValue();
Aby uzyskać więcej informacji o filtrach zobacz dokumentację klasy Zend_Filter.
Metody powiązane z filtrami to:
addFilter($nameOfFilter, array $options = null)
addFilters(array $filters)
setFilters(array $filters) (nadpisuje wszystkie filtry)
getFilter($name) (pobiera obiekt filtra)
getFilters() (pobiera wszystkie filtry)
removeFilter($name) (usuwa filtr)
clearFilters() (usuwa wszystkie filtry)
If you subscribe to the security mantra of "filter input, escape
output," you'll want to validate ("filter input") your form input.
In Zend_Form, each element includes its own validator
chain, consisting of Zend_Validate_* validators.
Weryfikatory mogą być dodane na dwa sposoby:
przekazanie konkretnego egzemplarza obiektu weryfikatora
przekazanie nazwy weryfikatora – krótkiej lub pełnej nazwy
Zobaczmy kilka przykładów:
// Konkretny egzemplarz obiektu weryfikatora:
$element->addValidator(new Zend_Validate_Alnum());
// Pełna nazwa klasy:
$element->addValidator('Zend_Validate_Alnum');
// Krótka nazwa weryfikatora:
$element->addValidator('Alnum');
$element->addValidator('alnum');
Krótkie nazwy są zazwyczaj nazwą klasy weryfikatora pozbawioną przedrostka. W domyślnym przypadku, będzie to oznaczało że pomijamy przedrostek 'Zend_Validate_'. Nie jest też konieczne aby pierwsza litera była wielka.
![]() |
Użycie własnych klas weryfikatorów |
|---|---|
|
Jeśli posiadasz własny zestaw klas weryfikatorów, możesz przekazać
klasie
$element->addPrefixPath('My_Validator', 'My/Validator/', 'validate');
(Zauważ że trzeci argument oznacza typ wtyczek dla którego określamy przedrostek) |
If failing a particular validation should prevent later validators
from firing, pass boolean true as the second parameter:
$element->addValidator('alnum', true);
If you are using a string name to add a validator, and the
validator class accepts arguments to the constructor, you may pass
these to the third parameter of addValidator() as an
array:
$element->addValidator('StringLength', false, array(6, 20));
Arguments passed in this way should be in the order in which they
are defined in the constructor. The above example will instantiate
the Zend_Validate_StringLenth class with its
$min and $max parameters:
$validator = new Zend_Validate_StringLength(6, 20);
![]() |
Określanie własnych komunikatów o błędach |
|---|---|
|
Some developers may wish to provide custom error messages for a
validator.
A better option is to use a |
Możesz także ustawić wiele weryfikatorów na raz, używając metody
addValidators(). Podstawowym sposobem użycia jest
przekazanie tablicy tablic, gdzie każda z tablic posiada od 1 do 3
wartości, zgodnych z wywołaniem metody addValidator():
$element->addValidators(array(
array('NotEmpty', true),
array('alnum'),
array('stringLength', false, array(6, 20)),
));
If you want to be more verbose or explicit, you can use the array keys 'validator', 'breakChainOnFailure', and 'options':
$element->addValidators(array(
array(
'validator' => 'NotEmpty',
'breakChainOnFailure' => true),
array('validator' => 'alnum'),
array(
'validator' => 'stringLength',
'options' => array(6, 20)),
));
Ten przykład pokazuje w jaki sposób możesz skonfigurować weryfikatory w pliku konfiguracyjnym:
element.validators.notempty.validator = "NotEmpty"
element.validators.notempty.breakChainOnFailure = true
element.validators.alnum.validator = "Alnum"
element.validators.strlen.validator = "StringLength"
element.validators.strlen.options.min = 6
element.validators.strlen.options.max = 20
Notice that every item has a key, whether or not it needs one; this is a limitation of using configuration files -- but it also helps make explicit what the arguments are for. Just remember that any validator options must be specified in order.
Aby sprawdzić poprawność elementu przekaż wartość do metody:
isValid():
if ($element->isValid($value)) {
// prawidłowy
} else {
// nieprawidłowy
}
![]() |
Weryfikowane są przefiltrowane wartości |
|---|---|
|
![]() |
Weryfikacja w kontekście |
|---|---|
|
Metoda
class My_Validate_PasswordConfirmation extends Zend_Validate_Abstract
{
const NOT_MATCH = 'notMatch';
protected $_messageTemplates = array(
self::NOT_MATCH => '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;
}
}
|
Weryfikatory są uruchamiane w kolejności. Każdy weryfikator jest
uruchamiany, chyba że weryfikator z ustawioną flagą
breakChainOnFailure nie przejdzie pomyślnie weryfikacji.
Upewnij się, że określisz swoje weryfikatory w określonej kolejności.
Po nieudanej weryfikacji możesz pobrać kody i komunikaty błędów:
$errors = $element->getErrors();
$messages = $element->getMessages();
(Uwaga: komunikaty o błędach są zwracane jako asocjacyjna tablica w postaci par kod / komunikat.)
In addition to validators, you can specify that an element is
required, using setRequired(true).
By default, this flag is false, meaning that your validator chain
will be skipped if no value is passed to isValid().
You can modify this behavior in a number of ways:
By default, when an element is required, a flag,
'allowEmpty', is also true. This means that if a value
evaluating to empty is passed to isValid(), the
validators will be skipped. You can toggle this flag using
the accessor setAllowEmpty($flag); when the
flag is false, then if a value is passed, the validators
will still run.
By default, if an element is required, but does not contain
a 'NotEmpty' validator, isValid() will add one
to the top of the stack, with the
breakChainOnFailure flag set. This makes the
required flag have semantic meaning: if no value is passed,
we immediately invalidate the submission and notify the
user, and prevent other validators from running on what we
already know is invalid data.
If you do not want this behavior, you can turn it off by
passing a false value to
setAutoInsertNotEmptyValidator($flag); this
will prevent isValid() from placing the
'NotEmpty' validator in the validator chain.
Aby uzyskać więcej informacji o weryfikatorach, zobacz dokumentację klasy Zend_Validate.
![]() |
Użycie klasy Zend_Form_Elements jako weryfikatora |
|---|---|
Klasa |
Metody powiązane z weryfikatorami to:
setRequired($flag) and
isRequired() allow you to set and retrieve the
status of the 'required' flag. When set to boolean true, this
flag requires that the element be in the data processed by
Zend_Form.
setAllowEmpty($flag) and
getAllowEmpty() allow you to modify the
behaviour of optional elements (i.e., elements where the
required flag is false). When the 'allow empty' flag is
true, empty values will not be passed to the validator
chain.
setAutoInsertNotEmptyValidator($flag) pozwala
na określenie, czy weryfikator 'NotEmpty' ma być dołączony
do łańcucha weryfikatorów gdy element jest oznaczony jako
wymagany. Domyślnie flaga ta ma wartość true.
addValidator($nameOrValidator, $breakChainOnFailure = false, array $options = null)
addValidators(array $validators)
setValidators(array $validators) (nadpisuje wszystkie weryfikatory)
getValidator($name) (pobiera obiekt weryfikatora)
getValidators() (pobiera wszystkie obiekty weryfikatorów)
removeValidator($name) (usuwa obiekt weryfikatora)
clearValidators() (usuwa wszystkie obiekty weryfikatorów)
At times, you may want to specify one or more specific error messages to use instead of the error messages generated by the validators attached to your element. Additionally, at times you may want to mark the element invalid yourself. As of 1.6.0, this functionality is possible via the following methods.
addErrorMessage($message): dodaje komunikat
błędu który ma być wyświetlany w razie nieudanej weryfikacji
formularza. Możesz tę metodę wywoływać wiele razy, a nowe
komunikaty będą dodawane do stosu.
addErrorMessages(array $messages): dodaje wiele
komunikatów błędów do wyświetlenia w razie nieudanej
weryfikacji formularza.
setErrorMessages(array $messages): dodaje wiele
komunikatów błędów do wyświetlenia w razie nieudanej
weryfikacji formularza, nadpisując wszystkie wcześniej
ustawione.
getErrorMessages(): pobiera listę własnych
komunikatów błędów jakie zostały zdefiniowane.
clearErrorMessages(): usuwa wszystkie własne
komunikaty błędów jakie były zdefiniowane.
markAsError(): oznacza element jako
nieprawidłowy.
hasErrors(): pozwala sprawdzić czy element nie
przeszedł pozytywnie weryfikacji, czy ręcznie został
oznaczony jako nieprawidłowy.
addError($message): add a message to the custom
error messages stack and flag the element as invalid.
addErrors(array $messages): add several
messages to the custom error messages stack and flag the
element as invalid.
setErrors(array $messages): nadpisuje
custom error messages stack with the provided messages and
flag the element as invalid.
All errors set in this fashion may be translated. Additionally, you may insert the placeholder "%value%" to represent the element value; this current element value will be substituted when the error messages are retrieved.
One particular pain point for many web developers is the creation of the XHTML forms themselves. For each element, the developer needs to create markup for the element itself, typically a label, and, if they're being nice to their users, markup for displaying validation error messages. The more elements on the page, the less trivial this task becomes.
Zend_Form_Element tries to solve this issue through
the use of "decorators". Decorators are simply classes that have
access to the element and a method for rendering content. For more
information on how decorators work, please see the section on Zend_Form_Decorator.
Domyśle dekoratory używane przez klasę Zend_Form_Element to:
ViewHelper: określą klasę pomocniczą widoku,
która ma być użyta do renderowania określonego elementu. Atrybut
'helper' może być użyty aby określić która klasa pomocnicza ma być
użyta. Domyślnie klasa Zend_Form_Element określa
domyślną klasę pomocniczą jako 'formText', jednak klasy
rozszerzające określają inne klasy pomocnicze.
Errors: dołączą komunikaty błędów do elementu
używając klasy Zend_View_Helper_FormErrors. Jeśli błędów
nie ma nic nie zostaje dołączone.
HtmlTag: otacza element i błędy znacznikiem HTML <dd>.
Label: dołącza etykietę do elementu
używając helpera Zend_View_Helper_FormLabel i
umieszcza etykietę wewnątrz znacznika <dt>. Jeśli etykieta
nie została ustawiona, wyświetlana jest tylko część znacznika
definicji.
![]() |
Domyślne dekoratory nie muszą być ładowane |
|---|---|
|
Domyślny zestaw dekoratorów jest ładowany podczas inicjowania obiektu. Możesz to zablokować określając opcję 'disableLoadDefaultDecorators' konstruktora:
$element = new Zend_Form_Element('foo',
array('disableLoadDefaultDecorators' =>
true)
);
Ta opcja może być użyta równolegle wraz z dowolnymi innymi
opcjami jakie przekażesz, zarówno w postaci tablicy opcji jak
i obiektu |
Z tego względu, że kolejność w jakiej rejestrowane są dekoratory ma znaczenie -- dekoratory są uruchamiane w takiej kolejności w jakiej zostały zarejestrowane -- musisz się upewnić, że rejestrujesz je w odpowiedniej kolejności lub użyć opcji pozwalającej na zarejestrowanie dekoratora w konkretnej pozycji. Poniżej jako przykład został zamieszczony przykładowy kod, który rejestruje domyślne dekoratory:
$this->addDecorators(array(
array('ViewHelper'),
array('Errors'),
array('HtmlTag', array('tag' => 'dd')),
array('Label', array('tag' => 'dt')),
));
The initial content is created by the 'ViewHelper' decorator, which creates the form element itself. Next, the 'Errors' decorator fetches error messages from the element, and, if any are present, passes them to the 'FormErrors' view helper to render. The next decorator, 'HtmlTag', wraps the element and errors in an HTML <dd> tag. Finally, the last decorator, 'label', retrieves the element's label and passes it to the 'FormLabel' view helper, wrapping it in an HTML <dt> tag; the value is prepended to the content by default. The resulting output looks basically like this:
<dt><label for="foo" class="optional">Foo</label></dt>
<dd>
<input type="text" name="foo" id="foo" value="123" />
<ul class="errors">
<li>"123" is not an alphanumeric value</li>
</ul>
</dd>
Aby uzyskać więcej informacji o dekoratorach, zobacz dokumentację klasy Zend_Form_Decorator.
![]() |
Użycie wielu dekoratorów tego samego typu |
|---|---|
|
Internally,
To get around this, you can use aliases.
Instead of passing a decorator or decorator name as the first
argument to
// Alias dla 'FooBar':
$element->addDecorator(array('FooBar' => 'HtmlTag'),
array('tag' => 'div'));
// Pobieramy dekorator:
$decorator = $element->getDecorator('FooBar');
Do metod
// Dodanie dwóch dekoratorów 'HtmlTag', ustawiając nazwę jednego z nich na 'FooBar':
$element->addDecorators(
array('HtmlTag', array('tag' => 'div')),
array(
'decorator' => array('FooBar' => 'HtmlTag'),
'options' => array('tag' => 'dd')
),
);
// I pobranie ich póżniej:
$htmlTag = $element->getDecorator('HtmlTag');
$fooBar = $element->getDecorator('FooBar');
|
Metody powiązane z dekoratorami to:
addDecorator($nameOrDecorator, array $options = null)
addDecorators(array $decorators)
setDecorators(array $decorators) (nadpisuje wszystkie dekoratory)
getDecorator($name) (pobiera obiekt dekoratora)
getDecorators() (pobiera wszystkie dekoratory)
removeDecorator($name) (usuwa dekorator)
clearDecorators() (usuwa wszystkie dekoratory)
Zend_Form_Element obsługuje wiele atrybutów i danych
meta dla elementów. Te atrybuty to:
name: nazwa elementu. Używa metod dostępowych
setName() oraz getName().
label: etykieta elementu. Używa metod dostępowych
setLabel() oraz getLabel().
order: pozycja w której element ma być wstawiony
w formularzu. Używa metod dostępowych setOrder() oraz
getOrder().
value: obecna wartość elementu. Używa metod
dostępowych setValue() oraz getValue().
description: opis elementu; zazwyczaj używane
do utworzenia
often used to provide tooltip or javascript contextual hinting
describing the purpose of the element. Używa metod dostępowych
setDescription() oraz getDescription().
required: flag indicating whether or not
the element is required when performing form validation. Uses
the setRequired() and getRequired()
accessors. This flag is false by default.
allowEmpty: flag indicating whether or not
a non-required (optional) element should attempt to validate
empty values. When true, and the required flag is false, empty
values are not passed to the validator chain, and presumed true.
Uses the setAllowEmpty() and getAllowEmpty()
accessors. This flag is true by default.
autoInsertNotEmptyValidator: flag
indicating whether or not to insert a 'NotEmpty' validator when
the element is required. By default, this flag is true. Set the
flag with setAutoInsertNotEmptyValidator($flag) and
determine the value with
autoInsertNotEmptyValidator().
Elementy formularzy mogą wymagać dodatkowych danych meta. Przykładowo dla elementów formularzy XHTML możesz chcieć określić takie atrybuty jak 'class' czy 'id'. Do obsługi tego istnieje kilka metod dostępowych:
setAttrib($name, $value): dodaje atrybut
setAttribs(array $attribs): tak jak metoda addAttribs(), ale nadpisuje atrybuty
getAttrib($name): pobiera wartość jednego atrybutu
getAttribs(): pobiera wszystkie atrybuty w postaci par klucz/wartość
Most of the time, however, you can simply access them as object
properties, as Zend_Form_Element utilizes overloading
to facilitate access to them:
// Odpowiednik metody $element->setAttrib('class', 'text'):
$element->class = 'text;
By default, all attributes are passed to the view helper used by the element during rendering, and rendered as HTML attributes of the element tag.
Komponent Zend_Form posiada duży zestaw standardowych
elementów; przeczytaj rozdział
Standardowe Elementy
aby poznać więcej szczegółów.
Klasa Zend_Form_Element posiada bardzo dużo metod. Poniżej
zamieszczono podsumowanie ich sygnatur, pogrupowanych na podstawie typu:
Konfiguracja:
setOptions(array $options)
setConfig(Zend_Config $config)
I18N:
setTranslator(Zend_Translate_Adapter $translator = null)
getTranslator()
setDisableTranslator($flag)
translatorIsDisabled()
Właściwości:
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()
Ładowanie wtyczek i ścieżki:
setPluginLoader(Zend_Loader_PluginLoader_Interface $loader, $type)
getPluginLoader($type)
addPrefixPath($prefix, $path, $type = null)
addPrefixPaths(array $spec)
Weryfikacja:
addValidator($validator, $breakChainOnFailure = false, $options = array())
addValidators(array $validators)
setValidators(array $validators)
getValidator($name)
getValidators()
removeValidator($name)
clearValidators()
isValid($value, $context = null)
getErrors()
getMessages()
Filtrowanie:
addFilter($filter, $options = array())
addFilters(array $filters)
setFilters(array $filters)
getFilter($name)
getFilters()
removeFilter($name)
clearFilters()
Renderowanie:
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)
Konstruktor klasy Zend_Form_Elementprzyjmuje w
parametrze tablicę opcji lub obiekt Zend_Config
zawierający pcje. Klasa może być także skonfigurowana za pomocą
metod setOptions() oraz setConfig().
Generalnie klucze nazwane są w taki sposób:
Jeśli klucz zaczyna się przedrostkiem 'set' i oznacza metodę
klasy Zend_Form_Element, to ustawiona dla niego
wartość zostanie przekazana do tej metody.
W przeciwnym wypadku wartość zostanie użyta do ustawienia atrybutu.
Oto wyjątki od tej zasady:
Klucz prefixPath zostanie przekazany do metody
addPrefixPaths()
Poniższe metody dostępowe nie mogą być użyte w ten sposób:
setAttrib (ale
setAttribs będzie
działać)
setConfig
setOptions
setPluginLoader
setTranslator
setView
Jako przykład poniżej zamieszczamy plik konfiguracyjny pokazujący wszystkie możliwe dane konfiguracyjne:
[element]
name = "foo"
value = "foobar"
label = "Foo:"
order = 10
required = true
allowEmpty = false
autoInsertNotEmptyValidator = true
description = "Foo elements are for examples"
ignore = false
attribs.id = "foo"
attribs.class = "element"
; ustawia atrybut 'onclick'
onclick = "autoComplete(this, '/form/autocomplete/element')"
prefixPaths.decorator.prefix = "My_Decorator"
prefixPaths.decorator.path = "My/Decorator/"
disableTranslator = 0
validators.required.validator = "NotEmpty"
validators.required.breakChainOnFailure = true
validators.alpha.validator = "alpha"
validators.regex.validator = "regex"
validators.regex.options.pattern = "/^[A-F].*/$"
filters.ucase.filter = "StringToUpper"
decorators.element.decorator = "ViewHelper"
decorators.element.options.helper = "FormText"
decorators.label.decorator = "Label"
Możesz tworzyć własne elementy po prostu rozszerzając klasę
Zend_Form_Element. Powodami aby to zrobić mogą być:
Elementy które używają podobnych zestawów weryfikatorów i/lub filtrów
Elementy które posiadają własną funkcjonalność dekoratorów
Dwie metody są najczęściej używane do rozszerzenia elementu:
metoda init(), która może być użyta do dodania własnej logiki
inicjującej element oraz metoda loadDefaultDecorators(),
która może być użyta do ustawienia listy domyślnych dekoratorów
używanych przez element.
As an example, let's say that all text elements in a form you are
creating need to be filtered with StringTrim,
validated with a common regular expression, and that you want to
use a custom decorator you've created for displaying them,
'My_Decorator_TextItem'; additionally, you have a number of standard
attributes, including 'size', 'maxLength', and 'class' you wish to
specify. You could define such an element as follows:
class My_Element_Text extends Zend_Form_Element
{
public function init()
{
$this->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');
}
}
You could then inform your form object about the prefix path for such elements, and start creating elements:
<?php
$form->addPrefixPath('My_Element', 'My/Element/', 'element')
->addElement('foo', 'text');
Element 'foo' będzie teraz typu My_Element_Text
i będzie posiadał wyżej pokazaną funkcjonalność.
Another method you may want to override when extending
Zend_Form_Element is the
loadDefaultDecorators() method. This method
conditionally loads a set of default decorators for your element;
you may wish to substitute your own decorators in your extending
class:
class My_Element_Text extends Zend_Form_Element
{
public function loadDefaultDecorators()
{
$this->addDecorator('ViewHelper')
->addDecorator('DisplayError')
->addDecorator('Label')
->addDecorator('HtmlTag',
array('tag' => 'div', 'class' => 'element'));
}
}
Jest wiele sposobów na konfigurację elementów; pamiętaj aby
przeczytać dokumentację API klasy Zend_Form_Element
w celu poznania wszystkich dostępnych metod.