01-15-2008 08:50 AM
Published 16 August 07 03:50 PM
As you may or may not know, my team is working on custom sub-entities (aka custom tables) for the ACT! SDK, allowing custom entities to be created, and be related to Contacts, Groups, or Companies with a one-to-many relationship. A common scenario use-case would be to create such a sub-entity, (e.g., ‘pets'), and a custom tab on the Contact detail view, to access, edit, and delete the sub-entities related to a Contact.
First, we would love to get your feedback on any specific requirements you think would useful to have there.
Second, we'd like to share our current thinking on the field naming model regarding custom sub-entities, and get your feedback there as well. Specifically, how one will be able to define sub-entity fields and reference them in the SDK.
When setting out to design the metadata model for custom sub-entities, we tried to address several concerns we have today relating to field naming:
1. Spill-over tables Implications- in creating a field in Define Fields or in the current SDK, the field which is created may or may not physically be created in the primary table for that entity, due to physical limitations on the table size in the database. E.g., a contact field may be created on a ‘spill-over' table, because the contact table has reached capacity. And, because field metadata (field descriptor) access is done today using the format <tablename>.<fieldname> (using either real or display names), the name if the field cannot be reliably known until after field creation.
2. Field naming constraints -SDK consumers today cannot control the name of a custom field when it is created. This is due to spill-over table behavior, as well as other complexities, such as naming conflicts, etc.. The display name can be controlled by the consumer, but can be modified by the user.
Because of these current behaviors and our current field naming format in the SDK (<tablename>.<fieldname>), field creation today leads to a model where SDK consumers have to discover field name after field creation (because of the table name included in the field name format). This leads to complexities for SDK consumers, as they cannot easily create their known fields, and data bind these fields, without some level of indirection. Worse, some mapping between what the consumer needs and what the field actually is then needs to be stored external to ACT!, such that these fields can be reliably discovered by the consumer which created them on subsequent AC T! runs. E.g., to get or edit field values of the previously created fields. Display names cannot be used for this as these can be changed by an ACT! user.
We want to resolve this.
For sub-entities, and to address the aforementioned concerns, our current thinking is to introduce a new field naming paradigm, dubbed an alias name.
Of course, the current model would still exist for existing entities, in the very least. The introduction of the alias name would likely manifest itself as an optional parameter to the existing SDK GetFieldDescriptor() methods. E.g., ActFramework.ContactManager.GetFieldDescriptor(string fieldname, FieldNameType nameType). FieldNameType being an enum, of which Alias is a valid option. For custom sub-entities, a consumer would request a sub-entity manager based on the entity name, and would then be able to make those same field descriptor request, passing in the field alias name.
Again, we would love your feedback and input. Drop a comment and let us know!