Chris,
I think this is something that you should probably do on the database side. Nonetheless, I did get the following code to work.
import datetime
global_contract_date = datetime.datetime.now().date()
def is_valid_contract_date(value):
from dateutil import parser
from django.core.exceptions import ValidationError
try:
dt = parser.parse(value)
except ValueError:
raise ValidationError('Invalid date')
global global_contract_date
global_contract_date = dt.date()
return dt.date().isoformat()
def is_valid_expiry_date(value):
import datetime
global global_contract_date
if global_contract_date:
expiry_date = global_contract_date+datetime.timedelta(days=365)
else:
expiry_date = datetime.datetime.not().date()
return expiry_date.isoformat()
I would highly recommend that you do not do this! There are just too many things that can go wrong with this code. For example, because there is an "Update" checkbox when editing metadata, I can bring up the metadata, change the "contract_date", uncheck the "Update" box behind "contract_date", and click "Save". The "expiry_date" will be updated with the new value of "contract_date", but "contract_date" will not actually change. The end result is that the dates no longer correspond. Also, there are not constraints to make the "expiry_date" dependent on the "contract_date". As a result, I could add the "expiry_date" metadata type to a document that does not even possess the "contract_date" metadata type, making it completely meaningless. There would have to be a major "overhaul" of the metadata subsystem to make these kinds of things work correctly.
I think the use of validators (as I have implemented them) should be limited to validating and, perhaps, normalizing the data (as there is little harm that can be done by the latter).
Gary