ASP.NET v2.0: Posting to Other Pages is too Limited

I'm definitely excited about ASP.NET v2.0 and all the new features it brings, so its hard to criticize it in most cases.  However, one problem I have is with the current implementation of posting to other pages.  As most ASP.NET developers know, your server-form is limited to posting back to itself in ASP.NET v1.*.  This behavior will change in ASP.NET v2.0 with a feature called cross-page posting.  Basically, each button (and other relevant controls) have a postTargetUrl property.  This property allows you to specify where that control will cause the page to be posted to.  This is great in most cases since it allows the post target to be changed on a case-by-case basis, while keeping the rest of the form to still post back to itself.  The problem is that the  current implementation forces this url to be a page in the same application!

I understand what the ASP.NET team is doing -- they are allowing you to actually code against the original page from the new page that was posted to.  This is a great feature, but there is little need for posting to another page of your own application!  On the other hand, there are very real and important needs to be able to post to other pages outside of your server, let alone your application.  These include all sorts of services that others have implemented, including some payment processing engines.  There are work-arounds to this right now in v1.* that will continue to work in v2.0, but I think they should address the real need here if they are going to address it at all.  In case you are wondering, the work-arounds are to (1) use non-server forms and no server controls, (2) emit client-side java-script to change the action attribute of the form, (3) or use a custom server form control like Andy Smith's from MetaBuilders or my WilsonWebForm.

I don't expect them to change their overall approach and start allowing multiple server forms, which so far can only be done with my WilsonWebForm.  I don't like that they limit valid html which makes perfect sense in some cases just because its not the best practice in most cases, but I do appreciate their stance on this -- and it certainly helps me sell more subscriptions.  But this is different, they are going out of their way to admit there are cases that require something different, while still ruling out the only scenarios that really matter.  And so far it seems that this feature is getting received very well (although I doubt this huge limitation is understood by most of these people), so its actually kind of funny to me that they originally didn't even want to provide this feature at all when I and others first asked for it.  So write to Rob Howard or Scott Guthrie and complain now while there is still time to correct this oversight.

9 Comments



  • >This is a great feature, but there is little need for posting to another page of your own application!



    and I thought I was the only one who did not get it.



    I agree, like you said, the form should be able to post to "other" applications, services etc.



  • Well, I think the MS solution is focuing on maintaining the ASP.NET "feel" around. You know, having the old page available, stuff like this. Stuff that is very valuable within the complex of one application.



    THe problem is, though, that it makes it "impossible" to integrate - as you do with your control - forms that are pbasically NOT controleld by ASP.NET and go for other applications. I definitly see your point with things like payment processors.



    This is definitly a limitation that people will stumble over soonish.

  • >This is a great feature, but there is little need for posting to another page of your own application!



    I have to disagree with this. Posting between pages in your application is very useful if you want to transfer state from page to page without relying on server-side session state (or resorting to the awful Server.Transfer, which completely destroys the browser navigation model).



    On the other hand, I agree that cross-site posting can be useful, and I'm not sure why they disabled.

  • I agree its useful in the same app, just not that big of a need in comparison since there are plenty of alternatives in the same app, unlike the cases outside of your own app.

  • Thanks Paul -- we'll definitely take a look at this.



  • Posting to other pages will eliminate some need of Response.Redirect,Server.Transfer that causes ThreadAbortException Exception boosting performance

  • Ouch - this is a problem in my case:



    I have a server control that used the render method exclusively to output the html. The control simply gathers user input but, since it can be used in any application, needs the ability to post the input to a "results" page in a particular application.



    I found the only way to get this to work was to send down javascript with the control that sets the form's action attribute when the submit button on the control is clicked.



    I also found that I had to explicitly set "enableViewStateMac" to false in the page directive on the receiving page - setting in the property dialog for the page seemed to have no effect.



    So seems like a problem case is anytime a server control is created using the render method (i.e. no events associated with the rendered controls), and the page hosting the control has to post the inputs to another page in another site...



  • I still think posting to other pages is not needed, even if it involves pages on different websites. It was probably disabled because of the better alternative, i.e. posting the data using XML Dom from one website to a webservice on the other website.

  • Cross server posting is an absolute essential for us to be able to fully take ASP.Net on board.



    Lack of the facility severely limits the amount of inter-application integration that we can do. Going into a .asp file to cross the border is rather ugly.



Comments have been disabled for this content.