Add StudioContentNode class to allow scripted curation of existing content from Studio #412
Conversation
| @@ -615,6 +619,68 @@ def validate(self): | |||
| assert len(tag) <= 30, ( | |||
| "ERROR: tag " + tag + " is too long. Tags should be 30 chars or less." | |||
| ) | |||
|
|
|||
There was a problem hiding this comment.
This was just moved up from a subclass to ensure it gets run for all node types.
There was a problem hiding this comment.
(same with the "role" stuff above)
jamalex
force-pushed
the
remote_content_nodes
branch
from
d85aa7a to
d464ee9
Compare
There was a problem hiding this comment.
Code looks good to me and the examples make it clear how it can be used - just had non-blocking thought on the example code.
One thought was that it might be a bit more consistent and clear to use Studio in place of Remote in the naming scheme since that's where we're getting the node from.
examples/remotecontent/sushichef.py
Outdated
|
|
||
| SOURCE_DOMAIN = "testdomain.org" ## change me! | ||
|
|
||
| original_channel_data = { |
There was a problem hiding this comment.
As I read through this it was odd that this null-filled dict was being referenced in a class definition until I got to the bottom and saw how the values were being set before the constructor call.
I think that this would read a bit more clearly if the values for this were passed as kwargs to the CuratedChannelChef constructor.
There was a problem hiding this comment.
The reason for this was that we need somewhere "global" to store the computed IDs that are generated during the creation of the original channel -- which would be messy to pull out later through introspection of that channel.
In terms of how they then get passed into the curated chef, I agree that arguments would be nicer. But currently the kwargs passed into a chef constructor are then just ignored completely and not stored anywhere. There are lots of things around these ricecooker idioms I'd love to rearchitect, but I was picking my battles for this PR.
There was a problem hiding this comment.
(For now I'll add a comment here to make this clearer, though)
Yeah, this was @rtibbles' recommendation to match the naming pattern of |
|
This change seems fine, but the backcompat alias would be helpful. Then in 3 years' time when we allow ricecooker to run against Kolibri we can rename it to |
jamalex
changed the title
|
In order to support the ability to create a new channel that includes content nodes that already exist on Kolibri Studio, this PR introduces a new node class called
StudioContentNode, which is provided with a reference to the IDs of content nodes that already exist on Studio, along with potential overrides of existing metadata such as the title, tags, or thumbnail. Studio then clones the existing node from its source channel and puts it into the appropriate spot in this newly cheffed channel.This PR depends on changes @rtibbles shall shortly open a PR for on https://github.com/learningequality/studio.