Multiple forms per "entity"?

Why not? I was just thinking about yesterday's post and had one of those disturbing thoughts that I get when I want to make software do something that its authors didn't intend (well, maybe, sorta, kinda).

 

Let's say I want to create multiple forms per "entity" (note the quotes). One way I might do this is to define a set of "like" entities in the metadata all pointing at the same physical location. I'd have to jury-rig the relationships a bit so the platform knew how to traverse them during create and update requests, but that's not really necessary.

 

If I were going to do this, what would I do? I'd define several entities that all mapped to a single, all-encompassing (data-wise) entity, I'd hide the super entity using roles and privileges because we don't want anybody messing with all that data (for some reason Steve Martin saying "you could melt all this stuff" pops into my head right about now… I don't know why), and then I'd configure-up all the forms for the shadow entities. Finally, I'd rename all the shadow entities so they show up, more or less, in the application. Then, and here's where the per-role stuff comes in, define roles for each entity.

 

In theory you should have different role-based views over the same set of data. Just a thought.

 

Update 13:45PDT - If I were really going to do this I'd just copy all of metadata for the source entity to the destination entities. There's no reason to go through the pain of actually creating the physical tables. That's why CRM is metadata-driven - so you can define things declaratively and the system will do the rest.

Comments

• Anonymous
  July 20, 2006
  I realy apreciate this post. For some time I fighting with idea. Result is a mess in CRM with all objects I have created. It would be nice If you could actualy try to achieve this and share it.
  
  Vladislav