Is there any way to prevent 'Fields mapped onto related fields' getting the related field's attributes?

Posts   
 
    
TomDog
User
Posts: 618
Joined: 25-Oct-2005
# Posted on: 07-Jan-2019 06:22:21   

I have this Field mapped onto related field

        /// <summary>Gets the value of the related field this.StaffMemberToBeTrackedBy.StaffMemberName.<br/><br/></summary>
        [Display(ResourceType = typeof(Labels), Name = "Form_StaffMemberName")]
        [Required(ErrorMessageResourceType = typeof(AdminStrings), ErrorMessageResourceName = "RequiredStaffName")]
        public virtual System.String StaffMemberToBeTrackedByName
        {
            get { return this.StaffMemberToBeTrackedBy==null ? (System.String)TypeDefaultValue.GetDefaultValue(typeof(System.String)) : this.StaffMemberToBeTrackedBy.StaffMemberName; }
        }


but the designer/generator copies all the attributes from the related field (StaffMemberEntity.StaffMemberName) and ignores any I have put on the StaffMemberToBeTrackedByName property.

In this case (and I imagine in most cases) this is not desirable. Is there anyway to prevent this?

Version 5.5 and earlier

Jeremy Thomas
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 07-Jan-2019 09:40:50   

Looks like a bug in the code generator (TDL interpreter), where it ignores the 'RelatedField' argument of the Foreach Attribute loop.

I can reproduce it indeed: ignores the Field mapped onto related field (forf)'s attribute and emits the attribute of the related field. This isn't how it should work, as forf's have their own attribute definitions/rules.

Looking into it.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 07-Jan-2019 11:34:52   

It's present since the beginning of this feature, in 2009. disappointed I can imagine people using the 'broken' behavior, namely they get the attributes like 'DataMember' defined on the related field now automatically defined on the Forfs. 'Fixing' this, will break that code and will require them to define the attribute also at the Forf level. Which might be a small task, but it's still a breaking change. We normally won't do that on a bugfix release (which these are, 5.4.4 & 5.5.1).

It sucks, as it's potentially a 1 line change (Line 5023 in Interpreter.cs, change:


case Token.RelatedEntityField:
    settingValuesTarget = _currentRelatedEntityField;    // Line 5023
    break;

Into

case Token.RelatedEntityField:
    settingValuesTarget = _currentFieldOnRelatedField;
    break;

and it will work properly, but have to check whether it will work in other loops using the same method)

and there's no easy workaround either.

I'm very reluctant to make this change at this point, as it's a breaking change and I really want to schedule this for 5.6. I know that sucks, but it's something we normally won't do as potentially breaking other people's code is something we try to avoid during bugfix releases (5.5.x)

That said, the feature has never worked as intended: defining an attribute on the field mapped on related field was never honored, as the method to obtain the object containing the attribute definitions always returned the object of the related field instead. So in all cases the user using this feature today got the attribute of the related field.

We've to think about it, but for now assume this won't be fixed before 5.6

Frans Bouma | Lead developer LLBLGen Pro
TomDog
User
Posts: 618
Joined: 25-Oct-2005
# Posted on: 08-Jan-2019 09:35:26   

That's OK I wasn't holding out much hope for a quick resolution. I've reverted the code back to using

interface IStaffMemberMetadata
{
            [Required(ErrorMessageResourceType = typeof(AdminStrings), ErrorMessageResourceName = "RequiredStaffName")]
            object StaffMemberName { get; set; }
}

[MetadataType(typeof(IStaffMemberMetadata))]
public partial class StaffMemberEntity

I was in the process of doing away with MetadataType etc but I guess this is the reason I used it back in the day.

Be good to see it sorted in the next version.

Jeremy Thomas
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 08-Jan-2019 11:36:28   

Thanks for understanding. simple_smile Yes, we'll fix it in 5.6 simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39590
Joined: 17-Aug-2003
# Posted on: 11-Mar-2019 15:09:03   

Fixed for v5.6

Frans Bouma | Lead developer LLBLGen Pro