Extending Zend_Form with ExtJS
Zend Framework contains a convenient form rendering tool - Zend_Form . The most important advantages are:
The most interesting is the symbiosis of ExtJS and Zend. The built-in validation of the fields of the Ext.form.BasicForm widget can be coordinated with the server side validators. Significant problems are possible due to the use of different philosophies when checking fields. For example, ExtJS uses field types and additional validators, while Zend_Formonly validators are present. But this problem is solvable, because in the client part, we can create our own data types that correspond to the verification functions implemented in Zend.
The updated component at this stage should perform two main tasks: data validation and filtering, form rendering. Therefore, first of all, a comparison was made of the capabilities of the two libraries that will be used to finalize the form component ( Zend_Form and ExtJS.form.BasicForm ). In both, tools have been developed to solve the tasks. Therefore, the main problem is the coordination of the functionality of each of the libraries with each other.
Statement of requirements:
1. rendering of the form;
2.Validation of data on the client (dynamically, i.e. immediately after entering data, and before submitting the form);
3. output of error messages with the ability to set the message text (dynamically, i.e. immediately after entering data, and after sending the form in case errors were already detected on the server);
4. filtering data on the client (prohibition of entering invalid characters, restriction on length, etc.);
5. data validation on the server;
6. filtering data on the server.
1. To solve the first problem, it will be easiest to use the rendering of the form components using the standard classes included in the Zend_Form_Element_ * package and the corresponding package view helpersZend_View_Helper_ * . These classes are fully responsible for displaying form fields on the screen. The appearance of the form itself, i.e. the position of elements on the screen, signatures, etc., is determined by the package of classes Zend_Form_Decorator_ * . In my opinion, resorting to adding new decorators should only be done if you can’t give the desired appearance to the form only using CSS.
From the ExtJS library, the most flexible element for working with forms is the Ext.form.BasicForm object , which contains the basic functionality for managing form fields. An important plus is the ability to "throw" this object onto an existing HTML form. Thus, when rendering the form with the Zend_Form classadditional javascript code will be inserted, responsible for communication with the new Ext.form.BasicForm object . It is important that the configuration of the form created on the server side will determine the field options for the object on the client side. Those. the configuration array will be passed to the constructor of the Ext.form.BasicForm object ({...}) , as well as to the function of adding fields Ext.form.BasicForm.add ({...}) . Thus, we can render standard forms only once setting their configuration on the server. This will reduce the time spent developing a new form several times.
2.4.ExtJS library contains the necessary functionality for data validation directly at input. To do this, add fields using the constructors of special objects, such as Ext.form.HtmlEditor (a simplified analogue of FCKEditor), Ext.form.DateField (analogue of a calendar from Yahoo UI), etc. In addition, it is possible to set special subtypes of fields that are defined in the static object Ext.form.VTypes . The important thing is that new subtypes can be added to this object, which simplifies the synchronization of the Zend Framework and ExtJS validators.
It should also be noted that ExtJS has additional fields, such as Ext.form.HtmlEditor , Ext.form.DateFieldand others. Therefore, it is necessary to implement the server classes of the Zend_Form_Element_ * package and the corresponding Zend_View_Helper_ * classes for simple and correct work with these UI components. In the future, using a similar mechanism, it will be possible to add a new UI element by developing its client object, which is allowed by the ExtJS library, and the corresponding server counterpart. Thus, the set of components can be replenished independently by different people, because they will comply with the two public standards Zend Framework and ExtJS.
Filtering data on the client side is also carried out using the objects and subtypes described above, and it makes no sense to dwell on this item in more detail.
3. Component is used to display errors in ExtJSExt.QuickTips . There are 4 options for displaying popups with messages, which are set by the Ext.form.Field.msgTarget property . Thus, to use this mechanism, it is necessary to initialize a 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 side), the text of error messages will be set for the object of the Zend_Form class , which is done by setting the property containing the object of the Zend_Translate class . The latter will contain error messages for all form fields. However, there may be an option to set the text directly for each form element. This issue needs additional research.
On the client side, using the functionality offered by the ExtJS library, you can also set the error text. Accordingly, the task is to synchronize the client and server code, which will be carried out at the stage of form rendering, when using the configuration of the Zend_Form object and Zend_Form_Element_ * objects , javascript code of the Ext.BasicForm object will be created with all the necessary fields added.
5,6. This functionality is implemented in the Zend Framework using two packages: Zend_Validate_ * and Zend_Filter_ * . When creating a Zend_Form objectYou can specify multiple validators or filters for each form element. There are 2 options for checking transmitted data: the Zend_Form :: isValid () function , which accepts an array and checks all data for correctness, and the Zend_Form :: isValid () function , which serves to validate partially transmitted data, for example, during Ajax checks. Accordingly, you can always add your own validator using the Zend_Validate_Interface interface .
The only significant drawback of the existing mechanisms for working with these forms is the lack of support for validation in several fields at once, for example, checking that password and confirm password match. In addition, it should be noted that some mechanisms require Ajax requests to validate data. This must be implemented as a form module in the MVC Zend Framework, as in most cases, these will be standard queries.
Thus, we get a fairly convenient mechanism for creating automatically validated forms according to a given configuration. However, it is necessary to conduct a more thorough analysis and create a detailed specification of how this mechanism should work.
PS Before starting the actual encoding process, I would like to hear healthy criticism. Most likely something was not taken into account now, so I hope this article will help to design this functionality with a sufficient degree of abstraction. Upon completion of the work, I will present the code of this component to the court of habro-publicity.
- data validation tools (a large number of validators);
- data filtering tools (for example, converting dates to a database format);
- rendering forms using decorators;
- screening of output data.
The most interesting is the symbiosis of ExtJS and Zend. The built-in validation of the fields of the Ext.form.BasicForm widget can be coordinated with the server side validators. Significant problems are possible due to the use of different philosophies when checking fields. For example, ExtJS uses field types and additional validators, while Zend_Formonly validators are present. But this problem is solvable, because in the client part, we can create our own data types that correspond to the verification functions implemented in Zend.
The updated component at this stage should perform two main tasks: data validation and filtering, form rendering. Therefore, first of all, a comparison was made of the capabilities of the two libraries that will be used to finalize the form component ( Zend_Form and ExtJS.form.BasicForm ). In both, tools have been developed to solve the tasks. Therefore, the main problem is the coordination of the functionality of each of the libraries with each other.
Statement of requirements:
1. rendering of the form;
2.Validation of data on the client (dynamically, i.e. immediately after entering data, and before submitting the form);
3. output of error messages with the ability to set the message text (dynamically, i.e. immediately after entering data, and after sending the form in case errors were already detected on the server);
4. filtering data on the client (prohibition of entering invalid characters, restriction on length, etc.);
5. data validation on the server;
6. filtering data on the server.
1. To solve the first problem, it will be easiest to use the rendering of the form components using the standard classes included in the Zend_Form_Element_ * package and the corresponding package view helpersZend_View_Helper_ * . These classes are fully responsible for displaying form fields on the screen. The appearance of the form itself, i.e. the position of elements on the screen, signatures, etc., is determined by the package of classes Zend_Form_Decorator_ * . In my opinion, resorting to adding new decorators should only be done if you can’t give the desired appearance to the form only using CSS.
From the ExtJS library, the most flexible element for working with forms is the Ext.form.BasicForm object , which contains the basic functionality for managing form fields. An important plus is the ability to "throw" this object onto an existing HTML form. Thus, when rendering the form with the Zend_Form classadditional javascript code will be inserted, responsible for communication with the new Ext.form.BasicForm object . It is important that the configuration of the form created on the server side will determine the field options for the object on the client side. Those. the configuration array will be passed to the constructor of the Ext.form.BasicForm object ({...}) , as well as to the function of adding fields Ext.form.BasicForm.add ({...}) . Thus, we can render standard forms only once setting their configuration on the server. This will reduce the time spent developing a new form several times.
2.4.ExtJS library contains the necessary functionality for data validation directly at input. To do this, add fields using the constructors of special objects, such as Ext.form.HtmlEditor (a simplified analogue of FCKEditor), Ext.form.DateField (analogue of a calendar from Yahoo UI), etc. In addition, it is possible to set special subtypes of fields that are defined in the static object Ext.form.VTypes . The important thing is that new subtypes can be added to this object, which simplifies the synchronization of the Zend Framework and ExtJS validators.
It should also be noted that ExtJS has additional fields, such as Ext.form.HtmlEditor , Ext.form.DateFieldand others. Therefore, it is necessary to implement the server classes of the Zend_Form_Element_ * package and the corresponding Zend_View_Helper_ * classes for simple and correct work with these UI components. In the future, using a similar mechanism, it will be possible to add a new UI element by developing its client object, which is allowed by the ExtJS library, and the corresponding server counterpart. Thus, the set of components can be replenished independently by different people, because they will comply with the two public standards Zend Framework and ExtJS.
Filtering data on the client side is also carried out using the objects and subtypes described above, and it makes no sense to dwell on this item in more detail.
3. Component is used to display errors in ExtJSExt.QuickTips . There are 4 options for displaying popups with messages, which are set by the Ext.form.Field.msgTarget property . Thus, to use this mechanism, it is necessary to initialize a 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 side), the text of error messages will be set for the object of the Zend_Form class , which is done by setting the property containing the object of the Zend_Translate class . The latter will contain error messages for all form fields. However, there may be an option to set the text directly for each form element. This issue needs additional research.
On the client side, using the functionality offered by the ExtJS library, you can also set the error text. Accordingly, the task is to synchronize the client and server code, which will be carried out at the stage of form rendering, when using the configuration of the Zend_Form object and Zend_Form_Element_ * objects , javascript code of the Ext.BasicForm object will be created with all the necessary fields added.
5,6. This functionality is implemented in the Zend Framework using two packages: Zend_Validate_ * and Zend_Filter_ * . When creating a Zend_Form objectYou can specify multiple validators or filters for each form element. There are 2 options for checking transmitted data: the Zend_Form :: isValid () function , which accepts an array and checks all data for correctness, and the Zend_Form :: isValid () function , which serves to validate partially transmitted data, for example, during Ajax checks. Accordingly, you can always add your own validator using the Zend_Validate_Interface interface .
The only significant drawback of the existing mechanisms for working with these forms is the lack of support for validation in several fields at once, for example, checking that password and confirm password match. In addition, it should be noted that some mechanisms require Ajax requests to validate data. This must be implemented as a form module in the MVC Zend Framework, as in most cases, these will be standard queries.
Thus, we get a fairly convenient mechanism for creating automatically validated forms according to a given configuration. However, it is necessary to conduct a more thorough analysis and create a detailed specification of how this mechanism should work.
PS Before starting the actual encoding process, I would like to hear healthy criticism. Most likely something was not taken into account now, so I hope this article will help to design this functionality with a sufficient degree of abstraction. Upon completion of the work, I will present the code of this component to the court of habro-publicity.