Empowerment Zend_Form using ExtJS

Zend Framework provides a convenient means of rendering form Zend_Form. The most important advantages are:
    the
  • means of validation of data (a large number of validators);
  • the
  • filtering data (for example the translation of dates in the format DB);
  • the
  • rendering of the form using decorators;
  • the
  • escaping of output data.
from this to create a form that is processed server side only causes problems. Now, however, this is no surprise. Note that Zend is actively cooperating with Dojo to create a dynamically processed forms, but the widgets developed by this company is poor compared to ExtJS. From this point of view, the best option is the adjustment of the rendering of the forms class Zend_Form.

The most interesting is the symbiosis of ExtJS and Zend. Built-in field validation widget Ext.form.BasicForm can be aligned with the validators server-side. Here there are significant problems in the utilization of different philosophies when checking fields. For example, in ExtJS using the field types and additional validators, and Zend_Form there are only validators. But this problem is solvable, because in the client side we can create your own data types appropriate to the validation functions that are implemented in Zend.

The updated component at this stage needs to perform two main tasks: validation and filtering data, rendering forms. Therefore, in the first place was the comparison of the two libraries that will be used for finalization of the component forms (Zend_Form and ExtJS.form.BasicForm). And that the tools developed for the task. Therefore, the main problem is the coordination functions of each of the libraries between them.

The wording of the requirements:
1. rendering;
2. data validation on the client (dynamically, i.e. directly after data entry and before submitting the form);
3. output error messages with the ability to specify message text (dynamically, i.e. directly after entering the data, and after sending the form in case errors were found already on the server);
4. filtering data on the client (prohibition of entering invalid characters a limitation in length, etc.);
5. data validation on the server.
6. filtering data on the server.

1. To solve the first problem, the easiest way is to use the render form components by using the standard classes included in the package Zend_Form_Element_*, and their corresponding helpers package Zend_View_Helper_*. These classes are fully responsible for the output form field on the screen. The appearance of the shape, i.e. the position of the elements on the screen, signatures, etc., is determined by the package of classes Zend_Form_Decorator_*. In my opinion, to resort to adding new decorators should only be the case if you are unable to give the desired look to the form just by using CSS.
From the ExtJS library is the most flexible element to form the object is Ext.form.BasicForm, which contains the basic functionality to manage form fields. Important advantage is the ability to "throw" the given object to an existing HTML form. Thus, when rendering the form the class Zend_Form to insert additional javascript code that is responsible for communicating with the new object Ext.form.BasicForm. It is important that the configuration forms created on the server side, will determine the options fields for the object on the client side. Ie configuration array will be passed to the constructor of the object Ext.form.BasicForm({...}) and in the function add fields Ext.form.BasicForm.add({...}). Thus, we will be able to render standard form only once by setting its configuration on the server. This will reduce the time spent on the development of new forms several times.

2.4 GHz. the ExtJS Library contains the necessary functionality for data validation directly when you enter. For this you need to add fields, constructors using special objects, such as Ext.form.HtmlEditor (simplified analogue of FCKEditor), Ext.form.DateField (similar to the calendar of Yahoo UI), etc. in addition, there is a possibility to install a special subtype fields defined in the static object Ext.form.VTypes. It is important that this object can be added new subtypes, that makes syncing validators Zend Framework and ExtJS.
Filtering data on the client side is also carried out by using the above-described objects and subtypes, and at this point more makes no sense.

3. For error output in ExtJS using the Ext.QuickTips. Possible 4 options of displaying popups with messages that are defined by the property Ext.form.Field.msgTarget. Thus, to use this mechanism you need to initialize the standard object and set the type of notifications.
According to the accepted scheme of working with forms (the entire configuration is installed on the server) the text of error messages will ask for an object of class Zend_Form that is done by setting properties that contain an object of class Zend_Translate. The latter will contain error messages for all fields in the form. However, perhaps there is an option set the text directly for each form element. This question needs additional study.
On the client side, using the functionality offered by ExtJS library, you can also set the error text. Accordingly, the task is a synchronization code of a client part and a server, which will be implemented at the stage of rendering when using the configuration object Zend_Form and close to Zend_Form_Element_* will create a javascript code object Ext.BasicForm with the addition of all the required fields.

5,6. This function is implemented in Zend Framework using two packages: the Zend_Validate_* and Zend_Filter_*. When the object is created Zend_Form you can specify multiple validators or filters to each form element. There are 2 ways to check transmitted data: Zend_Form::isValid(), which accepts an array and checks the data for correctness, and the function Zend_Form::isValid(), which is used for validation of the partially transferred data, for example, with Ajax validations. Accordingly, you can always add your validator using the interface implements zend_validate_interface.

The only significant drawback of the existing mechanisms for working with data forms is the lack of support for validation in several fields, such as matching the password and confirm password. Also, you should note that some arrangements require you to perform Ajax queries to validate data. This should be done as a module form in MVC Zend Framework, because in most cases it will be standard queries.
Thus, we will receive quite convenient mechanism of creating forms automatically validated according to the specified configuration. However, it is necessary to conduct a more thorough analysis and create a detailed specification of how should work the mechanism.

P. S. Before the actual coding process I would like to hear constructive criticism. Most likely something was not taken into account now, so I hope this article will help you to create this functionality with a sufficient degree of abstraction. Upon completion, I will present to herroommates code of this component.
Article based on information from habrahabr.ru

Популярные сообщения из этого блога

Approval of WSUS updates: import, export, copy

The Hilbert curve vs. Z-order

Configuring a C++ project in Eclipse for example SFML application