-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Field lifecycle methods #175
Comments
I think I should keep all the decorator names the same, but have them set foo = Field(int)
# this will set fooset into foo._iset
@foo.isetter
def fooset(self, value):
return value + 1
# foo._iset will get called at the end of foo.iset So I would modify def iset(self, orm, value):
# all the normal iset stuff
if self._iset:
value = self._iset(orm, value)
return value This way I can keep basically the same interface, keep the ever increasing amount of logic in all the lifecycle methods, and still allow easy customization |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The field methods like
fset
etc. are getting more and more complicated, so complicated that it is basically crazy to override them. For example, I've addedfvalue
andivalue
to normalize the values as they are set into the orm and the db, so I can lowercase the value without overriding the currentfset
,iset
, or similar methods.The question is should I make it so you can still override the methods but not override the main calling methods? Basically, make
fvalue
befset
andivalue
beiset
and then have external methods that do all the current things but then call all the definediset
things.I'll have to think about the best way to implement this.
The text was updated successfully, but these errors were encountered: