Tales from the Evil Empire : ASP.NET

Testing Orchard drivers

Bertrand Le Roy — Mon, 15 Apr 2013 19:51:31 GMT

If you’ve ever tried to test Orchard part drivers, you may have been blocked by the fact that the methods on drivers are protected. That, fortunately, doesn’t mean they are untestable. Those methods are still accessible through explicit interface implementations. In particular, drivers implement IContentPartDriver, which is defined as follows.

public interface IContentPartDriver : IDependency {
    DriverResult BuildDisplay(BuildDisplayContext context);
    DriverResult BuildEditor(BuildEditorContext context);
    DriverResult UpdateEditor(UpdateEditorContext context);
    void Importing(ImportContentContext context);
    void Imported(ImportContentContext context);
    void Exporting(ExportContentContext context);
    void Exported(ExportContentContext context);
    IEnumerable<ContentPartInfo> GetPartInfo();
    void GetContentItemMetadata(GetContentItemMetadataContext context);
}

By casting your driver to this interface, you get public access to these methods.

For example, here is some code I wrote recently to test the import and export methods of a driver:

[Test]
public void ImportGetAllDefinedProperties() {
    var doc = XElement.Parse(@"
<data>
<UspsShippingMethodPart
    Name=""Foo""
    Size=""L""
    WidthInInches=""10""
    LengthInInches=""11""
    HeightInInches=""12""
    MaximumWeightInOunces=""1.3""
    Priority=""14""
    International=""true""
    RegisteredMail=""true""
    Insurance=""false""
    ReturnReceipt=""true""
    CertificateOfMailing=""true""
    ElectronicConfirmation=""true""/>
</data>
");
    var driver = new UspsShippingMethodPartDriver(null)
        as IContentPartDriver;
    var part = new UspsShippingMethodPart();
    Helpers.PreparePart<UspsShippingMethodPart, UspsShippingMethodPartRecord>(
        part, "UspsShippingMethod");
    var context = new ImportContentContext(
        part.ContentItem, doc, new ImportContentSession(null));
    driver.Importing(context);

    Assert.That(part.Name, Is.EqualTo("Foo"));
    Assert.That(part.Size, Is.EqualTo("L"));
    Assert.That(part.WidthInInches, Is.EqualTo(10));
    Assert.That(part.LengthInInches, Is.EqualTo(11));
    Assert.That(part.HeightInInches, Is.EqualTo(12));
    Assert.That(part.MaximumWeightInOunces, Is.EqualTo(1.3));
    Assert.That(part.Priority, Is.EqualTo(14));
    Assert.That(part.International, Is.True);
    Assert.That(part.RegisteredMail, Is.True);
    Assert.That(part.Insurance, Is.False);
    Assert.That(part.ReturnReceipt, Is.True);
    Assert.That(part.CertificateOfMailing, Is.True);
    Assert.That(part.ElectronicConfirmation, Is.True);
}

[Test]
public void ExportSetsAllAttributes() {
    var driver = new UspsShippingMethodPartDriver(null)
        as IContentPartDriver;
    var part = new UspsShippingMethodPart();
    Helpers.PreparePart<UspsShippingMethodPart, UspsShippingMethodPartRecord>(
        part, "UspsShippingMethod");
    part.Name = "Foo";
    part.Size = "L";
    part.WidthInInches = 10;
    part.LengthInInches = 11;
    part.HeightInInches = 12;
    part.MaximumWeightInOunces = 1.3;
    part.Priority = 14;
    part.International = true;
    part.RegisteredMail = true;
    part.Insurance = false;
    part.ReturnReceipt = true;
    part.CertificateOfMailing = true;
    part.ElectronicConfirmation = true;

    var doc = new XElement("data");
    var context = new ExportContentContext(part.ContentItem, doc);
    driver.Exporting(context);
    var el = doc.Element("UspsShippingMethodPart");

    Assert.That(el, Is.Not.Null);
    Assert.That(el.Attr("Name"), Is.EqualTo("Foo"));
    Assert.That(el.Attr("Size"), Is.EqualTo("L"));
    Assert.That(el.Attr("WidthInInches"), Is.EqualTo("10"));
    Assert.That(el.Attr("LengthInInches"), Is.EqualTo("11"));
    Assert.That(el.Attr("HeightInInches"), Is.EqualTo("12"));
    Assert.That(el.Attr("MaximumWeightInOunces"), Is.EqualTo("1.3"));
    Assert.That(el.Attr("Priority"), Is.EqualTo("14"));
    Assert.That(el.Attr("International"), Is.EqualTo("true"));
    Assert.That(el.Attr("RegisteredMail"), Is.EqualTo("true"));
    Assert.That(el.Attr("Insurance"), Is.EqualTo("false"));
    Assert.That(el.Attr("ReturnReceipt"), Is.EqualTo("true"));
    Assert.That(el.Attr("CertificateOfMailing"), Is.EqualTo("true"));
    Assert.That(el.Attr("ElectronicConfirmation"), Is.EqualTo("true"));
}

The Attr method, in case you're wondering, is an extension method I blogged about yesterday.

The Helper class that I’m using here massages a fake part to behave like a real part. It gives the part a fake record, and adds a fake content item around it. It might not be enough in all situations, but it does make the fake convincing enough in this case.

public static ContentItem PreparePart<TPart, TRecord>(
    TPart part, string contentType, int id = -1)
    where TPart: ContentPart<TRecord>
    where TRecord: ContentPartRecord, new() {

    part.Record = new TRecord();
    var contentItem = part.ContentItem = new ContentItem
    {
        VersionRecord = new ContentItemVersionRecord
        {
            ContentItemRecord = new ContentItemRecord()
        },
        ContentType = contentType
    };
    contentItem.Record.Id = id;
    contentItem.Weld(part);
    return contentItem;
}

Logging SQL queries in Orchard

Bertrand Le Roy — Thu, 04 Apr 2013 02:02:00 GMT

It is often useful to see what database queries were made during a specific request in Orchard. There are quite a few ways to do this (you can trace right from SQL Server, or you can use Mini-Profiler for instance), but this morning Sébastien showed me a really easy one that I thought I’d share.

Find the log4net.config file in /src/Orchard.Web/Config and edit it to add the following tag:

<logger name="NHibernate.SQL">
  <priority value="DEBUG" />
</logger>

Restart the application, then hit the URL you want to test, and look at your logs in App_data/logs. You should see new entries looking like this:

2013-04-03 18:57:30,367 [17] NHibernate.SQL -
  SELECT warmupsett0_.Id as Id575_0_,
         warmupsett0_.Urls as Urls575_0_,
         warmupsett0_.Scheduled as Scheduled575_0_,
         warmupsett0_.Delay as Delay575_0_,
         warmupsett0_.OnPublish as OnPublish575_0_
  FROM VuLu_Orchard_Warmup_WarmupSettingsPartRecord warmupsett0_
  WHERE warmupsett0_.Id=@p0;

  @p0 = 1 [Type: Int32 (0)]

(only not as nicely formatted)

To disable the SQL trace, just edit log4net.config and set the value to ERROR instead of DEBUG.

This is how we should read hexadecimal…

Bertrand Le Roy — Fri, 22 Mar 2013 05:04:00 GMT

Today my five-year-old told me that when she was four, she thought that what came after ninety-nine was… tenty. You know, because seventy, eighty, ninety, tenty.

At first I thought it was just funny and charming, but then I realized it was actually a really good idea. Tenty is only nonsensical if you’re counting in base ten (or lower), but it makes total sense for higher bases.

How do people usually read 0xA0? “A-zero”? How unimaginative! Let’s read that “tenty” from now on!

Here are some more examples of how to read hexadecimal in a non-boring way:

0xB3 is eleventy-three
0xCA is twelvety-ten
0xD9 is thirteenty-nine
0xEC is fourteenty-twelve
0xFF is fifteenty-fifteen
0xF04A is fifteen hexathousand forty-ten
0x4B2AC0AA is forty-eleven hexamillion, two hexahundred tenty-twelve hexathousand tenty-ten
and of course, seven-eleven will have to change their logo to 0x7B.

Is this the greatest thing or what?

Taking an Orchard site offline while you update it

Bertrand Le Roy — Tue, 12 Mar 2013 18:52:28 GMT

If your hosted environment does not give you a staging site and the means to swap it easily with the production environment like Azure Cloud Services do, or if you don’t have a staging database, or if you just need to take your site offline for the public while you perform data updates in the admin, you may be wondering what solutions you have, if any.

IIS has an app_offline.htm feature that you can use, that will serve a static page for all requests but that’s rather brutal as it does not just take the site offline for your users, it also does so for you. While that file exists, you can do absolutely nothing with your site. You cannot access the admin, you cannot preview your changes, nothing. So when you flip the switch back, it’s anyone’s guess whether the changes you blindly made actually work, even if they did on your machine…

We need a better solution. Well, I happen to have one...

All you have to do is create a new theme named “Offline” with just one /Views/Layout.cshtml file containing a message along the lines of “We are updating the site. We apologize for the inconvenience. Please come back in a few minutes.” You can add stylesheets to make it pretty if you want to. It’s a full theme, you can go crazy.

The important thing is that this theme has one layout, and that this layout does nothing but display its message. It has no zones, so no dynamic content is going to be served to the public from the site no matter what URL is hit.

Once you have made this theme current, all your visitors are seeing it, but you can still access the admin of the site and do whatever you want.

Better, you can use the “Theme Preview” feature of Orchard to check what your changes look like while your users continue to see the “offline” page. Just go to Themes, and click Preview on your regular theme…

Once you are satisfied with your changes and judge the site to be ready to be taken back online, just restore your theme as the current. The “Offline” theme can sit there and do nothing until the next time you need it.

I’ve used this technique successfully last time I updated an Orchard site. It worked great. I hope it helps others…

Dead simple stubbing for JavaScript

Bertrand Le Roy — Fri, 08 Mar 2013 18:29:00 GMT

I’m writing a lot of JavaScript these days, and for testing I mostly use QUnit. When I need to quickly stub a piece of the code that I’m testing, I like to use the following micro-library. What it does is enable you to replace a bunch of methods on an object with stub versions, in a easily reversible way.

I use RequireJS, but if you don’t, just remove the define and outer function.

define(function() {
    var stub = function(obj, stubs) {
        obj._stubbed = obj._stubbed || {};
        for (var name in stubs) {
            obj._stubbed[name] = obj[name];
            obj[name] = stubs[name];
        }
    };
    stub.restore = function(obj) {
        if (!obj || !obj._stubbed) return;
        for (var name in obj._stubbed) {
            obj[name] = obj._stubbed[name];
        }
        delete obj._stubbed;
    };
    return stub;
});

Here is how you would replace two methods bar and baz on an object foo:

stub(foo, {
    bar: function() {
        return "stubbed bar";
    },
    baz: function(glop) {
        return "stubbed baz " + glop;
    }
});

And here is how you can put everything back in place once you’re done:

stub.restore(foo);

I hope this helps...

Always have a host or URL prefix on the default Orchard tenant

Bertrand Le Roy — Mon, 25 Feb 2013 01:54:00 GMT

The multi-tenancy feature in Orchard enables you to host multiple sites within the same Orchard instance. It’s not a a security feature, just a way to improve site density, and to enable you to save on hosting costs. Nevertheless, a request to a specific existing tenant should never be answered with a page from another tenant. Ever.

There is however a fallback mechanism that enables one tenant to handle all requests that weren’t identified by another tenant. While this could be considered useful in some scenarios, I’m hereby declaring it bad practice.

If for any reason a tenant fails to start, for example, requests to that tenant are going to fall back. Even if you were in a scenario where you considered fallback to be useful, this is an unexpected and positively undesirable result. It’s much better to fail with an error message or a 404 than to fail with a fallback to a different site than the one the client asked for.

So here is my recommendation:

Always have a host or URL prefix configured on all tenants, in particular the default tenant.

This way, no fallback will ever happen, and requests will only be handled by a tenant that recognizes its own host name.

Here is, for example, the new configuration of the default tenant on my hosted web sites:

Note that I have multiple hosts configured here, including the host that I use on my dev machine for local development, but the point here is to specify something on all tenants.

This is important.

Easy content templates for Orchard, take 2

Bertrand Le Roy — Thu, 14 Feb 2013 00:21:00 GMT

Placement.info is an XML file that orchestrates the different parts of a content item and sends each of the shapes they create into specific local content zones. If the previous sentence sounded confusing to you, fear not, this post is for you.

When writing an Orchard theme, more often than not, you know exactly what parts exist in your content type, and you know where you want them to render. Placement can be extremely powerful, but it’s rather abstract and it reverses the usual logic of placing contents on a page. What most people really want to do is write a template with simple markup and placeholders inside that markup for the rendering of specific parts such as title, summary, tags, etc. Placement forces you to dispatch those part shapes from a completely separate file.

In the Summer of 2011, I wrote a little article to explain how to write custom templates for specific content types in Orchard, without using placement.info:

So you don’t want to use placement.info?

The solution worked, but relied on a hack that will break with the next version of Orchard (1.7).

Sébastien Ros gave me a little trick the other day that enables the same thing, in a simpler, less hacky form. It still uses placement somewhat, but in a very simple way.

The idea is to create one local zone per part instead of the usual header, content and footer zones. Here we are going to send the relevant shapes to those zones through placement:

<Match ContentType="BlogPost">
  <Match DisplayType="Summary">
    <Place Parts_Common_Body_Summary="Summary:0"
           Parts_Tags_ShowTags="Tags:0"
           Parts_Common_Metadata_Summary="MetadataSummary:0"
           Parts_Comments_Count="CommentsCount:0" />
  </Match>
</Match>

This sends shapes into Summary, Tags, MetadataSummary and CommentsCount zones. Those do not yet exist.

Caveat: when naming your custom zones, be careful not to collide with existing properties or zones on the Model, lest you end up with unexpected and confusing results. Using longish and very explicit names usually works well for that.

The template can now simply create and render those zones. Here is my Content-BlogPost.Summary.cshtml template:

@using Orchard.ContentManagement
@{
    var blogPost = Model.ContentItem;
}
<article class="content-item blog-post">
    <header><h1><a href="@Url.ItemDisplayUrl((IContent)blogPost)">
      @blogPost.TitlePart.Title
    </a></h1></header>
    @Display(Model.Summary)
    <footer>
    @Display(Model.Tags)
    @Display(Model.MetadataSummary)
    @Display(Model.CommentsCount)
    </footer>
</article>

Notice how in the case of the title, I’m not even using the shape given by the part, but I’m accessing the properties directly on the TitlePart. The other parts are rendered through the special zone that we created using the Display function. And that is all. You can now focus on building your template, and it will be pretty obvious what will render where…

Creating simple custom Orchard widgets

Bertrand Le Roy — Wed, 06 Feb 2013 06:21:27 GMT

If you want to create a simple widget in Orchard, such as a box of social links, you have three possibilities:

Find a module on the gallery or write one yourself, but there is overhead associated with modules, which may make this overkill.
Use an HTML widget and paste a bunch of HTML and Javascript, hoping administrators of the site don’t break it accidentally. I don’t like this, it feels like a hack.
Create a simple widget, following the instructions in this post.

First, let’s create a content type (in the admin, go to Content / Content Types and click “Create new type”) and call it “Social Links”.

Add the widget and identity parts. Those are the only ones you really need:

Uncheck creatable and draftable, add the “Widget” stereotype (with an upper-case ‘W’: I made the mistake, as you can see, of using a lower-case ‘w’ on my first try, and it did prevent the widget from being seen as such):

Now when you add a widget, the social links widget appears in the list:

It’s a simple, apparently featureless widget, which minimizes the chances of accidentally messing it up.

All that’s left to do now is to add a template to the theme that will render what we want. We’ll take advantage of shape alternates. Using shape tracing, we quickly discover that we can name our template Widget-SocialLinks.cshtml to target it narrowly enough:

Once the file has been added to the Views folder of my theme, I can paste in the code from Facebook, Twitter, or whatever else I want in there.

Done. Fastest and simplest way to create a new widget.

Writing an unthemed view while still using Orchard shapes and helpers

Bertrand Le Roy — Sat, 20 Oct 2012 21:16:00 GMT

This quick tip will show how you can write a custom view for a custom controller action in Orchard that does not use the current theme, but that still retains the ability to use shapes, as well as zones, Script and Style helpers.

The controller action, first, needs to opt out of theming:

[Themed(false)]
public ActionResult Index() {}

Then, we still want to use a shape as the view model, because Clay is so awesome:

private readonly dynamic _shapeFactory;

public MyController(IShapeFactory shapeFactory) {
    _shapeFactory = shapeFactory;
}

[Themed(false)]
public ActionResult Index() {
    return View(_shapeFactory.MyShapeName(
        Foo: 42,
        Bar: "baz"
        ));
}

As you can see, we injected a shape factory, and that enables us to build our shape from our action and inject that into the view as the model.

Finally, in the view (that would in Views/MyController/Index.cshtml here), just use helpers as usual. The only gotcha is that you need to use “Layout” in order to declare zones, and that two of those zones, Head and Tail, are mandatory for the top and bottom scripts and stylesheets to be injected properly. Names are important here.

@{
    Style.Include("somestylesheet.css");
    Script.Require("jQuery");
    Script.Include("somescript.js");
    using(Script.Foot()) {
        <script type="text/javascript">
            $(function () {
                // Do stuff
            })
        </script>
    }
}
<!DOCTYPE html>
<html>
    <head>
        <title>My unthemed page</title>
        @Display(Layout.Head)
    </head>
    <body>
        <h1>My unthemed page</h1>
        <div>@Model.Foo is the answer.</div>
    </body>
    @Display(Layout.Tail)
</html>

Note that if you define your own zones using @Display(Layout.SomeZone) in your view, you can perfectly well send additional shapes to them from your controller action, if you injected an instance of IWorkContextAccessor:

_workContextAccessor.GetContext().Layout
    .SomeZone.Add(_shapeFactory.SomeOtherShape());

Of course, you’ll need to write a SomeOtherShape.cshtml template for that shape but I think this is pretty neat.

TypeScript first impressions

Bertrand Le Roy — Mon, 01 Oct 2012 20:51:00 GMT

Anders published a video of his new project today, which aims at creating a superset of JavaScript, that compiles down to regular current JavaScript. Anders is a tremendously clever guy, and it always shows in his work. There is much to like in the enterprise (good code completion, refactoring and adoption of the module pattern instead of namespaces to name three), but a few things made me rise an eyebrow.

First, there is no mention of CoffeeScript or Dart, but he does talk briefly about Script# and GWT. This is probably because the target audience seems to be the same as the audience for the latter two, i.e. developers who are more comfortable with statically-typed languages such as C# and Java than dynamic languages such as JavaScript. I don’t think he’s aiming at JavaScript developers. Classes and interfaces, although well executed, are not especially appealing.

Second, as any code generation tool (and this is true of CoffeeScript as well), you’d better like the generated code. I didn’t, unfortunately. The code that I saw is not the code I would have written. What’s more, I didn’t always find the TypeScript code especially more expressive than what it gets compiled to.

I also have a few questions.

Is it possible to duck-type interfaces? For example, if I have an IPoint2D interface with x and y coordinates, can I pass any object that has x and y into a function that expects IPoint2D or do I need to necessarily create a class that implements that interface, and new up an instance that explicitly declares its contract? The appeal of dynamic languages is the ability to make objects as you go. This needs to be kept intact.

UPDATE: this works.

More technical: why are generated variables and functions prefixed with _ rather than the $ that the EcmaScript spec recommends for machine-generated variables?

In conclusion, while this is a good contribution to the set of ideas around JavaScript evolution, I don’t expect a lot of adoption outside of the devoted Microsoft developers, but maybe some influence on the language itself. But I’m often wrong. I would certainly not use it because I disagree with the central motivation for doing this: Anders explicitly says he built this because “writing application-scale JavaScript is hard”. I would restate that “writing application-scale JavaScript is hard for people who are used to statically-typed languages”. The community has built a set of good practices over the last few years that do scale quite well, and many people are successfully developing and maintaining impressive applications directly in JavaScript.

You can play with TypeScript here: http://www.typescriptlang.org

Namespaces are obsolete

Bertrand Le Roy — Mon, 03 Sep 2012 21:42:00 GMT

To those of us who have been around for a while, namespaces have been part of the landscape. One could even say that they have been defining the large-scale features of the landscape in question.

However, something happened fairly recently that I think makes this venerable structure obsolete. Before I explain this development and why it’s a superior concept to namespaces, let me recapitulate what namespaces are and why they’ve been so good to us over the years…

Namespaces are used for a few different things:

Scope: a namespace delimits the portion of code where a name (for a class, sub-namespace, etc.) has the specified meaning. Namespaces are usually the highest-level scoping structures in a software package.
Collision prevention: name collisions are a universal problem. Some systems, such as jQuery, wave it away, but the problem remains. Namespaces provide a reasonable approach to global uniqueness (and in some implementations such as XML, enforce it). In .NET, there are ways to relocate a namespace to avoid those rare collision cases.
Hierarchy: programmers like neat little boxes, and especially boxes within boxes within boxes. For some reason. Regular human beings on the other hand, tend to think linearly, which is why the Windows explorer for example has tried in a few different ways to flatten the file system hierarchy for the user.

1 is clearly useful because we need to protect our code from bleeding effects from the rest of the application (and vice versa). A language with only global constructs may be what some of us started programming on, but it’s not desirable in any way today.

2 may not be always reasonably worth the trouble (jQuery is doing fine with its global plug-in namespace), but we still need it in many cases. One should note however that globally unique names are not the only possible implementation. In fact, they are a rather extreme solution. What we really care about is collision prevention within our application. What happens outside is irrelevant.

3 is, more than anything, an aesthetical choice. A common convention has been to encode the whole pedigree of the code into the namespace. Come to think about it, we never think we need to import “Microsoft.SqlServer.Management.Smo.Agent” and that would be very hard to remember. What we want to do is bring nHibernate into our app.

And this is precisely what you’ll do with modern package managers and module loaders. I want to take the specific example of RequireJS, which is commonly used with Node.

Here is how you import a module with RequireJS:

var http = require("http");

This is of course importing a HTTP stack module into the code. There is no noise here. Let’s break this down.

Scope (1) is provided by the one scoping mechanism in JavaScript: the closure surrounding the module’s code. Whatever scoping mechanism is provided by the language would be fine here.

Collision prevention (2) is very elegantly handled. Whereas relocating is an afterthought, and an exceptional measure with namespaces, it is here on the frontline. You always relocate, using an extremely familiar pattern: variable assignment. We are very much used to managing our local variable names and any possible collision will get solved very easily by picking a different name.

Wait a minute, I hear some of you say. This is only taking care of collisions on the client-side, on the left of that assignment. What if I have two libraries with the name “http”? Well, You can better qualify the path to the module, which is what the require parameter really is.

As for hierarchical organization, you don’t really want that, do you?

RequireJS’ module pattern does elegantly cover the bases that namespaces used to cover, but it also promotes additional good practices.

First, it promotes usage of self-contained, single responsibility units of code through the closure-based, stricter scoping mechanism. Namespaces are somewhat more porous, as using/import statements can be used bi-directionally, which leads us to my second point…

Sane dependency graphs are easier to achieve and sustain with such a structure. With namespaces, it is easy to construct dependency cycles (that’s bad, mmkay?). With this pattern, the equivalent would be to build mega-components, which are an easier problem to spot than a decay into inter-dependent namespaces, for which you need specialized tools.

I really like this pattern very much, and I would like to see more environments implement it. One could argue that dependency injection has some commonalities with this for example. What do you think? This is the half-baked result of some morning shower reflections, and I’d love to read your thoughts about it. What am I missing?

A quick guide to the built-in Orchard modules

Bertrand Le Roy — Mon, 16 Jul 2012 11:35:05 GMT

With the imminent release of Orchard 1.5, the number of built-in modules in the default distribution is getting quite impressive, if not intimidating. Now may be a good time to give new and old users a tour of what comes out of the box. Who knows, we may discover a hidden nugget or two along the way…

I just finished writing a massive documentation topic that describes all Orchard features that come with the source code and WebPI distributions:

All built-in Orchard modules described

I added the guide to the official Orchard documentation site. It details what modules come in the default package, which are only available from the source code package or from the gallery, and also mentions which are enabled by default.

Documentation, like everything in Orchard, is open source, so you can contribute to this topic and others: Edit this topic.

I hope this helps.

My Body Summary template for Orchard

Bertrand Le Roy — Mon, 02 Jul 2012 02:25:00 GMT

By default, when Orchard displays a content item such as a blog post in a list, it uses a very basic summary template that removes all markup and then extracts the first 200 characters. Removing the markup has the unfortunate effect of removing all styles and images, in particular the image I like to add to the beginning of my posts.

Fortunately, overriding templates in Orchard is a piece of cake. Here is the Common.Body.Summary.cshtml file that I drop into the Views/Parts folder of pretty much all Orchard themes I build:

@{ 
    Orchard.ContentManagement.ContentItem contentItem =
        Model.ContentPart.ContentItem;
    var bodyHtml = Model.Html.ToString();
    var more = bodyHtml.IndexOf("<!--more-->");
    if (more != -1) {
        bodyHtml = bodyHtml.Substring(0, more);
    }
    else {
        var firstP = bodyHtml.IndexOf("<p>");
        var firstSlashP = bodyHtml.IndexOf("</p>");
        if (firstP >=0 && firstSlashP > firstP) {
            bodyHtml = bodyHtml.Substring(firstP, firstSlashP + 4 - firstP);
        }
    }
    var body = new HtmlString(bodyHtml); 
}
<p>@body</p>
<p>@Html.ItemDisplayLink(T("Read more...").ToString(), contentItem)</p>

This template does not remove any tags, but instead looks for an HTML comment delimiting the end of the post’s intro:

<!--more-->

This is the same convention that is being used in WordPress, and it’s easy to add from the source view in TinyMCE or Live Writer.

If such a comment is not found, the template will extract the first paragraph (delimited by <p> and </p> tags) as the summary.

And if it finds neither, it will use the whole post.

The template also adds a localizable link to the full post.

Code is not the best way to draw

Bertrand Le Roy — Sat, 23 Jun 2012 00:26:00 GMT

It should be quite obvious: drawing requires constant visual feedback. Why is it then that we still draw with code in so many situations? Of course it’s because the low-level APIs always come first, and design tools are built after and on top of those. Existing design tools also don’t typically include complex UI elements such as buttons.

When we launched our Touch Display module for Netduino Go!, we naturally built APIs that made it easy to draw on the screen from code, but very soon, we felt the limitations and tedium of drawing in code. In particular, any modification requires a modification of the code, followed by compilation and deployment. When trying to set-up buttons at pixel precision, the process is not optimal.

On the other hand, code is irreplaceable as a way to automate repetitive tasks. While tools like Illustrator have ways to repeat graphical elements, they do so in a way that is a little alien and counter-intuitive to my developer mind. From these reflections, I knew that I wanted a design tool that would be structurally code-centric but that would still enable immediate feedback and mouse adjustments.

While thinking about the best way to achieve this goal, I saw this fantastic video by Bret Victor:

The key to the magic in all these demos is permanent execution of the code being edited. Whenever a parameter is being modified, everything is re-executed immediately so that the impact of the modification is instantaneously visible. If you do this all the time, the code and the result of its execution fuse in the mind of the user into dual representations of a single object. All mental barriers disappear. It’s like magic.

The tool I built, Nutshell, is just another implementation of this principle. It manipulates a list of graphical operations on the screen. Each operation has a nice editor, and translates into a bit of code. Any modification to the parameters of the operation will modify the bit of generated code and trigger a re-execution of the whole program. This happens so fast that it feels like the drawing reacts instantaneously to all changes.

The order of the operations is also the order in which the code gets executed. So if you want to bring objects to the front, move them down in the list, and up if you want to move them to the back:

But where it gets really fun is when you start applying code constructs such as loops to the design tool. The elements that you put inside of a loop can use the loop counter in expressions, enabling crazy scenarios while retaining the real-time edition features.

When you’re done building, you can just deploy the code to the device and see it run in its native environment:

This works thanks to two code generators. The first code generator is building JavaScript that is executed in the browser to build the canvas view in the web page hosting the tool. The second code generator is building the C# code that will run on the Netduino Go! microcontroller and that will drive the display module.

The possibilities are fascinating, even if you don’t care about driving small touch screens from microcontrollers: it is now possible, within a reasonable budget, to build specialized design tools for very vertical applications. Direct feedback is a powerful ally in many domains. Code generation driven by visual designers has become more approachable than ever thanks to extraordinary JavaScript libraries and to the powerful development platform that modern browsers provide.

I encourage you to tinker with Nutshell and let it open your eyes to new possibilities that you may not have considered before. It’s open source. And of course, my company, Nwazet, can help you develop your own custom browser-based direct feedback design tools. This is real visual programming…

Azure Web Sites FTP credentials

Bertrand Le Roy — Tue, 12 Jun 2012 19:34:00 GMT

A quick tip for all you new enthusiastic users of the amazing new Azure. I struggled for a few minutes finding this, so I thought I’d share. The Azure dashboard doesn’t seem to give easy access to your FTP credentials, and they are not the login and password you use everywhere else. What Azure does give you though is a Publish Profile that you can download:

This is a plain XML file that should look something like this:

<publishData>
  <publishProfile
    profileName="nameofyoursite - Web Deploy"
    publishMethod="MSDeploy"
    publishUrl="waws-prod-blu-001.publish.azurewebsites.windows.net:443"
    msdeploySite="nameofyoursite"
    userName="$NameOfYourSite"
    userPWD="sOmeCrYPTicL00kIngStr1nG"
    destinationAppUrl="http://nameofyoursite.azurewebsites.net"
    SQLServerDBConnectionString=""
    mySQLDBConnectionString=""
    hostingProviderForumLink=""
    controlPanelLink="http://windows.azure.com">
    <databases/>
  </publishProfile>
  <publishProfile
    profileName="nameofyoursite - FTP"
    publishMethod="FTP"
    publishUrl="ftp://waws-prod-blu-001.ftp.azurewebsites.windows.net/site/wwwroot"
    ftpPassiveMode="True"
    userName="nameofyoursite\$nameofyoursite"
    userPWD="sOmeCrYPTicL00kIngStr1nG"
    destinationAppUrl="http://nameofyoursite.azurewebsites.net"
    SQLServerDBConnectionString=""
    mySQLDBConnectionString=""
    hostingProviderForumLink=""
    controlPanelLink="http://windows.azure.com">
    <databases/>
  </publishProfile>
</publishData>

I’ve highlighted the FTP server name, user name and password. This is what you need to use in Filezilla or whatever you use to access your site remotely. Notice how the password looks encrypted. Well, it’s not really encrypted in fact. This is your password in clear text. It’s just crypto-random gibberish, which is the best kind of password.

UPDATE: About 2 minutes after I posted that, David Ebbo mentioned to me on Twitter that if you've configured publishing credentials (for Git typically) those will work too. Don't forget to include the full user name though, which should be of the form nameofthesite\username. The password is the one you defined.

That’s it. Enjoy.