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
This is a combination of 3 commits. Brace yourself.
For now the taxonomy depth is max 3. Because why not.
This required looking up to parent context for content modelling
information, instead of reaching out to the collection. So, throughout
the depth of the taxonomy, content modelling can manipulate the cascade.
To achieve that, the context object is converted into a stack. An
ImmutableStack class is used to pop() it without worrying. It has a
throwUntil() to dig the stack until reaching a point of interest (for
example digging the context to find a collection). That was needed to
avoid passing post and category contexts to tags, as tags don't carry a
hierarchial-relationship in respect to them.
Now, each subCategory can define content-modelling attributes in its
index file. Therefore, each subCategory can have a custom indexFileName
and custom names for its subCategories and posts. For example:
Demos (collection contentType: DemoPortfolio)
- CSS (category contentType: Technology)
+ CSS-Only (category contentType: Technique)
+ Sliding Doors (category contentType: Technique)
- Three.js
- Whatever
The easiest way to deal with rendering subCategories was to merge
the rendering counterpart of models into the models themselves. So,
now, in addition to match() and create(), there's a render(). The render()
is pretty scrappy for now and probably needs more thinking. One of the
main ideas in this implementation is to nest the rendering of the
model's child entities (e.g. for a category, rendering of subCategories,
posts, attachments) into the models' render(). When root render()s,
render flows downstream from there. So, CM2's rendering counterpart is
now only the renderer itself, there's no more views.
Invent something called 'levelPosts' in Category. It contains only the
posts belonging to the category's specific depth. The regular 'posts'
field contains all posts downstream. This was particularly necessary to
avoid duplicate rendering of sub-categorized posts. So, each category
renders only its levelPosts.
For now, inject the global settings and debug as dependencies into
models. That's for keeping templates' access to those. Maybe a classier
way is needed.
Also, don't pass keys like collection and category into the templates
any more.
Should the pagination helper be kept in renderer though? Feels much like
it's a content-model thing. But the code implies otherwise.
0 commit comments