You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is not really an issue in the sense of malfunction, but more about logic or "cleanness".
Lets say we have the endpoints /api/notes and /api/notes/{id} which acting on all CRUD operations. The records created by this endpoints always belonging to the current user, so the CurrentFeUser() serializer is used on a $user attribute. In this way, the user property is always shown in the response data-structure, which is "useless" as it is always the user itself.
Adding Exclude() to the property does not work, as it disables all serialization and will return NULL for getUser() than (which is expected, sure!). Also using serialization-groups doesn't work, as the $user attribute could be omitted in collection and item GET responses, but has to be set for POST and PUT (other wise user is NULL again). The latter case would make trouble in the front-end code as well, as the object structure varies (user attribute is sometimes there, sometimes not)
For now we keep the user attribute in all responses and ignore it in the front-end. Like I said, its not an issue, but maybe an improvement for a later versions. Maybe it is even possible, that the property where CurrentFeUser() is used on excludes itself in the response (but will be there for the internal database handling). If someone really wants to include the user, an explicit Include() needs to be set or so...
This discussion was converted from issue #27 on March 29, 2021 09:55.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The following is not really an issue in the sense of malfunction, but more about logic or "cleanness".
Lets say we have the endpoints
/api/notes
and/api/notes/{id}
which acting on all CRUD operations. The records created by this endpoints always belonging to the current user, so theCurrentFeUser()
serializer is used on a$user
attribute. In this way, the user property is always shown in the response data-structure, which is "useless" as it is always the user itself.Adding
Exclude()
to the property does not work, as it disables all serialization and will return NULL forgetUser()
than (which is expected, sure!). Also using serialization-groups doesn't work, as the$user
attribute could be omitted in collection and item GET responses, but has to be set for POST and PUT (other wise user is NULL again). The latter case would make trouble in the front-end code as well, as the object structure varies (user attribute is sometimes there, sometimes not)For now we keep the user attribute in all responses and ignore it in the front-end. Like I said, its not an issue, but maybe an improvement for a later versions. Maybe it is even possible, that the property where
CurrentFeUser()
is used on excludes itself in the response (but will be there for the internal database handling). If someone really wants to include the user, an explicitInclude()
needs to be set or so...Beta Was this translation helpful? Give feedback.
All reactions