Hi!
> 4 hours in the train, enough to dream...
Hehe :)
> I've tried to imagine the best evolution for livedocs, and I've seen one
> major modification needed : Separation
>
> Actually, we have three main parts :
> - Build
> - XML parsing
> - HTML rendering
>
> When livedocs was available through CVS, I've checked it out and started
> to adapt its design for my own website. While doing this, I fixed some
> bugs (BAD ID:..) and added some features like showing the available
> languages in the Index, and so on.
> When I wanted to commit my changes, I've seen that the noise caused by
> my design stuff was to huge. So I was unable to commit it.
We have talked about some things on the linuxtag docmeeting about
developing plugins for it. This is only possible however if livedocs
allows plugins :) Separation of different parts is essential to enable
livedocs to handle plugins.
While we split up the logic it needs to be kept in mind that we try to
solve a lot of issues with livedocs:
- translators quickview of modified files
-> no special requirement
- php website manual presentation:
-> integrate with the websites functionality (shortcut handling,
error handling, language fallback)
-> integarate with website design
-> cache pages so often visited pages will be pushed from the
static cache
-> livedocs need to work without the build part with a prebuilt
manual, with all the langauges behind
-> handle user notes display
- generated HTML files for offline viewing
-> livedocs need to be able to generate the 'multiple HTML files'
and 'one big HTML file' version of the manual for download
- offline personalized manual
-> this is an old idea, and livedocs need to mature much to fulfill
the expectation I have written down, but livedocs will fulfill
those sometime and we ned to keep in mind that livedocs should
work with a prebuilt envrionment, and need to support settings
based personalization
-> again, this is along term goal, so included here just for the
records
-> See also: http://marc.theaimsgroup.com/?l=phpdoc&m=105251292424018
- other PHP.net projects (PEAR, PHP-GTK, Smarty, etc.)
-> reuse some of the XML parsing, but add their own extensions to
it
-> different presentation due to different website environment
I beleive that if we keep these in mind, the resulting livedocs framework
will be so extensible and so flexible that anybody will be able to set up
his own docbook project and start displaying it with livedocs... So we
need to think about allowing the extensions on livedocs on multiple
levels:
- input XML parsing and TOC generation (build stage)
- presentation (big HTML, mutiple HTMLs:
phpweb view, simple view, customized viwe)
- performance (caching, no caching)
- additional components (ex. user notes)
>From the structure you presented it is not clear to me, what separation is
done on the XML parsing and HTML presentation. The PHP subprojects for
example will significantly overlap in their XML -> HTML conversion, so
there should be some feature to present a common ground for them. Their
styelsheets however might be more different, and due to performance
reasons, the style information should be contained in as few files as
possible.
Goba
