Hi,

This is a complicated description :) I'll start with some basics:

[ChildActionOnly] shouldn't be used with [HttpGet]. The reason is because when you mark an action with [ChildActionOnly] you are telling MVC to make this not publicly routable (i.e. it doesn't have a URL) and can only be rendered using Html.Action so applying [HttpGet] is irrelavent.

Next, when you post to a SurfaceController, you are posting directly to the surface controller, it is the same as if you were in a normal MVC app and posted to a controller. Therefore, even in a normal MVC app you'd never just return a PartialView because all you'll get is the markup for the partial view. This is exactly the same when working within Umbraco.

It's also very important to NOT cache your macro in your macro definition in the Umbraco back office as this will cache validation messages, etc...

Next, the message you are getting: "Error loading Partial View script" is due to an exception being thrown during the rendering of your macro. You can change the exception handling of macros by changing a config setting in your umbracoSettings.config file, by default you should have this:

<MacroErrors>inline</MacroErrors>

but you can change the value to: "silent", "inline" or "throw". For debugging it is best to change this to "throw" so you can see the real exception that is being thrown. My guess is that you are getting a Null reference exception in this code:

varuser=Membership.GetUser(username);
             returnPartialView("Reset",newResetPasswordSurfaceModel{UserID=user.ProviderUserKey.AsInt()});

Since you are not doing a null check on 'user' and then trying to access it's properties. And the reason it will be null is because you are not passing in any route parameters to your child action like 'token' or 'email' in your call:

@Html.Action("Reset","ResetPasswordSurface")

You should be doing something like this:

@Html.Action("Reset","ResetPasswordSurface", new {token="sometoken", email="someemail"})

Cheers! Shannon 

Thanks for that quality response.
I didn't mean for my request to be complicated, just thorough. I was hoping to avoid responses like "what version are you using?", "What are you trying to achieve?" or "can you post your source code?". (the more info i include the less back-and-forth is required.)
Please forgive any ignorance on my part as i'm a webforms developer attempting to familiarize myself with both Umbraco and MVC.

Steps i've taken so far:

1. removed [HttpGet] from Reset action
2. changed umbracoSettings.config with  <MacroErrors>throw</MacroErrors>
3. Handled exception in controller
   side note: When the page with an encrypted token in the query string is posted back the token seems to be UrlDecoded a second time resulting in an exception when decrypting.

This does not seem to have resolved the issue.

What Is currently occurring:

When the form is submitted the PostReset action is executed, but then the Reset action is executed and the result of this action is displayed in the response.

What i'm trying to achieve:

When the form is submitted the PostReset action is executed and the resut of this action is displayed in the response.

I've tried calling the PostReset action from the macro when the HttpMethod is POST but an exception is thrown:

an only use UmbracoPageResult in the context of an Http POST when using a SurfaceController form

It definately IS a POST as you can see from the modified Macro partial code (Exception thrown on the PostReset action line):

@inherits Umbraco.Web.Macros.PartialViewMacroPage
@if (Request.HttpMethod == "POST") { 
    @Html.Action("PostReset", "ResetPasswordSurface")
} else {
        @Html.Action("Reset", "ResetPasswordSurface")
}

From everything i've read Return CurrentUmbracoPage should allow me to display the validation messages for my model.

What am i doing wrong?

Okay i think it's clicked with me now.

The post action does not return anything for the response (that bit was new to me).
After the post when the Reset action is run the second time, since the modelstate is maintained, by passing a newly instantiated model, this model will inherit the model state of the model processed in the POST action (PostReset).

During the second time the Reset action was called, since the token data has been corrupted along the lines somewhere the token validation fails and it never gets to the point where it returns the partial view.

i temporarily bypassed the token validation and sure enough the model validation messages were displayed.
All I need to do now is get it to stop corrupting the encrypted token when calling returnCurrentUmbracoPage();.

Thanks for all your help, It is very much appreciated.

BTW. the parameters for the Reset method are received from the querystring the url generated and sent to the user by email.

Ok at least we're on to something here :)

With regards to the parameters for the Reset method coming from the current query string of the request, are you passing in these parameters manually to your Html.Action call or is it magically binding these parameters based on the current query string of the request ? If it is the latter, then this is probably your issue. To pass parameters into a Child Action you should explicitly do this, it's more of a fluke if your parameters are being bound by the actual query strings of the request.

Try this if that is the case:

@Html.Action("Reset","ResetPasswordSurface",new{token=Request.QueryString["token"], email=Request.QueryString["email"]})

You'll obviously need to use the correct query string keys.

Fluke! Wow. I was pretty sure that the model binding and rout data logic used to determine the appropriate controller action worked this way by design.
Oh well, i replaced the Html.Action call to include the values from the query string.
I was hoping that this might prevent the token from being sent unencoded when the form is submitted, no such luck.

The reason it's 'fluke' is because ChildActions are slightly different than normal actions. They are not publicly routable and used to just render views from views. Some call this an MVC anti-pattern (but whatevs). So yeah they'll follow the same binding rules as normal controllers but what would happen if you wanted to use that child action in a page that never has query strings. Anyways, IMHO its probably best to explicitly pass in the route parameters to child actions.

BTW, I've updated the docs here to explain the routing process:

http://our.umbraco.org/documentation/Reference/Mvc/forms#UnderstandingtheRoutingProcess

and added docs describing how to access the ViewData in child actions here:

http://our.umbraco.org/documentation/Reference/Mvc/forms/turorial-child-action#AccessingViewData

Hello,

I'm having the same problem and have no clue

This are the controller actions

[ChildActionOnly]
public ActionResult SubscribeToSession(int trainingid)
{
  return PartialView("Inschrijving", subscriptionViewModel);
}

[HttpPost]
public ActionResult SubscribeToSession(SubscriptionViewModel model)
{
  if (!ModelState.IsValid)
  {
     return CurrentUmbracoPage();
  }  
  // Handle post
}

This is the error i get

Can only use UmbracoPageResult in the context of an Http POST when using a SurfaceController form

Following your explanation, i do not see what i am doing wrong...

thx for your help...

Benoit

Hi Benoit - assuming your controller actions are within a controller that inherits from SurfaceController, you may be running into an issue because your two methods are named the same.  See here and in particular the attribute [NotChildAction] that you can use to decorate the second of your methods.

I have also had some issues where I'd followed the ChildAction Form method provided by @Shannon. I kept  getting the error message:

Can only use UmbracoPageResult in the context of an Http POST when using a SurfaceController form

Even though I'd followed the example to the letter.

What I had done was create a document type called Member Login (with alias "MemberLogin").

I had called my surface controller class MemberLoginController, and was therefore accessing it using the same name as the document type, "MemberLogin".

After pulling my hair out for a couple of hours I realised there might be a naming conflict, so I renamed the surface controller to MemberLoginFormController. Then it all worked as expected.

So it would seem having a document type alias and a surface controller with the same name causes some issues. Just thought I'd point it out in case anyone else runs into the same issue.

that did it for me. nice one. i'm using the hybrid framework and using a macro to render a custom form. been banging my head against the wall all day and finally solved it thanks to you!

is working on a reply...