Coding Critique is the place to post source code for peer review by other members of DevNetwork. Any kind of code can be posted. Code posted does not have to be limited to PHP. All members are invited to contribute constructive criticism with the goal of improving the code. Posted code should include some background information about it and what areas you specifically would like help with.
Popular code excerpts may be moved to "Code Snippets" by the moderators.
How do you deal with form layout customization? My experiences show that this is usually the weakest point of most form processors. And how about extending it with new types of fields?
The form API got created in 2 days, so there are still room for changes and addons.
How do you deal with form layout customization?
Right now it's possible to override the css file in the themes (like any other core frontened files).
Css file looks like this. http://peecfw.org/Application/core_tpl/ ... W_Form.css
When it comes to modifying the HTML, i am not sure what i will do, either make it impossible or move the generation of HTML to a tpl file and make themes possible to override this tpl file if wanted.
And how about extending it with new types of fields?
My goal is to support all (x)HTML form fields available, as well as HTML5 fields. But there are not yet possible to add custom fields. But good idea, I should make a clean way to implement this.
The possibility to create custom form fields is very useful. Suppose that someone would like to have a JavaScript markup editor or use various Dojo components. Form layout customization is also obligatory. You should not assume that a typical person would like to use the HTML structure you will give him, because he or she may get a different layout made by an external webmaster, and what then? I prefer using templates for this mixed with objects to represent certain form widgets. In this way you can define the form structure in a natural way, and still have OOP flexibility, but this requires a good template engine (by "good" I don't mean PHP, because this is not a template engine, but just a language, in addition pretty useless when it comes to write flexible templates).
You are right, so I sat this whole day and implemented the new changes, it made me rewrite the whole API
What I have done is that i have created a class for each field.
fields implements a field interface and extends an abstract.
Now it's totally customizable (in my eyes) and templating of the whole form is pretty easy because i have a getHTML() for each field, but without getHTML you have access to the fields' properties.
I rolled out a new version of PeecFW today with it's changes and updated the wiki page if someone's interested seeing it: