LDPSerializer dependent on view and request
There are several points in the LDPSerializer
code where it relies on the Request and View objects in the context. This prevents us from being able to use it outside of strict boundaries
Permissions
One reason why the request/view are accessed is during the serializing of permissions, which invariably require the view/request for context. This could be refactored by passing the permissions into the serializer during construction, if they are missing then don't serialize them (#299 (closed) , #277 )
Serializer cache
The cache is varied on the user. I think that the cache could probably also be bypassed when no request is present - leaving it up to the developer to make their own performance improvements
Resolving ID
-
many_init
uses the request path to resolve the container's urlid. Perhaps here we could pass in the urlid as a parameter or use a Blank node if none is present - Rest Framework's
HyperlinkedField
uses the request to resolve the ID. We often use theurlid
of the instance and I'm not sure that we would want to inherit the behaviour that generates one, since it duplicates the urlid-generation logic
Resolving parent_model in LDListMixin
Needs further research
With the changes suggested in #277 it may be that the LDPModelSerializer
(or a variation of it) has to become coupled to the view in this way, but it should be totally possible to decouple at least the LDPSerializer
from this, which should be possible to use freely as it is in DRF