Ok, let me try here;
Controllers are an MVC concept. There's obviously already tons of documentation about them completely separate from Orchard. It might be a good idea to work thru some "pure MVC" tutorials to help understand what it is and what it isn't.
But in a nutshell, a controller surfaces entry points to an application. These entry points are "actions" and are implemented as methods on your controller. You can then also define routes which determine how URLs are wired up to those actions (although
a default route will exist of /Area/Controller/Action)
Orchard provides a modular way to customise routes (via IRouteProvider) but it's still just MVC routing.
Now what a Controller typically does, is load some data from the database, and then decide how it's going to be viewed.
This data could be loaded from an arbitrary XML file, from any data source, or from an Orchard service or just an IRepository<T>.
At this point you can display the data using plain ol' MVC views, and no drivers will ever be called. Orchard will still participate in Theming decisions (if you tell it).
The only way drivers will get called from a controller is if you use specific methods of IContentManager; e.g. IContentManager.BuildDisplay(item). At this point drivers are used to perform shape composition for a content item. They're also
used for BuildEditor(item) and at that point can also provide postback/update handling. Drivers
only apply to content items. Actually I've been working on some code that lets you write drivers and build shapes in a similar way for any objects, basically by copying a bunch of the driver code and generalising it. But you still have to make
a special call to use it.
So what you'll see if you look at something like Orchard.Core.Contents.ItemController.Display is first a call to BuildDisplay (which runs drivers and builds a shape for the content item) and then "return new ShapeResult" which is an MVC action result that
Orchard has provided specially for displaying shapes generated by Orchard. You will also see non-content shapes displayed using this method but in those cases no drivers are used.
Does this help separate out those concepts?
Ok - regarding your other questions and comments;
- I've mostly learned by reading source code. Just looking at examples of how things are using in different modules. I've also dug into Orchard core quite heavily and it is pretty hard to understand (particularly everything relating to Drivers!) but it was
worth it and it learned a lot of useful stuff.
- I do agree that the Codeplex forums could be much better from a usability point of view. I just have all new messages emailed to me because it's way easier to follow in my email client than in the web interface. It's just obvious things that are missing
like when you look at the forum topics list there's no way to see if there are any new/unread posts. I think the way forward for this would be having a forum on the orchardproject.net website instead, preferably built
in Orchard, with some of these more standard forum features. But I guess for that we're waiting for a community forum module to happen! (Although there have been some discussions and I believe something might be in the works in that regard)