It would be nice to have the edit mode to allow quick editing of many records in a list view. Can you provide some screen shots of how that might look like?

Itamar, thanks for your suggested improvement. Setting a fix version of DEV backlog for it to be considered for inclusion in a future version.

Paul, how the list view will look in quick editing mode depends on your list view design. Conceptually there is no big difference between the default list, single and add views. The single view is a list view with max entries per page fixed on 1. The add/edit view is a single view in edit mode. So, by default the list view in edit mode will look like multiple add/edit views on the same page with one save button (with or without individual save buttons). Now, if you design the list view to be an aligned table (each entry in a table row), in edit mode it will look like a table of textfields and other elements depending on the field types in your database and which of these fields are included in the that list template. Editor fields may be handled by displaying a link which opens the editor in a popup window so as to keep the table in a reasonable size. Also, since this improvement will allow you to add more than one list template to the activity, the quick list editing doesn't have to be the same view as the one for display.

If I understand it correctly, the list and single views will look the same as the current design in the non-edit mode, but differently when the edit button (to be added in the upgrade) is clicked. I assume that in the list and single views under the edit mode the style of the textfields (size, border, font, etc.) can be defined in the quick list editing template.

Another suggestion is to add a "save and add new" button in the add view so that user can save the current entry and enter another new record directly.

Thank you for working on this. I really look forward to the upgrade.

Take for example the default single and add/edit entry templates in the current design. In the new design they will be 2 modes of the same template rather than 2 templates, and the edit icon will simply reload the same template in edit mode wherein each field in the template will be displayed as a form field.

In the new design there is no distinction between list and single view types. The currently 2 distinct templates will be 2 instantiations of 1 template type called 'entries template'. When you create a new instance of this template type, you will have an option to set 'max entries per page' . If you set it to 1 the instance will behave like the current single view, that is, display only 1 entry per page. If you leave it unset, the instance will behave like the current list view. And of course you can fix it to any number you want.

Input fields styles may be controlled by css. While the css template provides a convenient placeholder for all the styles of the activity it may be useful to allow css definitions in the template level. Also each template type may already include default styles. I'll consider these things in due time.

Not only 'save and add new' but also the option to add a number of new records. So for instance, you design a list view and enable its edit mode. Then when you want to add entries, say 7 entries, you can open this view, select 'add 7 entries' (dropdown + button or some other interface) and this will automatically add 7 new empty records and switch the list view to edit mode where you will be able to fill out the fields in these records and save all in one click.

Just to get the terminology right, when we go to the templates tab to modify templates, we design views not templates.

In the current structure of the module there are 7 predefined template types (list, single, asearch, add/edit, rss, css, js) which are fixed in the module structure. Five of these templates (list, single, asearch, add/edit, rss) constitute views, only one view per template type.

In the new structure template types are plugins. There will be five predefined template types: entries, asearch, rss, css, js. New templates types may be added as plugins (just like new field types). So for instance someone could write a new plugin which offers an simplified editor interface for creating aligned lists. Then we may add any number of views based on any template type (just like adding a number of text fields, or checkboxes etc.)

"In the new design there is no distinction between list and single view types. The currently 2 distinct templates will be 2 instantiations of 1 template type ..."

If 2 instantiations are from the same template, can they have different views? If there are many fields, some people might prefer to have different views with the list view (in the current terminology) showing the most important fields and the the single view showing all fields.

An instantiation of a template is a view. So for instance you have a database with the fields 'Name', 'Description', 'Price', 'Details', and the predefined 'entries' template. This template allows to define views of entries with any number of entries per page. In one instantiation of the entries template you can define a view with the fields 'Name', 'Description' and 'Price', set the max entries per page to multiple, and add list header and list footer. In another instantiation you can define a view with the fields 'Name', 'Description', 'Price', 'Details', set the max entries per page to 1, and leave the list footer and header empty. The first instance is the equivalent of the current list view and the second of the current single view. Suppose you decide that you need another list view with only 'Name' and 'Price'. So you instantiate the template again, and add the fields 'Name' and 'Price', set the max entries per page to multiple, and add list header and footer. And so you have in the activity two list views and one single and in the main page of the activity you can select which view to browse from a dropdown list (or some other interface).

This is cool!

Hi, Itamar. Do you have a tentative timeline for this development? I have a very important project to be developed in two months and would like to use the new features. Or can I just develop the views as usual and simply upgrading Moodle system once it is available? Thanks!

Sooner than later. Since I need to do some substantial code reorganization in the viewing section of the module, I'm switching from an 'improvement' to a plugin and the transition will take a few days after which I should have a better idea of completion time. In the meantime you can definitely start working with the standard module. The main infrastructural change is moving the templates placeholders from the data record in the main database table to designated records in a new table. But the content structure remains the same so converting a database activity to the plugin activity should be fairly straightforward.

Just a quick update. I've added the option to create predefined filters (what is currently known as advanced search). So, after adding some fields and views, the teacher can add predefined "advanced searches" which users could select to filter the entries in the current view. The predefined filter may set the number of entries per page (but not override the view's per-page setting), custom sort (overrides the default sort), simple search and custom search. In the custom search I deviate from the current design of the advanced search which lists search values according to existing content (e.g. in menu field). Since a predefined filter is prepared for future content any foreseen content should be addressed. I currently working on implementing from-to search criteria for timeadded and timemodified (and for the standard date field for that matter). Another feature in the pipe is group-by by means of which a list of entries may be broken down to aggregations according to the content of a certain field. As always comments and suggestions are welcome .

In the current version, the search function cannot search numeric fields by >, <, >=, or <=. Can this be addressed?

I'll see what I can do.

Progress update. See http://moodle.org/mod/forum/discuss.php?d=173013#p761756 for an illustration of multi-view browsing. Another implemented feature is activity intervals, that is, teachers can set the activity to fixed intervals (e.g. 7 day, 10 day, 30 day) such that 'required entries' and 'required to view' are applied to each interval. This may be useful for periodic reports and similar applications of the activity.

First preview of the dataform.

Here is a quick manual.

Since this is a plugin you can simply add the dataform folder from the attached zip to moodle\mod\

The dataform.php should go to moodle\lang\en_utf8\

Then notifications and with a bit of luck it will install properly.

Now, some things do not work yet and I haven't tested yet those that should work. But the following simple scenario seems to work and should give a good idea of where it is going.

Add a dataform activity. You don't need to enter intro (!!!). You may notice that the time settings are somewhat different from the database activity. On that later. For this scenario just go with the default.

When you go into the new dataform you should be redirected to add fields. Add a text field 'Name' and a number field 'Progress'.

In the fields list you can set the default sort. For this scenario just set Name to order 1 and direction Descending.

Now go the views tab to add a view. Add an 'aligned list' view. Set the 'group by' option to Name (some module strings may be missing) and leave everything else default. Save the view.

In the views list choose this view as default.

Then add a 'bar graph' view. Here too, set the 'group by' to Name. Clear the list header and select from the available tags ##timecreated:day## (note that each section has its own available tags dropdown). Clear the repeated entry section and select from the available tags [[Progress] ]. Save the view.

Now go to the browse tab. Since there are no entries yet you should see only the add a new entry option (which btw is also a tag in the view which is added to the default view). You can add an entry. Alternatively, you can go back to manage and then Import and dump the following csv block into the csv textarea:

Name,Progress
John Doh,3
Jane Duh,4
Jack Dude,7
John Doh,3
Jane Duh,6
Jack Dude,5
John Doh,6
Jane Duh,5
Jack Dude,3

and import. This will import all these entries and now when you go to browse you should see some entries.

Now the scenrio is set such that the entries are grouped by name and so you should 3 pages one for each distinct name.

Switch to the bar graph view to see a progress bar for each 'Name'.

Hope this works. Comments and suggestions are welcome.

Itamar,

In one project I am working on, there are many fields in one database activity (more than 50). When they are all presented in the view single page, the page is way too long. Is it possible for you develop a tabbed page function so that the many fields can be displayed in tabs? For example, one tab is for the demographics fields, a second tab is for assessment scores, and the third tab is for student attributes. Thanks!

No need Paul. The multi-view approach already fulfills this function. You simply create a view per what you call tab, give it a meaningful name (e.g. 'demographic information') and add to the view design only the desired subset of fields. Then, in the views dropdown on the main activity page (that is, the browse page) all the views/tabs you created will be listed and you will be able to switch from one to another by selecting from that list.

See http://moodle.org/mod/forum/discuss.php?d=173013#p761756 for how it works.

I see, Smart design!

Hi, Itamar

Any news on the dataform development? Is the attached zip file you uploaded on 26/Apr/11 usable? I cannot wait.

The 26/Apr/11 version is incomplete and may be unstable. I'm currently attending other business but work on this project will resume in a couple of weeks and a stable version may be expected a couple of weeks later.

Quick update. A new approach for presets management (which will have to be revisited for 2 (sigh)). Presets are saved as zipped xml. The presets page displays the list of available presets in the course level and site level. The options are self explanatory.

The filter form allows defining multiple nested sort options (one for each field including internal fields such as timecreated, timemodified etc.) and multiple search options, one or more for each field. The latter may be useful for cases such as searching name1 or name2 or ... on the same name field. See attached image for illustration. The number of options increases automatically upon submission.

Added support in operators (like, in, between, =, >, <, >=, <=) for search options. See attached image for illustration.

Hi Itamar,

I am very much looking forward to start using the new dataform plugin, when do you think a stable version will become avaialble?

By the end of this week although some of the new features won't be thoroughly tested yet and there are quite a few new features.

The occasion arose and I just couldn't resist the challenge so I added a calculated field type. The field can be used to perform any of five binary operations (+ - * / %) with or without negation on two numerical fields in the activity. See image for illustration of the field display in a list view (top) and the field definition form (bottom).

Tobias, I will try to finalize a reasonably stable version by tomorrow.

Ratings is the last major component to be improved in this round. The dataform will allow rating both in the entry level and the activity level. Rating may be done either inline or in popup. The ratings aggregation, which in the standard module is hardcoded to mean, is calculated on display and can be shown as mean, sum, max and/or min. See image for illustration.

Is this going to be available for Moodle2 as well?

Of course. But the 1.9 version has to be tested first and prove stable before it is migrated to 2.0.

The latest version of the dataform should be attached. I've just begun finalizing and debugging and there is some house cleaning and optimization to do, but the basics seem to work. So feel free to play with it and any feedback will be greatly appreciated.

Here are some noteworthy notes:
1. This is a 1.9 mod plugin. The dataform directory in the zip should go under moodle/mod. The dataform.php is the lang file and should go under moodle\lang\en_utf8.
2. With a bit of luck installation should succeed and you can start setting up the activity.
3. The entry settings have been moved from the module settings form into the activity.
4. The module activity rating is not implemented yet.
5. Once an instance is added you need to add fields. Many of the fields have new options, most of which have not been tested yet.
6. Then you add views. Currently there are two types, the familiar list template and a tabular template. There is no help files yet so hopefully the forms will be sufficiently self-explanatory.
7. Note that you can create many instances of each view type and and in each instance you can have a different subset and layout of the fields.
8. A view can be made single view by setting the view per page to 1.
9. Then you can create filters and when you have filters you can either use them on the fly in the browse page or assign a certain filter to a certain view to set the view to a fixed subset.
10. Note that views/filters menus and quick search are design items and need to be added to the view design. The default view of each type already includes them. And you can remove them from certain views if you wish.
11. Then you can adjust entry settings such as required entries and max entries. Note new features such as editing time limit which when set to a certain number of minutes will lock the entry after the duration. There are also other locking options: lock on approve, lock on comments and lock on ratings.
11.1. Entry rating is separated from the activity rating. The aggregation is calculated on the fly and the display depend on the pattern you add to the view design (avg, sum, max, or min).
12. The last two items in the entry settings offer a way to get the familiar database activity behavior with respect to views by assigning a view to the edit and more icons. If these options remain unset, editing is inline and more should do nothing. When these options are assigned a view, clicking the icon will will open the entry for edit/more in that view.
13. Presets are now zip files. They can applied with or without mapping.
14. Import can work from a csv file or csv text. You can also choose to update existing entries in which case you need to have the entry ids as a column in the csv text/file. Needless to say, entry ids can now be exported in the export tab. The other two userdata import options (zip with and without preset) are not implemented yet.
15. Export works to the familiar csv, excel, ods. The other two options are not implemented yet. You can assign a filter so as to export only a subset of the entries. You can select the fields to export. Note that you can export most of the entry information.

Hope some of all that works. If you have question please don't hesitate.

Helen, how do I upload the zip to the modules and plugin database? It says I don't have a repository for external files.

Bug fixed in adding a new filter and a few adjustments of the sql queries. But I've just started testing the filters so there may be more issues there.

This may be of interest to some. I've implemented a chart view type which offers a ui for basic yui charts. See attached images for illustrations. This component will appear in the next release of the dataform.

Added a slideshow view. For this view the entry should have a Picture field with and the thumbnail dimensions set (so that a thumbnail will be created for an uploaded image). Then you create a slideshow view select the Picture field as the paging field, and design an entry layout (in the standard way). On display, the paging bar of the view is constructed from the thumbnails of the batch per page, and the next and previous navigate the next and previous batches (respectively).

Added an internal virtual group 'separate participants' as an option of the group mode in the dataform settings page (see image for illustration). Setting the dataform to separate participants effectively makes it a private per participant activity without the need to generate a group per participant or the familiar work around of requiring approval without approving any entry. Although the option appears in the common group mode menu, it is local to the dataform and does not affect group mode menu in other modules (grouplib was not modified).

An initial implementation of a 'Dataform block'. See image for illustration. The block can display a selected view from a selected dataform.

Hats off to Itamar! The dataform module transformed the database module in such a revolutionary way.

This is just to update that I have finally completed the dataform grading component. A quick illustration may be found in http://moodle.org/mod/forum/discuss.php?d=181577#p791276. The dataform grading allows for grading the activity as a whole (per participant), grading by aggregation of entry ratings, and auto-grading (of sort). The grading is a view and can be designed in various ways. The grading goes well together with the entry locking settings which I have mentioned somewhere in the forums. Entries may be set to lock on comments or on ratings such that once a submission is graded its author may no longer modify it.

Most importantly, this completion marks the end of the proof of concept. A concluding beta version will be released in a few days, but I will not continue working on 1.9 unless there will be explicit requests for support. I begin now migration of the dataform to 2.1 and testing and debugging will continue on that version.

As usual, any feedback would be greatly appreciated.

Itamar, you might have mentioned this. Will the dataform allow restricting access to views. For example, a dataform has 5 fields. The teacher can add and edit 1 field only and the students can add and edit the other 4 fields only. Two data entry views will be developed with one for the teacher and one for the students respectively. The teacher can only access the teacher entry view where she can add entries to that one field only. The students can only access the student entry view where they can add entries to those 4 fields only. Is this possible in dataform?

Everything is possible but there's always a price, whether performance or some other.

I don't follow your scenario.

First, a teacher normally has 'managetemplates' capability which allows her to set up fields, views, etc. If a teacher is restricted in the way you describe, it must be a non-editing teacher or some new role.

Second, do the student and teacher work on the same entry? If they don't, then why need it be the same dataform/base? If they do, then if the teacher adds an entry, it should be added on the students behalf so that the student will do his part on that same entry. The dataform allows for adding entries on students behalf by import. but the procedure may be too cumbersome for the average teacher because you need to know the students moodle ids. Shouldn't be too difficult to add a button that retrieves these ids though.

In our case, we want the teacher and students to work on the same entry. Each student can access his or her own entry and contribution. The teacher can see all students' entries as well as all contributions. However, we don't want the student contribution to be edited by the teacher to prevent cheating by the teacher.

From your description, it seems a new role is necessary. Be it non-edit teacher or new role, can the above scenario be achieved in dataform?

Restricting editing of certain fields requires roles assignment in the field level, not the view. Same as with views, it is doable but not implemented yet.

The dataform says hello to the world of Moodle 2 (see illustration).

Hi Itamar,

Thank you so much for your contribution to moodle. The dataform includes all the functionalities I have been missing in the current database activity.

I am now planning to transfer all my existing databases over to the dataform module and are therefore wondering if you know when a fully tested version will be released in the Modules and plugins section for Moodle 1.9.

Hi Itamar,
I am trying to upload entries through the Manage > Import section without any success, I receive the following error message "No entry was saved. Please check the format of the uploaded file."

To ensure that I am uploading in the correct format I have also tried to export the existing records and then re-imported it without any success. I have also ensured that I have specified the same "CSV delimiter" in the upload section as I have used in the imported csv file.
Do you know if anyone else has had problems with this?

Also do you know if it would be possible to define different background colours in the tabular view for each entry depending on the values in a field? I.e. if a field called status had a value of "not started" the background would be white, if it had "under development" it would be yellow, if it had "completed" it would be red, etc.

Thanks,
Tobias

Hi Tobias,
I don't know whether there is a fully tested of 1.9 version of the dataform. I'm no longer working on that version and currently focusing on completion of the 2+ version which will offer much more including the option to set required fields. Although I stated that I would support the 1.9 version if anyone used it, I'm not sure this would be possible in the near future as the 2+ version is quite demanding and substantially different to share debugging. If you can, you should upgrade to 2.1.

I think that I have an unreleased version of the 1.9 dataform in which the import from file works. I'll upload it. But you can also try the import from text. Simply copy/paste the csv from the file into the import textarea and import.

I don't think it would be possible to set the color of a row based on a field value in the tabular view. But if you construct the html of the table yourself, in the standard view, you could use the field values as class names (e.g. <tr class="||status||">) and define a background color for these classes in the css template (e.g. .not_started

Note that the values cannot contain spaces!). I will consider this feature for the 2+ version.

Hi Itamar,

Absolutely love what you have done! To echo Tobias, I would also like to test the most recent version of dataform. I've downloaded the most recent 1.9 version available (Jul 10) however I notice this version is missing many of the more desired features you have created such as chart views, seperate participants, and dataform block.

Is there a 1.9 version with these elements?

Many thanks,
Todd

I will try to upload the most updated 1.9 version I have by this weekend. It is likely to be unstable though. As for the extra features, some are only stubs just to show that it can work. So for instance, there is no proper UI for the charts view and you cannot do much unless you can script with the yui charts api. I'm currently too busy with the 2.1 version to be able to do much with the 1.9. But I may have some more time in the future although I do hope that by that time everyone will have upgraded to Moodle 2.