One of the demos I show at the Roadshow is how easy it is to hook up Atlas controls to ASP.NET application services (in this case the Profile Service). I use a DragOverlayExtender to add drag/drop functionality to a panel on my page. The position of this panel is persisted using the ASP.NET profile service to a profile property called “PanelLocation”. An extract from the web.config file looks something like this:

<microsoft.web>
   <…>
   <profileService enabled="true" setProperties="PanelLocation" getProperties="PanelLocation"/>
</microsoft.web>
<…>
<system.web>
   <profile>
      <properties>
         <add name="PanelLocation" type="System.String" />
      </properties>
   </profile>
<…>
</system.web>

And the relevant page markup looks something like this:

<atlas:ProfileScriptService ID="Profile1" runat="server" AutoSave="true">
</atlas:ProfileScriptService>
<atlas:DragOverlayExtender ID="Drag1" runat="server">
   <atlas:DragOverlayProperties Enabled="true" TargetControlID="xxxx" ProfileProperty="PanelLocation" />
</atlas:DragOverlayExtender>

Each time I move the panel, its position is persisted to the PanelLocation property via the profile service (so next time I go to the site, the panel appears in the position I last left it). In the case of the demo I have my site setup for Windows Authentication so I am authenticated on the site with my Windows credentials but profiles also work with Forms Authentication. They also have an “Anonymous Identification” capability that supports various modes including UseCookie and UseUri to identify the user.  Have a look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/userprofiles.asp and http://msdn.microsoft.com/msdnmag/issues/05/10/CuttingEdge for more information.

What all this means is that I can take advantage of all the benefits of the Atlas framework safe in the knowledge that I can still make use of ASP.NET’s application services. There’s great integration between the two so you don’t have to throw away your investments in that area (or conversely you can still benefit from those powerful application services) just because you want to leverage Ajax functionality.