I'm trying to convert a classic ASP page to ASP.NET 3.5. The page has several forms on it for several different things.
In ASP.NET, there's a server form control wrapping the entire page, and form controls don't work within a server form control, and you can't have more than one server form control on a page.
So in order to keep this functionality, I can either:
Remove the server form control that's wrapping the page, and leaving the html forms on the page.
Create button click events for every form and perform the POST in the code-behind.
What's the preferred method here?
I wonder if converting to vanilla asp.net (aka webforms) is a bad idea here. Personally I'd go to MVC instead - allows multiple forms etc, and the views are much closer to he HTML, a lot like ASP.
I guess I'm saying there are some glitches vanilla asp.net introduces that you don't have to suffer.
I would go with the second option, any button click is going to post the whole page back anyway so you're not saving any bandwidth. Simply handle each button appropriately.
Check the answer I provided to a similar question here :-)
How to get past embedding a html form for paypal buttons asp.net
If you're going to use different button clicks, you still need to use this override to disable the non-related buttons in each handler, otherwise it won't work. You can only have one form tag at a time - this way you can toggle/disable the ones you're not using as appropriate.
Better still, refactor your application to use a single form. While MVC would be a closer match to the model you're using right now, it wouldn't make sense to go that route unless you were experienced enough with it; Web Forms is an easier jump.
Related
I am forced to use Web Forms in my project, and sadly, Web Forms only allow - If I may - "Strict" Websites to be created.
Whenever you need a Button you need to put it in a form, and then you need another button which has nothing to do with the previous button, and you can't have 2 forms,
And the idea of putting a DIV that fires a server side (C#) method is kind of difficult, okay it may be easy but all I have found are "tricks", not an "official" clean way.
So I have this idea of making a webpage for each action in my websites.
For Example:
Let's say I wanna click on the ARROW that raises the rating of this question, I would put something like this.
HTML
Rate Up
And Some CSS Codes to make it look like a beautiful button...
Okay now this will take me to a page called Rating.aspx with 2 parameters, the first parameter is the ID of the question that I would like to raise its rating, and the second parameter is either UP (+rating) or DOWN(-rating).
On the Page Load method of Rating.aspx, I would update the database, then redirect to the question page.
This will work perfectly, BUT, is it a good approach? is it professional? (put in mind that there will be many actions to preform like that...)
With ASP.NET you better use server controls. Better way of implementing that is using or , that actually renders your anchor tag. But you can attach OnClick event handler to this control (link button) so after clicking there would be automatic POST to server. The same page cycle for the current page will take place (this is called PostBack) and your attached event handler will fire, where you can actually make changes to the database. So you don't even need to create any other pages for tasks like this. Every server control has specific set of events like OnClick for buttons or OnSelectedIndexChanged for dropdown lists. You can even create your own controls or derive from existing ones and create your own events.
Take a look on following links for more information:
Button Click
Event Handling in ASP.NET
ASP.NET Page Life Cycle
I'm in a huge bind.
Long story short, I am working on a big project and am learning ASP.NET, C#, everything as I go.
The elementals of my project are comprised of user controls. My line of thinking was that I could create many user controls, each performing a function for a "component" of the project I'm building. Up until now I have been using clientside scripting to postback ajax calls to the code-behind on each of my user controls. AJAX worked well because it allowed to me pass data(that I need from the client) to my user controls and then I could return something in order to do an action.
I have been using a method for generating querystrings to create a callback "action" in order to determine what method needs to handle what data when the postback is sent to the code-behind side.
My problem now is that I need to start using many user controls one page -- and so now whenever ANY control does a postback ALL of the controls go through a page load. I thought my callback solution would take of this, but it isn't. Particularly when I drop a custom registered control into another user control.
I have done multitudes of research and having seen various ways to get around this, the best of them being [WebMethod] and controllers. However the project I am working on is NON-MVC.
I am also attempting to use UpdatePanel controls to minimize postback to the entire page but have had little success.
What can I use as alternatives? I feel like I'm running out of options or am missing something very basic here.
TL;DR -- I need a non-MVC method to pass data to user controls that can distinguish between multiple controls. Cannot use pagemethods(or page). Manual ajax calls are not working out. Cannot afford to do a full postback
Take a look at:
updatepanel vs page methods
Based on this:
My problem now is that I need to start using many user controls one page -- and so now whenever ANY control does a postback ALL of the controls go through a page load.
This might sound simple but have you tried to use if(!this.IsPostBack) in your load events?
Well not, the only way to avoid this situation, is using PageMethods or create a Script Service to handle AJAX requests (Web services with the ScriptService attribute or WCF REST services)
Note that even if you use the evil UpdatePanel, absolutely all the page life cycle will execute, which means that the whole page viewstate has to be sent in each post, the only advantage of using UpdatePanel controls is that you gain partial rendering, that's it, the performance on the server side doesn't change at all.
So you could use PageMethods or Script Services. But there's a catch, if you start using them you will notice an incredible performance change, your application will be more responsive (RIA applications), but the catch is that you won't be able to use the benefits of the ASP.Net server controls such as GridView, Repeater, etc. In other words you would need to change most of your view controls (this is the approach followed when working with MVC applications)
You can create static methods on your aspx page and mark it with [WebMethod]. Then you can call the method using jQuery ajax from the user user control markup. Take a look at this blog
I am struggling with finding clear answers to dynamically creating the same page over and over. The questions and samples I have found seem to be all over the board on this topic. I have studied the life cycle and still seem to not have a clear answer as to where code should go.
I have a master page and a content page. All the content in the content area needs to be dynamically created (text boxes, ddl's, page tabs, buttons/onclick etc.).
After a user fills in data and clicks a submit button, I need to read the values off the form and rebuild the page completely again (not add/remove controls to current content).
My question is then.
Where do I put my code to build the page?
Will this area allow me to use IsPostBack so I can rebuild content with Request.Form values?
Will my buttons _Click events work?
Are there any working samples out there you could direct me to?
Thank you very much for the feedback...
I don't know all the answers to your questions, but I hope this may get you started. When dynamically generating the UI through code, this happens in Init. Controls dynamically loaded on Init is key because between init and load, on postback, viewstate is loaded for these controls.
This means you need, on every postback, recreate the page as is to match the previous control tree, then deconstruct it after init and recreate the new UI, if something is supposed to change UI wise. This is because it validates the tree structure to determine its the same UI. Now, if you don't need viewstate, this may not be as much of an issue. I haven't verified this without viewstate to see if it behaves different.
It depends how dynamic you need it, whether you need viewstate (is a big factor).
HTH.
Try creating the controls in the page's PreInit method. "IsPostBack" should work and the click event handlers should work as well.
What you need is a web user control, see ASP.NET User Controls
Brian's advices are good and you should follow them.
This might not really answer your question but still I add it as an advice. I'm professionally creating ASP.net web applications at quite a large scale and from my experience I can say that too much "dynamics" is usually bad and should be avoided because it just introduces complexity. Normally you might want to expose UI parts into ASP.net UserControls or if you want to make them even more reusable (if that's a factor) then into ASP.net Server controls. Then you replace different of them dynamically rather than creating everything from scratch.
Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks
In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.
Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.
How can I create a <form runat="server" /> with code (c#)? My problem is that I want to have multiple forms on my page (and none initially). I'm loading all components from db.
I've looked everywhere and can't find anything about it.
From painful memory, working with multiple forms in ASP.NET-webforms is a real pain. Maybe consider looking at ASP.NET-MVC which is much closer to the HTML; consequetly you can do anything you like re forms; just use a foreach in the view, writing a form for each item.
ASP.NET page can have only one "server side" form.. that's one of the "core" rules.
So you'll have to find other way to achieve what you need.
You can work with UpdatePanels and "submitting" specific panel should send only its contents, ignoring the other data in the form.
ASP.NET only allows for one serverside form but allows multiple regular forms in one page. I suggest you read this article: ASP.NET Forms.
Thanks for the replies. I solved it using this inside my Page:
public override void VerifyRenderingInServerForm(System.Web.UI.Control control)
{
}
And then render my form with plain text.. Can't see any errors yet, but will update if any turns up.
Also, as I said in my question, I'm loading all control dynamically and I don't use any code behind with the controls (if I did, I guess some errors would turn up). All my post are handled by checking against HttpContext.Current.Request.Form.