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 Ext.form.BasicForm widget fields can be coordinated with server side validators. Here, significant problems are possible due to the use of a different philosophy when checking fields. For example, ExtJS uses field types and additional validators, while only validators are present in Zend_Form . But this problem is solvable, since in the client part, we can create our own data types corresponding to the validation functions that are implemented in Zend.
The updated component at this stage should perform two main tasks: validation and filtering of data, rendering forms. Therefore, first of all, a comparison was made of the capabilities of the two libraries that will be used in finalizing the form component ( Zend_Form and ExtJS.form.BasicForm ). Both in the one and in the other, tools for solving the set tasks were developed. Therefore, the main problem is the coordination of the functionality of each of the libraries among themselves.
')
Formulation of requirements:
1. rendering the form;
2. data validation on the client (dynamically, i.e. immediately after entering the data, and before the form is submitted);
3. displaying error messages with the ability to set the message text (dynamically, that is, immediately after entering the data, and after submitting the form in case errors have already been detected on the server);
4. filtering data on the client (prohibition of entering invalid characters, restriction on length, etc.);
5. validation of data on the server;
6. filtering data on the server.
1. To solve the first task, it will be easiest to use the rendering of form components using the standard classes included in the Zend_Form_Element_ * package and the corresponding helpers of the Zend_View_Helper_ * package type. 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 Zend_Form_Decorator_ * class package. In my opinion, one should resort to adding new decorators only if it is not possible to give the desired look to the form only with the help of 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 advantage is the ability to "throw" this object on an existing HTML form. Thus, when the form is rendered by the Zend_Form class, additional javascript code will be inserted, which is responsible for communicating with the new Ext.form.BasicForm object. It is important that the form configuration 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 Ext.form.BasicForm ({...}) object constructor, as well as to the Ext.form.BasicForm.add ({...}) field addition function. Thus, we will be able to render standard forms only once having specified their configuration on the server. This will reduce the time spent on developing a new form several times.
2.4. The ExtJS library contains the necessary functionality for validating data directly upon input. To do this, you need to add fields using the constructors of special objects, such as Ext.form.HtmlEditor (simplified analogue of FCKEditor), Ext.form.DateField (analogue of calendar from Yahoo UI), etc. In addition, it is possible to set special subtypes of fields that are defined in the static Ext.form.VTypes object. It is important that new subtypes can be added to this object, which makes it easier to synchronize the validators of Zend Framework and ExtJS.
It is also necessary to take into account that ExtJS has additional fields, such as Ext.form.HtmlEditor , Ext.form.DateField , etc. It is therefore 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, developing its client object, which is allowed by the ExtJS library, and the corresponding server counterpart. Thus, a set of components can be replenished independently by different people, because they will comply with two generally accepted standards Zend Framework and ExtJS.
Filtering data on the client side is also carried out using the objects and subtypes described above, and to dwell on this point does not make much sense.
3. To output errors in ExtJS, the Ext.QuickTips component is used . There are 4 options for displaying popups with messages that are set by the Ext.form.Field.msgTarget property. Thus, to use this mechanism, it is necessary to initialize the standard object and set the type of notifications.
According to the accepted form of working with forms (the entire configuration is set on the server side), the text of error messages will be set for an 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 a variant of setting the text directly for each form element. This question 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-side and server code, which will be carried out at the form rendering stage, when using the configuration of the Zend_Form object and Zend_Form_Element_ * objects, the javascript code of the Ext.BasicForm object is created with the addition of all the required fields.
5.6. This functionality is implemented in the Zend Framework using two packages: Zend_Validate_ * and Zend_Filter_ * . When creating a Zend_Form object, you can specify multiple validators or filters for each form element. There are 2 options for checking the transferred 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 transferred data, for example, with Ajax checks. Accordingly, you can always add your own validator using the Zend_Validate_Interface interface.
The only significant disadvantage of the existing mechanisms for working with these forms is the lack of support for validation over several fields at once, for example, checking the matching password and confirm password. In addition, it should be noted that some mechanisms require that Ajax requests be performed to validate the data. This should be implemented as a form module in the MVC Zend Framework, since 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 the beginning of the actual coding process, I would like to hear healthy criticism. Most likely, something has not been taken into account now, so I hope this article will help to design this functionality with a sufficient degree of abstraction. Upon completion, I will submit the code for this component to the public.
- means of data validation (a large number of validators);
- means of filtering data (for example, transfer dates to the database format);
- rendering forms using decorators;
- screening output data.
The most interesting is the symbiosis of ExtJS and Zend. The built-in validation of the Ext.form.BasicForm widget fields can be coordinated with server side validators. Here, significant problems are possible due to the use of a different philosophy when checking fields. For example, ExtJS uses field types and additional validators, while only validators are present in Zend_Form . But this problem is solvable, since in the client part, we can create our own data types corresponding to the validation functions that are implemented in Zend.
The updated component at this stage should perform two main tasks: validation and filtering of data, rendering forms. Therefore, first of all, a comparison was made of the capabilities of the two libraries that will be used in finalizing the form component ( Zend_Form and ExtJS.form.BasicForm ). Both in the one and in the other, tools for solving the set tasks were developed. Therefore, the main problem is the coordination of the functionality of each of the libraries among themselves.
')
Formulation of requirements:
1. rendering the form;
2. data validation on the client (dynamically, i.e. immediately after entering the data, and before the form is submitted);
3. displaying error messages with the ability to set the message text (dynamically, that is, immediately after entering the data, and after submitting the form in case errors have already been detected on the server);
4. filtering data on the client (prohibition of entering invalid characters, restriction on length, etc.);
5. validation of data on the server;
6. filtering data on the server.
1. To solve the first task, it will be easiest to use the rendering of form components using the standard classes included in the Zend_Form_Element_ * package and the corresponding helpers of the Zend_View_Helper_ * package type. 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 Zend_Form_Decorator_ * class package. In my opinion, one should resort to adding new decorators only if it is not possible to give the desired look to the form only with the help of 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 advantage is the ability to "throw" this object on an existing HTML form. Thus, when the form is rendered by the Zend_Form class, additional javascript code will be inserted, which is responsible for communicating with the new Ext.form.BasicForm object. It is important that the form configuration 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 Ext.form.BasicForm ({...}) object constructor, as well as to the Ext.form.BasicForm.add ({...}) field addition function. Thus, we will be able to render standard forms only once having specified their configuration on the server. This will reduce the time spent on developing a new form several times.
2.4. The ExtJS library contains the necessary functionality for validating data directly upon input. To do this, you need to add fields using the constructors of special objects, such as Ext.form.HtmlEditor (simplified analogue of FCKEditor), Ext.form.DateField (analogue of calendar from Yahoo UI), etc. In addition, it is possible to set special subtypes of fields that are defined in the static Ext.form.VTypes object. It is important that new subtypes can be added to this object, which makes it easier to synchronize the validators of Zend Framework and ExtJS.
It is also necessary to take into account that ExtJS has additional fields, such as Ext.form.HtmlEditor , Ext.form.DateField , etc. It is therefore 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, developing its client object, which is allowed by the ExtJS library, and the corresponding server counterpart. Thus, a set of components can be replenished independently by different people, because they will comply with two generally accepted standards Zend Framework and ExtJS.
Filtering data on the client side is also carried out using the objects and subtypes described above, and to dwell on this point does not make much sense.
3. To output errors in ExtJS, the Ext.QuickTips component is used . There are 4 options for displaying popups with messages that are set by the Ext.form.Field.msgTarget property. Thus, to use this mechanism, it is necessary to initialize the standard object and set the type of notifications.
According to the accepted form of working with forms (the entire configuration is set on the server side), the text of error messages will be set for an 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 a variant of setting the text directly for each form element. This question 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-side and server code, which will be carried out at the form rendering stage, when using the configuration of the Zend_Form object and Zend_Form_Element_ * objects, the javascript code of the Ext.BasicForm object is created with the addition of all the required fields.
5.6. This functionality is implemented in the Zend Framework using two packages: Zend_Validate_ * and Zend_Filter_ * . When creating a Zend_Form object, you can specify multiple validators or filters for each form element. There are 2 options for checking the transferred 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 transferred data, for example, with Ajax checks. Accordingly, you can always add your own validator using the Zend_Validate_Interface interface.
The only significant disadvantage of the existing mechanisms for working with these forms is the lack of support for validation over several fields at once, for example, checking the matching password and confirm password. In addition, it should be noted that some mechanisms require that Ajax requests be performed to validate the data. This should be implemented as a form module in the MVC Zend Framework, since 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 the beginning of the actual coding process, I would like to hear healthy criticism. Most likely, something has not been taken into account now, so I hope this article will help to design this functionality with a sufficient degree of abstraction. Upon completion, I will submit the code for this component to the public.
Source: https://habr.com/ru/post/49617/
All Articles