mardi 24 février 2015

PHP object oriented form generator

I am trying to create an object oriented form generator. Please keep in mind it will be used only by a handful of people in our company to solve a specific problem.


I am currently facing two little caveats.


Syntax of creating elements


There are few approaches I can take.


Setting everything in constructor. As a drawback this could result in inconsitent constructor usage



Input::create('text', 'name', array('maxlength' => 10));


Limit constructor to type and expose only the most used attributes as methods (keep one method for mass attribute setting)



Input::create('text')->name('name')->value('value')->attribute('max_length', 10);


Expose every attribute as method with either creating a method for every attribute or with __call magic method which will result in no autocomplete support in an IDE. And even now, I can keep the attribute method.



Input::create()->type('text')->name('name')->value('value')->max_length(10)->id('id'); //etc.


At the moment, I consider the second approach as the best one, since it keeps "good" stuff from both worlds. As still provides a way to abstract some of the work, since e.g. method required would not only set the required attribute, but also mark this field for validation object as required.


Code duplication with approach 2 and 3


Since there are attributes that can be used by every element, but also attributes that are only usable by 3 or 4 elements, e.g. HTML5 attribute form.


Every element can inherit from base element which has methods for attributes that are universal for every element (e.g. name). Partially usable attributes can be solved with interfaces, but this leads to code duplication as they cant contain method body.


Traits would be the solution, but sadly, I am stuck at PHP 5.3 with no way to upgrade. That leaves me with either implementing Mixin or Composition pattern, which again, might lead to no autocomplete support. This would be partially mitigated when using second approach.


So to my actual question:


Which approach can end as most suitable? (suitable as in minimal code duplication, solid code reuse and easiness of implementation)


I realize this might very well spawn opinion based answers so I apologize in advance if it does.


Aucun commentaire:

Enregistrer un commentaire