Itamar Tzadok

Just wanted to share a nice effect of displaying entries by category. The categorisation is done by a designated tag of the menu field. The tag works such that it displays the field value only once for each sequence of entries with the same value in that field. For best results the entries should be sorted by the category fields in the order of categorisation. In the following illustration the entries are categorised by two fields. The first is formatted to heading 1 with green background and the second to heading2 with yellow background and indented. The rest of the entry content is in a table, indented and with fixed cell sizes.

This is a sort of headsup to a work in progress which should, if successful, offer a way to create a multi-page book-like resource with multi-level hierarchy, treeview (collapsible) TOC with rich content labels, auto-numbering and other effects. The following are a few sneak peek illustrations.

For book editing purposes it may be convenient to show and edit a few pages at a time.  The pages may be rendered aligned, or indented

or in a collapsible treeview

As can be seen in the illustrations above nested headings and numbering can be added to format page titles. The headings and numbering are optional per view instance and are generated by the view if enabled.

For book browsing/reading, the number of pages per page can be set to 1 and a TOC can be added. The following illustration demonstrates rich content TOC label by adding to each toc label an image of  the page author.

There are still some issues to sort out but in the meantime any thoughts, suggestions or requests are welcome.

While debugging (and enhancing) version 1.0.3 of the dataform I use it to track progress. One outcome of this is a treeview view which displays a tree menu of the displayed entries. The leafs are links to the entries in the main view and allow jumping to items out of the visible screen from the tree. This treeview view is just a stub but the possibilities are endless.

Continuing the dragdrop for match question type discussion.

I'm not sure that maintaining two additional question types for something which is essentially a skin is worthwhile. I'm inclined to think that dd skins should be part of the standard question and even in question base. This should make it much easier to upgrade b/c even if the skin is not compatible yet with the new version, the question will still upgrade and fallback to the standard rendering.

At any rate, I've made a quick implementation of YUI 3 dd-match as a layer on top of the standard match question type. Here is an illustration:

This implementation adds to the standard question type a js file, a css file, and a minor modification of the renderer to initiate the dd if usable. I also intend to add to the question edit form an option to enable/disable the dd skin for the question.

The ordering question could be implemented in a similar way. The only difference between ordering and matching is that in ordering the answers should be entered in order and not shuffled. This, however, would require adding a setting to shuffle options (currently, answers and options are shuffled/not-shuffled together).

Revisiting the UI and features of entries import (export soon to follow) I have come up with a preliminary design and I'd appreciate some comments and suggestions for improvements.

The link to the import form is a "template tag" and may or may not be included in a view depending on preferences.

Clicking the link opens the form on the same page (this may be ajaxed):

The form is meant for import but it also allows for adding multiple new entries. That's like adding a new entry but plural. So you enter the number of new entries you want to edit, say 3, and submit ("import"). This opens 3 new entries for editing:

But back to import. There is the CSV settings and import input which may be either a file or text. The text option basically allows you to enter the csv in the textarea and may be useful for quick adding a few simple entries. The importer may select to edit existing entries, in which case the csv should contain a designated column for entry id and each record should have its entry id. The importer may also select to open the imported entries for editing after import. This may be useful for small imports where the imported data is partial for this or that reason and should be amended manually.

I suppose the important questions are with respect to importing (and exporting) rich content such as files or formatted content such as dates. Binary data (such as image files) may be imported/exported in csv as base64. This however, is likely to make the csv file unintelligible to the naked eye. So perhaps identifying files by name in the csv and uploading next to the csv file a zip of the imported files. Let me know what you think.