Anything?...anyone?...

Coordinator
Apr 12, 2010 at 2:05 PM

Are people finding their way with the limited documentation and the source code? Anyone have any problems or get any errors? I want for everyone to love this framework as much as I do. Hit me up with anything I'm eager to help. 

Jul 21, 2010 at 9:51 AM

Hello

Hope you are fine.
I readed your docs and downloaded .net 4 source, and i think i will use it in my project (a kind of a admin CMS, which is highly  customizable and works a lot with Ajax).

I started the project, using .net ajax.

The structure is more or less the following
Masterpage: with some Update Panels
Default.aspx: Main Page, where i load dynamically user controls in to the Update Panels

This works fine, Update Panels are updated via Ajax Script Manager etc...

But, when it comes to eg a Gridview based User Control, I run in problems with .NET 4 ajax. for example
user need to click 2 times on edit button in the Grid, that edit works (problem of different control IDs after first
callback) etc. I just goes through 100s of pages/blogs, no solution works.

So my big question: Using your framework, making the Update Panels to normal panels, defining it as a UpdateRegion
from your FW, will resolve that problem ? I ask before doing it (lot of changes)
And... Apart of this change, i have to do more things in user controls ?

btw. In the Bing Example i didnt found a example of a Update region.

 

Tks a lot

 

 

Coordinator
Jul 21, 2010 at 10:31 AM

Hi there. Thanks for posting your question. 

 

I can't say if your situation would be remedied by making use of the UpdateRegion in place of the UpdatePanels. We wouldn't know that until either 1) we try using the UpdateRegion or 2) we figure out what is causing the problem with the current implementation. 

From experience, when using data bound controls like GridView or DataList or ListView, most of my problems involve ViewState. My framework has a limitation in that it operates using ASP.NET Callbacks and many of the out-of-the-box ASP.NET data bound controls (GridView for example) actually has code to NOT data bind if the current request is a Callback. That's why I've included some measures to help with these situations in the latest source code of the AJAX Control Framework. I would first make sure that you are properly loading the contents of the GridView on PostBack. Note, that if you have ViewState enabled on your GridViews, you have to do your data binding during the Page_Load event (not the Page_Init). This is because ViewState is processed during the Page Event Lifecycle after Init, but before Load. After ViewState is restored, all Controls on your page will be rebuilt from the ViewState, thus restoring the state of the controls as they were before the PostBack. From there, you process changes and update the GridView accordingly within PostBack event handlers (like button clicks). Also, if you have ViewState enabled, be sure to NOT rebind all of your data on every PostBack since that is the purpose of the ViewState. If ViewState is disabled, note that you will have to rebind your GridView on every PostBack and Callback. 

Great benefit comes from using my UpdateRegion (instead of the UpdatePanel) because unlike the UpdatePanel, the UpdateRegion only reloads and re-renders the contents of the UpdateRegion. With the UpdatePanel, ASP.NET AJAX will reload and re-render the ENTIRE PAGE and return it to the browser, only then replacing the content of the UpdatePanel after scraping it from the HTML returned from the server. There is a huge performance boost with my UpdateRegion. 

 

You don't need to do everything in User Controls. You can wrap everything in UpdateRegions if you like. I favor using User Controls because its promotes development of components and building blocks. User Controls help you separate your application into logical pieces easier, and unlike WebControls (like Label or TextBox) you write your own markup to be rendered and don't have to build out the control's DOM manually using C# (or VB). 

Its usually not much effort to convert to UpdateRegions from UpdatePanels, so if you're interested in trying them, give it a shot. When you start having trouble with the data bound controls within the UpdateRegion, send me a note and I'll walk you through how to get it all to work (it's very easy with the new utility methods I've added to the framework...these utility methods aren't in the official release yet but are available starting with the version of the source code you've already downloaded). 

Here's a tip. It's better to do away with ViewState. Try developing all your components with ViewState disabled. If you do this you'll find that your application runs WAY smoother and faster. I have ALOT of experience in developing ViewState-less applications so feel free to ask for help if you need it. 

 

- "Peanutbutter" Lou

Jul 21, 2010 at 10:35 AM

wow, thats a supported project :) tks for quick and helpful answer

I will check and test and come back after

 

Tks

Stefan

Jul 21, 2010 at 11:14 AM

Hello

I subistuded the update panel the following way (in master):

<cc1:UpdateRegion ID="UpdateRegion1" runat="server">
<asp:Placeholder ID="PlaceHoldermaincontent" runat="server" >
                    </asp:Placeholder>
    </cc1:UpdateRegion>

then in the menucontrol.ascx, where the user controls are loaded into the placeholder basicly the following:

ctrl = LoadControl(ctrlitem.modul.control, parameters)

Dim modulholder As PlaceHolder = DirectCast(Me.Page.Master.FindControl("UpdateRegion1").FindControl("Placeholder" & ctrlitem.modulposition.name), PlaceHolder)
              
modulholder.Controls.Add(ctrl)

this worked with the update panel, so the updatepanel was updated and showed the loaded control.

With the updateregion nothing happens, means it doesent update the content in the region

I'm sure that i miss something ;) if you can help me ...

Cheers

Stefan

Coordinator
Jul 21, 2010 at 11:39 AM

Where are you executing this code (like what event: Load, Init, ...)?

Also, make sure that runat="server" is on the <body> element within your Master Page. This is needed for the InternalScriptManager to attach the UpdateRegion scripts to be rendered at the bottom of the <body>. Btw, this is a base and required step to get the framework working. Do I mention that you always HAVE to have the runat="server" on the body plainly in the documentation? If I don't then I need to add that ASAP. 

 

Jul 21, 2010 at 11:48 AM

I added the runat to the body, no change.

The controls are loaded from another user control (a tab control, which is used as a menu). This user control
is static in masterpage inside a Updatepanel (whould i change that to region too ?).
In the Load event of this usercontrol is where i load the controls in to the placeholder inside the updateregion
on the masterpage.

Btw. Do I need to add the Scriptmanager from you FW too ? if yes, where ?

Tks once more

 

Coordinator
Jul 21, 2010 at 12:27 PM

You don't need to include any ScriptManagers. They're optional for use. They're very handy though.

I've never tried using an UpdateRegion within an UpdatePanel. I've written a bit of code to support nested UpdateRegions though so that should work (never ceases to amaze me how the little thing can break your code though). I would definitely try changing that parent UpdatePanel to an UpdateRegion.

So, if this still doesn't work for you, give me a description of the hierarchy of your controls as they are loaded on the page and I will try to recreate it on my end as soon as I get the chance (most likely this evening).

Coordinator
Jul 21, 2010 at 12:29 PM

Oh, and if you can, View Page Source and check for some JavaScript at the bottom of the <body> that declares and registers the UpdateRegion instance.

Jul 21, 2010 at 1:38 PM

Sorry. The usercontrols are loaded only in a UpdateRegion, not  inside a Updatepanel.

But  the menu user control was (only) in a Updatepanel.

I changed that now, so the menu is in a updateregion too, no updatepanels, but now the menu, which is static in masterpage

is not more showed... a bit strange

 

Jul 21, 2010 at 2:04 PM

I successfully bring it working, all based on your updateregion. (had to take out the updatepanel and scriptmanager)

all like before now, but including the gridview click problem, which remains :(

so my problem is probably in the way i load the controls.

After the first load, ID is diferent from the ID after the first click on edit button.

Coordinator
Jul 21, 2010 at 2:19 PM

Excellent! I'm glad you were able to get it to load. We've narrowed down the problem. You can see how easy it is to go back and forth between the UpdateRegion and UpdatePanel. In the end, if you decide that the AJAX Control Framework isn't what you're looking for or it doesn't work good enough you can go back to what you had fairly quickly.

Now let's get this loading issue worked out. I'm determined to help you get this working. My lunch break is approaching and I will be able to give you a solid response then. I have an idea for you try and some best practices to explain that may help, if not better your page loading in general. Hang in there.

 

-Lou

Jul 21, 2010 at 2:37 PM

Hope you had a good lunch

This is the call after loading the grdview in the user control the first time:

<a href="javascript:__doPostBack('ctl00$ctl10$GridView1','Edit$0')">Edit</a>

After clicking on edit once this changes to:

<a href="javascript:__doPostBack('ctl00$ctl08$GridView1','Edit$0')">Edit</a>

and then it stays like that, edit update etc works fine after.

I disabled the Viewstate for the Gridview, but nothing changed

I also disabled it for the hosting usercontrol itself

Jul 21, 2010 at 3:48 PM
I fixed the problem :) It was a kind of "try 10000 things and after dont know anymore what you did for what";) For some reason, i disposed/removed all usercontrols in load event, before i reloaded them. Taking this out plus the disabled viewstate resolved the problem and it runs now well with updateregion or panel. Nothing to do with your FW, hope i didnt robbed to much of your time. many tks, and i will update you on my use of your FW
Coordinator
Jul 21, 2010 at 5:08 PM

Excellent! Good job on figuring that out. Persistence pays off. Thank you for posting. I appreciate your interest in the framework. I truly believe that for a framework to be a good one, it has to "just work." If you have any problems with it, I will fix them.