Dynamics CRM 2011：添加非实体表单字段

Question

I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...

For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...

Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.

The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.

This would work, but involves filling the DB schema with fake columns that will (or should ) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.

So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?

Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?

Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.

Answer 1

Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.

I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.

Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.