OK, I am not sure if the title it completely accurate, open to suggestions!
I am in the process of creating an ASP.NET custom control, this is something that is still relatively new to me, so please bear with me.
I am thinking about the event model. Since we are not using Web Controls there are no events being fired from buttons, rather I am manually calling __doPostBack with the appropriate arguments. However this can obviously mean that there are a lot of postbacks occuring when say, selecting options (which render differently when selected).
In time, I will need to make this more Ajax-y and responsive, so I will need to change the event binding to call local Javascript.
So, I was thinking I should be able to toggle the "mode" of the control, it can either use postback and handlle itself, or you can specify the Javascript function names to call instead of the doPostBack.
What are your thoughts on this?
Am I approaching the raising of the events from the control in the wrong way? (totally open to suggestions here!)
How would you approach a similar problem?
Edit - To Clarify
I am creating a custom rendered control (i.e. inherits from WebControl).
We are not using existnig Web Controls since we want complete control over the rendered output.
AFAIK the only way to get a server side event to occur from a custom rendered control is to call doPostBack from the rendered elements (please correct if wrong!).
ASP.NET MVC is not an option.
Very odd. You're using ASP.NET server controls and custom controls, but you're not using web controls? And you're calling __doPostBack manually?
Do you like to do things the hard way?
If I was still using the server control model rather than MVC, I would slap ASP.NET Ajax controls on that sucker and call it a day. What you're doing is like putting a blower on a model T. It may be fun and interesting, but after you're done with all the hard work, what do you really have?
I have been doing some more digging on this, and came across how to inject Javascript in to the client when required. This will obviously play a huge part in making the controls more responsive and less round-trips to the server.
For example: RegisterClientScriptBlock.
Look forward to playing with this more, feel free to get invovled people!
Related
I'm newbie in ASP.NET and i think that my question is quite simple, but I'm not getting success in my searches through google or even stackoverflow.
I have a asp.net method (vb.net) that loads a entire html page inside a div.
Doing searches, i discovered that it can be like this:
On .aspx page:
<div id="content"></div>
On .vb codebehind:
Private sub LoadContent()
content.InnerHtml = MyDLL.LoadFromDatabase.Value.ToString()
End Sub
So, nothing special until here.
But, if consider that the html code loaded from database has form elements like <input id="name" type="text">, my problem starts...
On page postback these don't keep the values as <asp:TextBox> created natively on code, does.
And the other thing that I want is a way to retrieve the value from them to work on codebehind, like: myvar = content.Controls("name").Value
At least, is there a way to solve my problem?
Sorry for my bad english, and thanks so much.
CRice is right. If you want the viewstate to persist through postback you need to create the controls server-side.
Careful though: I've had bad experience with dynamically created controls on Asp.Net, specifically when trying to bind events to them. Not only would you have to use delegates and events (a hard topic for a newbie), also when I tried it a few years ago I just couldn't get it to work, no matter what.
If you're going for dynamic created controls, make sure it's worth the effort, because it WILL be an effort, now and in the future when you would like to maintain and add expand. A rule of thumb is that dynamic mechanisms are always harder to maintain than static ones, but they provide more flexibility.
Having that said, if you're still going for dynamic html loading, be aware that better solutions exist, though they require different architectures: client side frameworks (best is angluar.js) provide dynamic loading of "modules" (and much more), which is what you want. On the server side, asp.net MVC with its Razor view engine, partial views etc., is better suited for dynamic html generation.
Back to your original question,are you sure you need a full postback? What about a nice neat Ajax call to a web service? Can get the job done in many cases without reloading the whole page. I guess using jquery's $.ajax syntax and creating a simple .asmx web service will be easiest for you.
Last but not least, why use vb.net instead of c#? It sucks man. Give it up while you still can.
Folks,
I have some personalized properties on an ASP.Net Web Part that I would like to set via Ajax (for example, the size to which the user has expanded the WebPart using the jQuery Resizable plugin.)
I've read this question and answer, but I don't think it will work. Personalized properties are instance properties. (If they were static, they couldn't be user-scoped, could they?) A WebMethod, which must be static, can't access them.
You might be thinking that I could just use a hidden field and send my values back that way, but that assumes that a postback is done at least once after the values are set. In this case I can't guarantee that: the page in question displays a lot of data but doesn't take any user input other than for configuration.
I seem to recall that some Ajax techniques involve remotely instantiating a page on the server and going through at least part of the page life cycle, but the last time I messed with that was 2006 and I never could get it to work very well. I have the impression that modern Ajax techniques, even for ASP.Net, work in other ways.
So, does anybody have an idea of how this could be managed?
Thanks very much,
Ann L.
Webmethods only have to be static when they are page-based. Create a webservice in your project and stick non-static webmethods in there. You can even enable session state.
I recently discovered the client-side methods of some of the controls in the Microsoft ajax control toolkit. For instance, with the TabContainer, I can do something like this:
$find('tabsEditJob').get_tabs()[1].set_enabled(true);
without having to resort to server side code. Is there a way to do this in your own custom user controls without too much work?
UPDATE: I was going to implement show and hide methods: although setting display to none would probably work just fine, they would prefer an explicit method. I know that the ajax control toolkit controls have a set_visible method. Do user controls get this too?
The approach the ajax control toolkit is a managed approach, so you should check out this walkthrough as a good overview of what it is and how you create it: http://www.asp.net/learn/Ajax-Control-Toolkit/tutorial-49-cs.aspx
There is both a server-side and client-side piece; it can be confusing at first, but it isn't that difficult to setup once you are used to it. But it does require some reading up on it first and a some considerable planning.
I've built a few of my own, and you have to think about all the interations you want to include and at what point certain pieces of code should run, all of the events, etc.
HTH.
What are the advantages and disadvantages of using Ajax update panels in ASP.NET application. Is there any alternatives available to avoid the use of Ajax update panel?
Advantages:
Easy to use and configure (Well, I don't know of any other advantages!)
Disadvantages:
See here and here
Now for the best part, the alternatives:
Use jQuery's built in support for Ajax to make GET/POST Ajax calls, it's very simple (simpler than the update panel I would say), and absolutely compatible with most browsers!
An example of using one of the many easy ways jQuery provides for doing Ajax calls:
$('#anotherContainer').load('/Home/RegularAjaxResource');
This would simply call a server resource (RegularAjaxResource in this case) and display it's returned data on an UI element with id anotherContainer
I agree with 7alwagy, except just want to add an important point.
You have to use the UpdatePanel if you want to update/change controls AND still work within the Webforms Postback model of state control, in particular, Viewstate.
For example:
if you explicitly use JS to update the values of a DropDownList control on the client, and you're using the built in Webforms Postback model, the changes you've made won't be picked up.
Essentially, if you're relying on the built in Viewstates, then you have to use the UpdatePanel. You can technically not use it, but you'll really have to fight agaisnt the framework to get things done.
If you're not relying on Postbacks or Viewstates, then you totally don't need the UpdatePanel.
I seriously cannot think of 1 advantage of using updatepanels. They are grief and i found that out the hard way.
They're usable only for the most trivial ajax effects and if you're going to do any data retrieval or database lookups they have a huge problem in scaling up. UpdatePanels are frustrating and not a long time I have shared the updatepanel grief here, here, here and here.
If that's not enough to convince you not to use updatepanel then nothing will.
I agree that update panel is evil and dangerous but in some cases you may want to use it, instead of other options.
The page has few asp.net controls, and less viewstate.
The page html is not too big.
The time is limited to finish the task.
The performance is not the first concern.
Want to keep the sate of controls with postbacks.
Have a lot of server side events you want to fire.
Advantages:
Easy to implement
No need to write javascript in the client
Disadvantages
Uses more bandwidth since all view states are transferred
Element which is supposed to fire the ajax call should be inside the update panel. It is not practically possible all the time
Data outside the update panel is not sent to the server which may be needed for further processing.
In practice developer cannot pre-determine what all data is needed to include in the update panel
On my journey into the depths of custom ASP.NET control development I am obviously getting my head around the ASP.NET PostBack model and how it affects control development.
I understand that controls have no "lifetime" in ASP.NET, and therefore must be re-initialized on each and every page load. We overcome this by persisting the objects values/parameters to the ViewState.
Many articles I read therefore suggest not using PostBack since this can add considerable overhead to the Page. I am not looking for how to disable it, I know that.
What I am looking for is:
What alternatives to we have to using the PostBack model to initialize controls?
I know we could use the QueryString, but that seems awfully messy, and obviously unreliable.
Ideally you could give me an overview of the architecture/design of a different approach and the pro's/con's of it..
Many thanks ^_^
Well, Session State is a server-side solution, with its own pile of cruft to deal with if you want to avoid ViewState altogether. Really though, using ViewState in a custom control is all fine and good - just be picky about what you store - only store deltas from the declared control state, don't store anything you're going to get on postback anyway (e.g. from a DB call), etc.
You have to store the values somewhere, so you are limited to the query string and hidden form fields. If you relate that to HTTP, basically it's either GET or POST parameters.
I suppose you could use cookies, but that would be really messy.
Store your object state in the session context: this will shift the burden of keeping state from the client to the server, which may be acceptable for small-scale intranet apps. For sites on the capital-I Internet, this won't work;
AJAX-enable your control: in this case, only state changes need to be posted back. Picking the right framework is key here; see http://www.asp.net/ajax/ajaxcontroltoolkit/samples/ for the official MS approach; many others are possible.
If you're truly looking for alternatives to the PostBack model altogether, then I would suggest researching the ASP.NET MVC Framework. I would love to kick WebForms to the curb and do all my stuff in MVC, but alas, legacy code is a tarbaby and rewriting is almost never the answer, so I plug onwards...
I think you still mis-understand controls somewhat. Controls only have the problem you describe when you add them to the page dynamically. If you declare your controls upfront in the aspx code then they build along with the page.