[feat] models/data files #32

Closed
danreeves opened this Issue Apr 15, 2016 · 4 comments

Comments

Projects
None yet
2 participants
@danreeves

Support for models (as in Mixture) or data files (as in jekyll) is very useful.

Proposal:

  • configurable data folder in _config.yml
  • files named matching a template are pulled automatically
  • a global data file, e.g. _global.json, available everywhere
  • a tag to load models on demand, e.g. {% model 'data.json' as data %}

Thoughts? Should this be a plugin or core?

@hswolff

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Apr 15, 2016

Member

I like this! A lot of what you suggested sounds good. Thoughts:

I'm conflicted on whether this should be a new collection type or just be a new primitive type. My instincts say this should be a DataCollection that you can just configure as a new collection. This allows you to have multiple location of data files, not just one fixed location. What do you think would be better?

Whether it's a DataCollection or one-off thing I think at the end of the day it should process .json, .js, and .yml at first and whatever JSON object they convert to will be available as a variable for all templates to use.

I think having this in core is worthwhile. I made CollectionTypes extendable and pluggable but this is probably common enough to just include in core.

Also: thanks for opening the issue! :D :D

Member

hswolff commented Apr 15, 2016

I like this! A lot of what you suggested sounds good. Thoughts:

I'm conflicted on whether this should be a new collection type or just be a new primitive type. My instincts say this should be a DataCollection that you can just configure as a new collection. This allows you to have multiple location of data files, not just one fixed location. What do you think would be better?

Whether it's a DataCollection or one-off thing I think at the end of the day it should process .json, .js, and .yml at first and whatever JSON object they convert to will be available as a variable for all templates to use.

I think having this in core is worthwhile. I made CollectionTypes extendable and pluggable but this is probably common enough to just include in core.

Also: thanks for opening the issue! :D :D

@danreeves

This comment has been minimized.

Show comment
Hide comment
@danreeves

danreeves Apr 15, 2016

I would have to dig around and understand the Collection abstraction a little more before I could say whether it fits there or not. I can say that being able to specifically grab named data models is really useful, rather than just looping through all the data models.

I should be able to look more into this next week

I would have to dig around and understand the Collection abstraction a little more before I could say whether it fits there or not. I can say that being able to specifically grab named data models is really useful, rather than just looping through all the data models.

I should be able to look more into this next week

@hswolff

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Apr 15, 2016

Member

Feel free to hit me up on twitter or here with any questions. Would love to expand both the docs and comments in the code to help make things easier to understand.

Member

hswolff commented Apr 15, 2016

Feel free to hit me up on twitter or here with any questions. Would love to expand both the docs and comments in the code to help make things easier to understand.

@hswolff hswolff modified the milestone: 2.0 Oct 1, 2016

@hswolff

This comment has been minimized.

Show comment
Hide comment
@hswolff

hswolff Oct 18, 2016

Member

Got this working! Will be release shortly in v2.0.0!

Member

hswolff commented Oct 18, 2016

Got this working! Will be release shortly in v2.0.0!

@hswolff hswolff closed this in 7941441 Oct 18, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment