One-file paradigm and external core

[hsablonniere]

Here is the situation :

• Some projects use DZSlides as a third party tool to provide slides (http://johnmacfarlane.net/pandoc, http://txt2tags.org...)
• Some people use DZSlides for a collection of presentations (teachers, speakers...). They need to apply DRY principle.
• The shells and the template share common/duplicate code.
• ...

As we discussed it in #52, the one-file paradigm doesn't always fit with these different cases.

What we could/should provide :

• The classic one-file template.html (like the current one)
• The JS core as a standalone file
• The CSS core as a standalone file
• The HTML core skeleton (with progress bar...)
• Other examples that demonstrate different styles and demo of third party integration like with SVG charts, code highlighting...
• A contribution guide/doc

Questions :

How does someone contribute to DZSlides core? Which files are the source?

We can use the 3 standalone files as source and build the different examples (template.html and others) with a simple script (bash, makefile, node...).

What would be the source tree and the branch repartition?

• The 3 core files should be available through the gh-pages like a CDN.
• The master branch could be something like that :

├── dist (only on gh-pages branch)
│   ├── dzslides-min.css
│   ├── dzslides-min.html
│   └── dzslides-min.js
├── gallery
│   ├── highlighted-code.html
│   ├── interactive-datagrid.html
│   └── svg-chart.html
├── shells
│   ├── embedder.html
│   └── onstage.html
├── src
│   ├── dzslides.css
│   ├── dzslides.html
│   └── dzslides.js
├── README.md
└── template.html

Pros

1. Simple usage for simple users (template.html as before) and for power users (standalone files).
2. Better reuse of code for collections of slides or third party project with the standalone core (minified or not) files.
3. Possibility to provide different kinds of presentations. Different styles, different use case and third party library integration.
4. Possibility to detect impact of core modifications on different kinds of presentations.
5. Code reuse between core and shells would be easier. I still don't know how to handle that.

Cons

1. It introduces a small compilation phase for core contributors. I'm not sure it is really a problem.
2. I'm sure there's more...

How could we reuse duplicate code from shells and template.html?

Still thinking...

Request for comment!

Let me know all your impressions on that subject...

[hsablonniere]

First time I come across this fork : https://github.com/mojavelinux/dzslides

It has interesting ideas (transitions, themes...)

[reagle]

mojavelinux's fork is interesting... Also, while I, in part, prompted this thread by trying to figure out how to best maintain my slides while being able to take advantage of new underlying features, I do like the simplicity and capacity of single file slides. I would hope we'd not lose that capacity.

[reagle]

I have a pandoc template in a fork which produces a more full featured (i.e., slide types) dzslides template.html.

[hsablonniere]

Note for future : maybe we need some kind of explicit versions for core CSS, JS etc...

[itpastorn2]

FYI, I also have begun looking at splitting HTML, CSS and JavaScript. I intend to use 20+ slides on a single site. Since this is the companion site to a book where I teach web dev, and mention the DRY-principle, I expect lots of comments from students all over Sweden if I keep the current monolithic system.

OTOH, DZSlides is about to enter classrooms in 50 - 100 schools all over Sweden :-)

[hsablonniere]

I also teach web dev and that was my first thought about the one file paradigm. It's good but not when you're trying to explain DRY-principle...

So now DZSlides <3 Sweden ;-)

[paulrouget]

DZSlides is about to enter classrooms in 50 - 100 schools all over Sweden :-)

Wow!