A collection of tools for the creation, editing, transformation, and publishing of a variety of documents
This is an idea for a collection of applications currently under design and initial prototyping by Neil Madden.
What is ArTcl
ArTcl (pronouced as "article") is a collection of components that are being designed to support the creation and publishing of documents. I'm currently envisoning three parts to this:
These names are subject to change if I think of something better.
I wonder if providing a GUI to create doctools input might fit into this big scheme? That might help all the people who are writing docs for tcllib and such quite a bit. - Roy Terry, 20Jan2004
NEM doctools support has been requested twice now, so I'll think I'll make it the first supported format for the editor, and try and wrap up the doctools functionality into a transform process.
I'm hopeful the three components should be useful independently, as well as collaborating together in various configurations. For instance, you might use the editor to create documents and publish them directly to the webserver. Or you might use the editor to create documents and then run them through the transformer to produce PDF or LaTeX or some such.
I'll try and briefly explain the three parts in a bit more detail. Each will work with a variety of different document types, which will be distinguished by a system similar to mime-types. For instance:
As you can see, the scheme is similar to mime-types, except that it shows a strict inheritance hierachy (obviously limited to single inheritance). One thing to notice is the inclusion of "image/gif" there, hinting that the document types would not be limited to just text...
Update: Looking at this again, it may be useful to provide a root for this naming scheme, e.g. "/text/xml". That way a default document type/view could be provided for document types which have not had one crafted for them.
escargo 19 Jan 2003 - Which flavor of text do you think of as plain text? I have moved text files among many kinds of systems, and issues of line endings and tab widths (not to mention certain character encoding issues) keep popping up. When I use Emacs it discovers for itself the kind of line endings in a file and maintains them. (The main flavors I encounter these days are Windows and UNIX; MacOS was also different, although I don't know if that is still the case.) If a file is a plain text document and it is moved between systems, can the ArTcl programs cope with changed (or unchanged) line endings?
NEM "text" would be the equivalent of "text/plain" mime-type. In other words, the type refers only to the content type, and not to issues of line endings, encoding etc. These are separate issues, which would be handled by the individual document model, and/or views. For instance, I could add information to the type specifying the encoding, or the language, or the line-ending, but these wouldn't generally make much sense for e.g. an image document type (binary data, no words etc). It should be fairly easy to maintain line-endings I would have thought. As to whether ArTcl will be able to cope with different line-ending: of course, this functionality is in Tcl.
Perhaps I should emphasise here that the three parts laid out below are general frameworks which can be used to write useful components which all play together nicely. Individual features are mostly left up to document models and view implementations. Of course, I do intend to write some of these components eventually, but for now I'm just trying to get the basic framework running, with little more than notepad functionality.
ArTcl-Edit
The editor is based on a Model / View / Controller design (at least, if I understand that design idea correctly). Each type of document has a document model associated with it (for instance "text/xml" might have some variation of a DOM tree as the model). Documents provide some common functionality (very little - pretty much just creating new instances and saving). All other functionality is done through views. A view is associated with a document type (for instance, a view based on the tk text widget would be associated with "text", a view based around tkhtml would be associated with "text/html"). Any subtype of that document type is viewable with that view (so for instance, html would be viewable as plain text or rendered in the tkhtml view). The editor basically provides a consistent interface, some basic menus, toolbars, dialogs etc and passes off almost all functionality to the views. Document types would be allowed to register new menus with the interface, as would views.
ArTcl-Transform
This would be a framework for providing processes which take a document of one format and transform it to another format. Pretty simple really! An example might be a generic XSLT transformer which takes "text/xml" input, a "text/xml/xslt" stylesheet and produces some "text" output. You could have more complicated transformation processes. I'm still thinking about this bit some more... The data would be passed around as snit document models, as used in the editor.
AK: Whatever way this is done, I would like to be able to plug doctools into this as my transformer.
NEM: That shouldn't be a problem. I'll bear it in mind though. In fact, doctools would make a good test case.
CMcC: FWIW, tclhttpd already generates html from doctools.
ArTcl-Publish
This is the content-management system (CMS) built on top of tclhttpd (see also starsite for some old ideas I had on this kind of thing). It would support user authentication, web-based editing, session management, multi-level caching etc. I've been thinking this one over for quite a while, and I think I've almost reached a decent design. Once again, this would use the document models used in the other two processes. The object of this component though would be to make content available to the public through the web server. I'd like it to provide support for collaborative editing, version control, and maybe WebDAV one day....
There's loads more to this that I haven't got time to go into now (I'm itching to get coding). It's a big project, and it may not be feasible to get everything working, but I'd like to. It would be a great environment, as well as a (IMHO) killer app for Tcl/Tk. If you want me to give you more info, or if you want to volunteer to write some of this, add your comments below, or hassle me at nem AT cs.nott.ac.uk.
SEH Have you looked at Quarterstaff [L1 ]? I haven't either, but it claims to be a featureful pure-Tcl CMS. Maybe you could build on that rather than start from scratch.
NEM: Thanks for the link. I wasn't aware of Quarterstaff, and I will have a look at it. It's GPL, so I'd rather not use it, as ArTcl will be BSD licensed. Also, I can't quite figure out from the docs what exactly it does.