Difference between ClientSide Callback and Atlas

what is the difference between ClientSide Callback feature in ASP.NET 2.0 and Atlas.

regards

Hi,

Both are functinally same.

Microsoft has designed Gridview for having this as a implicit feature. as its a very complex control. So you can say that every grid is Ajax enabled.

When you use Atlas grid view behave same.

But important difference to note that, when you use clientscriptcallback, you can not use template columns.

But same can be done in Atlas.

So gridview is partially callbacks enabled.

So both are different

Development Strategy

I'm already using homegrown callbacks in my app, it's a great feature, and so I'm happy to see that Atlas is coming along so well.

My challenge is that I've got limited development resources (me and mine) and a limited window of opportunity to get my app to market. So I'm probably going to continue to test Atlas, and wait to put it into the app later in the development cycle, depending on how strong it looks at the time.

My question is, though, is there anything about the use of Atlas that I need to consider in terms of writing the app in the first place? More specifically, I recognize the "no screen flash" and other possible effects as seen by the user...that's why I started using callbacks to begin with. And I appreciate that there are probably ways to "optimize" the way the code is written to maximize the benefits of Atlas. However, I can't afford to do that now because of the risk that Atlas interfaces or behaviors will change at the last minute, and throw off my development schedule.

So the crux of the question is, is it safe to assume I can write my ASP.NET app without specific consideration of Atlas, and then drop Atlas elements (notably update panels) into it at the last minute, and for the most part "get away with it", i.e., not be stuck with a lot of changes required to make the app "Atlas" compatible?

Hope this makes sense, and would appreciate any guidance on it.

Thanks!

One advice is to make use of good HTML coding practice, such that when you integrate Atlas into the webpage, you don't get into a confusion yourself. Try to avoid using having too many layers of z-index. z-index:1 to z-index:3 should be enough for most scenarios.

I once working on a project, which requires me to atlacise a existing page with many bad HTML and CSS coding. The result was I end up re-writing the HTML elements and dragging in the ASP Controls one at a time as a attempt to clean up the attrocious HTML which the previous developer wrote. After the HTML is cleaned up, it took me just 10 minutes to atlacise the entire site.

hello.

hum...well, i'd say that with the updatepanel it's really easy (almost too easy, if there's such a thing as too easy) to transform an aspx page intro an atlas pages. if you want to use the full power of atlas, then you'll really need to decide on several things - ex.: how to update a record on a db? use a traditional page or use only client side HTML and perform the update of the record through a web service? you'll probably drop the updatepanels in many scenarios (specially if you're looking for a perfomance)

THanks Luis for sharing. Update panel actually affects performance? How much performance advantage would you get if you update directly via a webservice? Are there any advices when to use an update panel and when not to? It seems that most using the Atlas framework would make use of the UpdatePanel .

hello.

well, what i say is that if you're buildning a new app and want to use atlas, you probably should start by looking at the client side of atlas before using the updatepanel. i really think that the updatepanel is great when you just need to enable atlas on an existing aspx page. however, i also think that its usage is only justified when you are using a server side approach. and when you use it, you should also keep in mind that a partial postback results in the sending of all the fields maintained in the form (which might not be what you want when you need to perform a simple server side operation).

Thanks for inputs. The anectdotal experience reports and cautioning comments are great for providing "view ports" into this technical area.

I'm concluding that waiting to add update panels to well-formed pages is a relatively low risk approach. I'm sure I'll be testing Atlas along the way, as well.

Agradecimento!

DefaultButton in UpdatePanel

ASP.Net 2.0 has a nice feature. You can - in a panel - define a DefaultButton. When you have focus in a TextBox (on the panel) and presses RETURN, you click the DefaultButon.
When using an UpdatePanel (ScriptManager:EnablePartialRendering="True) this also works fine, but... only once.
Does somebody knows a workaround or a solution or am I doing something wrong?

<atlas:UpdatePanelID="UpdatePanel1"runat="server">
<ContentTemplate>
<asp:PanelID="Panel1"runat="server"DefaultButton="Button1">
<asp:TextBoxID="TextBox1"runat="server"></asp:TextBox>
<asp:ButtonID="Button1"runat="server"OnClientClick='alert("click")'Text="Button"/></asp:Panel>
</ContentTemplate>
</atlas:UpdatePanel>

hello.

well, this is a side-effect bug related with the way the code used by the asp.net works. when you add a default button, you get this on your panel:

THe problem happens on the WebForm_firedDefaultButton. Inside, the method checks for a global variable called __defaultFired which initially is set to false. the 1st thing the method does is check the value of this var. if it is set to true, it doesn't do anything since it thinks you're re-submitting the form. if you think only about ASP.NET, this makes sense, right?

unfortunatelly, when yuo use atlas you start getting the behavior you've described. for now, i think that you can override the prerender method of your page and add this:

protected override void OnPreRender (EventArgs args)
{
base.OnPreRender(args);
this.ClientScript.RegisterStartupScript(this.GetType(), "resetBt", "__defaultFired = false;", true);
}

By injecting this instruction, you're resetting the state of the _defaultFired variable so that you're able to start another request when you press the enter key.

btw, what's wrong with the feedback center? i'm trying to add a bug and can't pass from the searh page :(

Thank you for your reply Luis. It works!

Sorry to say but then i am having the same problem and not bale to get it work :(

Can you please help ?

This is a known issue in the current CTP and we are considering fixing it in a future release.

Thanks,

Eilon

the prerender solution doesn't work at my neither :(

maybe it depends on which CTP you're using? are there any other solutions available right now?

protected override void OnPreRender(EventArgs args)
{
base.OnPreRender(args);
this.ClientScript.RegisterStartupScript(this.GetType(), "resetBt", "__defaultFired = false;", true);
}

works in IE but not in Firefox

always working Workaround or Fix would be great

Does anyone have a workaround for this that will work in Firefox? I'd really rather not have to yank out all of my updatepanels, but this is about the only option I see right now.

Thanks

hello.

i really hanve't checked how the current version implements this functionality. i suggest that you use a new static methods of the scriptmanager class instead of using the clientscriptmanager class to register the startup scripts.

Has anyone figured out a way to get the the default button working with firefox in an updatepanel?

Did'nt want to start a new topic!

Thanks

hello.

if i recall correctly, the approach mentioned on this thread doesn't work only in IE (ie, it should work without any problems in firefox)

After struggling with this for a while between browsers andAtlas ajax.net I chose a dumb method and implement this in code, w/o using the DefaultButton attribute. I set this on Page_Load for any control collection. In fact ASP.NET should have a default button setting for just about anything that is clickable - for example the button on an panel extender.

publicstaticvoid SetDefaultButton(WebControl button,ControlCollection cc)
{
foreach (System.Web.UI.Control wcin cc)
{
SetDefaultButton(button, wc.Controls);
if (wcis System.Web.UI.WebControls.WebControl)
{
if (wcis System.Web.UI.WebControls.TextBox)
{
TextBox tb = (TextBox)wc;
SetDefaultButton(button, tb);
}
}}}publicstaticvoid SetDefaultButton(WebControl button,TextBox tb)
{
if (tb.TextMode ==TextBoxMode.MultiLine)
return;

tb.Attributes.Add(

"onkeydown","if(event.which || event.keyCode){if ((event.which == 13) || (event.keyCode == 13)) {document.getElementById('" + button.UniqueID +"').click();return false;}} else {return true}; ");
}

The OnPrerender() solution above didn't work for my app.

I had this issue in IE and Firefox.In IE the first time the user pressed enter the default button fired, but after that it won't fire. In FireFox is was just the opposite, the first time it wouldn't fire and then it fired fine after that.

The fix I came up with (after seeing the OnPrerender() exmaple) is to set the __defaultFired variable appropriately in the pageLoad() function which AJAX calls after the page is completely loaded. This works for IE, Firefox and Safari.

<script type="text/javascript" language="javascript">
function pageLoad()
{
if (navigator.userAgent.indexOf("Firefox")!=-1)
{
__defaultFired = true;
}
else
{
__defaultFired = false;
}
}
</script>

I put this on my master page and now all my default buttons fire properly now.

Anyone know why Firefox has the reverse logic for __defaultFired?

I am having the same problem. :( DefaultButton works only in IE, not in Firefox. Can anyone on the Asp.net Ajax team comment on whether this will be fixed for the release version?

Thanks