Something I don’t quite understand.

[kennedystephen]

I create new tables and associated new entity types every-so-often. The tables are usually one-to-one to an existing entity type (like Account). The new entities are marked to extend the same existing entity type.  Then, under the existing entity node (FORMS folder), I create a new form containing fields from the new entity. I then add it as a SMART PART to an existing details page. After deployment, the new form shows up as a new tab under its associated details page. This process usually works successfully. When the user clicks SAVE on the main details page, the associated data in the new tab gets saved too. 

However, if I create the new form under the brand new entity itself (in the FORMS folder), and then add it as a SMART PART, it doesn’t seem to cascade the SAVE functionality when someone clicks SAVE on the details page. I’d much rather create new forms under the new entity, and associate it as a smart part to an existing entity…. rather than having a ton of forms under the existing entity’s FORMS folder. 

Am I making sense?

 Thank you for any help in advance.

[tagersea]

There are cases where using one-to-one tables is beneficial but I suggest avoiding it when possible. In the past we used one-to-one tables as SalesLogix did not support adding fields to stock (out of the box) tables. This is no longer the case.

When it comes to extension tables (one-to-one) you should base your forms on the root entity, not the extension entity. Is there a reason why you need to add a form at the extension entity level? You have a working solution by adding it as a root entity form so I am curious why you are trying to make it work another way.

With the Entity Model the rule of thumb with code and databinding is to approach solutions from the current entity's perspective. For example, if you are on the Account Detail Page any changes made to Account.Address.City will persist when the Account is saved. If you were to retrieve the Address entity from the database using the EntityFactory it would not be saved when the Account was saved. You would need to explicitly call Address.Save. Best case is that you are writing code that you should not have to. Worst case is that you encounter flaky behavior or exceptions because you and the databinding engine are stepping on each other's toes. I think this is what you are seeing.

[kennedystephen]

I add the one-to-one tables because I like the logistical seperation between the out-of-the-box root entity fields, and the new fields/table. Conceptually, it's the same issue I have with creating the form at the root level too.

For instance, we do some data collection (market research) on Accounts all dealing around a specific issue (say "cost of product"). Sometimes, this requires 20 new fields. Each of those fields directlying relating to "cost of product". I'd prefer not to create those 20 new fields as additional columns in the main Account table.

[tagersea]

I concede there are reasons that justify one-to-one tables and you have thought through your descision. I opt not to use one-to-one tables as it complicates reporting, group building, integrations, etc. Both descisions have merit.

However, when it comes to the SalesLogix solution I recommend not fighting its design to be root table centric (not extension table centric). If you use one-to-one extension tables you should still build the forms under the root entity. You could use a naming convention for your forms to keep them separated from the stock forms under the same entity.

Message Edited by tagersea on 06-28-2010 09:54 AM

[mdykun]

The reason that the smart part needs to be created under the root entity is to ensure that the binding context is correct. You are right that If you create it as its own entity the association would not directly be created. You would explicitly have to create that relationship before the save as it would not be easy to define your intent. This is also why grids and other smartparts are hosted underneath the parent entity and not the targeted entity (context).

Mark