Skip to content
This repository has been archived by the owner on Sep 29, 2023. It is now read-only.

bone specific renderings moved and split to their Bones. #122

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

akelch
Copy link
Member

@akelch akelch commented Jan 11, 2019

bone specific renderings moved and split to their Bones.
As a result we don't need to override the renderer for new Bones.

@phorward
Copy link
Member

Hello @XeoN-GHMB,
and thank your very much for this great pull request.

I did a review on you changes, tested it with a real project and and... I like it! Especially it is downward compatible, so no changes are necessary to existing projects, it doesn't contain any breaking changes, great!

I just did a commit 9600cd2 on your pull request. It changes a lot, but most of it are changes to fit into our general coding standards.

I'd also added some general changes to the pull request:

  • The renders now provide a member variable called render which contain a name for each renderer. So "xml", "html" and "json" are the base renders, vi and admin contain "json.vi" and "json.admin" within their render.render variable. This avoids many imports, which become needless in this case.
  • I've renamed renderObj to render because this is also the case in Jinja extensive functions, and shorter...

Yep, thats all. In my opinion this pull request brings much more flexibility into ViUR. I've already updated the recordBone from a company-internal project and it integrates perfectly. I would like to flag it for ViUR v2.5 if all are comfortable with it.

…e, which can be used in a Bone to avoid overriding the whole function. The rendererName can be dot separated. In this case the rendererName is resolved from back to front to find a matching function. The default uses the not prefixed version.
…work/server into feature/moving_bone_rendering

# Conflicts:
#	bones/bone.py
#	bones/captchaBone.py
#	bones/dateBone.py
#	bones/numericBone.py
#	bones/relationalBone.py
#	bones/selectBone.py
#	bones/textBone.py
#	render/admin/__init__.py
#	render/json/default.py
#	render/vi/default.py
#	render/xml/default.py
@akelch
Copy link
Member Author

akelch commented Jan 18, 2019

Hello @phorward,
i used some of your suggestions to improve this feature.
Each Renderer has now a rendererName. This name can, as you suggested, be dot separated.
The Renderer tries to resolve this Name from back to front and uses the first match. If no matching function is found, the non prefixed version of the function will be used.

With this mechanic it is possible to append a new renderer without overriting the whole function and multiple definitions for vi and admin renderer are not needed if they are named json.vi or json.admin

return bone.value.strftime("%H:%M:%S")

elif isinstance(bone, relationalBone):
for renderer in reversed( self.rendererName.split( "." ) ):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should spend a few more thoughts on speed. This would be the most flexible solution, but we'll have have this loop running for each bone in each entry returned. Maybe we should drop sub-classing support here and have only the base-name (ie "html") in that variable so simply know the function to call?

@@ -465,3 +465,18 @@ def setBoneValue(self, valuesCache, boneName, value, append, *args, **kwargs):
return True
else:
return False

def renderBoneStructure( self, renderer = None, *args, **kwargs ):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the structure guaranteed to be identically for each render? Otherwise we should also pre/post-fix this function.

…derBoneStructure and renderBoneValue to a new baseRender Class to avoid multiple definitions for each renderer. Each Bone could define a renderType prefixed version of renderBoneStructure and renderBoneValue if this function not exists the baseBone fallback will be used.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants