The Content Interface

  Everything in Mortar is about content. The most basic interfaces in
  Mortar are for working with content in a very generic fashion.

  So, lets start by creating a piece of content:

  >>> from mortar import content
  >>> fred = content()

  Lets give Fred a name:

  >>> fred['name'].set('Fred')

  Maybe Fred also needs an age:

  >>> fred['age'] = 42

  You can see here that we have two different ways of setting fields
  on a piece of content. The reason for this is in case we need to be
  more expressive:

  >>> from mortar import types
  >>> fred['date of birth'].set('1965/11/01',type=types.date)
  
  We can now see that Fred's date of birth has been stored as a date:

  >>> fred['date of birth'].get()
  datetime.date(1965, 11, 1)

  The date parsing used is fairly flexible:

  >>> fred['date of birth'].set('13th June 1978 20:01',type=types.datetime)
  >>> fred['date of birth'].get()
  datetime.datetime(1978, 6, 13, 20, 1)

  But, for the time being, be aware that ambigous dates will be parsed
  as if they were in non-american format:

  >>> fred['date of birth'].set('4/5/08',type=types.date)
  >>> fred['date of birth'].get()
  datetime.date(2008, 5, 4)

  If we wanted his date of birth as text, we could use a similarly
  more expressive version of get:

  >>> fred['date of birth'].set('1965/11/01',type=types.date)
  >>> fred['date of birth'].get(type=types.text)
  u'1965/11/01'

  However, since we often want to get field values as text, fields can
  also be easilly converted to unicode strings:

  >>> unicode(fred['date of birth'])
  u'1965/11/01'

  We can also ask each field what type of data it contains:

  >>> fred['name'].type
  <InterfaceClass mortar.types.text>
  >>> fred['date of birth'].type
  <InterfaceClass mortar.types.date>
  >>> fred['age'].type
  <InterfaceClass mortar.types.number>

  Now that we have a date of birth, we don't need an age anymore:

  >>> del fred['age']

  As with many things, we've also remembered that it's often a good
  idea to store first and last names seperately:

  >>> fred['first name'] = fred['name']

  We should probably note here that the above operation copies the
  value of the field, not the whole field, so if we change the 'name',
  the 'first name' field is unaffected:

  >>> fred['name'].set('rubbish')
  >>> fred['name']
  <Field 'name' containing u'rubbish'>
  >>> fred['first name']
  <Field 'first name' containing u'Fred'>

  In this case, however, we don't need the 'name' field anymore once
  we've stored Fred's last name:  
  >>> fred['name'].delete()
  >>> fred['last name'] = 'Jones'

  Okay, so now we want to record Fred's address. We already know that
  adding address fields to our existing content for Fred is probably a
  bad idea, so lets store his address in a seperate piece of content:

  >>> address = content()
  >>> address['number'] = 1
  >>> address['road'] = 'doe avenue'

  Now we can specify that this is Fred's address:

  >>> fred['address'] = address

  
  >>> address2 = content()
  >>> address2['number'] = 1
  >>> address2['road'] = 'doe avenue'

  Blah

  We can see what fields are actually in any piece of content by
  looking at the 'names' attribute of that content:

  >>> fred.names
  ['address', 'date of birth', 'first name', 'last name']

  We can use this information to, for example, display all the fields
  in a piece of content:

  >>> for name in fred.names:
  ...   print name,':',unicode(fred[name])
  address : Reference to None
  date of birth : 1965/11/01
  first name : Fred
  last name : Jones

