This project has moved. For the latest updates, please go here.

I am assuming what you want is a standard master detail, so if I had a list like:

And a relationship list for a Cascading Dropdown that looked like:

You could configure a cascading dropdpwn like this:

And then you could add a Lookup Detail adapter to the Description column with a dialog that looks very much like the cascading lookup dialog, like so:

Note that I would add a checkbox to determine if the child column should be read-only, with the default being true. In my experience, sometimes what you want with master/detail is to pre-populate as a starting point but let the user edit it, but usually you just want it read-only so that would be the default.

Now the form would look like:

So if I selected down to Connecticut, the description would be pre-populated with 'Really swell.', and by default at least it would be read-only. I could also configure Manager and Staff as Lookup Details, off of the SalesState lookup.

I would add the following caveats, all of which are negotiable ;):

  • The Description field would be a snap-shot of what was in the relationship list at the time the SalesState was selected. (i.e. it would not get updated just because the Description was updated in the relationship list). This is an important point, because the only legitimit reason to duplicate the data is because you want a snap shot in time of what the detail data was. If you want something more dynamic (i.e. always up to date), then it should only be stored in the lookup list, and I'm not sure how displaying it in a form using SPEasyForms would work.
  • If Description is read-only, it would get overwritten any time the SalesState is changed in the edit form.
  • If Description is editable, it would only get updated when SalesState is changed and Description is currently empty. Otherwise, I would risk overwriting user entered data.
  • I would not do anything to ensure that the source field and destination field are the same type; the onus would be on you to ensure they are, or at least that the destination field is big enough to hold the data from the source field. For example, I could add a Lookup Detail adapter to a multi-line text field with the source being the Staff column from above, and the result would be something like a text field with a bunch of user names in it (which might be what you want, so I wouldn't prevent you from configuring that). On the other hand, I could map Staff to a single line text field and the data could easily exceed the single line limit of 255 characters, and that would be your problem because I'm not planning on preventing that either, so just don't do that ;). The only alternatives would be:
    • To limit it to same field type only. I don't love this idea because it is limiting and it could get pretty complex. For instance, do I allow multi-line to multi-line, or do they have to be the same type of multi-line (i.e. plain, rich, or enhanced rich). The latter would be fairly hard to implement given all possible combinations of field types and their options.
    • Or I could take it a step farther and have some complex grid of compatible type-to-type mappings that would greatly increase the complexity of the code, and I would be a hard sell on that, because the gain is so small in my opinion and the increase in complexity is disproportionately larger.

Last edited Feb 4, 2015 at 9:19 PM by mcsheaj, version 10