Looking at line 30 of DefaultConfig you will notice that the path option only accepts the folder within a projects source as the input.
However given the potential addition of internationalization with #259 it would be beneficial to allow developers to dictate how the path gets parsed.
For example by default Tapestry will only look at filenames of any file found within a content type path for the date and slug e.g. 2017-10-05-post-title-slug.md. The aforementioned could be parsed by the following path option template: _blog/{yyyy}-{mm}-{dd}-{slug}.{ext} or _blog/{yyyy}-{mm}-{dd}-{slug}.md if they wanted to only deal with mark down files. This then opens people up to having their posts organised in folders for example _blog/{yyyy}/{mm}/{slug}.{ext}
Using the template paths Tapestry would better be able to fill a page's meta data while at the same time adding flexibility to how developers choose to lay out their projects.
Looking at line 30 of DefaultConfig you will notice that the
pathoption only accepts the folder within a projects source as the input.However given the potential addition of internationalization with #259 it would be beneficial to allow developers to dictate how the path gets parsed.
For example by default Tapestry will only look at filenames of any file found within a content type path for the date and slug e.g.
2017-10-05-post-title-slug.md. The aforementioned could be parsed by the followingpathoption template:_blog/{yyyy}-{mm}-{dd}-{slug}.{ext}or_blog/{yyyy}-{mm}-{dd}-{slug}.mdif they wanted to only deal with mark down files. This then opens people up to having their posts organised in folders for example_blog/{yyyy}/{mm}/{slug}.{ext}Using the template paths Tapestry would better be able to fill a page's meta data while at the same time adding flexibility to how developers choose to lay out their projects.