MediaPickerField, BodyPart, and Administration of Custom Content Parts

Topics: Customizing Orchard, Writing modules
Feb 2, 2013 at 2:53 AM
I have a very interesting problem. First, I will state that I am admittedly using the latest release of the "clayless" branch of Orchard 1.6. However, my problem involves the following:

I have written a module with quite a number of custom content parts, each linked to a POCO object that represents data that can be used outside of the Orchard system (i.e., each "thing" I manage is represented by a content part and content part record with a single integer property that is the foreign key to a POCO entity). Migrations manage the relationships of all this, and the reason for the separation between entities and content is that the entity data is made available to mobile devices using ASP.NET Web API web services--both inside and outside Orchard. Also, each content type supports an "IdentityPart", so each instance can be successfully imported and exported.

To manage administration of these entities, I have custom administration MVC controllers, regular controllers, and API controllers, all with routes registered. In all my ContentHandlers, I provide metadata to specify "CreateRouteValues", "EditorRouteValues", etc. that refer to my custom administrative controllers.

All works beautifully until I use Orchard to add built-in parts to my custom types (e.g., the MediaPickerField and BodyPart). When the "editor" for my parts are accessed using custom administrative routes as specified in my handlers, I find that I am unable to instantiate the popup box on the MediaPickerField. However, if I use the pure content-based administration route for content (e.g., "http://localhost:501/Admin/Contents/Create/MyContentType"), the MediaPickerField works and saves properly. However, in this case, my custom content part data is NOT saved properly (because only my driver is called and NOT my custom administrative controller).

Using my custom administrative controller, my custom parts save properly, but any fields (and sometimes other parts attached manually) do NOT save properly.

It is worth noting that I also have custom routes set for my regular controllers (landing pages for the "user" view of these entities) that are not actually intended to route requests to the administrative interfaces but do (e.g., "http://localhost:501/ShortCutRoute/User/EntityAdmin/Create" opens the administrative controller if the user has rights even though "http://localhost:501/MyCustom.Module/EntityAdmin/Create" is the intended route to be used. I am not sure if routing could be an issue, but I wanted to make sure and be complete in my description.

My question is how to resolve this problem, so I can add parts at will to custom content types with custom administrative controllers and still have everything work. I structure my module code after the "Blogs" example, because that code provides the best example of parts being treated as content accessible from plain content lists as well as specialized lists direct from custom controllers.

Has anyone seen this problem and found a solution?

Travis James
Feb 10, 2013 at 7:35 AM
I think you're over-complicating things. Why would you need your own controller?
Feb 10, 2013 at 12:06 PM
I was following the Blog module example, which would, by its structure, seem to imply that if you have a part that has some complex logic and/or relationships attached requiring logic to ensure proper construction, the better place to do this would be in a custom administrative controller as opposed to a driver. Is that incorrect?

The parts that we are building have relationships with other entities and meta-types that can change how they are handled during CRUD operations--similar to blogging with BlogParts and BlogPostParts (and updating BlogParts "counts" whenever a new post is done).

Is there a better way to handle this?
Feb 10, 2013 at 7:44 PM
Yes, I don't see anything in what you describe that wouldn't be more appropriately handled with parts and drivers.