Itamar Tzadok

Start with removing unsetting the default editing view (E) in the views list. The standard behavior of add/edit entry in the Dataform is that the add/edit form opens in the view you currently browsing. The E is for always sending the user to add/edit in a designated view.

Are you using the view templates generated by default? The Tabular view type generates a table and you should only add/remove columns to it. If you remove the table and put something else in its stead it won't work. It meant to simply creating tabular views of entries. If you want each entry in its own block, use the Grid view type.

The Dataform filters allow you to add search criteria in the filter form. You need to select whether the criterion is AND or OR, then the field to search on, then reload to display the value input boxes (depending on the field type), then enter the value by which to filter the entries. Then you can repeat to add more search criteria if needed. Then save.

Fields are represented in the views by their tags. For instance, the number field RecordOneId is represented by the tag [[RecordOneId] ] and will appear in the view where you put the tag.

hth

Try the Dataform module. It has a much more flexible filtering mechanism (although currently all filters have to be predefined) and export. Documentation is far from complete but we're working on that.

With the Dataform you can predefine filters and apply them to fetch and display only the entries that meet the filter criteria, and then you can export the content of the view.

It may even be possible to select entries from the view by ticking checkboxes and export only the selection, but it has been a while since I last looked at that so I'm not sure about that.

I'm inclined to think that nothing would work reasonably with more than a few fields. Consider the possible number of built in tags (e.g. ##edit## ##delete##; see http://docs.moodle.org/23/en/Dataform_Fields#Built-in_patterns for a list of possible tags in the entry level). The more flexibile the platform the more complex the ui. Just like Moodle 2 by comparison to Moodle 1(.9).

It shold be fairly easy to create a form layer as in your sketch above. It could look something like

but with more fields (and there already are quite a few built in tags even before adding fields) its usability would decrease.

Another approach, closer to your conception of a simplified form but in a sense more simplified and yet possibly more flexible is a simple text area where instructors can specify each column in a new line.

##author:name##
[[Concept] ]
[[Definition] ]
##edit##
##delete##

The tags can be selected from a dropdown or typed in. This makes it fairly easy to set the order of columns. A further enhancement allows for adding header titles:

##author:name##|My Name
[[Concept] ]|My Concept
[[Definition] ]|My Definition
##edit##
##delete##

In a similar way it could be possible to add a css class to set styles for the cell from the css tab.

Here are a few considerations.

I think that 'adept developer' (or 'adept contributor') should be defined as a contributor with at least one or two approved plugins in the repo. This should shrink the backlog, maybe dramatically.

Tracker component, Docs page and discussion thread should be created and linked from a new plugin automatically unless alternate links have been specified.

Adding a plugin/version should be able to internally convert md readme to txt. Some prefer to take plugins directly from git and it makes more sense to have there git's md format for the readme file.

There may be an issue with the plugin tracker issues as they seem to be associated with Moodle version rather than with the plugin version.