[Formsess-devel] HEAD version: fresh news
Status: Beta
Brought to you by:
mrkatana
|
From: Katana <ka...@ka...> - 2004-01-25 22:42:15
|
Hello, at last, I managed to get something out of the HEAD CVS version of formsess, which had been broken for a few weeks. First, the facts: - tags parsing is working - client side validation is working, but I didn't port all the validators to the new API yet - server side validation is not working yet Now, what has been done. A major cleanup, first. All classes and files are prepended with Formsess: Formsess.class.php, FormsessFilter.class.php, and so on, in order to get a clean API. Tags parsing is now OO. A base class FormsessTag provides the API for all the tags parsing classes, which can be found in libs/FormsessTag/. As far as I've seen, they are working correctly. Validators are also OO. A base class FormsessValidator provides a common API for 2 subclasses: FormsessValidatorPHP, and FormessValidatorJavascript. As explained above, I didn't work on the "new" server side validation model yet. But it is not gonna require much work to get it to work again. The Javascript ones are much more advanced, on the other hand. Each validator is placed in a file named as follows: libs/FormsessValidator/<validatorname>.class.php, containing 2 classes: FormsessValidatorJavascript<validatorname> and FormsessValidatorPHP<validatorname> these classes inherit the base classes of the same names. They use the API method provided by the base class, and new validators implementation is now quite easy. Mandatory fields are automatically handled by changing a class property, and the same goes for valid field types and the default error message. Now, what's gonna be done. 1) move Smarty_Formsess.class.php to libs. In the beggining it was intended to be a suggestion on how to implement formsess in your application, but it looks like almost everyone is using that class, so I guess it's better to complete it. 2) move the *smarty* methods in FormsessFilter to Smarty_Formsess (the class name is supposed to change as well). These methods extend smarty so I don't see why they're still in FormsessFilter :) 3) port all the client side validators to the new API 4) implement the required methods in FormsessValidatorPHP 5) Update the Formsess class in order to run validation using the new validation API I also have ideas regarding two classes: - FormsessControler: this one would use a singleton pattern, in order to provide a way to customize any Formsess operation running in your application: add custom validators path, enable / disable js validation, and so on - FormsessContainer (or Storage): an API used to access the form data instead of these ugly properties in Formsess. That's all for now. You can checkout the HEAD version and see the result. On your existing templates, you will probably run into issues with validators that were not yet reimplemented using the new API, and of course server side validation will not work, but it will allow you to get a quick overview of what is planned in the next release. Oh, and I also intend to release Formsess 2.0.0 final :) So if you have anything in mind i should fix before that, send an email on that mailing list, and if you don't mind post a bug report on sf.net :) Thanks in advance for any comment you like, Katana |