Posting data from partialview using MVC

Vote:
 

I have created a pagetype called 'CasePage' which, based on the case type (set as property), automatically adds the required editor using RenderAction. Those editors exist as partial views and each has its own form.

The problem is when filling in the form and submitting it. When I do so, the page is posted to the action 'Index', but I want it to be posted to an specific action for the case type. When I add the action to the 'BeginForm'-method, I also have to add the controller name and the form action ends up begin '/<controller>/action'. Since this URL doesn't exist in the CMS, submitting this form result in a 404.

What should I do to have the partial view post its data back to the current (CMS-)page and a specific action?

#66663
Mar 06, 2013 11:55
Vote:
 

I did find out that when I use @Html.RenderPartial, the form-action is correct. But since I want the partial to be dynamic, I'd like to use an action to determine which partial to load. Therefore I tried using @Html.RenderAction, but that results in an incorrect form-action.

#66669
Mar 06, 2013 14:15
Vote:
 

This sounds similar to an issue I had when working on getting XForms to work in a block type. What I ended up doing was building the action URL based on the current page's URL, so it looks something like this:

var urlResolver = ServiceLocator.Current.GetInstance<UrlResolver>();
var pageUrl = urlResolver.GetVirtualPath(currentPage.ContentLink);
var actionUrl = string.Format("{0}MYACTION/", pageUrl);

Then in the view:

@using (Html.BeginForm(new { Action = Model.ActionUrl }))
{
    // Your form...
}

That should get it to post to the current page the form is on.

#67878
Mar 13, 2013 19:46
Vote:
 

I find myself in exactly the same situation as Maikel. Any other solution to this in EPiServer 7.5 perhaps? Or do I need to craft my own url via UrlResolver as shown by Chris above?

#81205
Feb 11, 2014 14:31
Vote:
 

Has anyone been able to resolve this issue?  We have determined that XForms are not the solution we need because of their lack of layout customization and issues we would have with bootstrap.  I am trying to create the block that contains a form I am sent to a url with the controller and action method resulting in a 404 page. 

#109836
Oct 15, 2014 19:35
Vote:
 

Take a look at Ove Anderson's version of this: http://www.eyecatch.no/blog/2013/01/using-xforms-and-mvc-in-an-episerver-7-block/

Then for customization, Ove also wrote this: http://www.eyecatch.no/blog/2013/09/full-customization-of-xforms-with-episerver-7-and-mvc/

With the help of those two posts, you should be able to create a XForm block with a customized layout. I've actually relied on those posts in a recent project, and my XForm implementation has been pretty successful.

#109838
Oct 15, 2014 20:20
Vote:
 

Thanks for the suggestion Chris.  So do you not recommend developing forms in the tradional mvc style when using blocks or have you also had success with that in the past too? 

I only ask because we are going to have multiple forms on our site (different pages) but some of the data is being sent to third parties.  I honestly prefer to have the styling and development options of non XForm forms but at the same time I am running into routing roadblocks.  When I was in the episerver development training XForms were not really recommended.

#109839
Oct 15, 2014 21:16
Vote:
 

Thanks for the suggestion Chris.  So do you not recommend developing forms in the tradional mvc style when using blocks or have you also had success with that in the past too? 

I only ask because we are going to have multiple forms on our site (different pages) but some of the data is being sent to third parties.  I honestly prefer to have the styling and development options of non XForm forms but at the same time I am running into routing roadblocks.  When I was in the episerver development training XForms were not really recommended.

#109840
Oct 15, 2014 21:16
Vote:
 

I think it all depends on what you are doing with the form and its data. XForms are nice because they allow editors to create new forms and view its submitted data without outside developer interaction or codebase changes (providing that they are properly developed out). Out-of-the-box, they can cover for a large amount of use cases.

Though, as you've seen, XForm do have a less flexibilty, such as proper support for client-side validation and dynamic form values. There are ways around that, and given the time you have to implement XForms in your solution, you can develop the solution to use XForms that are just as powerful as standard MVC forms.

So I'm not for or against one method or the other; I've implemented both and continue to use both. You really just need to look at what you are building and providing to the editor, and make your decision from there.

And so you know, EPiServer is aware of the limitations and issues with XForms, and it is a topic of conversation when it comes to future releases of the platform.

#109842
Oct 15, 2014 22:15
This thread is locked and should be used for reference only. Please use the Episerver CMS 7 and earlier versions forum to open new discussions.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.