- Cartography is a hierarchical menu module. I built it as an example of how you can use Mechanics to create many-to-many relationships for multiple purposes. At the moment the UI is drop-down menus when you're actually creating
a page; so you can make a page be a top-level menu item, or make it a child menu of another page, etc. It's called Cartography because it's defining a map of the site and using that as a menu. But the system is very flexible so localization and named menus
can easily be added in.
Thanks for the info. I looked it up and I must admit that the terminology/naming (Cartography, Mechanics, Sockets, Plumbing, Paperclips, etc, etc) is utterly confusing in a technological/dev context. I tried to install the Cartography module in my
sandbox and now my Modules/Gallery is broken ("Error loading extensions from gallery source 'Orchard Gallery'. The operation has timed out.").
- What you're asking for with shapes sounds a lot like my Origami module which is also part of Science Project (http://scienceproject.codeplex.com). I use it to build all the custom UIs for Mechanics where you have a variety
of different models and editors (some nested). I've implemented a custom ModelDriver system which is very similar to ContentPartDrivers but can be applied to any model object you like, not just content parts. So it has separate logic which you can run on display/edit/update,
as well as some other hooks. Unfortunately I haven't documented it yet, it's just used heavily in Mechanics. What I'm saying about AJAX is that eventually I'll also be supporting that in these scenarios, by wrapping shapes (which are a core Orchard concept,
basically everything on the page is built out of shapes which are just little fragments of template in .cshtml files or in code).
Your third question is a bit more complicated. But basically drivers are only used when Content Items are displayed, or editors displayed, or when the POST is received and so the models are updated in the editor and logic
is handled there. On some other pages (i.e. not content items, for instance the registration page) you just have ordinary MVC views. Orchard takes care of applying a theme to your view ... it's just MVC. So drivers are just a specialised way of contributing
to content items. If you're making a custom view using a controller, you don't need drivers or parts.
After posting last night I spend some time looking through the Orchard source code and I think I understand a bit better now how the editing part works.
- When I am adding a new custom admin panel menu item on the left (such as "New Hierarchical Menu") it's driven by a standard ASP.NET MVC controller that returns normal views and handles POSTs, etc, but has the [Themed] attribute applied. This works fine
for either models that derive from ContentItem or ContentPart as well as such that don't (custom non-orchard-content models).
- ContentParts/ContentItems do not use standard MVC controllers - instead they use a Driver/Handler to handle the update/display, but still use Razor Views. However the pattern seems pretty similar, because I see that Display/Editor return a DriverResult
which probably subclasses ViewResult (haven't checked). Also does sortof makes me think that in the Razor View for the editor of the content part I can still use something similar to Url.Action() and a custom controller to add some extra dynamic behavior when
editing a content part.
It's quite interesting that one can combine both. E.g I can have a MenuItemPart which is attached to a content item and also have a MenuItem non-content model & record which simply have a string Url property. Then I can query the contentmanger for contentitems
that have a MenuItemPart and combine that with non-MenuItem parts. Can't wait to play around with that! :)