Customizing mode loading ...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Customizing mode loading ...

Bernd Wechner
Found this lovely doc:

But it leaves me with a thirst for more knowledge. My conclusion form reading it is, that if I wanted to put a hook into some custom code that always ran after data was loaded from the database, and after the model instance is created (populated with data) I would need to dos something like:

class Book(models.Model):
    title
= models.CharField(max_length=100)

   
@classmethod
   
def create(cls, title):
        book
= super().create(cls, title)
       
# hook to custom code here
       
return book

   
@classmethod
   
def from_db(cls, db, field_names, values):        
        book
= super().from_db(cls, db, field_names, values)
       
# hook to custom code here
       
return book

   
def refresh_from_db(self, using=None, fields=None, **kwargs):
       
super().refresh_from_db(using, fields, **kwargs)
       
# hook to custom code here

Taking note that the last of these is an instance method and the first two are class methods and returns nothing.

The documentation is not very clear in this space.

If that hook took the simple form of:

if hasattr(book_or_self, "_post_load") and callable(book_or_self._post_load):
     book_or_self
._post_load(book_or_self)

Then defining a model method _post_load(self) would provide a place to put code that ran reliably before any other code could inspect the instance?

It seems a little clunky almost as if it would be neater if there were a signal issued at that point in time by django base, but could be tidied up by writing
a new model class that derives from models.Model, like ModelWithPostLoadHooks and deriving a model from that if it wanted to have such hooks.

Musing here, and wondering if I have it right.

Bernd.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9c2b8368-6620-4387-83a7-f52390a0e921%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Customizing mode loading ...

Bernd Wechner
Well, not a single reply. So I'll reply with confirmation that the strategy below seems to work just fine! Have implemented what I need using that. Three distinct methods through which django loads a model instance (object) from database and overriding these provides a hook into making an object modification on load. Combined with the very awesome django-cuser which makes request.use available to these methods you can make mods tot he object based on the logged in user, at load time, so before it reaches any view. Important if you want one change to apply to a multitude of views. I use this to enforce privacy on certain fields, marke them appropriately and overrride save() to similarly not save private fields. And it all works like a charm!

On Monday, 5 March 2018 14:53:15 UTC+11, Bernd Wechner wrote:
Found this lovely doc:

<a href="https://docs.djangoproject.com/en/2.0/ref/models/instances/#customizing-model-loading" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Fmodels%2Finstances%2F%23customizing-model-loading\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-UJJbsC1bu5BjEtD2MTP-5M3UXA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.djangoproject.com%2Fen%2F2.0%2Fref%2Fmodels%2Finstances%2F%23customizing-model-loading\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE-UJJbsC1bu5BjEtD2MTP-5M3UXA&#39;;return true;">https://docs.djangoproject.com/en/2.0/ref/models/instances/#customizing-model-loading

But it leaves me with a thirst for more knowledge. My conclusion form reading it is, that if I wanted to put a hook into some custom code that always ran after data was loaded from the database, and after the model instance is created (populated with data) I would need to dos something like:

class Book(models.Model):
    title
= models.CharField(max_length=100)

   
@classmethod
   
def create(cls, title):
        book
= super().create(cls, title)
       
# hook to custom code here
       
return book

   
@classmethod
   
def from_db(cls, db, field_names, values):        
        book
= super().from_db(cls, db, field_names, values)
       
# hook to custom code here
       
return book

   
def refresh_from_db(self, using=None, fields=None, **kwargs):
       
super().refresh_from_db(using, fields, **kwargs)
       
# hook to custom code here

Taking note that the last of these is an instance method and the first two are class methods and returns nothing.

The documentation is not very clear in this space.

If that hook took the simple form of:

if hasattr(book_or_self, "_post_load") and callable(book_or_self._post_load):
     book_or_self
._post_load(book_or_self)

Then defining a model method _post_load(self) would provide a place to put code that ran reliably before any other code could inspect the instance?

It seems a little clunky almost as if it would be neater if there were a signal issued at that point in time by django base, but could be tidied up by writing
a new model class that derives from models.Model, like ModelWithPostLoadHooks and deriving a model from that if it wanted to have such hooks.

Musing here, and wondering if I have it right.

Bernd.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/e340d975-e008-4ccc-bf38-1be211cf046f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.