Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > Designer> Is there any way to prevent 'Fields mapped onto related fields' getting the related field's attributes?
 

Pages: 1
Designer
Is there any way to prevent 'Fields mapped onto related fields' getting the related field's attributes?
Page:1/1 

  Print all messages in this thread  
Poster Message
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
559 posts
# Posted on: 07-Jan-2019 06:22:21.  
I have this Field mapped onto related field
Code:
        /// <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
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37319 posts
# 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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37319 posts
# Posted on: 07-Jan-2019 11:34:52.  
It's present since the beginning of this feature, in 2009. Dissapointed 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:
Code:

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

Into
Code:
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
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
TomDog
User



Location:
Wellington, New Zealand
Joined on:
25-Oct-2005 22:21:17
Posted:
559 posts
# 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
Code:
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
VS 2017 C#, LLBLGen v5.4, Winforms, WPF and ASP.NET MVCLLBL & LinqPad
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37319 posts
# Posted on: 08-Jan-2019 11:36:28.  
Thanks for understanding. Regular Smiley Yes, we'll fix it in 5.6 Regular Smiley
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37319 posts
# Posted on: 11-Mar-2019 15:09:03.  
Fixed for v5.6

Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.