# Thursday, October 15, 2009

When creating web applications I like to extract common pieces of mark-up into helper functions. I use Hasic which means helper functions are just simple VB functions that return XElement objects.

However, dynamic web pages often use javascript to add elements at runtime. Consider a page with a table of data which has an form to add rows. We want to add rows without reloading the whole page. So we use AJAX to post the new data, then, in javascript, create the new table row and append to the table.

So we have a repetition of the same HTML template; server-side and client-side.

Using Hasic we can eliminate this repetition. The following class field defines an HTML template:

Shared customerRow As New HtmlTemplate(Of String, String)("customerRow", Function(first, last) _
  <tr>
    <td><%= first %></td>
    <td><%= last %></td>
  </tr>)

Let’s break this down. We are creating an HTML template that takes two string arguments and returns an XElement. We have named it “customerRow” and given a lambda expression that returns the HTML. That second argument is an Expression(of Func(of String, String, XElement)). So the HtmlTemplate is able to parse the expression tree and generate an equivalent javascript function.

Within my page (server-side) I can use the template like a function (by using an indexer property).

Protected Overrides Function Contents() As XElement
  Return _
  <_>
    <table id="customers">
      <tr><th>First name</th><th>Last name</th></tr>
      <%= customerRow("Andrew", "Davey") %>
      <%= customerRow("John", "Smith") %>
    </table>
    <div>
      <button id="add">Add Row</button>
    </div>
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
    <%= InlineJavascript(customerRow.Javascript) %>
    <script type="text/javascript">
$(function() {
    $('#add').click(
        function addRow() {
            $('#customers').append(customerRow('John','Smith'));
        }
    );
});
    </script>
  <_>
End Sub

The above code also includes the javascript for the page. Notice the customerRow.Javascript property. This returns the javascript function as a string. InlineJavascript is a helper that wraps up the javascript into a CDATA making the angle brackets safe. The javascript function looks like this:

function customerRow(first,last) {
  return '<tr><td>' + last + '</td><td>' + first + '</td></tr>';
}

The name of the function is what we gave to the HtmlTemplate constructor. Concat-ing strings may not be the best way, but it works for this prototype.

I hope you can see the value here. The template function is written only once. DRY win :)

hasic | html | javascript | vb.net | web
Thursday, October 15, 2009 12:39:59 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [1]  | 
# Sunday, October 11, 2009

Say hello to ProntoCMS a new open-source web content management system.

The project is hosted here: http://code.google.com/p/prontocms/

Pronto is built on ASP.NET MVC and uses JQuery and FCKeditor. It is very light-weight and ideal for small websites.

The code in subversion contains a couple of (very minimal) sample projects. Hopefully I will get around to writing some documentation soon.

Please take a look at the code and let me know what you think.

.net | cms | prontocms | web
Sunday, October 11, 2009 1:47:03 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [3]  | 
# Saturday, October 10, 2009

Thanks to everyone who left encouraging comments on my previous post about a new CMS I’ve created.

I have decided that I will be open sourcing the project. However I now need a snappy name for it. Naming is so hard for some reason!

Any ideas are greatly appreciated. The CMS is light-weight, very simple, runs on asp.net mvc and has plenty of ajax goodness.

.net | cms | mvc | oss | web
Saturday, October 10, 2009 6:24:40 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, October 08, 2009

Over the course of a couple of website developments I created a simple content management system. I know there are loads our there already, but I wanted something simple and easy for non-techie users. It runs on ASP.NET MVC, has an elegant extensibility model and produces clean HTML 5. I very happy with it and plan to use it on all upcoming simple websites.

The system is file based, so no SQL database is needed. This makes it ideal for running in shared hosting. It’s perfect for the ~10 page website. But there’s no reason it can’t scale up to larger sites too.

So I’m obviously enamoured with my own work :) but is it worth sharing? I would love to get the code out there for people to poke at. However, is it really worth my time doing so – setting up a project, documentation etc? My recent open sourced work seems to have taken off like a lead balloon (Snooze, Hasic, etc)! Do you want to see my new CMS? Or shall I just keep it to myself?

.net | c# | cms | mvc | web
Thursday, October 08, 2009 3:55:37 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [5]  | 

Hasic is a kick-ass view engine for ASP.NET MVC, with a completely different approach. It uses VB.NET's XML literals instead of nasty strings like most other view engines.

That's right, VB! If you are already closing your web browser upon reading that then shame on you. I'm not saying your whole app is in VB, just the views.

Using VB means this stuff comes for free:

  • Syntax colouring
  • Full intellisense in Visual Studio
  • Compiled views
  • Extensibility using regular CLR classes, functions etc

I’m looking for feedback. So please try out Hasic and let me know what you think – thanks!

.net | mvc | vb.net | web
Thursday, October 08, 2009 3:30:43 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Friday, March 13, 2009

Another approach I'm investigating for HTML form generation is using VB's XML literals.

Check out this screencast for a demo: http://screencast.com/t/WSoDB4B9M2

 

XML literals + Expression Trees gives us some serious power!

.net | html | screencast | vb.net | web | xml
Friday, March 13, 2009 6:44:33 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 

HTML forms seem to be general enough to warrant a better abstraction than manually creating the HTML, or even using simple HTML helpers. Ideally the semantics of the form should be enough to generate all the HTML content.

I have been prototyping some ideas in this area. Here is some code that demonstrates a simple (but incomplete) login form.

class LoginData
{
    public string Username { get; set; }
    public string Password { get; set; }
    public bool Persist { get; set; }
}
 
 
class LoginForm : Form<LoginData>
{
    public LoginForm()
    {
        FieldContainer = new DivFieldContainer();
 
        Add(d => d.Username);
        Add(d => d.Password).AsPassword();
        Add(d => d.Persist).WithLabel("Stay logged in on this computer");
    }
}
 
class Program
{
    static void Main(string[] args)
    {
        var data = new LoginData() { Username = "test" };
        var form = new LoginForm();
 
        var html = form.Create(data);
        Console.WriteLine(html.ToString());
    }
}

This generates the following HTML.

<form method="POST" action="http://localhost/">
  <div>
    <label for="Username">Username</label>
    <input id="Username" type="text" name="Username" value="test" />
  </div>
  <div>
    <label for="Password">Password</label>
    <input id="Password" type="password" name="Password" />
  </div>
  <div>
    <input id="Persist" type="checkbox" name="Persist" />
    <label for="Persist">Stay logged in on this computer</label>
  </div>
</form>

There is a clear separation of the data from the form meta-data. This lets me do interesting things like applying conventions, for example, the generation of label text from property names. I want to use mostly global conventions for a form, and then override a few specific fields where needed.

I think validation can also fit nicely into this approach. Validation logic can be put on the data model. The form model can then specify how errors are added to the HTML.

Has anyone else seen anything like this before? I don’t want the reinvent the wheel. Or at least I can steal some good ideas ;)

.net | c# | html | web
Friday, March 13, 2009 11:51:16 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [1]  | 
# Monday, January 19, 2009

Don't call SmtpClient.SendMail directly within your controller actions because it directly couples your controller to SmtpClient.

Don't even create an interface IMailer and wrapping implementation of this to SmtpClient.

Instead, create a new ActionResult subclass called EmailResult. Make this class have the properties From, To, Subject and BodyData. In the ExecuteResult method use the ViewEngine infrastructure to render a view of the BodyData into your own StringWriter. You can then send the resulting content via email using SmtpClient.

.net | asp | mvc | web
Monday, January 19, 2009 4:39:44 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, December 08, 2008

Avoid using HttpContext in controller actions to make testing much easier. Therefore all inputs to an action needs to be passed as parameters. In my new REST framework that builds on ASP.NET MVC I have created some useful model binders to make this easy.

[ResourceUriTemplate("")]
public class RootUri : ResourceUri
{
    public ResourceResponse Get([HttpCookie] string visited, [AppSetting] int visitTimeout)
    {
    ...
    }
}

The HttpCookieAttribute looks for a cookie called "visited". The AppSettingAttribute looks in web.config for an appSetting with the key "visitTimeout". The method is now easy to test and has very readable definition. :)

 

Both attributes will cast the raw string found into the required type by using a TypeConverter.

The AppSettingAttribute constructor can also take a key name if you want something different from the parameter name.

The code is in SubVersion, but I'll repeat some here to show just how easy it was:

namespace Snooze
{
    public class AppSettingAttribute : CustomModelBinderAttribute
    {
        public AppSettingAttribute()
        {
        }

        public AppSettingAttribute(string key)
        {
            _key = key;
        }

        string _key;

        public override IModelBinder GetBinder()
        {
            return new AppSettingModelBinder(_key);
        }
    }

    public class AppSettingModelBinder : IModelBinder
    {
        public AppSettingModelBinder(string key)
        {
            _key = key;
        }

        string _key;

        public ModelBinderResult BindModel(ModelBindingContext bindingContext)
        {
            string setting = WebConfigurationManager.AppSettings[_key ?? bindingContext.ModelName];
            object value;
            if (bindingContext.ModelType == typeof(string))
            {
                value = setting;
            }
            else
            {
                value = TypeDescriptor.GetConverter(bindingContext.ModelType).ConvertFromString(setting);
            }
            return new ModelBinderResult(value);
        }
    }
}

.net | mvc | REST | web
Monday, December 08, 2008 8:55:53 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [1]  | 
# Sunday, December 07, 2008

Filters in ASP.NET MVC provide a great way to attach functionality around controllers. By building on top of the MVC framework, my ResourceUri class (which inherits from Controller) gets all the filter goodness as well.

My library also has a SubResourceUri class. Any filters applied to the parent ResourceUri are also executed for the SubResourceUri.

[ResourceUriTemplate("customers/{CustomerId}")]
[MyLoggingFilter]
public class CustomerUri : ResourceUri { ... }

[ResourceUriTemplate("orders/{OrderId}")]
public class OrderUri : SubResourceUri<CustomerUri> { ...}

For example, when we GET an order the filter still catches the request and outputs logging information.

Another use is authorization. You can place an authorization filter on top level URI and it will protect all sub-URIs beneath it.

 

Keep track of the latest developments on the code here: http://svn2.assembla.com/svn/snooze/branches/aspnet

.net | mvc | REST | web
Sunday, December 07, 2008 9:34:25 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Sunday, November 30, 2008

Continued work on my resource-oriented library for ASP.NET MVC has expanded to include an XDocument based view engine for ASP.NET MVC.

This means we can now use VB.NET XML literals to define XHTML views (or any XML views).

Get the latest from SVN.

.net | html | mvc | REST | vb.net | web | xml
Sunday, November 30, 2008 10:49:44 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [2]  | 
# Wednesday, November 26, 2008

Now that the ASP.NET MVC API has settled down I decided to bring some of my ideas about REST and resource-oriented programming to it.

The following screencast shows my current prototype in action:
http://www.aboutcode.net/screencasts/snooze-aspnet-mvc.wmv

I'm keen for comments and feedback.

The source code is currently available via SVN here:
http://svn2.assembla.com/svn/snooze/branches/aspnet

.net | c# | mvc | REST | screencast | web
Wednesday, November 26, 2008 3:23:02 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [1]  | 
# Sunday, July 13, 2008

Sending data from a resource to a view in a strongly-typed, but syntactically lightweight manner is not possible with C# or VB.NET.

So check out this screencast of the new "render" macro in NRest!

In a nutshell, my resource looks like:

[Resource("")]
public class RootResource
{
    public Get() : void
    {
        def test = 42;
        render (Foo = "Hello", Bar = "World", test);
    }
}

My VB.NET view looks like:

Public Class RootPage
    Inherits Page(Of RootPageContent)

    Public Overrides Function GetHtml() As XElement
        Return _
        <html>
            <body><%= Content.Foo %>, <%= Content.Bar %></body>
        </html>
    End Function
End Class

The RootPageContent DTO class is generated at compile time by the render macro. Everything is strongly-typed.

.net | dsl | macro | nemerle | nrest | REST | web
Sunday, July 13, 2008 3:27:17 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Saturday, May 10, 2008

A demo website using my Hasic view engine for ASP.NET MVC.

HasicDemo.zip (275.95 KB)

.net | vb.net | web | hasic
Saturday, May 10, 2008 5:37:41 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [0]  | 
# Monday, March 24, 2008

I've seen people testing that RenderView is called by a controller by inheriting into a "testable" controller. Madness!

RenderView is just a convenience method that calls to IViewEngine, so why not just test expectations on that with a mock? We basically want to test that the correct ViewContext is sent to the RenderView method of the view engine.

This is my test:

[TestFixture]
public class HomeControllerTests : ControllerTestsBase<HomeController>
{
    public override HomeController CreateController()
    {
        return new HomeController();
    }

    [Test]
    public void Renders_Index()
    {
        var render = ExpectRenderView();

        Controller.Index();

        Assert.That(render.Data.ViewName, Is.EqualTo("Index"));
    }
}

I don't think we can get more straight forward than that!

This is my test base class:
(I'm using Moq as the mock framework.)

public abstract class ControllerTestsBase<T>
    where T : Controller
{
    public T Controller;
    public Mock<IViewEngine> ViewEngine;

    [SetUp]
    public virtual void SetUp()
    {
        Controller = CreateController();
        ViewEngine = new Mock<IViewEngine>();
        Controller.ViewEngine = ViewEngine.Object;

        Controller.ControllerContext = new Mock<ControllerContext>(new Mock<HttpContextBase>().Object, new RouteData(), Controller).Object;
    }

    public abstract T CreateController();

    public RenderCall<ViewContext> ExpectRenderView()
    {
        var render = new RenderCall<ViewContext>();
        ViewEngine.Expect(v => v.RenderView(It.IsAny<ViewContext>()))
            .Callback(new Action<ViewContext>(render.Set));
        return render;
    }
}

The RenderCall class provides a place to receive the view context that is passed.

public class RenderCall<T>
{
    bool _called;
    T _data;

    public T Data
    {
        get
        {
            if (!_called) throw new InvalidOperationException("View was not rendered.");
            return _data;
        }
    }

    public void Set(T data)
    {
        _data = data;
        _called = true;
    }
}

.net | mvc | thinking | web
Monday, March 24, 2008 4:08:16 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Tuesday, February 19, 2008

VB.NET 9 introduces a clean syntax for expressing XML data. XHTML is XML so why not use VB.NET to generate it, instead of ASPX pages? People are creating view engines for the new ASP.NET MVC framework. How about a view engine that uses VB.NET XML literals?

The benefits to this approach include full intellisense and access to a the full VB.NET language when creating HTML.

I see a view as a function from some data to an XML element (the <html> element):

Function CustomersPage(ByVal title As String, ByVal customers As IEnumerable(Of Customer)) As XElement
    Return _
        <html>
            <head>
                <title><%= title %></title>
            </head>
            <body>
            <%= From customer In customers Select _
                <div id=<%= customer.LastName %>>
                    <h1><%= customer.FirstName %></h1>
                </div> %>
            </body>
        </html>
End Function

The important change from ASPX is that this is HTML in Code, rather than Code in HTML. As a result less "automagical" behaviour is required; It's just a function! This means AJAX features like "partial rendering", where a section of page needs to be updated, can be expressed by just calling a function that returns a <div> element. That same function can be used by the full HTML page function too.

ASPX "usercontrols" become simply functions as well. ASPX Master Pages are functions that have arguments for "placeholders" that get inserted into an template HTML page. Instead of having to reinvent a bunch of programming language concepts inside ASPX, we can just use a programming language that now support XML!

The only down side to this approach is we lose the IDE visual designer support. However, I find viewing an ASPX page that contains even simple conditional data rendering next to useless. I'd rather keep IE open and just refresh the page to see changes.

I am yet to embrace the MVC framework. I am waiting to see if the next release can better support Snooze framework ideas. However, there's no reason I can't use this VB XML magic in Snooze as it current is.

.net | html | thinking | vb.net | web | xml
Tuesday, February 19, 2008 12:12:17 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [0]  | 
# Thursday, January 10, 2008

I have released an initial version of Snooze. http://www.assembla.com/wiki/show/snooze

Snooze is an REST framework for ASP.NET. It puts the emphasis back on the "R" of URI. The Resource concept is a first-class citizen.

In Snooze you create a resource class that defines the URI template and HTTP methods it supports.

[HttpResource("customer/{CustomerId}")] // Defines the URI template for this resource
public class CustomerResource : HttpResource // A useful base class that implements IHttpResource
{
    // URI template variables are mapped to properties
    public int CustomerId { get; set; }

    // Handles the HTTP GET method
    public override void Get()
    {
        RenderView("Customer", Data.Customers[CustomerId]);
    }

    public override void Put()
    {
        // Read data sent in Request body and update the customer...
    }

    public override void Delete()
    {
        // Delete the customer...
    }

    // HTTP POST can also be provided if it makes sense for the resource.
}

This will mean a URI like "http://yourserver.com/customer/42" will invoke the Get method of an instance where CustomerId equals 42.

What about creating a new Customer?

Well you don't have an ID for the new customer since that is probably created in the database. Therefore you don't know what the URI will be yet. The correct solution here is to POST the new customer data to a CustomerList resource, with URI "/customers".

Alternative GET Views

You can create extra GET methods:

[HttpGetView("edit")]
public void GetEdit()
{
    RenderView("CustomerEdit", Data.Customers[CustomerId]);
}

This results in URIs like "/customer/42?edit"

File Extensions

To support different file formats, such as XML and JSON use:

[HttpGetFile(".xml")]
public void GetEdit()
{
    SendXml(Data.Customers[CustomerId]);
}

This will be mapped to by URIs like /customer/42.xml

Sub-Resources

Resources can be naturally nested. For example, a Customer may have Orders.

[HttpSubResource(typeof(CustomerResource), "order/{OrderId}", true)]
public class OrderResource : HttpSubResource<CustomerResource>
{
    public int OrderId { get; set; }
    // ...
}

In this sub-resource, you can have access the parent CustomerResource, using the strongly-typed, ParentResource property.

URIs for this sub-resource will look like: "/customer/42/order/123"

The "true" argument in the attribute, specifies that parent query string parameters are added to this sub-resource URI as well. So a parent with URI template "customer/{CustomerId}?foo={Foo}" will yield sub-resource URI template "/customer/{CustomerId}/order/{OrderId}?foo={Foo}".

Nullable Resource Properties

Imagine a blog posts resource. Its URI could be /posts/{Year}/{Month}/{Day} to get all the posts on a given date. Now what if you want to naturally get the posts for a whole month, year, or ever?

By declaring the properties as nullable, e.g. "int?" in C#, Snooze will also map the "reduced" URIs to your class. You can then test the properties for "null" and return data accordingly.

Reusing Resource URIs

When rendering an HTML view it is likely you will need to link to other resources. Instead of manually typing the URI string, you can call the Uri property available on HttpResource.

new CustomerResource { CustomerId = 42 } .Uri

Resource Areas

Snooze supports resource "areas". These let you map all the resources of a given assembly into a given sub-path. If, for example, a third-party blogging package was built using Snooze you could include it as follows:

web.config:

<configuration>
  <restAreas>
    <area path="" assembly="MyWebsiteAssembly"/>
    <area path="blog" assembly="SomeCompany.BlogEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
  </restAreas>

So the blog resource URIs would look something like: http://mysite.com/blog/posts/2007/01

HTML Form Support

HTML forms only support GET and POST. To overcome this limitation you can include: <input type="hidden" name="__method" value="DELETE" /> to override the name of the HTTP method used by Snooze.

Feedback

This project came mostly out of curiosity! I wanted to see if REST could be done better under ASP.NET. The code is still very new (less than two days!) It is open source (BSD license) and available via SubVersion. A quick sample project is also provided.

Let me know what you think. Everything is open to changes. Join the assembla project if you would like to contribute your help.

.net | c# | programming | REST | web
Thursday, January 10, 2008 9:42:04 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [1]  | 
# Monday, December 24, 2007

This is just a quick thought that came to me whilst making coffee this morning...

REST places focus on nouns (resources) in a system. Whereas it seems web services are more concerned with verbs. A service is a collection of operations. The data is passed to and from operations as messages.

Now both approaches have their merits. What strikes me as strange is our choice of programming languages when attempting to implement the aforementioned architectural styles. Object orientated programming is all about nouns (classes). Functional programming is all about verbs (functions).

I know that there is way more to web services than just a bunch of operations (because that would be simply RPC right?). However, my point is that surely OOP is ideally suited to describing a set of resources as required by a RESTful design.

Monday, December 24, 2007 9:44:48 AM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [2]  | 
# Sunday, December 23, 2007

I am yet to play with the new ASP.NET MVC framework. However, I am spending time reading around the area to see if it will benefit me to get more involved.

A concern that came to mind when researching is the claims of it enabling a RESTful approach to web programming. Whilst this may be true, all the examples so far seem contrary to REST. My limited understanding of REST says that URLs represent a Resource. How is http://www.mysite.com/customers/delete/42 a resource?!

Yet that is indeed the format of URL we are being shown by Scott Guthrie and others. It makes ASP.NET MVC look more like another RPC system, just with parameters encoded into the address instead of message body.

So is it possible to specify a resource URL and then a number of HTTP verbs that can execute against it? It probably is, given the extensibility of ASP.NET MVC's architecture. However, one may ask, should I be hacking this into the framework? Would the end result look anything like the original MVC code at all? Probably not!

Is it time for a real REST framework built on top of ASP.NET? I think it is!

It needs to be Resource centered. It needs to fully leverage the rich feature set of HTTP, not just GET and POST! And just to be awesome, it needs to have a client-side story too. Real REST relies on the client-side to store state. Could this be Silverlight, or do we still want JavaScript? (I'm up for cross compiling to JS from C# or MSIL!)

.net | programming | REST | ria | thinking | web
Sunday, December 23, 2007 4:02:00 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [5]  | 
# Friday, November 02, 2007

There is a lot of hype around Silverlight and WPF enabling true separation of developer and designer. This is certainly a great way to work. However, I don't think this is enabled only now by XAML. There is no reason the same cannot be achieved with HTML.

It seems like developers went so far down the server-side HTML generation route we left designers floundering with only CSS left in their toolkit. Whilst you can do some amazing things with CSS, sometimes you just need to change the HTML. If the HTML is riddled with <% %>, server controls or other template commands how is out poor designer going to work with the file?

My current attention is around using pure HTML and putting all dynamic content generation into JavaScript. The only thing to enforce on the HTML is that certain elements have known "id" attribute values.

html | programming | ria | thinking | web
Friday, November 02, 2007 4:42:04 PM (GMT Standard Time, UTC+00:00)  #    Disclaimer  |  Comments [3]  | 
# Wednesday, October 17, 2007

My latest screencast is online: Mobile Model in MVP web app

This screencast continues from the work I demonstrated in a previous screencast: http://channel9.msdn.com/Showpost.aspx?postid=344711
When implemented a Model-View-Presenter pattern client-side in JavaScript there is a need to get data from the server. Rather than make this divide explicit with HTTP request, etc, I have used the idea of a model object that moves between the client and server.
So the programmer simply writes the client and server pieces of functionality and lets my framework do the plumbing.
I use code generation and Script# to make writing a client-side web app much more seemless than the usual javascript/XML/JSON/web service madness.
I'm developing the ideas shown here in a project at the moment. If there is sufficient interest I may extract a framework to give to the community.
How do people feel about this approach to web development? What kinds of additions/modifications should be made?
p.s. I have a bit of a cold at the moment, so sorry for the croaky voice in the recording!

.net | c# | mvp | programming | ria | screencast | tier_split | web
Wednesday, October 17, 2007 9:32:19 PM (GMT Daylight Time, UTC+01:00)  #    Disclaimer  |  Comments [11]  |