Should we access <form> data in ContentPartDriver<T>.Display?

Topics: Writing modules
May 19, 2014 at 4:06 AM
Hi All,

I'm new to Orchard but loving it. The project and the community that surrounds it is great!

We have a general question about style when developing with Orchard. We have a part that customizes its output based on <form> data from the user and properties of the part. We are comfortable building this functionality as a controller, however, it would be great if we could reuse the existing Orchard Content Item Composition and Auto route functionality.

It seems that we can get access to the Request through the IWorkContextAccessor in the Display method of the Part's driver. The question is should we or is there a more maintainable (and stylish) way to do this? It would be even better if we could make use of the existing model binding functions.

There are a few things that we can see this being useful for in out current project, however, in the situation at hand, we are building a "product selector" part. Input variables (questions) are attached to the "ProductSelectorPart" and the answers to these inputs (<form> data) determine the next question and the range of products appropriate to the users application.

Your guidance is appreciated.

May 19, 2014 at 10:22 PM
The display sounds like a weird place trying to access form values: if you want to handle the POST you should do that in the Editor() method, where you also have access to the IUpdateModel (gateway to the model binder).

We tend to use parts as view models too if the case is simple so could just update the part itself there and thus let the model binder bind the form values to the part itself. That is if you also want those values to be persisted through the part. Otherwise you can also create a separate view model and update that with IUpdateModel.
Marked as answer by Threeboxes on 5/20/2014 at 9:59 PM
May 21, 2014 at 4:59 AM
Sounds very logical.

It seems our situation might not be the best place to use a Part as a View Model. The content items containing this part will contain other parts which should not be editable on the front end. As we work through the details it seems like the best way to approach this is with a custom controller.

Thanks for your help.