Repository navigation
Dynamic Content Brainstorming #344
Description
Strawman Model
Imagining we adopt https://cel.dev/ and trust a Python binding for it...
class Selector(Model):
cel_query = TextField(...)
@property
def compiled_cel_query(self) -> CELQuery:
return CELQuery.parse(self.cel_query)class ContainerVersionSelector(Model):
selector = FK(Selector)
container_version = FK(ContainerVersion, related_name="cv_selectors")def get_children(container_version) -> list[PubEntVersion]:
children = container_version.entity_list.entities
params = ...
for cv_selector in container_version.cv_selectors:
children = cv_selector.selector.compiled_cel_query.evaluate(
context=dict(children=children, params=params)
)
return childrenclass ItemBank(Selector):
count = IntegerField(...)
def __init__(self, count):
super().__init__(count=count, cel_query=(
"random_shuffle(params.seed, random_choice(params.seed, children, count))"
)Metadata
Metadata
Assignees
Labels
No labels
Activity
[-]Selectors Brainstorming[/-][+]Dynamic Content Brainstorming[/+]<conditional>#363<randomize>#364<split_test>#365<item_bank>,<library_content>#366kdmccormick commentedon Aug 21, 2025
Let's pick apart two properties of dynamic content:
Analyzing known dynamic content blocks:
Still need to consider dynamic content which occurs outside of the scope of those blocks.
kdmccormick commentedon Aug 26, 2025
@ormsbee , @bradenmacdonald We had discussed a "flat" data model, where any given container's dynamic children would be rendered inline with its static children, and some "rules" (defined at the container level or the course level) would decide which dynamic children to hide for any given user. There's appeal to this, but as an authoring data model, I think it falls short in two areas:
Ordering: Dynamic children, particularly for an ItemBank, might need to appear in a different order for different users. But, the dynamic children may be surrounded on either side by static children with a constant order. Imagine a unit like this, where each B is an ItemBank configured to show 2 ordered random items, and each C is a regular component:
C0, B1, C2, B3, C4<- author viewC0, B1.3, B1.7, C2, B3.9, B3.1, C4<- learner viewIf each
Bwere not a node in the authored hierarchy, then I'm not sure how we'd encode that fact that eachB1.$xneeds to appear in a random position between C0 and C1 and that eachB3.$yneeds to appear at a random position between C2 and C4.UI and OLX correspondence: Now, I know that we are in no obligation to make our authored data model match OLX and the Studio UI, both of which currently encode several types of dynamic content as container-like things (
<split_test>,<itembank>, etc.). But, I think that we are introducing a certain amount of complexity and surprise by not choosing to make the authoring data model correspond to OLX and the UI. And that additional complexity would need to be seriously justified by some other data modelling benefits, and I'm just not seeing those concrete benefits right now.With that said, I do think it's natural to encode dynamic children flatly for a learner outline. Particularly, the outline model that @ormsbee is describing in #360 could exclude "dynamic containers", and instead just encode a static version of every outline that any user has seen.
For this reason, I am considering the idea of Pool, which would be a new type of PublishableEntity, but neither a Component nor a Container. It would appear as a node in the content hierarchy for authoring purposes, and it would have an orderless EntityList (or EntityList-like thing) for all its possible children. But, it would not manifest in the content hierarchy for learning purposes; we would have some pluggable subsystem that picks an ordered sub-list for every learner, and concatenates that sub-list into the parent container. (I have more semi-formed thoughts on this that I'd love to talk through today)
bradenmacdonald commentedon Aug 26, 2025
@kdmccormick I'm a bit reluctant to add a new "type" alongside container and component, but your points make a lot of sense.
Also, your
Poolin the container hierarchy seems to play the exact same role as theDynamicContentplaceholder that I had been starting to think about for the purposes of materializing the entire authoring outline hierarchy.bradenmacdonald commentedon Sep 5, 2025
As mentioned on another issue, I recently learned about three more examples of dynamic selector use cases:
kdmccormick commentedon Sep 5, 2025
Thanks, those are great to know about.
Thinking out loud, I wonder if replacing non-leaf block types in a backwards compatible way would require 3 separate plugin systems: