Tales from the Evil Empire

Seems rather complex with a whole new set of terms and languages I'm not familiar with.

Honestly I had a difficult time reading it - ie an object described as 'cheap' at first sounds good but then I'm left wondering what cheap objects really are.

I'm also trying to figure out how normal items we discuss like 'modules' - are they MEF? Are they 'Areas' ?  How does this differ from when we had Sharepoint zones, parts, sites, pages (note the familiar terms) and then previewing,authoring, validating content and how content is delivered ?

I'll go read through it again and see if I can wrap my head around the abstractness of the content.

Thanks

This is a very useful article. It's what I missed in order to grasp the fundamental design of Orchard. Thanks for this!

I have one reservation at this point: why exactly do you have to inherit your interface from IDependency for injectable dependencies? It's not a very big problem, but still seems a limitation. Does this leak to module development as well?

Very comprehensive description, hats off for such a nice framework that I will probably love to fiddle with.

A few nitpicks about the document:

in the architecture section, Castle should be replaced by Castle.DynamicProxy, maybe add Castle.Core.Logging.

Castle Windsor link is confusing (as AutoFac is used as the IoC container), link to www.castleproject.org/.../index.html instead?

MVC is a pattern name, better spell ASP.NET MVC

This sentence is not clear: "Similarly, we have route providers, model binders and controller factories whose work is to act like the singletons that MVC expects", I'm not sure ASP.NET MVC is expecting singletons here, although it exposes (not sure of the details) some helpers through the view context, a better wording

In "Anatomy of a content type", the handler description is a bit opaque starting from the second paragraph, although code samples are a good way to clarify, it's not easy to pickup, maybe explaining why you would implement them with real examples would help.

in Localization section, "in a call to T" maybe saying "T method" or provide an example: T("This is a localizable static content").

Logging, uses Castle.Core (Castle itself is really a bunch of frameworks and components, so it doesn't designate something precise)

Overall, the doc is pretty good ;) It asnwers the "how" but lacks on the "why" part.

E.g. Dependecny Injection. I'm not sure why the IDepency interface is required. I'm not familiar with Autofac yet the way Orchard requires to specify objects lifetime through IXXXDependency is a bit strange. Clearly, there are cases where an object assumes a certain lifetime to fulfill it's goal. In that case it's a good thing to explicitly specify it's lifetime through an interface. But for other cases where object's purpose doesn't depend so obviously on the lifetime? I.e. it's very much possible that the objects author at inception can't tell for sure the required lifetime. In that case it's better to leave that decision to external component. That adds flexibility (as mentioned above) and makes it less of a breaking change to change objects lifetime later.

Hi Bertrand, thanks for the head up.

I pulled a fork of orchard here, the solution works quite flawlessly, I was able to run the web site in a short time, nice work on this.

I'd like your team look at a slight change I did on the Orchard Page module codebase (the first one I've looked at), it seems that things could be kept KISSer, also I'm not sure the ViewModel name fits for what we are using these classes for.

One can look at the changes here: code.google.com/.../detail

any opinion on these?