Hi, Nice work Robert.
@Jason: I do believe there is value in yaml frontmatter. A lot of existing tools support markdown + frontmatter and people using them are familiar with that. Adding something Sling specific is going to make interoerability harder. It is going to be non portable as well. I'm in favor of using front matter. It will help port markdown apps to sling and promote interoperability between such apps. Regards, Eugen Stan Netdava International Mesaj original De la: jason.bai...@24601.org Trimis: 28 iulie 2018 20:28 Către: dev@sling.apache.org Răsp. la: dev@sling.apache.org Subiect: Re: Markdown resource provider I believe there's a difference between what the two end goals are. There is a the rendering of a Markdown resource into HTML and then there is using a Markdown file to generate a resource. A couple of thoughts on this. # For a Markdown Resource providing attributes, I don't see a reason to use YAML for this. Markdown support integrated HTML and HTML supports custom tags. You could create some thing along the lines of <resource-props data-sling-resourceType="foo"> this wouldn't be displayed when viewing a rendered version of the file but be accessible when parsing. # We have a module for taking different file types and creating a Resource Object out of them, that's the ContentParser. If the goal was to import the md file into an existing resource we'd use the ContentLoader. If we wanted the ability to read and write the file then I see a ResourceProvider and since we have a FSResourceProvider I still think it makes sense to allow that to be expandable. -- Jason On Fri, Jul 27, 2018, at 10:31 AM, Carsten Ziegeler wrote: > > > > > Daniel Klco wrote > >> My first thought after reading the last paragraph was - Wouldn't it be > >> cool if the FsResourceProvider was extensible so that specific files could > >> be rendered in a specific manner, then you could add a MarkDown Handler and > >> it would make it easier for other people to add custom handlers or to > >> extend existing one for specific requirements. > >> > > > > Agreed! This mechanism could be useful for XML or JSON files as well. > > Imagine if one could register an XSLT handler and just have Sling serve the > > rendered HTML for a dump of XML files. > > > > That's why I mentioned the resource decorator approach - it allows you > to do this, and then you're even independent of the resource provider > serving the resource. > The decorator approach might not be the most obvious one, but I think it > does the trick and doesn't require us to add another overlapping concept. > > Regards > Carsten > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
