Note: You are currently viewing documentation for Moodle 3.1. Up-to-date documentation for the latest stable version of Moodle is probably available here: Dataform building.

Dataform building: Difference between revisions

From MoodleDocs
No edit summary
m (Text replacement - "<mediaplayer>(.*)<\/mediaplayer>" to "{{MediaPlayer | url = $1}}")
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Dataform}}
{{Dataform | innertrail =  ► Creating an Activity }}
{{Dataform Docs Note 1}}
==Understanding the Dataform activity==
===Resource or Activity?===
A Dataform instance is essentially a collection of content entries entered and interacted with by the activity participants. The type of content, the content itself and the manner of interaction depend on the specific objectives of the intended activity.


Moodle divides modules into two groups, Activities and Resources. Modules that involve something that a participant will do by way of interaction with other participants are typically classified as [[Activities]]. Modules that can be seen is mere channels of content are typically classified as [[Resources]]. To be sure, this classification is often not a clear-cut as some Activity modules do not really involve interaction between participants (e.g. Quiz) and some Resource modules can be constructed with interactive components and allow interaction between participants (e.g. adding comments block to Book pages).
==Building a simple activity==
{{MediaPlayer | url = http://www.youtube.com/watch?v=Ab9jLl8ZV90}}


The Dataform is an example for a module that can be used either as an Activity or as a Resource depending on the specific application and/or learning objectives. When adding an instance to the course via the 'Add an activity or resource' link, the Dataform is listed in the Group of activities only because it can appear in one group only.
[[es:Dataform Hello World]]


Application wise, the Dataform can emulate many of the standard Moodle resources and activities at least to a certain extent. It's real strength is where the desired behaviour of the resource or activity is not quite standard and the non-standard part can be applied by means of components that are included in the Dataform or can be easily plugged in. Of course, designated modules are likely to be more user friendly for setup within their intended scope than the generic Dataform.
==Preventing participants from viewing other entries==
===Building blocks===
One setting and two permissions can affect whether the user can is limited to viewing only his/her entries.
The main building blocks of a Dataform activity are fields, views and entries. Each activity typically consists of several views through which content can be submitted and viewed, fields that store submitted content, and entries which are the virtual containers of the submitted content.


[[File:df-structure-view-entry-field.png]]
===Separate participants by activity setting===
[[File:df-activity-settings-separate-participants.png]]


The activity setting 'Separate participants' set to 'Yes' will restrict all roles which do not have the 'mod/dataform:manageentries' capability to their own entries. By default permissions, that's all roles below editing teacher. This means that non-editing teachers are also restricted to their own entries by this setting. If you want to allow non-editing teachers (graders/TAs) access to certain entries you can use an Entry access rule and set the rule with entry filter to fetch the designated entries and a role override where you assign the designated non-editing teacher to the editing teacher role.


===Separate participants by permission===
[[File:df-activity-permissions-entryanyview.png]]


====View====
By default the mod/dataform:entryanyview permission is granted to everyone. You can exclude certain roles in the activity level by removing the role from the permission (Prevent), or by adding the role under Prohibited. Note that if you want to then grant the permission to particular users from the excluded role, use the Prevent method and then add an Entry access rule with a proper override.
A '''view''' is a named entity that allows you to control the way activity content is submitted and displayed.
====Field====
A '''field''' is a named entity that can have content and/or behaviour.
====Entry====
An '''entry''' is a virtual content entity, such as an article in a dictionary or encyclopedia, a record in a log or a diary, or any other list item that can be organized in a similar way.


===Templates and patterns===
==Setting entry actions to open in different views==
This is similar to the technique used to mail merge letters in word processors such as Open Office Writer or Microsoft Word. In designated areas in the View configuration form you can insert special patterns that will be replaced with certain content when the view is displayed. The designated areas for these patterns are typically WYSIWYG editors which allow you to insert static content and decorations in addition to the patterns in order to create the desired visual effect.
Yes. There are many other patterns which are not visible via the UI and only some are currently listed in the docs.


For example, in order to display the list of entries in the view, you need to have the pattern ##entries## in the View template area in the view configuration form. In most view types this pattern is added by default when you create the view. If you delete it and want to re-insert it, you can either select it from the View patterns dropdown under the editor or simply type it in. Now you can add decorations to the layout.
In the entry level you can use (note redundant spaces between brackets)


The view template and its display with only the ##entries## pattern:
[ [EAC:more:viewname]]


[[File:df-view_template-styling2.png|400px]]    [[File:df-view_template-styling3.png|200px]]
[ [EAC:edit:viewname]]


Which will send you to view or edit (respectively) the entry in the specified view.


The template and its display with the ##entries## pattern and additional content and styles:
Also


[[File:df-view_template-styling.png|400px]]    [[File:df-view_template-styling1.png|200px]]
[ [EAC:moreurl:viewname]]


==Building a simple activity==
which you can use in the href of a tag to create a custom link to the target view.
<mediaplayer>http://www.youtube.com/watch?v=Ab9jLl8ZV90</mediaplayer>
 
 
In the view level you can use:
 
##viewurl:viewname##
 
which displays the url of the specified view and you can use in the href of a tag.
 
##viewlink:viewname##
 
which displays a link to the specified view
 
There is also a composite version of the viewlink pattern which looks like this:
 
##viewlink:Single view;Add a new entry;editentries=-1;##
 
This particular instance will mimic the addnewentry pattern but in the specified view. Details on the syntax should be available in this post: https://moodle.org/mod/forum/discuss.php?d=256813#p1123734.
 
The view patterns are also parsed in the entry level so you can use the composite viewlink pattern in the entry with the entry id pattern:
 
##viewlink:Edit view;Edit this submission;editentries=[ [entryid]];##
 
or
 
##viewlink:Details view;More details ...;eids=[ [entryid]];##


[[es:Dataform Hello World]]


==Setting permissions==
Another relevant view function is redirection of the view to another view in the activity after form submission. The setting under the 'Submission' section in the view configuration form. There you can also set the redirection timeout and message, and also add additional submission buttons as well as custom labels for these buttons.
TBC

Latest revision as of 13:40, 26 October 2017


Building a simple activity

Preventing participants from viewing other entries

One setting and two permissions can affect whether the user can is limited to viewing only his/her entries.

Separate participants by activity setting

df-activity-settings-separate-participants.png

The activity setting 'Separate participants' set to 'Yes' will restrict all roles which do not have the 'mod/dataform:manageentries' capability to their own entries. By default permissions, that's all roles below editing teacher. This means that non-editing teachers are also restricted to their own entries by this setting. If you want to allow non-editing teachers (graders/TAs) access to certain entries you can use an Entry access rule and set the rule with entry filter to fetch the designated entries and a role override where you assign the designated non-editing teacher to the editing teacher role.

Separate participants by permission

df-activity-permissions-entryanyview.png

By default the mod/dataform:entryanyview permission is granted to everyone. You can exclude certain roles in the activity level by removing the role from the permission (Prevent), or by adding the role under Prohibited. Note that if you want to then grant the permission to particular users from the excluded role, use the Prevent method and then add an Entry access rule with a proper override.

Setting entry actions to open in different views

Yes. There are many other patterns which are not visible via the UI and only some are currently listed in the docs.

In the entry level you can use (note redundant spaces between brackets)

[ [EAC:more:viewname]] 
[ [EAC:edit:viewname]]

Which will send you to view or edit (respectively) the entry in the specified view.

Also

[ [EAC:moreurl:viewname]]

which you can use in the href of a tag to create a custom link to the target view.


In the view level you can use:

##viewurl:viewname## 

which displays the url of the specified view and you can use in the href of a tag.

##viewlink:viewname## 

which displays a link to the specified view

There is also a composite version of the viewlink pattern which looks like this:

##viewlink:Single view;Add a new entry;editentries=-1;##

This particular instance will mimic the addnewentry pattern but in the specified view. Details on the syntax should be available in this post: https://moodle.org/mod/forum/discuss.php?d=256813#p1123734.

The view patterns are also parsed in the entry level so you can use the composite viewlink pattern in the entry with the entry id pattern:

##viewlink:Edit view;Edit this submission;editentries=[ [entryid]];##

or

##viewlink:Details view;More details ...;eids=[ [entryid]];##


Another relevant view function is redirection of the view to another view in the activity after form submission. The setting under the 'Submission' section in the view configuration form. There you can also set the redirection timeout and message, and also add additional submission buttons as well as custom labels for these buttons.