Thoughts on Software by Andrew Davey
| | Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 | | 2 | 3 | 4 | 5 | 6 | 7 | 8 | | 9 | 10 | 11 | 12 | 13 | 14 | 15 | | 16 | 17 | 18 | 19 | 20 | 21 | 22 | | 23 | 24 | 25 | 26 | 27 | 28 | 29 | | 30 | 31 | 1 | 2 | 3 | 4 | 5 |
Search
Navigation
Categories
Blogroll
|

Sunday, December 23, 2007
REST Verbs in ASP.NET MVC
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!)
Sunday, December 23, 2007 4:02:00 PM (GMT Standard Time, UTC+00:00)
.net | programming | REST | ria | thinking | web

Sunday, November 04, 2007
C# Code Transformation Tool
I've made a custom Visual Studio tool that uses a C# parser
(http://www.codeplex.com/csparser/) to convert C# code into an XML
representation. So far only the declaration stuff, classes, method
signatures etc.
I then have a XSLT template engine that takes the XML and a template
file to generate content.
Templates look like:
<% for-each /namespace/class[attribute/@type='ServerModel'] %>
public class <%@name%>
{
}
<%/for-each%>
Easy stuff if you are happy with XSLT.
Currently I use it to generate proxies to classes in my Mobile MVP
library. There are lots of uses I imagine.
Are there any other similar tools out there? If not what are the
prefered places to release this? I took a look at CodePlex but the
TFS source control made me shudder. I'm much more at home with SVN...
Sunday, November 04, 2007 11:02:13 PM (GMT Standard Time, UTC+00:00)
.net | c# | programming | thinking

Friday, November 02, 2007
Separating design and code with HTML and JavaScript
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.
Friday, November 02, 2007 4:42:04 PM (GMT Standard Time, UTC+00:00)
html | programming | ria | thinking | web

Wednesday, October 17, 2007
Mobile Model Screencast
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!
Wednesday, October 17, 2007 8:32:19 PM (GMT Standard Time, UTC+00:00)
.net | c# | mvp | programming | ria | screencast | tier_split | web

Tuesday, October 02, 2007
ToJavaScript Extension Method
Has anyone looked into an extension method on the .NET 3.5 Expression class that returns a JavaScript method? This could then be sent to the client web browser.
So you could then write validation logic in C# and run it in the browser as JavaScript!
Tuesday, October 02, 2007 8:39:56 AM (GMT Standard Time, UTC+00:00)
.net | c# | linq | thinking

Sunday, September 30, 2007
Thoughts on client-server communication for the Model in MVP
I am thinking about my client-side MVP pattern and how best to communicate with the server. The current issue is how explicit to make the client/server divide. There are ways to make it feel like the Model is one consistent class, with tools doing all the marshalling to the server, invocation and return. This papering over of the "cracks" may however bite me in the ass at a later date. I reckon that adding the required flexibility to enable tweaking will just end up making the divide explicit again - rendering the exercise pointless.
So the alternative is to write the model with only client-side code. The server-side logic will then be in a service class somewhere. A benefit here is that the developer is free to choose the service style (SOAP, REST, etc).
I still want to avoid writing the client-side model proxy class that calls to the server. A tool is needed to take a service description and create a proxy class. In the context of a JavaScript model object, we need the proxy to be making XML HTTP requests.
I would like to use WCF to create the service. This is a good overview of getting WCF to talk JSON. If I enable meta-data transfer on the service, writing a tool to read this and create a proxy class should be simple.
Sunday, September 30, 2007 9:02:14 AM (GMT Standard Time, UTC+00:00)
.net | mvp | thinking | tier_split

Saturday, September 29, 2007

Thursday, September 27, 2007
Lazy Functions in LINQ
Imagine we have a set of complex expressions. A subset of these need to be evaluated at runtime, depending on some state external to the program (e.g. user input). If these subsets are not distinct from each other then the code will likely become messy and unstructured.
What we would like to so is define all the expressions first and then pick and choose those required. This would of course involve evaluating all of the them. This wasteful of time if only a few are required.
Enter lazy evaluation! From my rather limited exposure to Haskell, I hear that lazy evaluation is all the rage. :)
Using lambdas in C# 3.0 we can create code like this:
long x = 42;
var lx = Lazy.Eval(() => x * x * x * x * x * x);
if (some_boolean_expression)
{
UseNumber(lx);
}
where UseNumber is some function that takes a "long" as input.
Now this example is over-simplified, but it shows the mechanics. We use a call to Lazy.Eval to return a wrapper around the lambda. So at that point we have not calculated the expensive expression. Later in the program the variable "lx" is used. lx is of type Lazy<long> and there exists an implicit cast from Lazy<long> to long. At this point the original expression is evaluated and saved by the lazy wrapper. So next time the value is required the cached value is returned.
Here is the Lazy<T> class:
public class Lazy<T>
{
bool _gotValue;
T _value;
Func<T> _expr;
public Lazy(Func<T> expr)
{
_expr = expr;
}
public T Value
{
get
{
if (!_gotValue)
{
_value = _expr();
_gotValue = true;
}
return _value;
}
}
public static implicit operator T(Lazy<T> l)
{
return l.Value;
}
}
And to allow the C# 3.0 compiler to infer types for us, we use a separate Lazy class:
public class Lazy
{
public static Lazy<T> Eval<T>(Func<T> expr)
{
return new Lazy<T>(expr);
}
}
Whilst lazy evaluation may not be useful in everyday programming, this example does show some of what can be achieved with lambdas in C# 3.0.
Thursday, September 27, 2007 10:56:51 AM (GMT Standard Time, UTC+00:00)
.net | c# | linq | programming