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: [email protected]
Trimis: 28 iulie 2018 20:28
Către: [email protected]
Răsp. la: [email protected]
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
[email protected]
