Skip to main content
Updated to remove bad intel
Source Link
Ken McAndrew
  • 5.1k
  • 3
  • 20
  • 55

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the item's name.

EDIT: One of my developers just told me that if we try to map a field to "Name" with our workaround even, if we use that class in an IEnumerable in another class (like for a multilist), it throws an "object not set to an instance of an object" message. I'm going to review that, but I wanted to tack that information on because it all seems very odd.

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the item's name.

EDIT: One of my developers just told me that if we try to map a field to "Name" with our workaround even, if we use that class in an IEnumerable in another class (like for a multilist), it throws an "object not set to an instance of an object" message. I'm going to review that, but I wanted to tack that information on because it all seems very odd.

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the item's name.

Updated information
Source Link
Ken McAndrew
  • 5.1k
  • 3
  • 20
  • 55

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the item's name.

EDIT: One of my developers just told me that if we try to map a field to "Name" with our workaround even, if we use that class in an IEnumerable in another class (like for a multilist), it throws an "object not set to an instance of an object" message. I'm going to review that, but I wanted to tack that information on because it all seems very odd.

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the

We're using interfaces for our models with [SitecoreType(AutoMap=true)]. The templates we're using (for a refit, we didn't create them) have "Name" fields, but when I just declare string Name {get; set;} it's grabbing the Sitecore item name and not the Name field defined in the template. I have the template name field being declared with the SitecoreInfo property to a different "ItemName" field to prevent conflicts.

We've used the Name field before in other templates, thinking it was pulling from the template and not the item name, so I don't know if this is a change in the latest Glass Mapper or something we didn't previously notice.

For now, I'm having our developers use the SitecoreField("Name") attribute and call the field something like "NameField" - this is getting the correct field, so we have a workaround. But I was curious if this is something that changed, if it's been that way and I hadn't noticed, or if this is a bug and "Name" should map to a field template first, and only if there is no field with that appellation use the item's name.

EDIT: One of my developers just told me that if we try to map a field to "Name" with our workaround even, if we use that class in an IEnumerable in another class (like for a multilist), it throws an "object not set to an instance of an object" message. I'm going to review that, but I wanted to tack that information on because it all seems very odd.

Adding Glass Mapper to the Title, since this is a questino specifically about Glass Mapper
Link

Sitecore item name being auto-mapped to "Name" field in Glass Mapper

Source Link
Ken McAndrew
  • 5.1k
  • 3
  • 20
  • 55
Loading