Atlas ScriptManager Control

This post describes the role and functionality of the Atlas ScriptManager control, which is in some sense the brains of an Atlas page. It also points out some of the changes from prior releases where functionality has been consolidated into this control.

The new ScriptManager is in some sense the brains of an Atlas-enabled ASP.NET page. It provides functionality to both the page developer and the control developer (for those writing Atlas-enabled controls), and it orchestrates partial refreshes, incremental updates, and will do even more in the future. I've seen a couple of questions already around some changes we made in the December build by consolidating functionality into the ScriptManager (the build is up btw at http://atlas.asp.net).

Bootstrapping Atlas

<atlas:ScriptManager runat="server" id="scriptManager" />
Atlas.js (and AtlasCompat.js on non-IE browsers) together bootstrap Atlas functionality on the client browser. The ScriptManager is now responsible for rendering out these references. You no longer need to have a series of <atlas:Script> tags on your page.

Using Atlas in Runtime Mode

<atlas:ScriptManager runat="server" id="scriptManager"
    EnableScriptComponents="false" />
As explained in my post a while back there are times when you want a lighter weight version of Atlas, i.e. in what we call Atlas runtime mode. For example on your site's homepage, where you need minimal script. Alternatively, you may be interested in just the JavaScript OOP patterns, and the ability to talk back to Web services, while coding directly against the raw DHTML DOM. Basically, you want to turn off all the script component support. This is done by referencing AtlasRuntime.js instead of Atlas.js.

Using Atlas in Debug Mode
Starting with this release, we're shipping both Debug and Release flavors of the Atlas scripts. The debug versions have their source formatting preserved, as well as some helpful debug asserts (we will add more over time to improve the error detection experience). ScriptManager detects debug mode as set in configuration in web.config and automatically references the appropriate Atlas scripts.

<system.web>
  <compilation debug="true" />
</system.web>

Adding Script References

<atlas:ScriptManager runat="server" id="scriptManager">
  <Scripts>
    <atlas:ScriptReference ScriptName="AtlasUIGlitz" />
    <atlas:ScriptReference Path="Foo.js" Browser="Firefox" />
    <atlas:ScriptReference Path="WeatherControl.js" />
  </Scripts>
</atlas:ScriptManager>
Previously you had to use several <atlas:Script> controls. All that functionality has been rolled into the Scripts collection of the ScriptManager, so you just have one non-visual control on your page.

Adding Service References

<atlas:ScriptManager runat="server" id="scriptManager">
  <Services>
    <atlas:ServiceReference Path="ZipCodes.asmx" />
  </Services>
</atlas:ScriptManager>
Previously, you had to manually type in a <script> tag with the path to an .asmx followed by "/js". No more. Its much more simpler, and can now be done in design-view as well, without manually typing in script tags. Basically add an item to the Services collection of the ScriptManager, and it will take care of adding the "/js" to the URL as well.

MasterPage/ContentPage Scenarios
You may have a ScriptManager on your master page, but you may want to add additional script or service references in your content page. However, you can only have one ScriptManager on your page. Therefore we have the accompanying ScriptManagerProxy control.

<asp:Content ...>
<atlas:ScriptManagerProxy runat="server" id="scriptManagerProxy">
  ...
</atlas:ScriptManagerProxy>
</asp:Content>

Support for Atlas-Enabled Server Controls
This deserves a blog post on its own, but I wanted to point out some of the interesting APIs on ScriptManager for control developers. The idea is you have a control that happens to use Atlas for its implementation, and needs to generate XML script to declare and initialize its script-based counterparts on the client.

Getting hold of the ScriptManager instance on the current page:
static ScriptManager ScriptManager.GetCurrent(Page page);

Registering an XML namespace to be rendered out in the XML script markup:
ScriptManager.RegisterScriptNamespace(ScriptNamespace ns);

Registering an Atlas-enabled control (one that implements IScriptControl) so it can be included into the XML script rendering:
ScriptManager.RegisterControl(control);

Registering a script reference so it gets added into the list of script references on the page:
ScriptManager.RegisterScriptReference(FrameworkScript scriptName);
ScriptManager.RegisterScriptReference(string scriptPath);

Note that you can use WebResources to package scripts. Simply pass the URL you get from GetWebResourceUrl to RegisterScriptReference.

And finally, ScriptManager manages the set of UpdatePanels on your page, and performs the work to process post-back requests meant to update just portions of the page, by determining the set of UpdatePanels to update, and rendering parts of the page as needed. I discussed partial rendering in my post from yesterday.

I hope this gives more sense of both Atlas functionality, what is new, and what has changed. You'll see ScriptManager evolve over time to include some even more smarter incremental update mechanisms we've been planning.

Posted on Thursday, 12/22/2005 @ 3:41 PM | #ASP.NET


Comments

22 comments have been posted.

Andrey Skvortsov

Posted on 12/26/2005 @ 2:57 AM
One note.As I can understand you shift accent to the server side again with new control model.So,you have to pay for statefull(postback based) server side webforms asp.net implementation(partial or not-dosen't really matter;-) though xmlhttp supposed to solve similar problems on client side.We return to asp.net=webforms dependent server side development.Where's logic here?Beside of support legacy apps,I wan't have to write forms runat="server" for every .aspx or even clear .html page.Or I don't have to?Is there possiblity to use atlas client side component model as complete replacement of webforms as whole for new projects?We must completly rethink our apps regards "new" xmlhttp's "out of band request" possibilities including SERVER side,but not introduce additional obsfucation layer for not very convenient(compared to xmlhttp) webforms model.Don't get me wrong,I'm very interested in server side support per se and in <atlas:ScriptManager/> paticularly(to generate <script/> statements for example),but I don't like xmlhttp's webforms dependency as ultimate target.I wan't have to pay webforms price if I don't have to.

Best wishes.

Nikhil Kothari

Posted on 12/26/2005 @ 10:20 AM
Andrey, if I get you right you are referring to the desire to work solely using the client-centric programming model (see http://www.nikhilk.net/AtlasProgModel.aspx). Atlas fully supports that model too (see http://www.nikhilk.net/VirtualPlaces.aspx for an example). In this model, I also see ScriptManager as a convenient way to get your script references...

Andrey Skortsov

Posted on 12/27/2005 @ 1:01 AM
Yes,I refer to client-centric programming as foundation for all future development and that webforms dependency is not very good option in such cases-less is better.You're talking about http://schemas.microsoft.com/xml-script/2005 as main declarative programming(client side)programming model,I like it but I can't find any definition of such .xsd.Where is it?What kind of validation logic is used in parser?

Thanks a lot.
P.S.I believe that Atlas should be that whidbey now and you must considerably rethink server side model taking into account client side as first class citizen.

Andrey Skvortsov

Posted on 12/27/2005 @ 7:06 AM
By the way,where to submit bugs?DragOverlayExtender is not working in UpdatePanel's ContentTemplate-if ContentTemplate contains simply <input/>,every attempt to click=focus control makes overlay to move by itself,and it dosen't remember position on corresponding "partial" postbacks.

Regards.

Nikhil Kothari

Posted on 12/27/2005 @ 12:30 PM
Andrey, the best place to post discuss bugs is on the Atlas forums on the atlas.asp.net site.

As far as xml script validation goes, the parser does not validate schema - it validates xml, and will eventually validate against the OM of the controls and components it is working on. The schema is simply a placeholder URN...

Rethinking the server-side model is always done in every release... in an incremental and evolutionary manner. We introduced several new things in Whidbey. As Atlas gets incorporated into ASP.NET, over time, you'll see more integrated support for it. Of course, there is a new model for client-centric development, and here you'll see ASP.NET as a whole evolve to better enable that model, as opposed to say the server controls by themselves.

STeve

Posted on 12/27/2005 @ 2:07 PM
Nikhil - with callbacks, the user needs an indication that something is happening. In other callback code I would include an animated gif that would run until the callback was complete.

With the refreshpanel that is being used, there needs to be a way to include a wait message or an animated gif.

Could this be included in the script manager or in the refreshpanel?

Thanks

Nikhil Kothari

Posted on 12/27/2005 @ 2:46 PM
Adding support for progress indicators is on the way, and yes, it will likely come in the form of properties on ScriptManager.

Steve

Posted on 12/27/2005 @ 3:49 PM
Good stuff, thanks for the quick update.

Matthew

Posted on 1/2/2006 @ 6:43 AM
I've noticed that after the Dec CTP build of the Atlas libraries, the ScriptManager control seems to ignore the scriptLibraryPath specified in the web.config file. I can't seem to change the location (path) of script files to be included using the web.config file anymore. Is there a different (new) way to do this now?

prasad patnaik

Posted on 1/2/2006 @ 10:52 AM
it gives me a feel of windows application while working with web, got some problem while working..

i have implimented the update panel for a dropdown, all other server controls in the form woked client side even if they are not a part of panel.

the server side code excutes but it cannot able to return any values to client gives a javascript error in atlas.js file
need more help on this..

Sharad K.

Posted on 1/2/2006 @ 11:04 PM
I agree with Prasad,

I also noticed same, since I put ScriptManager in my master-page (SMProxy in my page!), all my pages buttons stop doing post-back even though some do not have updatePanel used anywhere on that page. Shouldn't the buttons, that are not referenced in UpdatePanel for AJAXish behavior be excluded? Is this so by design?

Thanks...

Prasad Patnaik

Posted on 1/4/2006 @ 10:06 PM
Thanks,
i got a clue,

1. It does not work with the pages already implimented IClientCallback interface, i think it conflicts with the call back result set.

2. When there is no title set for the page, it gives a javascript error at the following lines
var title = delta.selectSingleNode('/delta/rendering//title/text()');
document.title = title.nodeValue.trim();
and stops functioning on the second postback . now it is working fine, but still i have no clue how can i include my external javascript(s) into the page.

<atlas:ScriptManager ID="sm" EnablePartialRendering="true" runat="server" Visible="true">
<Scripts>
<atlas:ScriptReference Path="advert.js" />
</Scripts>
</atlas:ScriptManager>

i tried the above script but it seems like not working ..

Cenk Pekiner

Posted on 1/12/2006 @ 2:07 PM
I have a question about the autoComplete functionality that Atlas provides. In my custom control I implement IScriptControl and create a valid XML string using scriptTextWriter. In my application, I would like to capture the ID of the item that is selected through the autocomplete list. For instance, if I select Apple from the autoComplete list., I would like to grab the ID of apple instead of the text 'apple' so that I can query against the database using the ID instead of a text filed. Since autocomplete functionality only fills the textbox, I couldn't find a way to store the ID of the selected item. I looked at AutoCompleteExtender class to see if I can use any of these extenders but I couldn't create a solution. Is there a way to accomplish this task using autoComplete?

Thanks,
Cenk Pekiner

Julián Hidalgo

Posted on 1/23/2006 @ 12:04 AM
I think i found a bug in Atlas, particularly in the ScriptManager and UpdatePanel controls. I posted the info in http://forums.asp.net/1176095/ShowPost.aspx.

I've been reading your blog for a couple of days and i really like it. Thanks for all the samples and stuff you have put here :)

Regards.

Siva Mohan Reddy

Posted on 3/3/2006 @ 5:02 AM
Hai,

I have a small doubt , please clarify whether it is possible or not,

Our application is three tier architecture from Asp.net layer that means from javascript i want to call directly BALService (middle layer) method using Atlas.net so i have given the javascript like this.

<script type="text/javascript" src="http://localhost:2726/WebSite5/WeatherService.asmx/js"></script>

but it is not working , then i tried this way,

<atlas:ScriptManager runat="server" ID="scriptManager">
<services>
<atlas:servicereference path="http://localhost:1468/CheckAtlas/WebService.asmx" type="text/javascript" />
</services>
</atlas:ScriptManager>

even this is also not working.

so is it possible to call webservice method from different location from javascript.

can any body give alter native way for this.

i am also looking for how to call codebehind function from javascript using atlas.net

Regards
Mohan

Abishek Bellamkonda

Posted on 3/5/2006 @ 4:12 PM
Looks like Atlas aussmes that all post backs is done by the fist form on the page (Web.Net.pageMethodRequst object). This is ok for most cases, but there are cases where we have more than one form on the page.

I am trying to call a WebService on the same page ShopCategory.aspx. I have a little client side 'site search' forms. Every time i try to call my service, th request goes to Search page.

The below is the cause

<pre>
Web.Net.PageMethodRequest = function() {
Web.Net.PageMethodRequest.initializeBase(this);

this.getEffectiveUrl = function() {
var form = document.forms[0];
return form.action;
}

this.invoke = function(userContext) {
var form = document.forms[0];
</pre>

Can

Posted on 3/18/2006 @ 4:06 AM
Is there a way to call a javascript function after the callback?

Montgomery Brookfield

Posted on 4/16/2006 @ 1:12 PM
Hi Nikhil,
Atlas looks awesome so far. Will eagerly be looking forward to future enhancements. One you may want to consider is an enhancement to ScriptManagers’ RegisterAsyncPostbackControl method to allow a given control to be UN-registered. Ie: RegisterAsyncPostbackControl(ctrl1, [true/false]). The point is that within, for instance, the UpdatePanel, any control contained therein appears to be registered for asynchronous postback preempting the postback normally associated with a given server control. Perhaps I’m getting something wrong here, but in many cases I would think that it might be advantageous to allow the normal postback flow from within UpdatePanel. For instance, I have been converting an ASP.NET 2003 web application to 2005. The overall framework of that application is a series of nested User Defined Controls. So there is a single Page in which is contained a Master Control (will later be converting this to Master pages or even better, perhaps something based on Atlas). That master control then makes visible or hides various UI “Views”. Within a given “View” is a GridView control. Within the Grid are columns of buttons. If the user selects one of these buttons, a directive is sent to the Master Control to hide the current “View” and display another. There are many reasons the architecture had been constructed in this way, the discussion of which would be outside the focus of this post. Regardless, normally this framework works extremely well. However when nesting the GridView within an UpdatePanel, the grid column buttons normal postback mechanism is preempted for the asynchronous postback which in turn preempts the Master Controls ability to swap “Views”. It seems to me that if RegisterAsyncPostbackControl were to allow the developer to Un-register as well as register, an additional level of functionality might be available.

Thanks very much and good luck - Monty

zation

Posted on 4/24/2006 @ 12:43 PM
much pontificating is possible here. but there is a brass tacks approach as well. the up-front money is not that good - what it represents, however, is pretty damn good. but, $2500… plus, you will (probably) never see the rest of the option ($75,000). gobs and gobs of scripts are optioned every year - not many get produced.

for me - i would decline the offer and play both sides against the middle. not in an underhanded way, but why not politely decline then tell the management company that you have done so for reasons which make you look more attractive to them? (it’s your career, right? you have a right to decline options then play your cards in the best possible manner)
http://www.garikorganization.info/org2

Montgomery Brookfield

Posted on 4/25/2006 @ 9:33 AM
Nikhil,

So much for Spam-protection. Low-life dirt bag spamers seem to have invaded your blog.

Adam @ Pretty

Posted on 6/19/2006 @ 6:33 AM
I also tried using scriptmanager to include js files to make sure things arent executed before the webservice is initalised, like :

<Scripts>
<atlas:ScriptReference Path="javascript/Stocks/StocksAtlas.js" />
</Scripts>

But it does not work, the js files do not seem to get loaded.
Thanks

pongpagong

Posted on 6/26/2006 @ 5:59 PM
for the people who have experienced javascript errors in their controls found in contentpages while using a scriptmanager and update panel in their masterpage, try to check first if those controls emit a postbackURL effect to another page... i have a theory that Atlas/AJAX has a bug or an unstable handling in postbackURLs'...

other alternative for using postbackURLs':
try using the onclientclick command and inside the function is a Response.Redirect("default.aspx"). avoid using a postbackURL for your control.

if you are using a querystring that will navigate to another page with data appended in the URL, for instance a postbackURL = "default.aspx?id=" <%# databind %>, try to use a hyperlink control and make use of its navigateURL instead of using a postbackURL...

Again, my theory on Atlas/AJAX is that there are still current bugs and fixes on going. whenever there are errors/problems encountered while developing, i advice you to find another way around using that method. there are always "smart-ass" ways.
The discussion on this post has been closed. Please use my contact form to provide comments.