-
Notifications
You must be signed in to change notification settings - Fork 14
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
refactor: Move JSON-serializable rendering into the bones
#1000
base: develop
Are you sure you want to change the base?
refactor: Move JSON-serializable rendering into the bones
#1000
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @ArneGudermann,
thanks for facing this!
I'm a little bit unlucky with the naming regarding values and single_values... but this is a general problem in the current implementation that must be redesigned in the whole bone system.
For now, we can make it this way. Can you please add the suggestion to the VIUR4 issue #647, this is important to clean-up the interface, especially for newbies. Oops, this was related to the structure rendering, I'm sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but this PR in this form makes no sense to me. The rendering of respectively for ALL renderers should be in the bones, not just for one. In addition, render_single_value
should be passed the current renderer by argument, so that different outputs can be generated.
The intention of this PR is to turn a JSON-serializable rendering of values into the bones logic, for easier maintenance. It will be the base for further developments regarding JSON, XML and MsgPack renderers, because rendering stuff into JSON-serializable structures is heavily used in several situations. The only special case is the HTML renderer for Jinja, which mostly just provides an adaption of the existing objects for faster access. This is a pull request on its own. Indeed, this pull request doesn't address all cases of the concept, but this wasn't the goal.
This could be considered in a follow up on this pull request, but it should be optional. The rendering is separated from the renders here, so turning data into equal structures is the main target to achieve. |
Bones
bones
@ArneGudermann please fix the conflicts with current develop. |
Proposal to fix #1064. I'm still a little unhappy with this, as it bites with #1000, but after all it's a different use case. Maybe we can bring both together in some way. --------- Co-authored-by: Sven Eberth <[email protected]>
@ArneGudermann I would like to add this PR to viur-core 3.7, can you please resolve the conflicts and we can make another iteration over it? |
This PR moves the JSON rendering to the bones.
Resolves #978.