The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Person is the superclass for all three, Member defines one aditional field named joindate (it also inherits all of Persons public properties and public methods ofc, and thier definitions in the classmap so no need to define them again) which is an Integer and can't be null.

Admin then extends Member, but there is not a required joindate for admins and thus it changes the "allownull" for joindate to true. The email adress is not required either for the admin so he changes the field define in his parents(Member) parent(Person) to allow null.

I think it's way to messy and I prefer to have set Classes/Objects to handle field mapping, such as in my last post. I played around with lastcrafts idea also but It just get's a bit to when you say wan't to add a primary key,

I think it's way to messy and I prefer to have set Classes/Objects to handle field mapping, such as in my last post. I played around with lastcrafts idea also but It just get's a bit to when you say wan't to add a primary key,

$mapping->id->primarykey->not_null->auto_increment->integer;

that's just like writing Sql ;p

I think you missunderstood me. I don't want you to write DB table definitions like this. Its messy. All I was trying to say is to rewrite this.

Idea is this: You have your basic "abstract class Model" which is the top level in the model heriarchy - to use objects with a model you extend it and define methods in your class named "ClassMap();" (as you can see above) which should be protected - this would allow you to builda heirarchy of model classes for example Module-based applications, etc. To hide a type of mapping from a subclass just make the method private instead.

I like the code example, but I'm on the fence with having all the mappings in one place.

I think in terms of modules for my sites. A module consists of the table definition, the php code and the html templates. Thus, I'd quite like to keep everything related to the module together so it's easy to take to another site.

Nice idea Ren, I agree that's a much better approach. (this is the exact reason I don't code everything and then release it as "this is done", perfer to debate / argue everything with others before making a decision)

Nice idea Ren, I agree that's a much better approach. (this is the exact reason I don't code everything and then release it as "this is done", perfer to debate / argue everything with others before making a decision)

This I'm interested in, does the above argument for the constructor(ModelMapContainer $parent = null) work for you, for me it just breaks the whole application without errors or anything.

Instead of using a "magic" class called ClassMapping you specify what you wan't by either asigning something of the correct type (ie array of groups for a group collection, etc.) or assign a string such as "string:25" or "integer:3", the default is also "NOT NULL" now, so you add :null at the end to allow null.