Showing posts with label purpose. Show all posts
Showing posts with label purpose. Show all posts

Saturday, March 24, 2012

Purpose of "AllowPartialRendering=true"

WHen I used "Autocomplete" contorl of Atlas, I did not need the scriptmanager to have the above attribute to be set specificcally to true and everything worked great.

However, when I started using web parts where I had two calendars in two web part zones, as soon as I clicked on a date in one calendar, i could see the entire page refresh. When i set the above mentioned parameter to true, that thing went away.

So when to set this parameter to true or is it required always?

When you use the UpdatePanel control, setting the EnablePartialRendering property to True allows you to get a partial page rendering...
When you use the UpdatePanel control, setting the EnablePartialRendering property to True allows you to get a partial page rendering...

Purpose of Bridging

Ok, I have the Atlas CTP, and I must say, this beats trying to just code AJAX straight up. I have gotten the hang of using the Atlas controls and can get them to do what I want on the pages I want them to perform. And if anyone on the Atlas team reads this, kudos to you guys for sharing this!

Now I have been reading somethings on Bridge files, and the .asbx extension and what not. I even read and followed thehttp://atlas.asp.net/docs/Walkthroughs/DevScenarios/bridge.aspx Mash-Up tutorial and got the application to compile and run. But still have yet to read something that says using a Bridge is good for (insert action here).

From looking at the example, it appears that it is a way to create classes that can be called from the javascript, and thus query webservices directly from the JavaScript. Is that correct, or did I miss interpret along the way?

Thanks!

I think you understand it exactly. Specifically, bridging is good when the webservice you want to call isn't on your server. Calling a webservice on another server is problematic given that modern browsers limit cross-site scripting for security reasons.

In this case, a common solution is to build a server-side proxy to make the call for you. Bridging automates much of the work involved in doing that. It also gives you an easy way to define data transformations on the results of that webservice call.

I hope that helps, and I'm glad to hear you enjoy the product!


Steve,
Thanks for the response. All of the webservices my site consumes are located on our servers and with in our domain. I guess I've never tried to consume something from another domain. Thanks for the help in the clarification, and for now, I think I'll leave bridging be, and focus more on how I can make the rest of Atlas work for me.

Thanks again!

Question about DragPanel implementation

I'm building a dragbuttonextender which purpose is to extend button control so that it can be dragged and dropped. In AjaxControlToolkit's implementation of DragPanel in FloatingBehavior.js there is a functioncheckCanDrag which looks like:

this.checkCanDrag = function(element) {
var undraggableTagNames = ["input", "button", "select", "textarea", "label"];
var tagName = element.tagName;
if ((tagName.toLowerCase() == "a") && (element.href != null) && (element.href.length > 0)) {
return false;
}
if (Array.indexOf(undraggableTagNames, tagName.toLowerCase()) > -1) {
return false;
}
return true;
}

My question is:Why are buttons and input controls undraggable?

I wrote my extender (which extends ASP.NET Button controls) and I can drag&drop buttons. The problem is that when drag&drop ends a full postback occurs and position of the button is restored to its original location. When I use my extender (which is currently almost identical to AjaxControlToolkit's DragPanelExtender except checkCanDrag function) to extend ASP.NET Panel control then everything works fine and panels are placed where I dropped them. When I put buttons in a panel and attach my extender to this panel, again everything works fine. So, why can't buttons be extended just like panels are extended?

Anybody?