Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
is Asciidoc java integration able to integrate with a Virtual File System for resolving resources such as inclusion ?
Intellij works with a VFS and does not provide physical files. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Administrator
|
We could certainly do it, though I don't think it's capable today. If you point to a strategy for doing VFS, I'm sure Alex and others interested in hacking on the java integration would be eager to add this feature. Naturally, if this warrant changes in Asciidoctor core, we can get that updated as well. -Dan On Jul 25, 2013 2:06 AM, "julien [via Asciidoctor :: Discussion]" <[hidden email]> wrote:
is Asciidoc java integration able to integrate with a Virtual File System for resolving resources such as inclusion ? |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by julien
Hi Julien,
I am Alex, the leader of Asciidoctor-Java-Integration project, I think it could be interesting adding support for VFS, I have never worked with it, so it is something new, but of course we can talk about it and integrate it. On the other side if you are thinking about supporting VFS inside AsciiDoc format (for example for using in include keyword) I think it would require some changes on Asciidoctor gem, or in next release developing an extension to resolve VFS locations. Well if you need anything from Asciidoctor-java-integration project feel free to ask it, and of course we are in touch for VFS support. Alex. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by julien
Replying to myself since I can't reply to both Dan and Alex at the same time :-)
Now, the IDE plugin would have to locate all relevant adoc files and copy them to a temp directory before doing a render. It can be resource consuming for the IDE and also could raise other issues. With a basic resource resolution (like "Reader resolveResource(String uri)" ), Asciidoc can decouple the identifier of a resource from the actual content of this resource allowing an IDE plugin to delegate to the IDE filesystem. (note that would also ease integration in content management system, ServletContext#getResourceAsStream(), etc...). |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
I think I am missing something about VFS:
If the problem is resolving the document that is going to be rendered (in most cases transform an URI to a Reader instance), Asciidoctor-java-integration project offers a method where you can pass a Reader object, so I think that this transformation should be managed externally from asciidoctor-java-integration project, resolveResource method it is something specific of each system. If the problem is with include keyword then from java part we cannot do anything. Again maybe I am missing something and some changes on java part should be done. Alex. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Yeah, I can see includes being a little bit of a problem. Dan, sounds like we're starting to build up the need for an SPI in core. If we had an SPI from core where it calls out to something to retrieve the referenced resources we'd be good. Of course we'd need Language X to Ruby capabilities, but with JRuby that's hardly a problem.
This also presents a possible performance hit, but it would be minor and we'd gain quit a bit from it. On Thu, Jul 25, 2013 at 10:13 AM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: I think I am missing something about VFS: ... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
In reply to this post by asotobu
I haven't been clear enough. The resolver is useful when Asciidoc process includes. At the moment it seems that processing an include resolves to the file designed file on the filesystem (likely resolving to a java.io.FIle with jruby). In case of Intellij, it would be resolved using the Intellij VFS.
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Yes, I understood this, sorry if my response didn't seem to indicate this. What I'm proposing is an SPI to allow you to create different resolvers and plug them into Asciidoctor core. That way it wouldn't have to be a file. As long as what Asciidoctor receives from this chain, hierarchy, whatever will resolve and return that resource in a way that Ruby can read it we're good. You'd need to write to whatever it is so that you can * register it with Asciidoctor * have it return something that Asciidoctor can use We could use this to resolve Files, URIs, VFS entries, bits stored in a database or other datastore.
On Thu, Jul 25, 2013 at 2:27 PM, julien [via Asciidoctor :: Discussion] <[hidden email]> wrote: I haven't been clear enough. The resolver is useful when Asciidoc process includes. At the moment it seems that processing an include resolves to the file designed file on the filesystem (likely resolving to a java.io.FIle with jruby). In case of Intellij, it would be resolved using the Intellij VFS. |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
can you schedule it in Asciidoctor roadmap ?
|
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
If it is inplemented as Jason said, then I will implement in Java part. We have been playing with Dan with something similar for extensions, so for this case an interface would be created, so resolvers could be written in Ruby or Java
El dijous 25 de juliol de 2013, julien [via Asciidoctor :: Discussion] ha escrit: can you schedule it in Asciidoctor roadmap ? -- Enviat amb Gmail Mobile |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Dan is pretty much the owner and lead for the project. I'll have to defer to him for scheduling and design decisions. On Thu, Jul 25, 2013 at 3:13 PM, asotobu [via Asciidoctor :: Discussion] <[hidden email]> wrote: If it is inplemented as Jason said, then I will implement in Java part. We have been playing with Dan with something similar for extensions, so for this case an interface would be created, so resolvers could be written in Ruby or Java ... [show rest of quote] |
Loading... |
Reply to author |
Edit post |
Move post |
Delete this post |
Delete this post and replies |
Change post date |
Print post |
Permalink |
Raw mail |
Actually if someone can come up with a small specification for this work in the Ruby part (a doc that describes what to do at high level), I'm willing to implement it.
Although I don't know the Ruby language at all, it would be a good incentive and opportunity for me to learn it. let me know if that is feasible. |
Free forum by Nabble | Edit this page |