sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruben Reusser ...@headwire.com>
Subject Re: Markdown resource provider
Date Sun, 29 Jul 2018 13:45:41 GMT
on a more serious note, this would be possibly great for dita as well 
(for example better process for the xmladdon for AEM)

Ruben


On 7/29/2018 6:30 AM, Jason E Bailey wrote:
> 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