sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioan Eugen Stan <>
Subject Re: Markdown resource provider
Date Sun, 29 Jul 2018 05:52:42 GMT

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.


Eugen Stan 
Netdava International

  Mesaj original  
De la:
Trimis: 28 iulie 2018 20:28
Răsp. la:
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. 


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
View raw message