short-video-back/web/vendor/mindplay/annotations/todo.txt

Decide whether type-conversion and property-validation should be a separate framework, or
features built into the annotation classes directly - if not:

  Demo script / annotations:
    add interfaces for type-conversion and property-validation
    simplify demo-script, using type-conversion and property-validation interfaces


Add DataTypeAnnotation

http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.datatype%28VS.95%29.aspx

Custom 	Represents a data type that is not one of the known types.
	DateTime 	Represents an instant in time, expressed as a date and time of day.
	Date 	Represents a data value.
	Time 	Represents a time value.
	Duration 	Represents a continuous time during which an object exists.
	PhoneNumber 	Represents a phone number value.
	Currency 	Represents a currency value.
	Text 	Represents text that is displayed.
	Html 	Represents an HTML file.
	MultilineText 	Represents multiline text.
	EmailAddress 	Represents an e-mail address.
	Password 	Represents a password value.
	Url 	Represents a URL value.
	ImageUrl 	Represents a URL value that is displayed as an image instead of text.


Binding and validation in stages:

1. Client-side property validation

   * Simple validations of individual values, e.g. number, date, time, email, password strength, etc.

2. Server-side binding and validation
   
   This must not rely on client-side property validation in any way - the instant property-validation
   that takes place on the client-side is an added usability feature that provides the user with instant
   feedback for a subset of the overall validation.
   
   Throughout the binding/validation operation, a collection of errors reported for each property is
   available, and at each stage of validation, error messages may be added to these collections.
  
   Binding and validation on the server-side happens in three stages:
   
   * Input binding / type-validation: conversion of individual property values from raw POST data,
     e.g. the date "7/7/1975" would be converted to the timestamp integer value 173937600.
     
     Conversion of values happens with no awareness of an object or other property-values, and changes
     are not applied to the object at this stage.
     
     On successful conversion of the individual property value, we can proceed with the next stage.

   * Property validation: validation of individual property values according to property-validation
     rules - this includes basic rules, including not-empty (required), string-length and numeric range.
     
     Note that we're now working with a real, correctly typed value - for example, a date-string has
     been converted to an integer timestamp at this stage, so the validators are operating on correctly
     typed values. However, they are operating just on the individual value, with no awareness of the
     state of the object as such.
     
     If all of the property-values pass validation, the changes can now safely be applied to the object,
     and this happens as a single, atomic operation - we either safely update the entire state of the
     object, based on a complete set of input that satisfies all of our constraints, or we don't make
     any changes at all.
     
   * Object validation: this last stage of validation operates on the object itself, and typically is
     implemented simply as a method being invoked on the object - this method has access to the error
     collections, so it can add errors based on the current overall state of the object.
     
     Validations that are dependent on multiple properties can be performed at this stage - for example,
     range validations can be performed at this point, such as `$start_date < $end_date` ... the error-
     message can then be added either to one of the input fields, or both - or in cases where the error
     doesn't really related to any specific property, it can be added to a list of errors for the
     object itself.
     
     Binding and validation is complete and ends at this point.

     Note that this pattern does not preclude the possibility of implementing reusable multi-property
     validators, such as for example a range-validator - but even if such validators are specified and
     configured by the same means as the property validators, they cannot execute before this stage.
     
User interface widgets:

HTML-based user-interface abstractions must be value-based. That is, each widget operates on a value,
not on a object, and with no awareness of an object-property. This does not preclude multi-valued
user-interface widgets, it just means that such widgets have their own separate binding/validation
process, which occurs as a unit, during input-validation (stage 1) of a parent object.

UI abstractions must be able to handle raw input values. For example, a date input widget might
receive the value "7/7", which won't pass input-validation because it can't be converted to a date,
because the year is missing. We can't proceed past stage one (input validation) in this case, but we
need to display the form again with an error message explaining why, and the value needs to come back
as "7/7" in the input, so that the user can correct the value.

In other words, the date input widget needs to be able to handle both a valid timestamp, as well as
an invalid raw string - in other words, the date input widget needs to know whether the value it's
being asked to present is a valid, correctly typed value, or a raw input value.