publish-only notes

(very draft)

Concept

"publish-only" is the name we give to all activities related to supporting the creation of publishing applications, i.e. applications concerned with using/publishing content available in a Daisy repository. This is in contrast with Daisy's default frontend application, the Daisy Wiki, which is a read/write environment for collaborative content creation with limitted customisation possibilites.

There are various points from wich a "publish-only" type application can be created:

1. by using just the basic repository API.
2. by making use of the repository API and some repository extension components, such as the Navigation Manager and the Publisher.
3. by making use of the repository API, repository extension components, and basic Cocoon integration facilities (e.g. the machinery get a document published with document type specific styling applied, utility library to ease access from flowscript, ...). This is what we currently call the front-end client lib (see also the roadmap).

Note that the basic repository doesn't provide any publishing related features. Things like expanding in-page queries, processing includes, translating links and styling content are handled today by a combination of the Publisher component and the Daisy Wiki.

Points 1 and 2 are already possible today.

Point 3 (the front-end client lib) is what we are working towards. It mainly consists of removing some Daisy Wiki contextual ties from the functionality we want to reuse outside the Wiki, and providing cleaned-up, maintainable APIs for them. Once that's done, a second part will be bundling this functionality as a separate entity which can be easily added to a blank or existing Cocoon-based project.

It is possible to get an idea of how to development based on this front-end client lib will work by looking at the current Daisy Wiki extension mechanism.

front-end client lib

The first step is to identify what to include in the front-end client lib, a next step will be to identify any problems related to this move.

things we might want to move in there:

• xconf patch for installing repository client (including jms) in the cocoon.xconf.
  To research: possibility to add multiple repository clients, so that it is possible to talk to multiple repository servers from one Cocoon.
• PartReader to retrieve part data (blobs)
• Classes supporting communicating with the publisher and doing document type specific styling:
• components supporting html publishing
• components supporting xslfo publishing
• possibly also basic XSLs for this
• exception handling (ErrorGenerator)
• XSL and CSS to provide a default rendering of the navigation tree (?)
• components supporting RSS feeds (SerializerTransformer)

Things that will explicitely not become part of the front-end client lib:

• sites management
• skinning
• locale things
• extension mechanism
• any of the apples (and thus the functionality they provide)