Community
Showing results for 
Search instead for 
Do you mean 
Reply

Sub Entities and Field Naming in the SDK

Employee
Posts: 225
Country: USA

Sub Entities and Field Naming in the SDK

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

  • This alias name would no longer have the coupling to a table name, but instead would simply have the field alias name. The field alias name would be a static, logical name. Since each entity is unique per database (both our own entities and custom sub-entities), this would remove the dependency for having the table name as part of the field name format.
  • We would enable SDK consumers to control the name of a sub-entity, as well as the alias name of a to-be-created field; hence, the field name can be fully known before field creation. This would lead to a model where consumers can reliably create and depend on their known fields, data bind to those fields, and not be bothered with details of tables. In essence, an SDK consumer would be able to build upon a foundation that a particularly named field will exist because they created it as such.

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!

Highlighted
Avid Listener
Posts: 30
Country: india

Re: Sub Entities and Field Naming in the SDK

Hi,
In your blog,it is mention that we can create link between custom table field and contact table.But how can ,tell me