I have two tables, servicelist and serviceproperties. The first defines the basic characteristics of a service (for instance price, name, description), the second describes the various (dynamically definable) properties that a service may have (how long the service is offered, or at what address, or what quality of service, depending on what service we are talking about). The properties from serviceproperties are linked, MANY-ONE, to the services declared in servicelist.
I need to create an interface to add, update and delete various services. For that, I would like to create a… let’s call it meta-model, which would present a row from the servicelist table AND its corresponding properties from serviceproperties as a normal model, supporting find(), save(), delete() functions, but also custom functions such as createProperty(), deleteProperty(), updateProperty().
Any suggestions on the best approach for doing this ?
zaccaria, thanks for the reply. I’ve read those pages, but I’m not talking (only) about how to create/update services. I’m interesting in an elegant and Yii-like method of creating a model which would present an (already existing and defined) service to the outside world like a classical table row, even though at the db level it is held in two tables and its properties are dynamically defined. I have already defined, in the serviceproperties table, the appropriate fields for “property validator”, “validator options”, “validation scenario”, basically everything to be able to dynamically generate the validation rules.
I was thinking about extending the attributes array and adding the appropriate validation rules in an afterFind() function, and to extend the save() function, as well, to save the values of the dynamically declared properties. What do you think ?
If the properties are fixend, depending on the type, therefore I think is possible to di with one active record.
In this case give a look to how to collect tabual input, because each property will be a textbox with an identical name, so you sould disambiguate with something like: [address][description], [duration][description] and so on.
Unfortunately, the properties are not fixed, and they will not stay fixed. They share a common "schema", though, each property is defined by:
-serviceId - the service to which this property belongs;
-propertyName - self explanatory;
-propertyType - the same;
-validators - a list of validators which should be applied to this property (integerOnly, maxlen, required etc);
-validatorInfo - supplemental information required by certain validators;
-scenario - the (optional) scenario for which the validation should be applied.
Other than that, I have no idea about which and how many properties will be attached to the service, they should be administered by the supervisor, dynamically. Despite this, though, for other program components (such as invoicing, or technical administration), the service should appear as a monolith, as if all his properties would be in a table.
