populating ContentType Field properties?

Topics: Writing modules
Feb 25, 2011 at 7:53 PM
Edited Feb 25, 2011 at 7:54 PM

I have code to create the contentPart for a contenttype but how is a field created and set? eg. I have an imageField that I have added to a contentpart, I need to upload the image and set it's properties when the feature is enabled. The imagefield will be with the belts.


string[] martialArts = {
                                       "Tae Kwon Do","Escrima","Combat Hapkido"
            foreach (var martialArt in martialArts)
                var ma = _contentManager.Create("MartialArt", item =>
                        item.Record.Title = martialArt;
                        var map = item.As();
                        map.Active = true;
            string[] belts = {
                            "White","Yellow","Gold","Orange","Green","Purple","Blue","Brown","Black White","Black"
            foreach (var belt in belts)
                var beltCreate = _contentManager.Create("Belt", item =>
                    item.Record.Name = belt;
Feb 25, 2011 at 8:12 PM

var picture = (ImageField)contentItem.As<ProfilePart>().Fields.First(f => f.Name == "Picture");

In the next version it will be easier:


Feb 26, 2011 at 2:13 PM

Suggestion with the imagefield as well, it would be nice to be able to pick from the media service.  Thank you. 

Apr 16, 2011 at 6:16 PM

Is it possible to access parts easily, like "contentItem.ProfilePart.Picture" in 1.1?

Apr 16, 2011 at 6:48 PM

From inside your cshtml views, yes. You can use Shape Tracing to explore the model and when you click on a property it will show you the @ command to reach that property.

But from elsewhere (i.e. normal C# code) you still need to use contentItem.As<ProfilePart>() etc.

Apr 16, 2011 at 7:43 PM

Thank you for the information. I hope accessing like that from code feature will be added soon.

Apr 17, 2011 at 5:29 AM

I don't think that's true: if you treat a content item as dynamic, you're in business. dynamic ci = myContentItem;

Apr 17, 2011 at 4:22 PM
Edited Apr 17, 2011 at 4:22 PM

Hmm, I hadn't tried that - seems a bit strange to me to cast an object to dynamic just to access properties that you can get to anyway. Personally I don't see the problem with As<T>, it only takes a few extra characters (and actually with the benefits of Intellisense ultimately requires less keystrokes). I can see where dynamics are preferable in views and with some of the shape related stuff ... but with model objects I just feel happier using strong typing, particularly when it comes to refactoring.

Apr 18, 2011 at 11:53 PM

dynamic is not a type, so that is not technically casting. As<T> is great but it won't help for fields... See the horrible code Sébastien posted, that you still need to use if you don't want to use dynamic.

Apr 19, 2011 at 1:27 AM
Edited Apr 19, 2011 at 1:27 AM

I really don't mind Fields.First(f => f.Name == "Picture") ... I wouldn't exactly call it 'horrible', it's a fairly straightforward Linq query ... it's not that much more cumbersome than just typing the property name, and it's pretty rare that I actually need to access a field from code. Mostly I'll be building a Part if I need anything more serious than just displaying the field shape as usual. In fact there's only been one single time so far that I've needed access to a field like that; compared to dozens of times using As<T> for parts ... so for me it's not enough of a benefit to outweigh entirely losing Intellisense on the Part accessor.

Or maybe I've just got so used to Intellisense over the years that I find dynamics somewhat scary :)

Apr 19, 2011 at 2:37 AM
Edited Apr 19, 2011 at 2:44 AM

Just had some further thoughts on this because, well, dynamic really interests me and Orchard is the first time I've really seen it applied in any significant way. I'm not trying to complain about its usage; quite the opposite, in fact - it opens up some really interesting and powerful scenarios that would otherwise be extremely awkward... But "with great power comes great responsibility" and all that, and also I'm just trying to get my head around exactly what I prefer about the more longhand notation in certain cases.

What's worrying me is that there are times when dynamic notation can kind of obfuscate what's really going on and potentially make some things more confusing.

Before I go on, I'm going to quickly invent a new extension method for ContentPart. It's a one-liner called Field<T> and it will make Sébastien's longhand code look much nicer :)

public static T Field<T>(this ContentPart part, string name) {
    return (T)(part.Fields.First(f=>f.Name==name));

So let's suppose for a minute that I'm tracking down a bug in some code written by someone else. I see a line like this:

var thing = ContentItem.Something.Else.New;

Now; what exactly is going on there? Is "Something" a Part, or could it be an obscure property of ContentItem that I was previously unaware of? I really don't know, and I can't even find out by hovering over it, because dynamic won't give me any information. Then, if I assume it is a Part, what is "Else"? It could be a Record-backed property of that part (perhaps a join to another table) or it could be a field. I still don't know; the only way to find out is to run the thing and debug, and even then the readout the debugger gives me on dynamic objects is frequently very hard to understand!

Contrast the above with:

var thing = ContentItem

Ok; so it doesn't look quite as pretty, but actually it doesn't look that ugly, especially with my extension method; and there is an immediate and obvious advantage here that I can see at little more than a glance exactly what's going on. I'm drilling into a Part called Something and then a Field called "Else" of type NewField, which has a property called New. I can even hover the mouse over New and see that it's a Boolean (perhaps in the first example I might even have suspected it was some kind of factory method; this code I'm debugging was clearly written by someone with a brazen disregard for conventions!)

I can see that there are situations where the dynamic syntax is really very quick and useful; and particularly in Views where the model is dynamic anyway I would of course favor the shorter version. But where there's a possibility of keeping things strongly-typed, which there still is a lot of times you'd be writing this kind of code, I'd rather do so - even if it takes a few extra keystrokes and an extension method or two.

But then, I am also just a big fan of the As<T> method, largely because it's pretty much exactly the same as a method I wrote myself months ago in a project I was building, and it's a nice elegant compromise between adding dynamic functionality whilst retaining strong typing. So I really just enjoy using it :)

Apr 19, 2011 at 2:42 AM

Err, sure, whatever works for you... Look, somebody was saying that they wish the dynamic form that is available from views was also available from code. I merely provided a way to make it work. Now if you prefer the strongly-typed stuff, I can see nothing wrong with that. I was just answering the question.

Apr 19, 2011 at 3:09 AM

Sorry, I can get carried away sometimes when a point interests me. It is a very cool feature. I guess I just wish there could be a "best of both worlds" where the dynamic objects could still have some form of Intellisense support (I know that's impossible - at least right now ...)

Apr 19, 2011 at 3:15 AM

It's not impossible: if it can be done at runtime, it can be done in principle at design time. Look at how much IntelliSense can be provided in JavaScript...

Apr 19, 2011 at 3:28 AM

That's why I said "at least right now..." ;) With all the advances C# has made, who knows what it'll be doing by, say, .NET 6 or 7?