Cannot initialise a FieldName with ChoicesFieldName() method configured

Aug 1, 2012 at 2:04 PM

I have a conventional field 

[MemberOrder(100), StringLength(60)]
        [DisplayName("User Name")]
        [Required ]
        public virtual string PersonName { get; set; }

with choices method implemented 

        public IList ChoicesPersonName()
            var q = from person in Container.Instances()
                    select person.PersonName;
            return q.Distinct().ToList();

I also have an action to create new object with the PersonName field initialised

        public FaultReport CreateNewFaultReport()
            var newFaultReport = Container.NewTransientInstance();
            newFaultReport.PersonName = this.PersonName;
            return newFaultReport;

Invoking this action delivers a new object but with out the initialisation data

However if I remove the ChoicesPersonName() method the new object is displayed with the initialisation data.

How should I implement both capabilities together?


Aug 1, 2012 at 2:22 PM
Edited Aug 1, 2012 at 2:22 PM

My first suggestion is to try adding a DefaultPersonName method also.  I'm not sure that it matters what (string) value that method returns  -  could be an empty string  -  I'm hoping that setting the PersonName in your CreateNewFaultReport method will override that default method.

(I'm basing this on a note in section 3.6.6. of the manual  -  which is admitedly not about choices, but I think the same principle holds.)

Let me know if this works.  If it doesn't, try making the DefaultPersonName return the existing value in the PersonName property  - though I'm not at all sure that would make any difference.

But, on a separate note, why does FaultReport have a string property 'PersonName' rather than a Person property that holds a Person object  -  that looks like denormalisation to me?


Aug 2, 2012 at 11:11 AM

Adding DefaultPersonName method works, the default value returned is immaterial as the instance initialisation prevails. Thanks very much for the pointer.

Concerning PersonName string rather than Person property; you are completely correct. The particular object  here is totally standalone from the rest of the domain model solely because I am iterating user interface options with end users for a facility that is not (yet) integrated into the domain model. By demonstrating NO can be setup to satisfy the detailed user demands is proving really useful for getting buy in to a new shop floor process we want to introduce.