I'm looking at a major change in coding strategy and am hoping for some opinions. Partly I'm writing this to force myself to think it through. But input would be appreciated.
The central question is whether to continue with my home grow AJAX or convert (at least in part) to UpdatePanels.
The app in question has its primary functionality on single "Main Page" where people stay and do collaboration using different panels (review, discuss, control, help, etc). Right now all these panels rely on full postback. For context, this app
is intended to be prototype that hopefully I could stretch to light SAS service with a limited audience (and maybe further, who knows) until I can attract a development partner. I've already run it in that limited audience scenario on an ISP for a brief
time, but it's never been really pounded on.
Re the homegrown AJAX: for certain control function the app uses a set of callback utilities I built using native javascript in 2006 using VS2005; basically a main callback send and receive script and then a callback sender and receive router in js, and
a callback receive router and replier in codebehind. There are over a dozen miscellaneous functions that send and receive between client and server through these utilities. In some cases I build whole popup menus in codebehind, convert them to raw html
and send them the client as callback replies where the html is reinstantiated as a div. All works fine, which is to say, I'm reasonably comfortable with this technology.
Now I'm thinking about converting the panels to use ajax/callbacks. If I did it using my home grown utilities, I would use the existing panel build functions in codebehind and then treat them like the callback popup menu described above.
Re the UpdatePanel alternative: one of the panels on my main application page is a dynamic, drag-and-drop diagram that can contain scores of elements. The codebehind for this dynamically adds a bunch of controls (div, images, labels) to a
div and then reposts. I've validated (with help from CruzerB @ http://forums.asp.net/t/1878128.aspx and some prototyping) that I can likely convert this functionality to use an UpdatePanel and related technology. All the content on the diagram is saved
to a DB and refreshes with each postback so there's not an issue with losing dynamically added controls.
I would similarly use UpdatePanels for six other such panels, which contain gridviews and/or miscellaneous sets of controls.
In terms of UpdatePanel performance, there's not a huge amount of volume in any of these panels. A gridview with 100 items, and a diagram with 100 elements would be about normal, 500 each would be rare, at least for the majority of early adopter users.
After that it's a different problem in terms of business and technology architecture.
Maybe the UpdatePanel approach is much more robust and maintainable, adding to the lifetime of the prototype.
Maybe there's better security and error handing available with the UpdatePanel.
Comparing the two approaches, I'm not sure how much conversion would be required.
1) I would have to build a control function in Javascript to decide which panel reloads to trigger in any case, based on user actions, instead just using postbacks in every case.
2) Right now the panels are built in codebehind during PageLoad. There might be certain conditions under which not ALL the panels would be updated on each PageLoad, so I might have to change the main page load logic to account for that. That might be needed
with both the homegrown ajax approach or the update panels.
3) In the homegrown I would definitely have to build routines to convert the panels to and reconstitute the panels from strings, but I can copy techniques I've already written for that.
4) ?
Given all that, again, I was hoping for some feedback, advice, opinions, on what other factors should I be considering in terms of whether to use my homegrown AJAX versus update panels, and which approach might be better for different reasons.
Actually Update Panel is a spoon feed feature from ASP.NET to let programmer implement AJAX features easily. But as what you can read from Why ASP.NET AJAX UpdatePanels
are dangerous, it still kind of Postback request, not
Callback. You can test this by using Page.IsPostBack property. There are list of well known issues when you using Update Panel in your page. One of them are you cann't use it together with File Upload control directly.
I had also use Developer Express ASP.NET controls. I found they are using Callback features and that why all the controls come with rich Client API.
Actually, I'm a custom Callback fan and I even have a blog, ASP.NET Callback – and WHY? to talk about this. So, if you want a truely resposive
web page, then you should use the Callback features.
No matter how much time you spend on coding. Wish you happy coding.
My Technical Blog
Thanks to both for input. Good thought provoking stuff. I would actually prefer to use the callback utilities I've already built, so these are good nudges in that direction. If I don't use JSON specifically, it has already given me some good ideas. And
re "spoon feed", I had the thought last night that update panels might be like FrontPage. Lots of powerful "easy to use" features; just don't ever look under the hood.
codequest
Contributor
2130 Points
484 Posts
Why User Update Panel instead of Home Grown Callbacks?
Jan 27, 2013 08:59 PM|LINK
I'm looking at a major change in coding strategy and am hoping for some opinions. Partly I'm writing this to force myself to think it through. But input would be appreciated.
The central question is whether to continue with my home grow AJAX or convert (at least in part) to UpdatePanels.
The app in question has its primary functionality on single "Main Page" where people stay and do collaboration using different panels (review, discuss, control, help, etc). Right now all these panels rely on full postback. For context, this app is intended to be prototype that hopefully I could stretch to light SAS service with a limited audience (and maybe further, who knows) until I can attract a development partner. I've already run it in that limited audience scenario on an ISP for a brief time, but it's never been really pounded on.
Re the homegrown AJAX: for certain control function the app uses a set of callback utilities I built using native javascript in 2006 using VS2005; basically a main callback send and receive script and then a callback sender and receive router in js, and a callback receive router and replier in codebehind. There are over a dozen miscellaneous functions that send and receive between client and server through these utilities. In some cases I build whole popup menus in codebehind, convert them to raw html and send them the client as callback replies where the html is reinstantiated as a div. All works fine, which is to say, I'm reasonably comfortable with this technology.
Now I'm thinking about converting the panels to use ajax/callbacks. If I did it using my home grown utilities, I would use the existing panel build functions in codebehind and then treat them like the callback popup menu described above.
Re the UpdatePanel alternative: one of the panels on my main application page is a dynamic, drag-and-drop diagram that can contain scores of elements. The codebehind for this dynamically adds a bunch of controls (div, images, labels) to a div and then reposts. I've validated (with help from CruzerB @ http://forums.asp.net/t/1878128.aspx and some prototyping) that I can likely convert this functionality to use an UpdatePanel and related technology. All the content on the diagram is saved to a DB and refreshes with each postback so there's not an issue with losing dynamically added controls.
I would similarly use UpdatePanels for six other such panels, which contain gridviews and/or miscellaneous sets of controls.
In terms of UpdatePanel performance, there's not a huge amount of volume in any of these panels. A gridview with 100 items, and a diagram with 100 elements would be about normal, 500 each would be rare, at least for the majority of early adopter users. After that it's a different problem in terms of business and technology architecture.
Maybe the UpdatePanel approach is much more robust and maintainable, adding to the lifetime of the prototype.
Maybe there's better security and error handing available with the UpdatePanel.
Comparing the two approaches, I'm not sure how much conversion would be required.
1) I would have to build a control function in Javascript to decide which panel reloads to trigger in any case, based on user actions, instead just using postbacks in every case.
2) Right now the panels are built in codebehind during PageLoad. There might be certain conditions under which not ALL the panels would be updated on each PageLoad, so I might have to change the main page load logic to account for that. That might be needed with both the homegrown ajax approach or the update panels.
3) In the homegrown I would definitely have to build routines to convert the panels to and reconstitute the panels from strings, but I can copy techniques I've already written for that.
4) ?
Given all that, again, I was hoping for some feedback, advice, opinions, on what other factors should I be considering in terms of whether to use my homegrown AJAX versus update panels, and which approach might be better for different reasons.
Any help with this would be appreciated.
Thanks!
chetan.sarod...
All-Star
65739 Points
11138 Posts
Re: Why User Update Panel instead of Home Grown Callbacks?
Jan 28, 2013 02:52 AM|LINK
Refer this
http://encosia.com/why-aspnet-ajax-updatepanels-are-dangerous/
Senior Software Engineer,
Approva Systems Pvt Ltd, Pune, India.
CruzerB
Contributor
5399 Points
1098 Posts
Re: Why User Update Panel instead of Home Grown Callbacks?
Jan 28, 2013 06:11 AM|LINK
Hi,
Actually Update Panel is a spoon feed feature from ASP.NET to let programmer implement AJAX features easily. But as what you can read from Why ASP.NET AJAX UpdatePanels are dangerous, it still kind of Postback request, not Callback. You can test this by using Page.IsPostBack property. There are list of well known issues when you using Update Panel in your page. One of them are you cann't use it together with File Upload control directly.
I had also use Developer Express ASP.NET controls. I found they are using Callback features and that why all the controls come with rich Client API.
Actually, I'm a custom Callback fan and I even have a blog, ASP.NET Callback – and WHY? to talk about this. So, if you want a truely resposive web page, then you should use the Callback features.
My Technical Blog
codequest
Contributor
2130 Points
484 Posts
Re: Why User Update Panel instead of Home Grown Callbacks?
Jan 29, 2013 03:14 AM|LINK
Thanks to both for input. Good thought provoking stuff. I would actually prefer to use the callback utilities I've already built, so these are good nudges in that direction. If I don't use JSON specifically, it has already given me some good ideas. And re "spoon feed", I had the thought last night that update panels might be like FrontPage. Lots of powerful "easy to use" features; just don't ever look under the hood.
Grazie!