Feature Wiki

Information about planned and released features

Tabs

Context Aware Page Editor Plugins

Page Overview

1 Initial Problem
2 Conceptual Summary
3 User Interface Modifications
- 3.1 List of Affected Views
- 3.2 User Interface Details
- 3.3 New User Interface Concepts
4 Technical Information
5 Contact
6 Funding
7 Discussion
8 Implementation

1 Initial Problem

Currently page component plugins are context blind. Their properties are saved in the XML of a page and the getElementHTML() function has no clean way to determine on which page or even on which kind of page the element is shown.

But sometimes a page element needs to know whether it is displayed on a learning module page or a test page. Sometimes even the page id is needed if runtime data has to be bound to the page.

Example:

A specific media player plugin is able to restrict the number of playbacks of a media file. The context determines how the paybacks are counted: per test pass for pages of test questions or in the session for learning modules.
Another plugin realizes user input fields on leaning module pages. Inputs done on one page can be show on another page in a different context to support the self reflection of the student. Inputs may also be sent to tutors and they should know from where the inputs come.
Another page component plugin should make plugin question types available on learning module pages, e.g. the STACK question. User inputs have to be stored for a question on a page and when a page is copied then the copied question element should use its own data set for answers.

2 Conceptual Summary

Context awareness can simply be supported by adding three protected methods to the class ilPageComponentsPlugin:

getPageId()
getParentId()
getParentType()

They just provide the information that is already available for a page.

3 User Interface Modifications

3.1 List of Affected Views

None.

3.2 User Interface Details

None.

3.3 New User Interface Concepts

None.

4 Technical Information

This feature is located in Services/CoPage.

5 Contact

Author of the Request: Neumann, Fred [fneumann]
Maintainer: Killing, Alexander [alex] for Services/CoPage
Implementation of the feature is done by: Neumann, Fred [fneumann] as PullRequest for 5.3

6 Funding

DHBW for the optes project.

7 Discussion

Killing, Alexander [alex], 27 Apr 2017: I support the general idea. Another option would be to add ilPageComponentPluginGUI->getPage() that returns the current page object. This would give plugins even more possibilites (e.g. $page->getLanguage(), ...).

Neumann, Fred [fneumann], April 28, 2017: Thanks for the support. A getPage() would be fine for me, too. I just consider if that would encourage using page methods that may change with the page editor revision.

JourFixe, ILIAS [jourfixe], May 22, 2017: Highly appreciated and scheduled for 5.3