Charles Nurse posted on July 31, 2008 10:33

This blog was originally posted on my dotnetnuke.com Blog. It has been updated and edited.

Michael Washington in a blog about updating his DotNetNuke sites made reference to the fact that you no longer need to manually modify your web.config settings prior to upgrading a site.

Why is this?  The answer is a new class that was introduced into the core (in DotNetNuke version 4.6.0) called XmlMerge.  This class is designed to allow developers to create xml files that can be used to "update" one or more of the core "config" files, and is especially useful for upgrades and component installations.

We have had the ability for some time to provide file-cleanup files - these files are named xx.xx.xx.txt and contain a list of folders and files to delete when upgrading to version xx.xx.xx.  This allows us to remove unnecessary files from production sites.  Starting in version 4.6.0 we added the ability to add a "xx.xx.xx.config" file which contained the changes required to "upgrade" a core config file.

Rather than try and explain - lets look at an example. The 4.6.0.config file:

Listing 1: 04.06.00.config file
   1:  <configuration>
   2:    <nodes configfile="web.config">
   3:      <node path="/configuration/system.web/httpModules" action="update" key="name" 
                 collision="overwrite">
   4:        <add name="Compression" type="DotNetNuke.HttpModules.Compression.CompressionModule, 
DotNetNuke.HttpModules"
/>
   5:        <add name="RequestFilter" type="DotNetNuke.HttpModules.RequestFilter.RequestFilterModule, 
DotNetNuke.HttpModules"
/>
   6:        <add name="UrlRewrite" type="DotNetNuke.HttpModules.UrlRewriteModule, 
DotNetNuke.HttpModules"
/>
   7:        <add name="Exception" type="DotNetNuke.HttpModules.Exceptions.ExceptionModule, 
DotNetNuke.HttpModules"
/>
   8:        <add name="UsersOnline" type="DotNetNuke.HttpModules.UsersOnline.UsersOnlineModule, 
DotNetNuke.HttpModules"
/>
   9:        <add name="DNNMembership" type="DotNetNuke.HttpModules.Membership.MembershipModule, 
DotNetNuke.HttpModules"
/>
  10:        <add name="Personalization" 
type="DotNetNuke.HttpModules.Personalization.PersonalizationModule,
DotNetNuke.HttpModules"
/>
  11:      </node>
  12:      <node path="/configuration/dotnetnuke/friendlyUrl/providers" action="update" key="name" 
collision="overwrite">
  13:        <add name="DNNFriendlyUrl"
  14:             type="DotNetNuke.Services.Url.FriendlyUrl.DNNFriendlyUrlProvider, 
DotNetNuke.HttpModules"
  15:             includePageName="true"
  16:             regexMatch="[^a-zA-Z0-9 _-]" />
  17:      </node>
  18:    </nodes>
  19:  </configuration>

In version 4.6 - the HttpModules were all merged into a single assembly - the web.config file therefore needed to be updated to reflect this.  In this config file - there are two "node" elements which are the building blocks of the XmlMerge file.  The attributes tell the XmlMerge class how to deal with the content inside the node. 

So for the first node we have:

  • path="/configuration/system.web/httpModules" - this is an Xpath path that identifies the node being modified in the target file - in this case the "httpModules" element in the system.web element of the configuration
  • action="update" - this is the action - in this case the existing element is being "updated".  Other values for action are add, insertbefore, insertafter, remove, removeattribute, updateattribute.
  • key="name"  - this is the key to use - in this case "name" - the XmlMerge class will identify the child nodes to change by matching the name attribute "Compression", "Exception etc.
  • collision="overwrite" - this is the behaviour to use if the child node exists - in this case the old entry will be overwritten by the new one

The target file is "web.config" as identified by the configfile attribute on the outer nodes element.  

Note - in this scenario if the end user has added additional HttpModules these are unaffected by the "merge" - only the named child nodes are replaced.

During the install/upgrade, the DotNetNuke core installer calls the UpdateConfig method for each version (see Listing 2).  This method checks that the file exists, creates an instance of the XmlMerge class and calls the UpdateConfig() method.  Finally the StreamReader is closed to release the file systems lock on the file.

Listing 2: UpdateConfig method
   1:  Private Shared Function UpdateConfig(ByVal strVersion As String) As String
   2:      Dim strExceptions As String = ""
   3:   
   4:      Try
   5:          Dim strConfigFile As String = DotNetNuke.Common.HostMapPath & strVersion & ".config"
   6:   
   7:          If File.Exists(strConfigFile) Then
   8:              'Create XmlMerge instance from config file source
   9:              Dim stream As StreamReader = File.OpenText(strConfigFile)
  10:              Dim merge As XmlMerge = New XmlMerge(stream, strVersion, "Core Upgrade")
  11:   
  12:              'Process merge
  13:              merge.UpdateConfigs()
  14:   
  15:              'Close stream
  16:              stream.Close()
  17:          End If
  18:   
  19:      Catch ex As Exception
  20:          strExceptions += "Error: " & ex.Message & vbCrLf
  21:      End Try
  22:   
  23:      Return strExceptions
  24:  End Function

In addition to using this in the core Installer/Upgrader - the new "Universal Extension Installer" that will be included in DotNetNuke 5.0 supports this ability too.  Again - as an example lets look at a fragment of a manifest from the new installer (see Listing 3).

Listing 3: BroadcastPollingCachingProvider Manifest
   1:  <component type="Config">
   2:    <config>
   3:      <configFile>web.config</configFile>
   4:      <install>
   5:        <configuration>
   6:          <nodes>
   7:            <node path="/configuration/dotnetnuke/caching/providers" action="update" key="name" 
   8:                  collision="overwrite">
   9:              <add name="BroadcastPollingCachingProvider"
  10:                   type="DotNetNuke.Services.Cache.BroadcastPollingCachingProvider.BPCachingProvider, 
  11:                         DotNetNuke.Caching.BroadcastPollingCachingProvider"
  12:                   providerPath="~\Providers\CachingProviders\BroadcastPollingCachingProvider\" />
  13:            </node>
  14:          </nodes>
  15:        </configuration>
  16:      </install>
  17:      <uninstall>
  18:        <configuration>
  19:          <nodes>
  20:            <node path="/configuration/dotnetnuke/caching/providers/add[@name=
  21:                                                 'BroadcastPollingCachingProvider']" 
  22:                  action="remove" />
  23:          </nodes>
  24:        </configuration>
  25:      </uninstall>
  26:    </config>
  27:  </component>

In this example (part of the manifest for installing the BroadcastPollingCachingProvider) you can see that the manifest defines a "config" element - which tells the Installer that we are "updating" a config file - in this case web.config.  It has two separate sections that correspond to the same basic structure as the XmlMerge file above, one for installing the provider - with a similar set of attributes, and one for uninstalling, which shows how you would remove a section of the config file.

A full description of the XmlMerge API is beyond the scope of this blog post, but if you want to start learning how to use this in your own modules/extensions - I would suggest that you look for the "XmlMerge.vb" file in the DotNetNuke project source - the main entry points are the "UpdateConfig" methods.


Posted in: DotNetNuke  Tags:

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

This article is based on material originally published on DNN Developer Zone (www.dnndevzone.com).  This version has been edited slightly.

Introduction

Version 4.3 of the DotNetNuke Web Application Framework introduced a suite of Property Editors. These Property Editors dynamically inject the appropriate Edit Control depending on the Data Type to be edited. There are 5 types of editor and 47 class or enum files that make up the Property Editor suite of controls. Previous articles in this series introduced the Property Editors. This article introduces the 14 EditControls included with the core distribution. Future articles in this series will describe how to create your own EditControl.

The Abstract EditControl

Figure 1: The Abstract EditControl Base Class
EditControl  

Figure 1 shows the definition of the abstract base class EditControl. Every EditControl used by the Property Editors is derived from this base class.

Lets take a look at this abstract class. There are 9 Properties in this class and one abstract Property (StringValue).

  • CustomAttributes - An array of Attributes that can be used by the derived classes to add customisation (for instance the DNNListEditControl uses the Attributes collection to determine which list to display).
  • EditMode - Determines whether the control is in Edit or View mode.
  • LocalResourceFile - This property is used by the EditControl to reference the current LocalResourceFile.
  • Name - The name of the property being edited.
  • OldValue - the old value of the property.
  • Required - whether the property is required (used by drop-down lists to determine whether to add a < None Specified > option).
  • StringValue - the Value expressed as a String , each derived class must override this property.
  • SystemType - the underlying System.Type of the value of this control.
  • Value - the value of the property.

The abstract class also defines a number of protected methods. Three methods control the rendering process.

  • Render - the Render method is called by the .NET Framework at Render time and this method calls RenderEditMode or RenderViewMode to render the control, based on the value of the EditMode property.
  • RenderViewMode - this method renders the control when the EditMode is set to View, as is the case in "View Profile" .
  • RenderEditMode - this method renders the control when the EditMode is set to Edit, as is the case when editing a Profile. This method is shown in Listing 1 below.

 

 

 

Listing 1: The RenderEditMode method
   1:  Protected Overridable Sub RenderEditMode(ByVal writer As HtmlTextWriter)
   2:      Dim propValue As String = CType(Me.Value, String)
   3:      ControlStyle.AddAttributesToRender(writer)
   4:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "text")
   5:      writer.AddAttribute(HtmlTextWriterAttribute.Value, propValue)
   6:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
   7:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
   8:      writer.RenderEndTag()
   9:  End Sub

These methods provide a default implementation that is called if the derived class does not provide its own rendering methods. Later in this article we will show how a derived EditControl overrides these methods. In the abstract base class a text box is rendered (an XHTML <input /> tag), the value is set to the value of the property, and the name is set to the UniqueID of the control. This last value is very important, as it is used by the .NET Framework to identify the control on PostBack.

IPostBackDataHandler Interface

If you look at Figure 1 you will see that the EditControl class implements the IPostBackDataHandler Interface. This interface provides two methods that are called automatically by the .NET Framework LoadPostData (see Listing 2) and RaisePostDataChangedEvent (see Listing 3)

Listing 2: LoadPostData method
   1:  Public Overridable Function LoadPostData(ByVal postDataKey As String, _ 
ByVal
postCollection As NameValueCollection) As Boolean
   2:      Dim dataChanged As Boolean = False
   3:      Dim presentValue As String = CStr(Value)
   4:      Dim postedValue As String = postCollection(postDataKey)
   5:      If Not presentValue.Equals(postedValue) Then
   6:          Value = postedValue
   7:          dataChanged = True
   8:      End If
   9:      Return dataChanged
  10:  End Function

The LoadPostData method is called by the .NET Framework for any Control that implements IPostBackDataHandler. It is called just after the View State is loaded (LoadViewState) and just before the Load phase of the Control Life Cycle. The postCollection represents all the name/value pairs returned to the Server by the PostBack, and the postDataKey is the key for the current control. (Remember above when I said the UniqueID was rendered to the Name attribute of the <input/> tag). The LoadPostData method returns a boolean that lets the Framework know whether the data was changed since it was rendered.

Listing 3: The RaisePostDataChangedEvent method
   1:  Public Sub RaisePostDataChangedEvent()
   2:      'Raise the DataChanged Event
   3:      OnDataChanged(System.EventArgs.Empty)
   4:  End Sub

Once the Load phase is complete, the .NET Framework then calls the RaisePostDataChangedEvent for every control that had previously reported that their data had changed. This allows the control to raise an event indicating its value has changed, In our case the RaisePostDataChangedEvent method calls the abstract OnDataChanged method. An abstract must be implemented in the derived class, and when the RaisePostDataChangedEvent calls the OnDataChanged method it actually calls the derived classes version, so the derived class can determine what to do next.

The base class also provides the ValueChanged event and associated OnValueChanged method (see Listing 4)

Listing 4: The Value Changed Event and the OnValueChanged Method
   1:  Public Event ValueChanged As PropertyChangedEventHandler
   2:   
   3:  Protected Overridable Sub OnValueChanged(ByVal e As PropertyEditorEventArgs)
   4:      RaiseEvent ValueChanged(Me, e)
   5:  End Sub
A derived class can use these events to indicated to the Editors that their values have been changed, passing the relevant information in a custom PropertyEditorEventArgs object.
Figure 2: PropertyEditorEventArgs Class
PropertyEditorEventArgs

EditControls included with DotNetNuke 4.3

As mentioned in the Introduction 14 EditControls are included with DotNetNuke (1 abstract base class and 13 derived classes). Figure 3 shows how 9 of the controls derive from the abstract base class. In general the controls can be divided into 4 groups:

  • Text controls - which derive from the TextEditControl
  • Integer controls - which derive from the IntegerEditControl
  • True False controls - either True/False (using radio buttons) or a check Edit Control
  • Lists - derived from DNNListEditControl
Figure 3: Some of the EditControls included in DotNetNuke v4.3.
 EditControls

The TrueFalseEditControl

As an example of a derived EditControl let's look at the TrueFalseEditControl. This control can be used to edit a boolean value using two radio buttons (True and False). As can be seen in Figure 4, this control has three properties and 2 methods.

Figure 4: The TrueFalseEditControl
 TrueFalseEditControl

The StringValue property is abstract in the base class so every derived class must implement this property.

The BooleanValue and OldBooleanValue properties are ReadOnly typed versions of the base classes Value and OldValue properties. They are not neccessary but are provided as helper properites that can be used in the methods of the class and any classes derived from it.

Listing 5: The three properties of the TrueFalseEditControl
   1:  Protected ReadOnly Property BooleanValue() As Boolean
   2:      Get
   3:          Dim boolValue As Boolean = Null.NullBoolean
   4:          Try
   5:              'Try and cast the value to an Boolean
   6:              boolValue = CType(Value, Boolean)
   7:          Catch ex As Exception
   8:          End Try
   9:          Return boolValue
  10:      End Get
  11:  End Property
  12:   
  13:  Protected ReadOnly Property OldBooleanValue() As Boolean
  14:      Get
  15:          Dim boolValue As Boolean = Null.NullBoolean
  16:          Try
  17:              'Try and cast the value to an Boolean
  18:              boolValue = CType(OldValue, Boolean)
  19:          Catch ex As Exception
  20:          End Try
  21:          Return boolValue
  22:      End Get
  23:  End Property
  24:   
  25:  Protected Overrides Property StringValue() As String
  26:      Get
  27:          Return BooleanValue.ToString
  28:      End Get
  29:      Set(ByVal Value As String)
  30:          Dim setValue As Boolean = Boolean.Parse(Value)
  31:          Me.Value = setValue
  32:      End Set
  33:  End Property

The TrueFalseEditControl overrides the RenderEditMode method of the base class as we are using two radio buttons (rather than a text box) to edit the data. This method is shown in Listing 6.

Listing 6: The RenderEditMode method of the TrueFalseEditControl
   1:  Protected Overrides Sub RenderEditMode(ByVal writer As HtmlTextWriter)
   2:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio")
   3:      If (BooleanValue) Then
   4:          writer.AddAttribute(HtmlTextWriterAttribute.Checked, "checked")
   5:      End If
   6:      writer.AddAttribute(HtmlTextWriterAttribute.Value, "True")
   7:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
   8:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
   9:      writer.RenderEndTag()
  10:   
  11:      ControlStyle.AddAttributesToRender(writer)
  12:      writer.RenderBeginTag(HtmlTextWriterTag.Span)
  13:      writer.Write("True")
  14:      writer.RenderEndTag()
  15:   
  16:      writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio")
  17:      If (Not BooleanValue) Then
  18:          writer.AddAttribute(HtmlTextWriterAttribute.Checked, "checked")
  19:      End If
  20:      writer.AddAttribute(HtmlTextWriterAttribute.Value, "False")
  21:      writer.AddAttribute(HtmlTextWriterAttribute.Name, Me.UniqueID)
  22:      writer.RenderBeginTag(HtmlTextWriterTag.Input)
  23:      writer.RenderEndTag()
  24:   
  25:      ControlStyle.AddAttributesToRender(writer)
  26:      writer.RenderBeginTag(HtmlTextWriterTag.Span)
  27:      writer.Write("False")
  28:      writer.RenderEndTag()
  29:  End Sub

This is a much more complicated method than the one in the base class (compare with Listing 1), as it needs to render two radio buttons, and make one of them selected (or "checked") depending on the vale of the BooleanValue property. It is important to note also that the name attribute for both buttons is given the same value, the UniqueID property of the EditControl, so that the .NET Framework can correctly identify the control.

As mentioned above the RaisePostDataChangedEvent method of the base class calls the abstract OnDataChanged method, so the TrueFalseEditControl has to provide an implementation of this method. This is shown in Listing 7.

Listing 7: The OnDataChanged method of the TrueFalseEditControl
   1:  Protected Overrides Sub OnDataChanged(ByVal e As EventArgs)
   2:      Dim args As New PropertyEditorEventArgs(Name)
   3:      args.Value = BooleanValue
   4:      args.OldValue = OldBooleanValue
   5:      args.StringValue = StringValue
   6:      MyBase.OnValueChanged(args)
   7:  End Sub

The OnDataChanged method creates a new PropertyEditorEventArgs object, and sets its Value, OldValue and StringValue properties - the Name property is created in the constructor, and the controls Name value is passed as a parameter of the constructor.

This PropertyEditorEventArgs object is then passed to the base classes OnValueChanged method, which raises the ValueChanged event.

As can be seen from this discussion, there really isn't very much to the derived EditControls. In future articles in this series we will show how to develop new Edit Controls, and how to register them in your DotNetNuke installation.


Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Introduction

Version 4.3 of the DotNetNuke Web Application Framework introduced a suite of Property Editors. These Property Editors dynamically inject the appropriate Edit Control depending on the Data Type to be edited. There are 5 types of editor and 53 class or enum files that make up the Property Editor suite of controls.

This third article in a series of articles I am writing on this topic, discusses the Fields collection and the FieldEditorControl.

Controlling the Behavior of the Editor with the Fields Collection

In Part 2 of this series I described how you can control the behavior of the Editor with Attributes.  There are two issues with this approach:

  1. The behavior is hard-coded.  In a Web Application Project it requires the developer to recompile the project if changes are made to the attributes.
  2. It mixes the design with the model, and does not allow projects to be split up with developers writing the code and designers creating the design.

There is another approach we can use to control the behavior, and this is to use the Fields collection of the PropertyEditorControl.  As mentioned in the first article in this series, the PropertyEditorControl is built from a collection of FieldEditorControl objects. 

If the AutoGenerate property of the PropertyEditorControl is set to true - the control constructs a FieldEditorControl from each property of the object where the Browsable attribute is true.  This is the procedure used in the previous article.  However, if the AutoGenerate property is set to false, then the Fields collection must be explicitly specified.  This is analogous to the ASP.NET DataGrid which has a Columns collection, which is auto-generated if the AutoGenerate property is set to true, but which requires the designer to add columns explicitly when the AutoGenerate attribute is set to false..

Lets look at the same example from the DotNetNuke Profile Definition Editor to see how we would redefine the editor to use this approach (Listing 1)

Listing 1 - The PropertyEditorControl Declaration using AutoGenerate=false
   1:  <dnn:propertyeditorcontrol id="Properties" runat="Server"
   2:      AutoGenerate="false"
   3:      SortMode="SortOrderAttribute"
   4:      ErrorStyle-cssclass="NormalRed"
   5:      labelstyle-cssclass="SubHead" 
   6:      helpstyle-cssclass="Help" 
   7:      editcontrolstyle-cssclass="NormalTextBox" 
   8:      labelwidth="180px" 
   9:      editcontrolwidth="170px" 
  10:      width="350px">
  11:      <Fields>
  12:          <dnn:FieldEditorControl ID="ctl1" runat="server" DataField="PropertyName" 
  13:              Required="true" EditMode="View" />
  14:          <dnn:FieldEditorControl ID="ctl2" runat="server" DataField="DataType" 
  15:              Required="true" EditMode="View"
  16:              EditorTypeName="DotNetNuke.UI.WebControls.DNNListEditControl, DotNetNuke" />
  17:          <dnn:FieldEditorControl ID="ctl3" runat="server" DataField="PropertyCategory" 
  18:              Required="true" />
  19:          <dnn:FieldEditorControl ID="ctl4" runat="server" DataField="Length" />
  20:          <dnn:FieldEditorControl ID="ctl5" runat="server" DataField="DefaultValue" />
  21:          <dnn:FieldEditorControl ID="ctl6" runat="server" DataField="ValidationExpression" />
  22:          <dnn:FieldEditorControl ID="ctl7" runat="server" DataField="Required" />
  23:          <dnn:FieldEditorControl ID="ctl8" runat="server" DataField="Visible" />
  24:          <dnn:FieldEditorControl ID="ctl9" runat="server" DataField="ViewOrder" 
  25:              Required="true" />
  26:      </Fields>
  27:  </dnn:propertyeditorcontrol>

The mark-up in Listing 1 is longer than in the previous article, but in compensation there are no longer any attributes in the ProfilePropertyDefinition class.

The resulting Edit page is essentially the same.

Figure 1: The Profile Property Edit Page
AddProfileProperty2

The only major difference is that the editor for the Data Type is not correct.  This is because the FieldEditorControl does not expose the Attributes collection and there is no way to configure the list so the drop-down combo's Text and Value properties are correct.  This can be done through code in the code-behind but it does demonstrate one limitation of this approach.

Manipulating the Fields and the child Edit Controls in the code file will be the topic of a future article in this series.


Posted in: DotNetNuke  Tags:

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Introduction

The primary goal in any family history research is to try and determine where the family originated. Sometimes, one is lucky and can accomplish this goal by pursuing the original records – birth/baptism, marriage, death/burial, wills and probate, but more often than not records are either lost or so illegible that the researcher reaches a dead end.

Figure 1 - Compton Dando
ComptonDando

This happened to me when researching my Nurse lineage. I managed to trace the family origins with a high degree of confidence to the parish of Compton Dando in northern Somerset, the first reference in that parish being the baptism[1] of James Nurse, son of William and Sarah Nurse in 1735.[2]

A thorough review of the parish records for the parishes of north Somerset showed that the family likely moved to Compton Dando from the Chew Stoke[3]/Chew Magna[4]/Norton Malreward[5] area. 

The earliest reference in the parish of Chew Magna is the burial of Joane Nurse of Stoke in 1573[6]. However, due to the poor state of the original records as well as their incompleteness, these conclusions are quite tentative and my research into the Nurse line came to a grinding halt.

The next stage in determining a family’s origin is to carry out research on the origin of the surname, with the hope that it can be shown that the name must have originated from a single source. This is actually very rare, but in the case of Nurse we can develop a few possible scenarios.

So, what is the origin of the surname Nurse?

I will take two different approaches to this question.

  1. The first approach will be to study the etymology of the name, to determine if there is a unique source.
  2. The second approach will be a statistical geographical approach. Through the use of various records we can attempt to determine the geographic location of the surname.

There is a third approach that can be used to trace your paternal ancestry (which in effect is what tracing the history of your surname is) and that is to use DNA.  This type of research is still in its infancy but can be used to confirm that male descendants with a common surname have a common Ancestor.

In this article I will focus on my research into the Etymology of the Nurse surname. I will describe my research into the geographic distribution of the Nurse surname in a future article.

The Origin of Surnames

Contrary to popular belief very few English families can trace their surnames to the “Domesday Book”, and fewer still can go back even tentatively to the pre-Conquest Anglo-Saxon era. Mainly this is due to a lack of records, but it is also due to the fact that hereditary surnames were restricted to the great land owning families.

Most of these surnames were derived from the locality where the family had their chief residence. For example, amongst William I’s barons at Hastings were William de Warenne from Varennes near Dieppe and Ilbert de Laci from Lassy, south of Bayeux.

During the two centuries or so that followed the Conquest most major landowning families and many knights adopted hereditary surnames, especially if they lived in the south of England, most of these hereditary surnames being derived from the place of origin of the family.

One of the largest categories of surnames is that which is derived from personal names. Some of these surnames, such as Paul or Thomas, derive directly from the personal name of the father of the man, who was the first in that line to adopt a hereditary surname. Others have –s or –son added as a suffix to a personal name, e.g. Roberts or Johnson, and yet others are prefixed by the Norman Fitz-, the Gaelic Mac or Mc, or the Welsh ap or ab, all of which mean “son of”.

Another large group of surnames, which became popular amongst the lower classes, is derived from occupations or from an office, rank or status. By the beginning of the thirteenth century, the more common occupational surnames, such as Smith, Taylor or Wright were already numerous.

Etymology of the Surname Nurse

The surname Nurse is derived from the same origins as the related names Nursey, Nourse, Norrish, Nurrish, Nowers, Norreys, Norrie and Norris, with the last being the form most common in recent times. The earliest mention of the variant Nurse appears to be in the early 16th century.[7],[8] There appears to be four different origins for this family of names.[9],[10]

The first origin is derived from the Old French word "norreis" which means "northerner" or "northman". This version of the name was found all over the country but particularly in the Midlands and the South. Some examples are;

  • Robert Noreis, who lived in Hampshire in 1148,[9]
  • William Le Norreis who lived in Gloucestershire between 1163 and 1200,[9]
  • Robert Le Norais who lived in Yorkshire in 1170,[9]
  • Robert Le Norreis who witnessed a charter by Earl Gospatric to the Priory of Coldingham in Scotland in 1166,[11] and
  • William Norrensis[12] who witnessed a charter by Malcolm, Earl of Fife in 1228.[11]

A second related, but far less common derivation is derived from the Old English words "noro" (north) and "hus" (house) meaning someone who dwelt in the north house or someone who lived on the north side of the estate, e.g.

  • Adam de Northus who lived in Essex in 1206.[9]

The third origin of the name, which is again quite common, is from the Old French word "norice", or "nurice" and the Latin "nutrix"/"nutricis" meaning wet nurse or foster parent. Again this version of the name is widespread throughout the country. Examples of people with the name with this origin are:

  • John "Le Norreys" who was one of an inquisition to inquire if Walter Biset was seized in the manor of Ulvington, Scotland at his death in 1251,[11]
  • Richard Norreys of Berwickshire who rendered homage to the King in 1296,[11]
  • Robert Le Noris of Yorkshire in 1297,[9] Alice La Norisse in Essex in 1310,[9] and
  • John Norice in Kent in 1317.[9]

The last origin of this family of names is derived from a family that came from Normandy with William the Conqueror; de Noers (and its variations, de Noiers, de Nuers). It is this last variation that most closely resembles the name Nurse, requiring only one letter to be moved.

At least one soldier named "de Noers" came with William the Conqueror and is on the Roll of Battle Abbey, in the Domesday Book.[10] The actual derivation of this name seems to be “de Noyers” after the name of a place –“Noyers”- in Normandy. As discussed earlier, surnames were only just beginning to be used in the 11th and 12th centuries; most people were referred to as John from some town (de Noyers in Norman French) or John the Smith (blacksmith).

There are records from Normandy to support the view that the family had its origins there. Here are a few:

  • Gilbert de Noyers witnessed a charter of Duke Richard to Fontanelles in 1024 A.D.
  • Richard, Gerald, and Gervase de Noiers, 1180-95 in Normandy
  • Andomar and William Norensis, 1180-95 in Normandy

While there is no evidence to suggest any connection to my ancestors, it is interesting to look at some of the people through the ages who have carried the name Noers, Norreys, Norris or Nurse. In a future article I will tell the story of William de Noers, Steward of King William I (The Conqueror). It is possible that William de Noers was a descendant of Gilbert de Noyers, listed above, but we have no proof that this is the case.

 


Bibliography and Notes

[1] - Parish Register for the Parish of Compton Dando Somerset, 1652-1900. Microfilmed by the Church of Jesus Christ Of Latter-Day Saints, Film No. 1526553.

[2] - James Nurse was baptized on 15th June 1735.

[3] - Parish Register for the Parish of Chew Stoke, Somerset, 1663-1789. Microfiched by the Somerset Record Office, Taunton, Somerset.

[4] - Parish Register for the Parish of Chew Magna, Somerset, 1569-1812. Microfiched by the Somerset Record Office, Taunton, Somerset

[5] - Parish Register for the Parish of Norton Malreward, Somerset, 1666-1812. Microfiched by the Somerset Record Office, Taunton, Somerset.

[6] - Joane Nurse of Stoke was buried on 19 Nov 1573. At that time Chew Stoke was part of the parish of Chew Magna.

[7] - International Genealogical Index, Rev. Jan 1988, Gloucestershire County, Page 16,867..

[8] - Boyd's Marriage Index for Somerset, Society of Genalogists (www.englishorigins.com).

[9] - A Dictionary of British Surnames, P. H. Reaney, Routledge and Kegan Paul, 1958.

[10] - An Etymological Dictionary of Family and Christian Names, William Arthur, Shilds Blakeman and Co, 1857.

[11] - Norensis is the Latin variation of the name Noreis

[12] - Surnames of Scotland, George Black, New York Public Library, 1946.


Posted in: Genealogy  Tags: ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

This week I attended my first ASPInsiders Summit.  Thanks to Scott Hanselman, our Microsoft liaison and Scott Galloway, about 30 of the ASPInsiders descended on the Redmond campus for meetings with the ASP.NET team.  The goal of the meeting was to allow the team to present some of their plans for the next release of ASP.NET and for us to provide some feedback.  As I am covered by an NDA I cannot reveal the substance of any of those discussions - sorry .

During one presentation on the MVC Framework, we got bogged down in a debate about the differences between MVC and WebForms, and TDD (Test Driven Development).  One Insider said - "My customers won't pay for me to spend the effort on Test Driven Development so MVC does nothing for me". 

Wait a minute, I thought, there's more to MVC than TDD, and it occurred to me that if an ASPInsider with our contacts with the team and our involvement in the ASP.NET Community feels this way, what does that mean for the ASP.NET Community at large?

ASP.NET MVC is a whole new way of doing web development for ASP.NET developers.  While it allows for full testability it does not require it, and while it supports TDD it certainly doesn't require developers to use that development method.  The ASP.NET MVC Framework being developed provides developers with a new and flexible way to build Web Applications.

And to dispel another myth - MVC does not replace WebForms - the tried and true method of developing ASP.NET Web Applications is here to stay.

Unfortunately, it seems to me, that the Microsoft message is putting too much focus on TDD, rather than all the benefits of MVC - Separation of Concerns, Control over HTML, Testability (not just TDD) and others. 

So before this product goes to RTM - lets get the message right


Posted in: ASP.NET  Tags: , ,

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

 Search Blog

 Adsense

 Calendar

«  January 2009  »
MoTuWeThFrSaSu
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678
View posts in large calendar

 Recent Posts

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2009 Thoughts from the Wet Coast