Add an API version of the rendered output.

[kaiserfro]

I happen to have a use case where I'd like to use the Jingo interface to maintain my wiki contents, however, for my API's audience, I'd like to embed the pages directly into another web application that I already have. For this purpose I'd like to basically expose the page retrieval/rendering part of the application as an API. This API would do the same as the standard /wiki/:page route, however leave out the layout and toolbar parts.

Then I can call the API and load another div in my other application with the result, skin with some CSS and now I've got the wiki pages in my app.

I can edit the pages, live, in the usual way also...best of both worlds.

I don't know if anyone else has the same needs as I do, but I figure I could post my PR, just in case.

[claudioc]

Hi @kaiserfro

this is a basically what I have in mind for Jingo 2, which (if ever released) will split jingo in a REST server and a client (HTML + JS) part. The project will release both of them, so one could use only the server or both to have what we have now :)

Actually your PR is a good idea because it would already meet some of the criteria which are the basis for Jingo 2, but I am not going to merge as it is (I will mention you in the credits nonetheless), because I need to think a bit more about it and I will probably release it with Jingo 1.6.

Thanks a lot!

[almereyda]

In designing this API, do you intend to make use of Linked Data standards such as LDP (for a generalized storage backend) or Hydra (for a self-documenting API)?

Exposing Jingo's data via JSON-LD as RDF would make its content immediately available to DBpedia and easier searchable for anyone due to the structured data attached to pages. Content-Negotiation would even allow for using the same routes and URLs for both machine and browser consumers.

Is there any anticipation about if and/or how to include the Jingo community in preparing 2.0?

[claudioc]

@almereyda wow, lot of food for thought here! I am not familiar with LD and I should definitely take a look at it.

Jingo 2 at the moment (as you'd probably already inferred) is just an idea. It will be a complete rewrite of the codebase (to finally also move to ES2015, SASS and Webpack too). The effort would probably take something around 80 hours which in my current job situation (a crazy startup) would take a long time stretch.

I'd be more than happy to involve other people in this effort but this is also why I want to start the project only when I'd be able to finish it.

[almereyda]

why I want to start the project only when I'd be able to finish it.

Isn't this the main reason why you host the code here, to attract further developers and engage your initially very own project in an ecosystem?

Could you activate the wiki for this GitHub Repository at https://github.com/claudioc/jingo to allow the community to scope expectations, possible hints for implementation and design quirks?
I.e. the role of a plugin/media system if server and client are decoupled (where do they live, how many assumptions does a client plugin make, how's it served)?

---

For a more exhausting investigation of where my motives are coming from:

I'd be happy to contribute content around a simple git-based node Markdown wiki engine, possibly involving real-time capabilities, (nested) templating and even more loosely-coupled alignment with an existing wiki federation (Federated Wiki - http://wikity.net/).

Goal for many could be to replace Hackpad as an "etherwiki", in the simplest form possible and extensible to computational scopes (think of IPython, IJulia) while retaining user ownership of data (Authentication mainly denominated to E-Mail, currently involving GitHub, Google and git, Persona favourable) or bleeding edge "standard" readwriteweb APIs (like LDP, Hood.ie, remoteStorage, etc.).

As you see on http://wiki.transformap.co/wiki/TransforMap, it's even simple to integrate into another federation of annotations by including https://hypothes.is - also see #117.

[claudioc]

It is of course a pleasure to see this project used and contributed to by a lot of people. What I meant with that comment is that – so far – Jingo development has been quite "under control" because I've been able to follow it and because after all it is quite a simple piece of software (I can test and integrate a PR with ease). Of course I'd like to see further and great developments of it but... will I be able to follow them if its community really wants it to become a ecosystem? Isn't there a peril for it to become yet another bloated monster, unmaintainable and horribly patched just to "make it work"? I'd hate that. What could I do then? I'd consider accepting other maintainers, of course, I am not that anal retentive :D

As we already discussed, I don't think Jingo 1.x would be suitable for these features (real time above all, because it would need a WebSocket channel and even maybe something like what I use on my antipad.com, https://github.com/share/ShareJS)

My "problem" is that your use cases look quite complex, in that you have quite a broad understanding of technologies with which I am not really familiar :/

[kaiserfro]

Well, I had an immediate need to hack together a wiki page renderer so I could embed the wiki in another application. Jingo fit the bill for a quick and easy renderer and editor. My implementation of an API for the renderer is pretty crude, so I would not expect that to be any thing like a final solution. Aside from that, there is probably few other features that would be useful for my needs.

[claudioc]

@kaiserfro since the request to the "api" is made through an ajax call (I see the CORS header you added), I guess the cleanest way is to just read the X-Requested-With header (which it is automatically set by almost all frameworks and can be manually set when it doesn't) and, if the value is XMLHttpRequest, provide the rendered body with anything else.

The nice advantage is that we don't need another route, just a couple of IFs :)

What do you think?

[kaiserfro]

That sounds perfect...better than duplicating the code. As for the CORS stuff, hardcoding the headers to a particular value is probably not ideal either. Adding those values to your config file is probably better.

[claudioc]

I implemented this feature (not directly with this PR, though, as I mentioned) and released it with 1.6.0. I added you to the AUTHORS because I guess this is the least I can do to thank you for the idea. I also made the CORS configuration a bit configurable as you can read in the wiki page

Thanks!