Rough and random thoughts while playing with the new Atlas bits.
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.
var SrchElem = document.getElementById("SearchKey");
var RsltElem = document.getElementById("Results");
RsltElem.innerHTML = result;
<binding dataContext="SearchKey" dataPath="text"
property="parameters" propertyKey="query" />
<invokeMethod target="resultsBinding" method="evaluateIn" />
<div id="completionList" />
made everything work.
Lab 4 implements the same auto-completion textbox as Lab 3, but with a server side Atlas control instead of client side gunk.
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">
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.