Notes From the Atlas Hands On Lab

Wednesday, September 21, 2005

Rough and random thoughts while playing with the new Atlas bits.

Lab 1

Lab 1 creates a master page with <atlas:script> tags to ensure links to the Atlas framework .js files are sent to the client. I’d like to see this functionality in a base class so it isn’t copy and pasted everywhere, or simply injected auto-magically, perhaps when an attribute like <% @ Page AtlasEnabled=”true” %> appears.

Nifty master page tricks: the master page uses a ContentPlaceHolder inside the %lt;head%gt; tag, which makes it easy for content pages to override the contents of head. The master page does not define a %lt;form> tag, but leaves the content pages to define the tag (typically with action=”” since there are no postbacks involved).

Glitch: the setup puts a default.master and a default.aspx in the same directory, which can produce duplicate definitions for _default in the codegen directory. The errors appear in temporary files with scary names, and the errors come and go depending on how many files compile. It’s scenarios like this that make the system appear broken and one reason why people hate the project-less web project.

Cool: you can generate JavaScript proxies for a web service by browsing to the asmx file and appending /js (why not ?js to be consistent with ?wsdl?). Assuming you wire up a button’s onclick event, you can pull back and process results with relatively simple code. Lab 1 passes the contents of a textbox to a HelloWorld type service, which essentially echoes the input back with a timestamp.

function DoSearch()

{

  var SrchElem = document.getElementById("SearchKey");

  Samples.AspNet.HelloWorldService.HelloWorld(

      SrchElem.value, OnRequestComplete

    );

}

 

function OnRequestComplete(result)

{

  var RsltElem = document.getElementById("Results");

  RsltElem.innerHTML = result;

}

Lab 2

Lab 2 performs the same work as Lab 1, but with a declarative syntax. Instead of writing JavaScript you write a mess of declarative XML that only a machine can love. Excerpt:

<serviceMethod

    id="helloService"

    url="HelloWorldService.asmx"

    methodName="HelloWorld">

  <bindings>

    <binding dataContext="SearchKey" dataPath="text"

            property="parameters" propertyKey="query" />

  </bindings>

    <completed>

      <invokeMethod target="resultsBinding" method="evaluateIn" />

    </completed>

</serviceMethod>

Weep: Lab 2 didn’t work for me immediately and I had to stare at the XML and compare the above to what was in the sample. Not knowing what else to do I started stepping through the Atlas JavaScript. I was deep inside a JSON.serialize method when I realized it was building a payload like “query:foo”, where “foo” was the value I typed into the textbox and “query” was the name of the web service parameter – except I had named my parameter on the C# method differently.

I hope that none of the XML cruft will have to be hand written. I hope there will be some way to keep the XML and web method in sync, or decoupled. Lab 1 worked because the JavaScript proxy was custom generated from the code– I hope something along those lines will be available for the declarative service method bindings.

Lab 3

Lab 3 added auto-completion to the textbox control, which I found rather appealing in a scary way. When typing into the textbox the JavaScript will invoke a web service method and bring back a list of possible matches to display in a DHTML control.

Unfortunately, this lab started throwing a JavaScript exception, so once more I tried to step through the optimized-for-transport-no-whitespace JavaScript of the framework. I thought my head was going to explode. I gave up and posted on the asp.net forums, and  found that changing:

<div id="completionList" />

to

<div id="completionList"></div>

made everything work.

Sigh.

Lab 4

Lab 4 implements the same auto-completion textbox as Lab 3, but with a server side Atlas control instead of client side gunk.

<atlas:TextBox

  id="searchBox"

  runat="server"

  AutoCompletionServiceUrl="AutoCompleteService.asmx"  

  AutoCompletionServiceMethod="GetWordList"

/>

Sweet.

Lab 5

Lab 5 uses Atlas server-side controls to call a web method and populate a templated listview control. The word “bindings” appears a lot. Excerpt:

<atlas:Button runat="server" ID="fillButton" Text="Get URL List">

  <click>

    <actions>

      <atlas:invokeMethodAction

        target="dataSource1"

        method="select" />

    </actions>

  </click>

</atlas:Button>

The declarative syntax feels passive and the terminology is vague, but I suppose that is the nature of the beast and something I have to get over.

This concludes my notes from the Atlas hands on exercises. I’m certain you have not enjoyed them half as much as I have enjoyed typing them in.


Comments
Tim Haines Wednesday, September 21, 2005
Thanks Scott. I doubt I'm going to get time to look at the labs anytime soon, so it was interesting to get some insight.
scott Wednesday, September 21, 2005
Bertrand Le Roy has an in-depth sample in his blog that goes far beyond what the labs do:

weblogs.asp.net/.../425698.aspx
tim Wednesday, September 21, 2005
Scott, you're right about the issue with needing the closing div tag in Lab 3. This is a bug in which IE does not recognize all self-terminating tags as in XHTML, so the tag has to be explicitly closed. This will be a good thing to remember when binding the results of returned method to HTML elements in Atlas applications, or in general with any DOM or DHTML application.
scott Wednesday, September 21, 2005
Thanks, Tim. I wanted to find out why I needed the explicit close - now I know!
Kevin Saturday, September 24, 2005
I did the same thing as you in Lab 2. Thanks for your help Scott!

Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!