Stud.IP  trunk Revision
WysiwygController Class Reference
Inheritance diagram for WysiwygController:
Inheritance graph
Collaboration diagram for WysiwygController:
Collaboration graph

Public Member Functions

 upload_action ()
 
 settings_action ()
 
 getCurrentUserSettings ()
 
- Public Member Functions inherited from StudipController
 before_filter (&$action, &$args)
 
 perform ($unconsumed_path)
 
 after_filter ($action, $args)
 
 validate_args (&$args, $types=null)
 
 url_for ($to='')
 
 link_for ($to='')
 
 relocate ($to)
 
 rescue ($exception)
 
 render_json ($data)
 
 render_csv ($data, $filename=null, $delimiter=';', $enclosure='"')
 
 relay ($to_uri)
 
 perform_relayed ($unconsumed)
 
 render_template_as_string ($template, $layout=null)
 
 __call ($method, $arguments)
 
 has_action ($action)
 
 action_url ($action)
 
 action_link ($action)
 

Data Fields

const UPLOAD_PERMISSION = 'autor'
 
const FOLDER_NAME = 'Wysiwyg Uploads'
 
const FOLDER_DESCRIPTION = 'Vom WYSIWYG Editor hochgeladene Dateien.'
 

Additional Inherited Members

- Protected Member Functions inherited from StudipController
 controller_path ()
 
- Protected Attributes inherited from AuthenticatedController
 $with_session = true
 
 $allow_nobody = false
 
- Protected Attributes inherited from StudipController
 $with_session = false
 
 $allow_nobody = true
 
 $_autobind = false
 

Member Function Documentation

◆ getCurrentUserSettings()

getCurrentUserSettings ( )

Return current user's WYSIWYG settings.

Returns
object User's settings.

◆ settings_action()

settings_action ( )

Store or retrieve settings.

Settings are further subdivided into groups. For example: global, seminar- and user-specific settings (see below).

HTTP GET returns a JSON object with current settings.

HTTP PUT expects a JSON object with settings to store and returns updated settings as a JSON object. Some settings are read-only, others can only be set if the user has the necessary access level.

Currently only the following basic features are supported:

HTTP GET wysiwyg/settings/global Always returns: { "upload": { "permission": "autor", "folder": { "name": "Wysiwyg Uploads", "description": "Vom WYSIWYG Editor hochgeladene Dateien." } } } }

HTTP GET wysiwyg/settings/users/current Always returns following setting for the authenticated user: { "disabled": false | true }

HTTP PUT wysiwyg/settings/users/current Allows only to reset or set the disabled state with: { "disabled": false | true }

Below is a specification of possible future extensions to this interface, that are based on current feature requests by users (mainly people from ELMO, ELAN and ECULT).

wysiwyg/settings/global Common settings for all WYSIWYG editors throughout Stud.IP. wysiwyg/settings/seminars Settings of all seminars. Listed seminars depend on access level: root => full access to all seminars dozent, tutor of a seminar => full access to those seminars others => read-access to seminars they are a member of wysiwyg/settings/seminars/ID Settings of the seminar with the given ID. Access permissions: see above. wysiwyg/settings/seminars/ID/users Seminar's settings for all its users. Access permissions: see above. wysiwyg/settings/seminars/ID/users/ID Seminar's settings for a specific user in that seminar. Access permissions: see above. wysiwyg/settings/users Settings of all users. Listed users depend on access level: root => full access to all users not root => full access to own settings only wysiwyg/settings/users/ID Settings of the user with the given ID. Access permissions: see above. wysiwyg/settings/users/ID/seminars User's settings for all seminars the user is a member of. Access permissions: see above. wysiwyg/settings/users/ID/seminars/ID User's settings for the seminar with the given ID. Access permissions: see above.

The difference of seminar's settings for a user and user's settings for a seminar:

A seminar's teacher may want to set the upload directory for each user to a separate one, which should not be overwritable by a user, in order to make sure that users cannot see other users uploads (there are other ways to do this, but it's just an example).

A user might want to have a specific upload directory in order to collaborate better with other users in the same seminar (e.g. when students form a study group).

For example the ELMO module needs such settings.

JSON scheme for access to wysiwyg/settings: { "global": { "SETTING": ..., ... }, "seminars": { "ID": { "users": { "ID": {...}, ... }, "SETTING": ..., ... }, "ID": {...}, ... }, "users": { "ID": { "seminars": { "ID": {...}, ... }, "SETTING": ..., ... }, "ID": {...}, ... } }

When accessing a sub-resource that resource's branch of the JSON scheme will be returned.

Here is the call graph for this function:

◆ upload_action()

upload_action ( )

Handle the WYSIWYG editor's file uploads.

Files must be posted as an HTML array named "files": <input type="file" name="files[]" multiple="">

Files will be stored in a folder named "Wysiwyg Uploads". If the folder doesn't exist, it will be created.

Results are returned as JSON-encoded array:

[{"name": filename, "type": mime-type, "url": download-link}, {"name": filename, "type": mime-type, "error": error-message}, ...]

Each array-entry corresponds to a single file, each file that was sent with the post request has exactly one entry.

Entries with the property "url" correspond to successful uploads. Entries with the property "error" correspond to failed uploads.

Here is the call graph for this function:

Field Documentation

◆ FOLDER_DESCRIPTION

const FOLDER_DESCRIPTION = 'Vom WYSIWYG Editor hochgeladene Dateien.'

◆ FOLDER_NAME

const FOLDER_NAME = 'Wysiwyg Uploads'

◆ UPLOAD_PERMISSION

const UPLOAD_PERMISSION = 'autor'

The documentation for this class was generated from the following file: