Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 24 2018 16:41

    leekelleher on develop

    Migration to UMCO - Updated th… (compare)

  • Jan 24 2018 16:40
    leekelleher edited #234
  • Jan 24 2018 16:40
    leekelleher edited #234
  • Jan 24 2018 16:40
    leekelleher edited #234
  • Jan 24 2018 16:22
    leekelleher edited #234
  • Jan 24 2018 16:20
    leekelleher edited #234
  • Jan 24 2018 16:03
    leekelleher labeled #234
  • Jan 24 2018 16:03
    leekelleher assigned #234
  • Jan 24 2018 16:03
    leekelleher opened #234
  • Jan 24 2018 15:39
    leekelleher unassigned #195
  • Jan 24 2018 15:39
    leekelleher unassigned #188
  • Jan 24 2018 15:39
    leekelleher unassigned #177
  • Jan 24 2018 15:39
    leekelleher unassigned #176
  • Jan 24 2018 15:39
    leekelleher unassigned #138
  • Jan 24 2018 15:39
    leekelleher unassigned #111
  • Jan 24 2018 15:39
    leekelleher unassigned #67
  • Jan 24 2018 15:39
    leekelleher unassigned #61
  • Jan 24 2018 15:39
    leekelleher unassigned #59
  • Jan 24 2018 15:39
    leekelleher unassigned #53
  • Jan 24 2018 15:39
    leekelleher unassigned #49
Matt Brailsford
@mattbrailsford
we took it as a sign when we were discussing it that it might not have been the right solution
but we've had that request / query a few times now
people "expecting" umbraco property to have run
James Jackson-South
@JimBobSquarePants
Hehehe... It's only really the DoctypeFactory that would require it really wouldn't it?
Barry Fogarty
@BarryFogarty
Cool. I'd be interested to hear, assuming you are working with a collection of nested contents (polymorphic), if this is the kind of way using Ditto you would resolve it to a collection of items that all implemented a common interface. Yes I did find it a bit confusing because it essentially overrides the default automatic behaviour where ditto auto converts based on property name, class prefix settings etc
Matt Brailsford
@mattbrailsford
can't recall what the other people were using
James Jackson-South
@JimBobSquarePants
I avoid decorating the properrties with UmbracoProperty by decorating the class or any base classes with UmbracoPickerAttribute. Then UmbracoPropertyAttribute is automatically aded anyway.
Matt Brailsford
@mattbrailsford
@BarryFogarty that's exactly what DocTypeFactory is for
Barry Fogarty
@BarryFogarty
But makes seense what you are saying @mattbrailsford - that if you declare a processor on a property that they all must be declared.
Matt Brailsford
@mattbrailsford
it uses the "DocTypeAlias" the resolve the type, and assumed the target type of the property is the base class
it's explicit for sure
the other option is to always call UmbracoProperty
but we don't do this because it's entirely feasible that a processor may not even need a property values
for example AppSettingAttribute
calling UmbracoProperty would be a waste of time and processing
which is why we took the stance "if you declare 1, declare them all"
and if you find yourself declaring the same set again and again, wrap them in a multi processor
Barry Fogarty
@BarryFogarty
Yep makes sense. I initially thought passing a PropertyName argument to the DocTypeFactory attribute might help avoid confusion but I guess it becomes less generic then.
Matt Brailsford
@mattbrailsford
maybe we could go the oposite direction and have a flag on a processor that says "I'm not UmbracoProperty dependant"
James Jackson-South
@JimBobSquarePants

@BarryFogarty If you use a base class for all your nested content you can decorate that class with [DittoDocTypeFactory]

Using it in any calling classes like

public virtual IEnumerable<NestedComponent> NestedContent { get; set; }

Will populate the values without having to declare any other attributes since Ditto will see no attributes and automatically add UmbracoProperty

NestedComponent is my base class there.
Matt Brailsford
@mattbrailsford
interesting
Barry Fogarty
@BarryFogarty
Cool, that's quite nice - is it only for base class or should it work on an interface?
James Jackson-South
@JimBobSquarePants
I think it should work on interfaces too. I'm sure we added that constraint @mattbrailsford
Barry Fogarty
@BarryFogarty
I'll give it a try now!
Matt Brailsford
@mattbrailsford
@JimBobSquarePants I think I came up with a need the other day with class decorated models
I think right now if we see a processors on a class, we use it completely
ie, we assume it will absolutely be able to resolve the value
wondered if we should add some checks to say, let it process it, but if it's not the right value that comes out, run regular processors
Matt Brailsford
@mattbrailsford
i had an example where I have a "link" model, which when mapping from IPublishedContent grabs the Name / Url, but wanted it to handle UrlPicker model values too
James Jackson-South
@JimBobSquarePants
@mattbrailsford I'd have to check our exact logic.
Matt Brailsford
@mattbrailsford
guess we should really write some docs :D
James Jackson-South
@JimBobSquarePants
Yeah.... It's about time. There's so much power there but it's all in our heads

Ok so the current logic is.

  1. Check the property for processor attributes and capture them
  2. If non found add the default (UmbracoProperty)
  3. Then check for type based attributes and add
  4. Then check TypeParams in enumerables
  5. Then add core types.

As long as the processor ones resolve to your expected type they should overule anything found elsewhere.... Should.

Barry Fogarty
@BarryFogarty
[DittoDocTypeFactory] on my interface works great guys. :thumbsup: :thumbsup: Keep up the good work, and HAPPY CHRISTMAS :-)
Matt Brailsford
@mattbrailsford
:+1:
James Jackson-South
@JimBobSquarePants
:clap:
You too!
Barry Fogarty
@BarryFogarty
Guys sorry for the interruption, just following on from yesterday, can I use [DittoDocTypeFactory] on a picker-based property? Basically I'm trying to do a similar thing as I described yesterday, but this time the collection will be derived from an MNTP:
[UmbracoProperty("cards_Items", Order = 1)]     
[UmbracoPicker(Order = 2)]
[DittoDocTypeFactory(Order = 3)]
public virtual IEnumerable<ICard> Items { get; set; }
Matt Brailsford
@mattbrailsford
If you have jeavons value converters installed, don't think you need the picker attribute
Barry Fogarty
@BarryFogarty
Ah that could be it, I've just come one to this project and not checked that. Theoretically it should work though? As long as the picked nodes implement ICard?
Matt Brailsford
@mattbrailsford
Yup
Barry Fogarty
@BarryFogarty
It is installed but removing UmbracoPicker attribute doesnt change things - I have 3 items of type ICard but they are all null. When this executes on the doctype with the nested content property however, I can see the {CardProxy} type in the watch. In both cases though, the GetPropertyValue returns a list of IPublishedContent correctly.
Maybe its not being wired up correctly on my concrete type - anyway off to lunch will do more investitgations after. Cheers
Matt Brailsford
@mattbrailsford
Hmm, it may not work with virtual props
James Jackson-South
@JimBobSquarePants
That RelatedPagesAttribute code I posted yesterday works fine with picked items. Everything should work with virtual properties.
I never install the value converters.
They won't work in that scenario anyway since the value converters return type is IEnumerable<IPublishedContent>
Barry Fogarty
@BarryFogarty
I tried uninstalling the value converters but the result is the same, list items are instantiated but null. The raw value from my picker is now a CSV of node IDs. I think I'll just take another approach, thanks for having a look though