Yes, I agree, it definitely is a property of the user not the entry. In fact there already is a user property called sticky (which is an ordered list of the user's stickies in the current state of the implementation and just the number of the sticky the central code base).
Possibly my problem is that I want to process this form value in _do_post not in _decode and the current structure of the two methods means the simplest way to do that seems to be to store the value in the props hash - however props obviously has some connection with the properties.
I _think_ I could still use the sticky userprop for this (since the value never actually gets written to the database, just stored in the hash) but that seems like really bad practice to put a value in the hash which is of a different type (i.e. a number rather than a list of numbers) to the actual value stored in the database.
I suppose the ideal solution is actually _not_ to put the value in props at all, but to process that particular value of the form input separately... hmm... I'd need to look at the code and at the moment that isn't really going to be practical for a few days.
no subject
Possibly my problem is that I want to process this form value in _do_post not in _decode and the current structure of the two methods means the simplest way to do that seems to be to store the value in the props hash - however props obviously has some connection with the properties.
I _think_ I could still use the sticky userprop for this (since the value never actually gets written to the database, just stored in the hash) but that seems like really bad practice to put a value in the hash which is of a different type (i.e. a number rather than a list of numbers) to the actual value stored in the database.
I suppose the ideal solution is actually _not_ to put the value in props at all, but to process that particular value of the form input separately... hmm... I'd need to look at the code and at the moment that isn't really going to be practical for a few days.