Login  Register

Deckjs backend guide review and general backend questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Deckjs backend guide review and general backend questions

graphitefriction
Administrator
Heya Alex and custom backend gurus,

I'm almost finished editing the deckjs backend guide, but before I do a pull request (probably late Friday or Saturday) I thought I'd let y'all review it if you like.  I also have a few questions.

1. I couldn't figure out how to 'split' a slide. What is the argument/syntax I should use in the document?
2. I tested out the backend attributes deckjs_theme, deckjs_transition, menu, navigation, and status, which map to deck.js modules. They all work just as Alex described. Next question, are the goto, hash, and scale modules mapped to backend attributes and/or values?

I'm also putting together a little example slideshow to show off each of these features; I'll link to it in the guide once I've finished it.

The guide is sitting in my repository. Feel free to edit it directly.

Once we've finished this guide, I'll put together a similarly structured one for the dzslides backend.

3. Also, does anyone have any tips, notes, information, for a general 'how to create a custom backend for Asciidoctor'?
4. How about backend standards? Are there common conventions, attributes, names, etc. that a lot of the backends would share that could be agreed on?
5. Dan and I have discussed the idea of releasing the backends as a gem. Should each custom backend be its own project so that it can be updated and released separate from other backends? Should all the backends be bundled together as one gem?

Alex, thank you so much for putting together the deckjs backend README. I'd never used deck.js or a custom backend before, and I wouldn't have known how to even get started much less embed images as slide backgrounds without you help!

Cheers,
Sarah
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Deckjs backend guide review and general backend questions

asotobu
Hi Sarah, I am going to answer using your message:

graphitefriction wrote
Heya Alex and custom backend gurus,

I'm almost finished editing the deckjs backend guide, but before I do a pull request (probably late Friday or Saturday) I thought I'd let y'all review it if you like.  I also have a few questions.

1. I couldn't figure out how to 'split' a slide. What is the argument/syntax I should use in the document?

Yes I remember now, sorry to not writing this information on documentation,  in fact it is writing three < characters (<<<) where you want to insert a page break.

2. I tested out the backend attributes deckjs_theme, deckjs_transition, menu, navigation, and status, which map to deck.js modules. They all work just as Alex described. Next question, are the goto, hash, and scale modules mapped to backend attributes and/or values?

No they are not backed with any attribute, they are simply registered by default. This happens because these modules are native to deck.js, meanwhile slide module is an external module, so I preferred to map with an attribute.

I'm also putting together a little example slideshow to show off each of these features; I'll link to it in the guide once I've finished it.

The guide is sitting in my repository. Feel free to edit it directly.

tomorrow I will take a look

Once we've finished this guide, I'll put together a similarly structured one for the dzslides backend.

3. Also, does anyone have any tips, notes, information, for a general 'how to create a custom backend for Asciidoctor'?

I have no notes, or information, but when I developed it I simply follow the html5 example, and one note where Dan commented that the name of the file should match with Asciidoctor element (for example document.html.haml for document , or block_image.html.haml for an image)

4. How about backend standards? Are there common conventions, attributes, names, etc. that a lot of the backends would share that could be agreed on?

I am sure that we could share some attributes (of course the name of the files should follow the conventions that I mentioned on third point), but as attributes for example :navigation: could be shared with all backends to render a navigation menu, and for example [canvas-image] which renders an image in full screen mode (an effect which I really love in presentations) could be also shared. Also an attribute to set a list of bullets (ul, li, ...) appear once per click instead of when the slide is loaded, could be common too. I think that because Dan has implemented the DZSlides backend, he could provide some feedback too in this point.

5. Dan and I have discussed the idea of releasing the backends as a gem. Should each custom backend be its own project so that it can be updated and released separate from other backends? Should all the backends be bundled together as one gem?

Well my impression is that each backend should go to one gem, it seems reasonable that if someone wants to create slides with deckjs, won't need to render the slides with DZSlides. I don't know if each backend in a gem would mean a lot of work and time to release a new backend. I think that all backends should be in their own project, if they are bundled in their own gem, because this would let us freedom to update them individually for new features, fixing bugs, ... but of course this would depends on the work behind maintaining all these repos. Moreover from the point of view of Asciidoctor-java-integration, we could release AJI as standalone application with no backends, another version with all backends, another one packaged with the backends only related to develop slides, ... I think that each backend in a gem will give much more flexibility.

Alex, thank you so much for putting together the deckjs backend README. I'd never used deck.js or a custom backend before, and I wouldn't have known how to even get started much less embed images as slide backgrounds without you help!

Thank you very much to you to professionalize the documentation, I am really bad writing documentation in Catalan (my native language) so in English is even worst, so thank you very much for taking your time reviewing all this documentation.

Cheers,
Sarah