Contents tagged with Extensibility

  • ASP.NET Web Forms Extensibility: Page Parser Filters

    Introduction

    ASP.NET includes a valuable yet not well known extension point called the page parser filter. I once briefly talked about it in the context of SharePoint, but I feel a more detailed explanation is in order.

    A page parser filter is a class with a public parameterless constructor that inherits from PageParserFilter and is registered on the Web.config file, in the pages section, pageParserFilterType attribute. It is called when ASP.NET is compiling a page, the first time it is called, for every page. There can be only one page parser filter per web application.

    Parser

    Why is it a parser? Well, it parses – or, better, receives a notification for - every control declared on the markup of a page (those with runat=”server” or contained inside of), as well as all of the page’s directives (<%@ … %>). The control declarations include all of its attributes and properties, the recognized control type and any complex properties that the markup contains. This allows us to do all kinds of crazy stuff:

    • Inspect, add and remove page directives;
    • Setting the page’s compilation mode;
    • Insert or remove controls or text literals dynamically at specific places;
    • Add/change/remove a control’s properties or attributes;
    • Even (with some reflection magic) change a control’s type or tag.


    So, how do we all this? First, the parser part. We can inspect all page directives by overriding the PreprocessDirective method. This is called for all page directives:

       1: public override void PreprocessDirective(String directiveName, IDictionary attributes)
       2: {
       3:     if (directiveName == "page")
       4:     {
       5:         //make a page asynchronous
       6:         attributes["async"] = "true";
       7:     }
       8:  
       9:     base.PreprocessDirective(directiveName, attributes);
      10: }

    The page’s compilation mode is controlled by GetCompilationMode:

       1: public override CompilationMode GetCompilationMode(CompilationMode current)
       2: {
       3:     return (base.GetCompilationMode(current));
       4: }

    As for adding controls dynamically, we make use of the ParseComplete method:

       1: public override void ParseComplete(ControlBuilder rootBuilder)
       2: {
       3:     if (rootBuilder is FileLevelPageControlBuilder)
       4:     {
       5:         this.ProcessControlBuilder(rootBuilder);
       6:     }
       7:  
       8:     base.ParseComplete(rootBuilder);
       9: }
      10:  
      11: private void ProcessControlBuilder(ControlBuilder builder)
      12: {
      13:     this.ProcessControlBuilderChildren(builder);
      14:  
      15:     if (builder.ControlType == typeof(HtmlForm))
      16:     {
      17:         //add a Literal control inside the form tag
      18:         var literal = ControlBuilder.CreateBuilderFromType(null, builder, typeof(Literal), "asp:Literal", "literal", new Hashtable { { "Text", "Inserted dynamically I" } }, -1, null);
      19:         builder.AppendSubBuilder(literal);
      20:  
      21:         //add an HTML snippet inside the form tag
      22:         builder.AppendLiteralString("<div>Inserted dynamically II</div>");
      23:     }
      24: }
      25:  
      26: private void ProcessControlBuilderChildren(ControlBuilder parentBuilder)
      27: {
      28:     foreach (var builder in parentBuilder.SubBuilders.OfType<ControlBuilder>())
      29:     {
      30:         this.ProcessControlBuilderChildren(builder);
      31:     }
      32: }

    Same for changing a control’s properties:

       1: private static readonly FieldInfo simplePropertyEntriesField = typeof(ControlBuilder).GetField("_simplePropertyEntries", BindingFlags.Instance | BindingFlags.NonPublic);
       2:  
       3: private void SetControlProperty(ControlBuilder builder, String propertyName, String propertyValue)
       4: {
       5:     var properties = (simplePropertyEntriesField.GetValue(builder) as IEnumerable);
       6:  
       7:     if (properties == null)
       8:     {
       9:         properties = new ArrayList();
      10:         simplePropertyEntriesField.SetValue(builder, properties);
      11:     }
      12:  
      13:     var entry = properties.OfType<SimplePropertyEntry>().SingleOrDefault(x => x.Name == propertyName) ?? simplePropertyEntryConstructor.Invoke(null) as SimplePropertyEntry;
      14:     entry.Name = propertyName;
      15:     entry.UseSetAttribute = (builder.ControlType != null && builder.ControlType.GetProperties().Any(x => x.Name.Equals(propertyName, StringComparison.OrdinalIgnoreCase)) == false);
      16:     entry.PersistedValue = propertyValue;
      17:     entry.Value = entry.PersistedValue;
      18:     entry.Filter = String.Empty;
      19:  
      20:     if (properties.OfType<SimplePropertyEntry>().Any(x => x.Name == propertyName) == false)
      21:     {
      22:         (properties as ArrayList).Add(entry);
      23:     }
      24: }
      25:  
      26: private void ProcessControlBuilder(ControlBuilder builder)
      27: {
      28:     if (typeof(IEditableTextControl).IsAssignableFrom(builder.ControlType) == true)
      29:     {
      30:         this.SetControlProperty(builder, "Text", "Injected dynamically!");
      31:     }
      32:  
      33:     this.ProcessControlBuilderChildren(builder);
      34: }

    And even changing the control’s output tag or instance type:

       1: private static readonly FieldInfo controlTypeField = typeof(ControlBuilder).GetField("_controlType", BindingFlags.Instance | BindingFlags.NonPublic);
       2: private static readonly FieldInfo tagNameField = typeof(ControlBuilder).GetField("_tagName", BindingFlags.Instance | BindingFlags.NonPublic);
       3:  
       4: private void SetControlType(ControlBuilder builder, Type controlType)
       5: {
       6:     controlTypeField.SetValue(builder, controlType);
       7: }
       8:  
       9: private void SetTagName(ControlBuilder controlBuilder, String tagName)
      10: {
      11:     tagNameField.SetValue(controlBuilder, tagName);
      12: }
      13:  
      14: private void ProcessControlBuilder(ControlBuilder builder)
      15: {
      16:     if (builder.TagName != null)
      17:     {
      18:         this.SetTagName(builder, builder.TagName.ToUpper());
      19:     }
      20:  
      21:     if (builder.ControlType == typeof(MyControl))
      22:     {
      23:         this.SetControlType(builder, typeof(MyDerivedControl));
      24:     }
      25:  
      26:     this.ProcessControlBuilderChildren(builder);
      27: }

    Why would we want to change a control’s type? Well, thing about generics, for once.

    Filter

    And now the filtering part: why is it a filter? Because it allows us to filter and control a number of things:

    • The allowed master page, base page class and source file;
    • The allowed controls;
    • The total number of controls allowed on a page;
    • The total number of direct and otherwise references on a page;
    • Allow or disallow code and event handler declarations;
    • Allow or disallow code blocks (<%= … %>, <%: … %>, <% … %>);
    • Allow or disallow server-side script tags (<script runat=”server”>…</script>);
    • Allow, disallow and change data binding expressions (<%# … %>);
    • Add, change or remove event handler declarations.


    All of the filtering methods and properties described below return a Boolean flag and its base implementation may or may not be called, depending on the logic that we want to impose.

    Allowing or disallowing a base page class is controlled by the AllowBaseType method (the default is to accept):

       1: public override Boolean AllowBaseType(Type baseType)
       2: {
       3:     return (baseType == typeof(MyBasePage));
       4: }

    For master pages, user controls or source files we have the AllowVirtualReference virtual method (again, the default is true):

       1: public override Boolean AllowVirtualReference(String referenceVirtualPath, VirtualReferenceType referenceType)
       2: {
       3:     if (referenceType == VirtualReferenceType.Master)
       4:     {
       5:         return (referenceVirtualPath == "AllowedMaster.Master");
       6:     }
       7:     else if (referenceType == VirtualReferenceType.UserControl)
       8:     {
       9:         return (referenceVirtualPath != "ForbiddenControl.ascx");
      10:     }
      11:  
      12:     return (base.AllowVirtualReference(referenceVirtualPath, referenceType));
      13: }

    Controls are controlled (pun intended) by AllowControl, which also defaults to accept:

       1: public override Boolean AllowControl(Type controlType, ControlBuilder builder)
       2: {
       3:     return (typeof(IForbiddenInterface).IsAssignableFrom(controlType) == false);
       4: }

    This may come in handy to disallow the usage of controls in ASP.NET MVC ASPX views!

    The number of controls and dependencies on a page is defined by NumberOfControlsAllowed, NumberOfDirectDependenciesAllowed and TotalNumberOfDependenciesAllowed. Interesting, the default for all these properties is 0, so we have to return –1:

       1: public override Int32 NumberOfControlsAllowed
       2: {
       3:     get
       4:     {
       5:         return (-1);
       6:     }
       7: }
       8:  
       9: public override Int32 NumberOfDirectDependenciesAllowed
      10: {
      11:     get
      12:     {
      13:         return (-1);
      14:     }
      15: }
      16:  
      17: public override Int32 TotalNumberOfDependenciesAllowed
      18: {
      19:     get
      20:     {
      21:         return (-1);
      22:     }
      23: }

    Direct dependencies are user controls directly declared in the page and indirect ones are those declared inside other user controls.

    Code itself, including event handler declarations, are controlled by AllowCode (default is true):

       1: public override Boolean AllowCode
       2: {
       3:     get
       4:     {
       5:         return (true);
       6:     }
       7: }

    If we want to change a data binding expression, we resort to ProcessDataBindingAttribute, which also returns true by default:

       1: public override Boolean ProcessDataBindingAttribute(String controlId, String name, String value)
       2: {
       3:     if (name == "Text")
       4:     {
       5:         //Do not allow binding the Text property
       6:         return (false);
       7:     }
       8:  
       9:     return (base.ProcessDataBindingAttribute(controlId, name, value));
      10: }

    For intercepting event handlers, there’s the ProcessEventHook, which likewise returns true by default:

       1: public override Boolean ProcessEventHookup(String controlId, String eventName, String handlerName)
       2: {
       3:     if (eventName == "SelectedIndexChanged")
       4:     {
       5:         //Remove event handlers for the SelectedIndexChanged event
       6:         return (false);
       7:     }
       8:  
       9:     return (base.ProcessEventHookup(controlId, eventName, handlerName));
      10: }

    And finally, for code blocks, server-side scripts and data binding expressions, there’s the ProcessCodeConstruct method, which likewise also allows everything by default:

    Conclusion

    This was in no means an in-depth description of page parser filters, I just meant to give you an idea of its (high) potential. It is very useful to restrict what end users can place on their pages (SharePoint style) as well as for adding dynamic control programmatically in specific locations of the page, before it is actually built.

    As usual, let me hear your thoughts! Winking smile

    Read more...

  • Making Better Use of the NHibernate HiLo Generator

    Introduction

    NHibernate’s HiLo (High-Low) id generation algorithm is one of the most commonly used, and for good reasons:

    • It is database-independent, that is, does not rely on any database-specific functionality such as SQL Server’s IDENTITY and Oracle’s SEQUENCE;
    • It allows batching of inserts;
    • It complies with the Unit of Work pattern, because it sends all writes at the same time (when the session is flushed);
    • Your code does not need to know or care about it.

    Now, this post does not intent to explain this algorithm in depth, for that I recommend the NHibernate HiLo Identity Generator article or Choosing a Primary Key: Natural or Surrogate?, for a more in-depth discussion of id generation strategies. Here I will talk about how to make better use of the NHibernate implementation.

    Max Low

    First of all, you can configure the max low value for the algorithm, using by code mapping, like this:

       1: x.Generator(Generators.HighLow, g => g.Params(new { max_lo = 100 }));

    The default max low value is 32767. When choosing a lower or a higher value, you should take into consideration:

    • The next high value is updated whenever a new session factory is created, or the current low reaches the max low value;
    • If you have a big number of inserts, it might pay off to have a higher max low, because NHibernate won’t have to go to the database when the current range is exhausted;
    • If the session factory is frequently restarted, a lower value will prevent gaps.

    There is no magical number, you will need to find the one that best suits your needs.

    One Value for All Entities

    With the default configuration of HiLo, a single table, row and column will be used to store the next high value for all entities using HiLo. The by code configuration is as follows:

       1: this.Id(x => x.SomeId, x =>
       2: {
       3:     x.Column("some_id");
       4:     x.Generator(Generators.HighLow);
       5: });

    The default table is called HIBERNATE_UNIQUE_KEY, and its schema is very simple:

    image

    Whenever NHibernate wants to obtain and increment the current next high value, it will issue SQL like this (for SQL Server):

       1: -- select current value
       2: select next_hi
       3: from hibernate_unique_key with (updlock, rowlock)
       4:  
       5: -- update current value
       6: update hibernate_unique_key
       7: set next_hi = @p0
       8: where next_hi = @p1;

    There are pros and cons to this default approach:

    • Each record will have a different id, there will never be two entities with the same id;
    • Because of the sharing between all entities, the ids will grow much faster;
    • When used simultaneously by several applications, there will be some contention on the table, because it is being locked whenever the next high value is obtained and incremented;
    • The HIBERNATE_UNIQUE_KEY table is managed automatically by NHibernate (created, dropped and populated).

    One Row Per Entity

    Another option to consider, which is supported by NHibernate’s HiLo generator, consists of having each entity storing its next high value in a different row. You achieve this by supplying a where parameter to the generator:

       1: this.Id(x => x.SomeId, x =>
       2: {
       3:     x.Column("some_id");
       4:     x.Generator(Generators.HighLow, g => g.Params(new { where = "entity_type = 'some_entity'" }));
       5: });

    In it, you would specify a restriction on an additional column. The problem is, NHibernate knows nothing about this other column, so it won’t create it.

    One way to go around this is by using an auxiliary database object (maybe a topic for another post). This is a standard NHibernate functionality that allows registering SQL to be executed when the database schema is created, updated or dropped. Using mapping by code, it is applied like this:

       1: private static IAuxiliaryDatabaseObject OneHiLoRowPerEntityScript(Configuration cfg, String columnName, String columnValue)
       2: {
       3:     var dialect = Activator.CreateInstance(Type.GetType(cfg.GetProperty(NHibernate.Cfg.Environment.Dialect))) as Dialect;
       4:     var script = new StringBuilder();
       5:  
       6:     script.AppendFormat("ALTER TABLE {0} {1} {2} {3} NULL;\n{4}\nINSERT INTO {0} ({5}, {2}) VALUES (1, '{6}');\n{4}\n", TableHiLoGenerator.DefaultTableName, dialect.AddColumnString, columnName, dialect.GetTypeName(SqlTypeFactory.GetAnsiString(100)), (dialect.SupportsSqlBatches == true ? "GO" : String.Empty), TableHiLoGenerator.DefaultColumnName, columnValue);
       7:  
       8:     return (new SimpleAuxiliaryDatabaseObject(script.ToString(), null));
       9: }
      10:  
      11: Configuration cfg = ...;
      12: cfg.AddAuxiliaryDatabaseObject(OneHiLoRowPerEntityScript(cfg, "entity_type", "some_entity"));

    Keep in mind that this needs to go before the session factory is built. Basically, we are creating a SQL ALTER TABLE followed by an INSERT statement that change the default HiLo table and add another column that will serve as the discriminator. For making it cross-database, I used the registered Dialect class.

    Its schema will then look like this:

    image

    When NHibernate needs the next high value, this is what it does:

       1: -- select current value
       2: select next_hi
       3: from hibernate_unique_key with (updlock, rowlock)
       4: where entity_type = 'some_entity'
       5:  
       6: -- update current value
       7: update hibernate_unique_key
       8: set next_hi = @p0
       9: where next_hi = @p1
      10: and entity_type = 'some_entity';

    This approach only has advantages:

    • The HiLo table is still managed by NHibernate;
    • You have different id generators per entity (of course, you can still combine multiple entities under the same where clause), which will make them grow more slowly;
    • No contention occurs, because each entity is using its own record on the HIBERNATE_UNIQUE_KEY table.

    One Column Per Entity

    Yet another option is to have each entity using its own column for storing the high value. For that, we need to use the column parameter:

       1: this.Id(x => x.SomeId, x =>
       2: {
       3:     x.Column("some_id");
       4:     x.Generator(Generators.HighLow, g => g.Params(new { column = "some_column_id" }));
       5: });

    Like in the previous option, NHibernate does not know and therefore does not create this new column automatically. For that, we resort to another auxiliary database object:

       1: private static IAuxiliaryDatabaseObject OneHiLoColumnPerEntityScript(Configuration cfg, String columnName)
       2: {
       3:     var dialect = Activator.CreateInstance(Type.GetType(cfg.GetProperty(NHibernate.Cfg.Environment.Dialect))) as Dialect;
       4:     var script = new StringBuilder();
       5:  
       6:     script.AppendFormat("ALTER TABLE {0} {1} {2} {3} NULL;\n{4}\nUPDATE {0} SET {2} = 1;\n{4}\n", TableHiLoGenerator.DefaultTableName, dialect.AddColumnString, columnName, dialect.GetTypeName(SqlTypeFactory.Int32), (dialect.SupportsSqlBatches == true ? "GO" : String.Empty));
       7:  
       8:     return (new SimpleAuxiliaryDatabaseObject(script.ToString(), null));
       9: }
      10:  
      11: Configuration cfg = ...;
      12: cfg.AddAuxiliaryDatabaseObject(OneHiLoColumnPerEntityScript(cfg, "some_column_id"));

    The schema, with an additional column, would look like this:

    image

    And NHibernate executes this SQL for getting/updating the next high value:

       1: -- select current value
       2: select some_column_hi
       3: from hibernate_unique_key with (updlock, rowlock)
       4:  
       5: -- update current value
       6: update hibernate_unique_key
       7: set some_column_hi = @p0
       8: where some_column_hi = @p1;

    The only advantage in this model is to have separate ids per entity, contention on the HiLo table will still occur.

    One Table Per Entity

    The final option to consider is having a separate table per entity (or group of entities). For that, we use the table parameter:

       1: this.Id(x => x.SomeId, x =>
       2: {
       3:     x.Column("some_id");
       4:     x.Generator(Generators.HighLow, g => g.Params(new { table = "some_entity_unique_key" }));
       5: });

    In this case, NHibernate generates the new HiLo table for us, together with the default HIBERNATE_UNIQUE_KEY, if any entity uses it, with exactly the same schema:

    image

    And the SQL is, of course, also identical, except for the table name:

       1: -- select current value
       2: select next_hi
       3: from some_entity_unique_key with (updlock, rowlock)
       4:  
       5: -- update current value
       6: update some_entity_unique_key
       7: set next_hi = @p0
       8: where next_hi = @p1;

    Again, all pros and no cons:

    • Table still fully managed by NHibernate;
    • Different ids per entity or group of entities means they will grow slower;
    • Contention will only occur if more than one entity uses the same HiLo table.

    Conclusion

    As you can see, NHibernate is full of extensibility points. Even when it does not offer out of the box what we need, we usually have a way around it.

    Let me hear from you!

    Read more...

  • NHibernate Connection Resiliency

    Entity Framework 6 included a feature known as connection resiliency. Basically, what it says is, when EF is trying to connect to a database, it will try a number of times before giving up. After each unsuccessful attempt, it will wait some time and then try again. As you can imagine, this is very useful, especially when we are dealing with cloud storage.

    NHibernate does not natively offer this, however, because it is highly extensible, it isn’t too hard to build one such mechanism, which is what I did.

    The code is below, as you can see, it consists of a custom implementation of DriverConnectionProvider, the component of NHibernate that opens connections for us.

       1: public class ResilientDriverConnectionProvider : DriverConnectionProvider
       2: {
       3:     public const String ConnectionDelayBetweenTries = "connection.delay_between_tries";
       4:     public const String ConnectionMaxTries = "connection.max_tries";
       5:  
       6:     private static readonly IInternalLogger log = LoggerProvider.LoggerFor(typeof(ResilientDriverConnectionProvider));
       7:  
       8:     public ResilientDriverConnectionProvider()
       9:     {
      10:         this.MaxTries = 3;
      11:         this.DelayBetweenTries = TimeSpan.FromSeconds(5);
      12:     }
      13:  
      14:     public Int32 MaxTries { get; set; }
      15:  
      16:     public TimeSpan DelayBetweenTries { get; set; }
      17:  
      18:     public override void Configure(IDictionary<String, String> settings)
      19:     {
      20:         String maxTries;
      21:         String delayBetweenTries;
      22:  
      23:         if (settings.TryGetValue(ConnectionMaxTries, out maxTries) == true)
      24:         {
      25:             this.MaxTries = Int32.Parse(maxTries);
      26:         }
      27:  
      28:         if (settings.TryGetValue(ConnectionDelayBetweenTries, out delayBetweenTries) == true)
      29:         {
      30:             this.DelayBetweenTries = TimeSpan.Parse(delayBetweenTries);
      31:         }
      32:  
      33:         base.Configure(settings);
      34:     }
      35:  
      36:     public override IDbConnection GetConnection()
      37:     {
      38:         IDbConnection con = null;
      39:  
      40:         for (var i = 0; i < this.MaxTries; ++i)
      41:         {
      42:             try
      43:             {
      44:                 log.Debug(String.Format("Attempting to get connection, {0} of {1}", (i + 1), this.MaxTries));
      45:                 con = base.GetConnection();
      46:                 log.Debug(String.Format("Got a connection after {0} tries", (i + 1)));
      47:  
      48:                 break;
      49:             }
      50:             catch(Exception ex)
      51:             {
      52:                 if (i == this.MaxTries - 1)
      53:                 {
      54:                     log.Error(String.Format("Could not get connection after {0} tries", this.MaxTries), ex);
      55:                     throw;
      56:                 }
      57:                 else
      58:                 {
      59:                     Thread.Sleep(this.DelayBetweenTries);
      60:                 }
      61:             }
      62:         }
      63:  
      64:         return (con);
      65:     }
      66: }

    The code wraps the attempt to open a connection and retries it a number of times, with some delay in between.

    The way to configure this, in fluent configuration, would be:

       1: var cfg = new Configuration()
       2:     .DataBaseIntegration(
       3:     db =>
       4:     {
       5:         db.ConnectionProvider<ResilientDriverConnectionProvider>();
       6:         //...
       7:     });

    Or if you prefer to use string properties, in either XML or fluent configuration, you can do:

       1: var cfg = new Configuration()
       2:     .SetProperty(NHibernate.Cfg.Environment.ConnectionProvider, typeof(ResilientDriverConnectionProvider).AssemblyQualifiedName);

    From looking at the class, you can see that it supports two properties:

    • MaxTries: the maximum number of connect attempts;
    • DelayBetweenTries: the amount of time to wait between two connection attempts.

    It is possible to supply this values by configuration:

       1: var cfg = new Configuration()
       2:     .SetProperty(NHibernate.Cfg.Environment.ConnectionProvider, typeof(ResilientDriverConnectionProvider).AssemblyQualifiedName)
       3:     .SetProperties(ResilientDriverConnectionProvider.ConnectionMaxTries, "3")
       4:     .SetProperties(ResilientDriverConnectionProvider.ConnectionDelayBetweenTries, TimeSpan.FromSeconds(5).ToString());

    As usual, hope you find this useful! Smile

    Read more...

  • Delete By Id in NHibernate

    NHibernate allows executable queries, that is, plain old UPDATEs, INSERTs and DELETEs. This is great, for example, for deleting an entity by its id without actually loading it. Note, that the following won’t give you that:

       1: session.Delete(session.Load<TEntity>(id));

    NHibernate will load the proxy before it actually deletes it. But the following does work perfectly:

       1: public static Boolean DeleteById(this ISession session, Type entityType, Object id)
       2: {
       3:     var metadata = session.SessionFactory.GetClassMetadata(entityType);
       4:  
       5:     var hql = String.Format("delete {0} where id = :id", metadata.EntityName);
       6:  
       7:     var results = session.CreateQuery(hql).SetParameter("id", id).ExecuteUpdate();
       8:  
       9:     return (results == 1);
      10: }
      11:  
      12: public static Boolean DeleteById<T>(this ISession session, Object id)
      13: {
      14:     return (DeleteById(session, typeof(T), id));
      15: }

    A single DELETE SQL command is sent to the database with this approach.

    Read more...

  • ASP.NET Web Forms Extensibility: Handlers

    In the .NET world, all HTTP requests, whether they be for web services (XML, WCF, Web API), pages (Web Forms and MVC), etc, are processed by a handler. Basically, a handler is a particular implementation of the IHttpHandler interface, and requests are routed to a particular handler class by one of four ways:

    • An entry on the Web.config file, on the httpHandlers section;
    • An instance returned from a Handler Factory;
    • A route handler, like in MVC or Dynamic Data;
    • Explicitly requested by the URL, in the case of ASHX generic handlers.

    The httpHandlers section can specify both a handler or a handler factory for a specific URL pattern (say, for example, /images/*.png), which may be slightly confusing. I have already discussed handler factories in another post, have a look at it if you haven’t already. A simple registration would be:

       1: <httpHandlers>
       2:     <add verb="*" path="Image.axd" type="MyNamespace.MyHandler, MyAssembly"/>
       3: </httpHandlers>

    Another option is through a route. The IRouteHandler interface defines a method GetHttpHandler which returns the route handler that will handle the request. You can register a IRouteHandler instance for a specific route by setting the RouteHandler property inside the Route class.

    Finally, there’s another kind of handler that doesn’t need registering and that is called explicitly: generic handlers. These are .ASHX markup files without any user interface elements that merely reference a code-behind class, which must implement IHttpHandler (you can also place code in the .ASHX file, inside a <script runat=”server”> declaration). Here’s an example:

       1: <%@ WebHandler Language="C#" Class="Handler" %>
       2: <script runat="server" language="C#">
       1:  
       2: public class Handler : System.Web.IHttpHandler
       3: {
       4:     //...
       5: }
       6:  
    </script>

    Having said that, what is a handler good for? The IHttpHandler interface only defines one method, ProcessRequest, and a property, IsReusable. As you can tell, this is considerably more simple than, for example, the Page class, with its myriad of virtual methods and events, which, of course, is also an implementation of IHttpHandler. Because of that, it is much more useful for handling requests that do not need a complex lifecycle. Some scenarios:

    • Downloading a file;
    • Uploading a file;
    • Streaming;
    • Redirecting;
    • Returning values for consumption by JavaScript, in AJAX style;
    • Tracing and monitoring, like ELMAH or the Trace handler;
    • Generating content dynamically, such as images.

    The IsReusable indicates to the ASP.NET infrastructure if the hander’s instance can be reused for different identical requests or if a new instance needs to be created. If you don’t store state on the handler’s class, it is safe to return true.

    As for the ProcessRequest method, a simple implementation might be:

       1: public class ImageHandler : IHttpHandler
       2: {
       3:     public void ProcessRequest(HttpContext context)
       4:     {
       5:         Bitmap bmp = new Bitmap(400, 300);
       6:  
       7:         Graphics g = Graphics.FromImage(bmp);
       8:         g.DrawRectangle(new Pen(new SolidBrush(Color.Green)), 10, 10, 300, 200);
       9:         g.DrawString(context.Request.Url.Query, new Font("Arial", 30), new SolidBrush(Color.Yellow), new PointF(10f, 10f));
      10:  
      11:         context.Response.ContentType = "image/gif";
      12:  
      13:         bmp.Save(context.Response.OutputStream, ImageFormat.Gif);
      14:     }
      15:  
      16:     public Boolean IsReusable
      17:     {
      18:         get
      19:         {
      20:             return (true);
      21:         }
      22:     }
      23: }

    This will create an image with a text string that is obtained from the query string, that is, anything in the URL after the ? symbol.

    Don’t forget to always return the appropriate content type, because the browser won’t know how to handle the content you send without it.

    One final note: from an handler you normally don't have access to the session - the Session property is null. If you need to use it, you must declare that your handler implements IRequiresSessionState or IReadOnlySessionState, the later for read-only access. That's basically what ASP.NET does when, on your page's markup, you place a EnableSessionState attribute.

    Read more...

  • ASP.NET Web Forms Extensibility: URL Mapping

    A long time before ASP.NET Routing came along, ASP.NET already offered a similar functionality: it was called URL mapping.

    URL mapping allows having virtual URLs that redirect to real ones. For example, you can have all requests for “/Product/IPhone” redirected to “/Product.aspx?ID=10”. This allows two simple things:

    • Hiding complexity (the ID parameter, for example);
    • Hiding the technology in use (in this case, the .ASPX extension is never seen);
    • Redirecting from one page (such as Default.aspx) to another transparently.

    You can configure URL mapping by just adding entries to the urlMapping section on Web.config:

       1: <urlMappings enabled="true">
       2:     <add url="~/Product/IPhone" mappedUrl="~/Product.aspx?ID=10"/>
       3: </urlMappings>

    And that’s it, no modules or additional configuration.

    You can keep using the QueryString collection:

       1: Int32 id = Convert.ToInt32(this.Request.QueryString["ID"]);     //10
       2: String path = this.Request.Path;                                //Product.aspx

    The Url property also contains the real URL, but the RawUrl contains the requested URL:

       1: String requestedPath = this.Request.RawUrl;    //Product/IPhone
       2: String mappedPath = this.Request.Url;          //http://localhost/Product.aspx?ID=1

    So, as you can see, this is much simpler that ASP.NET Routing and should only be used in very simple scenarios: when you are using a version of ASP.NET prior to 3.5, or you want to configure routes only through the Web.config file.

    Read more...

  • ASP.NET Web Forms Extensibility: Tag Mapping

    There may be times when you want a particular setting applied to all controls of a given type, in all pages. Or you want to debug this control, but you don’t have access to it’s source code. Or you want to change its behavior. For that, you can use tag mapping, and I have given an example before.

    In a nutshell, ASP.NET lets you change the control that would normally be instantiated by some server tag (like <asp:Image />, <asp:TextBox />, etc) for your own control, which must inherit from the class of the original control. This means that on all places that you have declared, for example, an <asp:TextBox />, instead of the standard TextBox, ASP.NET will instead place an instance of your own class, where you can override methods, set property defaults on its constructor or place breakpoints.

    Usage is very simple, just add entries to the tagMapping section:

       1: <tagMapping>
       2:     <add tagType="System.Web.UI.WebControls.TextBox" mappedTagType="MyNamespace.MyTextBox, MyAssembly"/>
       3: </tagMapping>

    Remember, MyTextBox must inherit from TextBox, or you will get an exception.

    All of the properties that are present on markup will be passed to the new control, skins will also apply. In case you are wondering, this won’t work with web user controls (those that have an .ASCX file).

    Read more...

  • ASP.NET Web Forms Extensibility: Modules

    Next in the series is modules. So, what is a module, and what does it do?

    A module is some class that implements IHttpModule. This is a very simple interface, which only defines two methods:

    • Init: this is the “body” of the module, where you place it’s logic (more on this later), called when the application is started (typically, upon the first request, unless you are doing application initialization);
    • Dispose: called when the application shuts down.

    A module is typically statically registered on the Web.config file, although I have talked in the past on how to register modules dynamically. While a module usually does not actually do anything by itself, it is useful for registering event handlers for ASP.NET application lifetime events, such as Error, BeginRequest, EndRequest and their likes. Please note that there is no event for the Start occurrence (normally handled on the custom Global class on an Application_Start method), you can just use the Init method for that, since it is called upon application startup.

    Out of the box ASP.NET includes a number of modules, which you can find on the global Web.config file, located in %WINDIR%\Microsoft.NET\Framework64\v4.0.30319\Config, some of which you are free to disable, that is, remove on you local Web.config file:

       1: <!-- for IIS < 7 -->
       2: <httpModules>
       3:    <remove name="PassportAuthentication" />
       4: </httpModules>
       5: <!-- for IIS 7+ -->
       6: <system.webServer>
       7:   <modules>
       8:     <remove name="PassportAuthentication" />
       9:   </modules>
      10: </system.webServer>
      11:  

    As you can see from the above snippet, one such module is PassportAuthentication, implemented by PassportAuthenticationModule, one that is marked as deprecated in current versions of .NET. Now, there are two sections where modules can be registered, one for IIS versions prior to 7, and the other for recent versions. Of course, if you only use one of them, do forget about the other section.

    A simple module implementation would be:

       1: public class FooterModule : IHttpModule
       2: {
       3:     void IHttpModule.Init(HttpApplication context)
       4:     {
       5:         context.EndRequest += (sender, e)
       6:         {
       7:             HttpContext.Current.Response.Write(String.Format("<p>Generated at {0}</p>", DateTime.UtcNow));
       8:         };
       9:     }
      10:  
      11:     void IHttpModule.Dispose()
      12:     {
      13:     }
      14: }

    This module registers an event handler for the EndRequest event, which, when called, outputs a string to the response. Nothing to be done on disposing, in this case, but a typical use case would be to release any sort of “heavy” module-held resources when the application shuts down. Please be careful to perform operations only when you can, for example, session is only available after the AcquireRequestState event is raised (and, of course, only for handlers implementing IRequiresSessionState), caller identity is only set after the AuthenticateRequest and authorization is only confirmed after AuthorizeRequest.

    You should favor writing code that handles an event in a module as opposed to having a similar method on Global.asax.cs because a module is more portable – you can even reuse it between different assemblies.

    Once you are finished, you need to register your module on Web.config, to have it being set up automatically. You have to give it a unique name and add an entry like the following:

       1: <!-- for IIS < 7 -->
       2: <system.web>
       3:     <httpModules>
       4:         <add name="MyModule" type="MyNamespace.MyModule, MyAssembly"/>
       5:     </httpModules>
       6: </system.web>
       7: <!-- for IIS 7+ -->
       8: <system.webServer>
       9:     <modules runAllManagedModulesForAllRequests="true">
      10:         <add name="MyModule" type="MyNamespace.MyModule, MyAssembly"/>
      11:     </modules>
      12: </system.webServer>

    Next, handlers and routes! Winking smile

    Read more...