sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason E Bailey <...@apache.org>
Subject Re: Markdown resource provider
Date Sun, 29 Jul 2018 13:30:36 GMT
Eugen - I didn't realize that it was a thing. So I'm good with it.  However I now have a strong
desire to make an HTML resource provider that will define resources trees with HTML, which
you can then use to generate HTML. A meta-HTML :) 

- Jason


On Sun, Jul 29, 2018, at 1:52 AM, Ioan Eugen Stan wrote:
> 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.bailey@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
> > cziegeler@apache.org

Mime
View raw message