Use PostBackUrl to submit specific part of form - asp.net

I have an ASP.NET webforms application and a requirement to add a form to a page which will be posted to an external URL, a payment processing provider. The form needs to include specific hidden inputs, one of which is a hashed string representation of the form data.
I understand given limitations of webforms I can't nest a second form within the main <form runat="server" />. However, I don't have the option to locate my form outside of that main form (due to the CMS this site is built into).
I know I can use an ASP.NET Button control with a PostBackUrl attribute which allows the form to post to a specific URL. However, this posts every form element on the page, including __VIEWSTATE, __EVENTTARGET etc.
This is not desired behaviour. I only want to submit specific data. Also, this makes it difficult (impossible?) to generate the hash representation of the form because this would have to include viewstate etc.
I also don't have the option to post the data from the code behind because the client is expected to continue their interaction at the target URL.
Do I have any options here? This must be possible, but an internet search has returned very little.
UPDATE: I'm looking for a solution that doesn't rely on Javascript.

One option would be to utilize ajax. Simply use it to post data you need and you don't even have to redirect or anything. You'd be in control of literally everything (well as long as the user has javascript turned on, of course).

You can use ajax update panel for this .
put asp:scriptManager on page
<asp:scriptManager></asp:scriptManager>
<asp:updatePanel runat="server">
<contentTemplate>
your controls to be submitted to next page
<asp:button><asp:button>
</contentTemplate>
</asp:updatePanel>
and put other controls outside updatePanel.

Related

Can we use multiple forms in a web page?

So far, all the web pages I met contain at most one <form> tag. Why not multiple ones? I can not think of reasons why multiple forms can't coexist within the same web page.
Also, to be specific to ASP.NET - why are all the server controls are placed within the <form> tag? Why not place them somewhere else?
Plus,
I noticed that in an .aspx file, the <form> tag has the runat=server attribute, while a normal server control such as Button also has one. So it seems the <form> is also a server control. But strangely enough, I cannot find it in the Visual Studio Toolbox.
There can be multiple forms, with hacks.
It is indeed a shortcoming of WebForms. In ASP.NET MVC you can implement as many forms as you want (and it is valid & correct behavior of web pages).
The reason all server controls are placed inside <form> tag is to allow the WebForms engine to recognize them, load their values & save their values from/to the ViewState. Almost all infrastructure of control management in WebForms is based on the idea that a tag contains everything you access from the code-behind.
As pointed out, this is one of the shortcomings of WebForms. I do want to point out, additionally, that with cross-page posting and validation groups, you can typically reach your desired behavior (for most "multi-form" solutions).
Regarding the additional question: the <form runat="server"> is parsed as HtmlForm class behind the scenes, which inherits from HtmlControl like any other HTML element with runat="server".
Unlike any other HtmlControl though, there can exist only one instance per page and it does not appear in the toolbox as it's added automatically to every new Form you create, so it's quite pointless.
Yes, it can be done - by creating a custom HtmlForm object and toggling the forms as needed. I've just answered a similar question here (with code):
Paypal Form Ruins My ASP.NET webforms layout -> How to Solve?
many non server forms - you can , but only one runAt Server form
i also found this :
A server-side form tag is the tag which has a runat="server" attribute. If this attribute
is missing, then it's a typical HTML form tag. The conclusion is that you are allowed to use
multiple form tags on a page, as long as only one has the runat="server" attribute. The
disadvantage of the form that doesn't have this attribute, is that view state won't work
(meaning form values will disappear when using the back/forward browser buttons). It's a
small price to pay if you really need multiple forms on a page.
Take master page & set design.
Take one form in master page.
Second form take in contain place holder.
In contain place holder in only for write form tag (not use)
Add aspx page & design second form but not write form tag only for control put
Take button click event fire code write
This is proper way of two form

Cross-Page Posting with a Master Page

I found a workaround for my specific need, but I thought I'd ask this question anyway.
Say I have a typical data entry web project with a master page -- instead of using the Session variable and using Response.Redirect or Server.Transfer to redirect users who are part of the way through data entry to the next step, I'd rather use cross-page posting.
I tried setting up one of my websites in this manner, with a button like:
<asp:Button ID="next" text="next" runat="server" PostBackUrl="EnterInfo.aspx" />
When I went to test the changes, my <form> tag hadn't changed at all:
<form id="aspnetForm" action="SelectUser.aspx" method="post" name="aspnetForm">
Did I miss any details here, or is cross-page posting simply not intended for use with a master page?
Edit:
The form tag above is the tag as rendered on the client -- not the server-side tag. I've read MSDN articles (like this one) that seem to me to explicitly state that cross page posting actually posts the form to another page.
Perhaps I've misinterpreted this as changing the form's action, but regardless my source form does not post invoke anything anywhere on my target when I click the button I altered -- it merely posts back to the current page.
I don't think using the PostBackUrl attribute will change the action of the form in the markup, as there could be many other controls just doing a normal postback. I imagine that some javascript is used to change the action of the form when this particular button is pressed.
You need to place a declaration on the second page where data come from.
So you have:
PostBackUrl="EnterInfo.aspx"
On EnterInfo.aspx you declare where you can get informations
<%# PreviousPageType VirtualPath="~/SelectedUser.aspx" %>
and you get them by...
if (Page.PreviousPage != null)
{
if(Page.PreviousPage.IsCrossPagePostBack == true)
{
GetTheClass = PreviousPage.MyDataClass;
}
}
The PostBackUrl not change the form url.
Some reference.
ASP.NET how to access public properties?
Cross-page postbacks and back again retaining data from source page
Ps
At first I was thinking that you have just type what you see at render, but if not the case As #Mystere point out you need to run this inside an asp.net form.
First, as Graham says.. PostBackUrl does not change the postback action. Second, you can only use PostBackUrl on an asp.net enabled form, which means the form must have runat="server"

validating form in sharepoint

I developed a screen in which there are fields like first name,username,password and email. I validated these fields using javascript and came to know that javascript is not that safe. So i decided to validate on server side also. My question is whether i can use asp controls like requiredfieldvalidator, regularexpression validator to validate the form or i have to validate through server side coding??
Usually you can, it depends on how you implement the form, whether you use ASP.NET/SharePoint controls on it
You can definitely use asp controls like requiredfieldvalidator and regularexpression to validate your form. I've done this before.
Extra information
Thing to watch out for: If the page that you put these controls on is a publishing page, e.g. based on a custom layout page where editors can go in change content, the asp validator controls will still try to validate in 'Edit' mode. Therefore any SharePoint out of the box form submissions that added to the form will also trigger that the validation on your custom fields. In my case, I had a form on the page layout and some content fields, every time I edited the page, I couldn't save changes or publish until I filled out my form.
The way around it is either, stick your validator controls in EditModePanels with the PageDisplayMode set to "Display":
<PublishingWebControls:EditModePanel ID="EditModePanel1" SuppressTag="true" runat="server" PageDisplayMode="Display">
Your validator control here
</PublishingWebControls:EditModePanel>
or check for edit mode in the code behind on page load and turn the validators off from there.

asp.net multiple server side forms on a page

I have the need to have 2 html forms on one page. One for login details, and one for feedback. Both forms cannot have runat="server" attrib.
Any suggestions?
Handle one of the forms as a regular HTML form -- don't use runat="server". Extract the values from any post from the Request.Form collection manually (since there won't be any server-side variables corresponding to the form).
Alternatively, put all the elements in the same form, but use different controls to submit. Each set of controls (and their submit button) should be in a different validation group to avoid having validation errors due to elements you don't care about. Handle the form processing in the callback for the submit button.
Also, I would recommend an eventual move to ASP.NET MVC. MVC is a much better architecture from the perspective of the web. It more closely aligns with the stateless web model and does not have the limitations imposed in ASP.NET to help it mimic WinForms development.
When using web forms, you should only ever have one form on the page. Probably crap, but such is a web forms world...
wrap one form around the whole page. Then when a button is clicked (or whatever event you are using) you should be able access the values of all the controls on the page.
Yes as you said, in ASP.NET you can't have more then one form element. but, you can handle more then one action in the same form. Do not use form's action attribute, use asp.net server controls like <asp:Button>, and write your logic into the event of the controls that post back.
ASP.NET page framework architecture allows single form with runat="server" attribute. You need not to worry about this thing. Place the controls on to the webform for two different purposes and handle the click events of two asp.net server control <asp:Button> separately.
You just have to split them up logically inside the one form. If you use validator and don't want the two "forms" to require the other values filled in, you have a property on the .NET controls called ValidationGroup, that just needs to be the same for all in one "form".
You won't be able to make two forms with runat="server" in one page.
Here is a nice solution
Can I have two separate forms runat="Server" in one page
though not a straight forward approach, you CAN have multiple server side forms on the same page , but it has its own limitations. Cost $50

asp.net 2.0: update formview with jquery

I'm struggling with an issue I just can find a solution for.
First of all, I can't use asp.net AJAX or anything else thant standard asp.net 2.0 as the server admin won't install anything else.
So here is, what I try to do. (For the curious, skip to the bold question below)
My page consists of several parts, each of which gets loaded by jquery.load(url). One of these page parts gets filled with an aspx that contains a form view. As I don't want to have postbacks, I switch to the EditTemplate of the form view by a simple click on a regular html button that submits a parameter indicating the aspx page to switch to edit mode, e.g.
Page_Load(...)
{
if(Request.Params["SwitchEditMode"]) SwitchEditMode();
}
This works perfectly! Now here the part where I'm stuck. The elements in the EditTemplate are based on a select from a database view and bound to the fields by <%# Bind("xx"). Then I have a html button (no asp control) that submits a parameter to the aspx page that tells it to invoke the DataSource update method. In the dataSource_updating method I look for the controls that contain the values I want to save. But these values are always the same, as when I switch to the edit view. No changes I make in the textboxes or dropdowns are preserved.
A long story short, the question how to save the values from EditTemplate back to the database with jquery?
Up to now I tried several approches, that didn't work out.
In the updating() method look for the controls by FindControl and set e.Command.Parameter["xyz"] = foundcontrol.SelectedValue;. The values are always the same as in the beginning.
Set <asp:parameter name="SampleValue" /> and in the EditTemplate <asp:TextBox Value='<%# Bind("SampleValue")#> The values are always null.
Set a hidden input field with the selected value via javascript. This doesn't work as the control within EditTemplate are only visible after the switch into edit mode
So maybe I'm totally wrong with my ideas, heading into a totally wrong direction and this can be accomplished much easier, but up to now I don't know how to achieve this. I could do it without ajax, but for the user experience I'd prefer the version with jquery.
For all that have read this far and not got confused :-), thanks for your effort!
Best regards,
Andreas
I would forget using a form view and just use a regular html form with regular input controls. Return an object from your web service that has all of your values and populate the controls with ajax and then subjmit with ajax. Either do fully asp.net or fully html/jquery with asmx back end. Otherwise it's just too confusing.
If you load both "modes" of the FormView into the same page using AJAX, you're probably getting duplicate field names. One of them contains the unchanged values which are being saved. How will ASP.NET know the difference? You only want to submit the ones from the EditTemplate, which will require a separate form (or some other hack).
Or perhaps your HTML submit button isn't giving ASP.NET what it needs to repopulate the controls. Are you using ViewState in the page with the FormView?
All in all, this sounds like a hairy combination of technologies... as you well know.

Resources