forked from php-annotations/php-annotations
-
Notifications
You must be signed in to change notification settings - Fork 0
/
todo.txt
98 lines (71 loc) · 5.39 KB
/
todo.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
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.