UI Inputs rebased

src/UI/Component/Input/Container/Container.php

@@ -0,0 +1,10 @@
+<?php
+
+namespace ILIAS\UI\Component\Input\Container;
+
+/**
+ * Common interface shared by all containers.
+ */
+interface Container extends \ILIAS\UI\Component\Input\Input {
+
+}

src/UI/Component/Input/Container/Factory.php

@@ -0,0 +1,49 @@
+<?php
+namespace ILIAS\UI\Component\Input\Container;
+/**
+ * This is how a factory for inputs container looks like.
+ */
+interface Factory {
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Filters enable to add and remove criteria for displaying or hiding items in a list or table.
+	 *   composition: >
+	 *     Filters are composed of the input selectors and fields for composing the individual criteria for the filter along with an “Apply Filter” Button to apply Filter Button.
+	 *
+	 * rules:
+	 *   accessibility:
+	 *     1: Every Input Element in every Input Collection MUST be accessible by keyboard.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Container\Filter\Filter
+	 */
+	public function filter();
+
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Forms are used for creating content of sub-items or for configuring objects or services.
+	 *   composition: >
+	 *     A form is divided into areas, which are further divided into sections containing settings with selection or input field controls.
+	 *   effect: >
+	 *     Users manipulate input in settings and save the form to apply the settings to the object or service.
+	 *
+	 * context: >
+	 *     Forms are usually placed in a tabbed content area.
+	 *
+	 * rules:
+	 *   usage:
+	 *     1: Forms MUST NOT be used on the same content screen as tables.
+	 *     2: Forms MUST NOT be used on the same content screen as toolbars.
+	 *   composition:
+	 *     1: Each form MUST contain at least one titled form section.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Container\Form\Factory
+	 */
+	public function form();
+
+}

src/UI/Component/Input/Container/Filter/Filter.php

@@ -0,0 +1,9 @@
+<?php
+namespace ILIAS\UI\Component\Container\Filter;
+
+/**
+ * Bundles some filter items together to form a complete filter.
+ */
+interface Filter extends \ILIAS\UI\Component\Input\Container\Container {
+
+}

src/UI/Component/Input/Container/Form/Factory.php

@@ -0,0 +1,95 @@
+<?php
+namespace  ILIAS\UI\Component\Input\Container\Form;
+/**
+ * This is how a factory for inputs looks like.
+ */
+interface Factory {
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Currently the only form available in ILIAS
+	 *
+	 * ----
+	 * @param string
+	 * @param \ILIAS\UI\Component\Input\Item[]
+	 * @return  \ILIAS\UI\Component\Input\Container\Form\Standard
+	 */
+	public function standard($action = "#", $title, $items);
+
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *    A titled form section subdivides a form allowing users to browse the screen.
+	 *    Titled Form Sections are stacked. The stacking reflects perceived relevance
+	 *    and is kept consistent across objects thus learners are “familiar” with forms.
+	 *   composition: >
+	 *     At least one titled form section is used in every form.
+	 *     A title states the purpose shared by all settings of the titled form section.
+	 *     The section visually groups settings.
+	 *   effect: >
+	 *     This element has no effect in terms of clicking.
+	 *
+	 * background: >
+	 *    Tidwell ‘Designing Interfaces’ proposed the pattern of
+	 *    ‘Titled Sections’ and describes it as: “Define separate sections of content by giving each one a visually strong title,
+	 *    separating the sections visually, … “. She further explains that those sections should be grouped by topic or task.
+	 *    According to Tidwell is content that is sectioned neatly into chunks easier to grasp since the human
+	 *    visual system is always looking for bigger patterns. In ILIAS such sections in a form are called titled form sections.
+	 *
+	 * rules:
+	 *   wording:
+	 *       1: A Titled Form Section MUST contain a title.
+	 *       2: The title SHOULD summarize the contained settings accurately from a user’s perspective.
+	 *       3: The title SHOULD contain less than 30 characters.
+	 *       4: The titles MUST be cross-checked with similar forms in other objects or services to ensure consistency throughout ILIAS.
+	 *       5: In doubt consistency SHOULD be prioritized over accuracy in titles.
+	 *   composition:
+	 *       1: Proper Titled Form Sections SHOULD comprise 2 to 5 Settings.
+	 *       2: More than 5 Settings SHOULD be split into two areas unless this would tamper with the “familiar” information architecture of forms.
+	 *       3: There MUST NOT be a Setting without an enclosing Titled Form Section. If necessary a Titled Form Section MAY contain only one single Setting.
+	 *       4: The first and last titled form section of a form MUST contain a “Save” and “Cancel” button for the form. “Save” is left and “Cancel” is right.
+	 *       5: >
+	 *         In some rare exceptions the Buttons MAY be named differently: if “Save” or “Cancel”  are clearly a
+	 *         misleading since the action is more than storing the data into the database. “Send Mail” would be an example of this.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Container\Form\Section
+	 */
+	public function section($title, $items);
+
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Settings can be nested allowing for settings-dependent further configuration.
+	 *   composition: >
+	 *     Subsettings are underneath the Setting they depend on. The Subsetting is indented to visually confirm said dependence.
+	 *   effect: >
+	 *     Subsettings are revealed after enabling the selection control of a setting. If the setting is not enabled, the subsetting remains hidden.
+	 *
+	 * rules:
+	 *   usage:
+	 *       1: >
+	 *         There MUST NOT be a nesting of more than one subsetting (see Jour Fixe comment in feature wiki reference).
+	 *         The only exception to this rule is the required quantification of a subsetting by a date or number.
+	 *         These exceptions MUST individually accepted by the Jour Fixe.
+	 *       2: The title SHOULD summarize the contained settings accurately from a user’s perspective.
+	 *       3: The title SHOULD contain less than 30 characters.
+	 *       4: The titles MUST be cross-checked with similar forms in other objects or services to ensure consistency throughout ILIAS.
+	 *       5: In doubt consistency SHOULD be prioritized over accuracy in titles.
+	 *   composition:
+	 *       1: Subsettings MUST bear an identifier.
+	 *   interaction:
+	 *       1: Subsetting MUST NOT be enabled by any other form element than a checkbox or a radio input group.
+	 *   ordering:
+	 *       1: >
+	 *          Subsettings of a setting can be stacked. The most relevant subsetting MUST be the first subsetting in the stack.
+	 *          The least relevant comes last in the stack.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Container\Form\Sub
+	 */
+	public function sub($items);
+}

src/UI/Component/Input/Container/Form/Section.php

@@ -0,0 +1,9 @@
+<?php
+
+namespace  ILIAS\UI\Component\Input\Container\Form;
+
+interface Section extends \ILIAS\UI\Component\Input\Container\Container {
+	/**
+	 * @Todo: Add Interface
+	 */
+}

src/UI/Component/Input/Container/Form/Standard.php

@@ -0,0 +1,24 @@
+<?php
+namespace  ILIAS\UI\Component\Input\Container\Form;
+
+/**
+ * Interface Standard
+ * @package ILIAS\UI\Component\Input\Container\Form
+ */
+interface Standard extends \ILIAS\UI\Component\Input\Container\Container {
+
+    /**
+     * Get the forms action
+     *
+     * @return string
+     */
+    public function getAction();
+
+
+    /**
+     * Get the title of the form
+     *
+     * @return string
+     */
+    public function getTitle();
+}

src/UI/Component/Input/Container/Form/Sub.php

@@ -0,0 +1,11 @@
+<?php
+
+/* Copyright (c) 2016 Timon Amstutz <[email protected]> Extended GPL, see docs/LICENSE */
+
+namespace  ILIAS\UI\Component\Input\Container\Form;
+
+interface Section extends \ILIAS\UI\Component\Input\Container\Container {
+	/**
+	 * @Todo: Add Interface
+	 */
+}

src/UI/Component/Input/Factory.php

@@ -0,0 +1,104 @@
+<?php
+namespace ILIAS\UI\Component\Input;
+/**
+ * This is how a factory for inputs looks like.
+ */
+interface Factory {
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Input Containers are aggregate controls in order to gather input from the user. Examples are Forms or Filters.
+	 *   composition: >
+	 *     They consist of one or multiple Input items.
+	 *   effect: >
+	 *      Input entered into in Input Collection is saved by clicking on an Interaction Trigger, mostly a Button.
+	 *
+	 * rules:
+	 *   accessibility:
+	 *     1: Every Input Item in every Input Collection MUST be accessible by keyboard.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Container\Factory
+	 */
+	public function container();
+
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     An Input Item is used to collect one specific piece of information from the  user.
+	 *   composition: >
+	 *     A Input item is composed of an label naming the concrete item, might contain a by line describing it and an input control
+	 *     the collect the actual data from the user.
+	 *   effect: >
+	 *     The effect depends on the control-type of the input element.
+	 *
+	 * rules:
+	 *   composition:
+	 *     1: A Input Item MUST use a label.
+	 *   wording:
+	 *     1: >
+	 *      A label MUST be composed of one single term or a very short phrase.
+	 *      The label is an eye catcher for users skimming the form.
+	 *     2: >
+	 *       A label MUST avoid lingo. Intelligibility by occasional users is prioritized over technical accuracy.
+	 *       The accurate technical expression is to be mentioned in the by-line.
+	 *     3: >
+	 *       An label MUST make a positive statement.
+	 *       If the purpose of the setting is inherently negative, use Verbs as “Limit..”, “Lock..”.
+	 *     4: >
+	 *       Wording and structure (sequence and control) MUST be consistent with identifiers in other objects.
+	 *       If you feel a wording needs to be changed, then you MUST propose it to the JF.
+	 *     5: A by-line (explanatory text) MAY be added below the input element.
+	 *     6: >
+	 *       If by-lines are provided they MUST be informative, not merely repeating the identifier’s or input element’s content.
+	 *       If no informative description can be devised, no description is needed.
+	 *     7: >
+	 *       A by-line MUST clearly state what effect the Setting produces and explain, why this might be important and what it can be used for.
+	 *     8: >
+	 *       Bulk by-lines underneath a stack of option explaining all of the options in one paragraph MUST NOT be used.
+	 *     9: >
+	 *       A by-line SHOULD NOT address the user directly. Addressing users directly is reserved for cases of high risk of severe mis-configuration.
+	 *     10: >
+	 *       A by-line MUST be grammatically complete sentence with a period (.) at the end.
+	 *     11: >
+	 *       By-lines SHOULD be short with no more than 25 words.
+	 *     12: >
+	 *       By-lines SHOULD NOT use any formatting in descriptions (bold, italic or similar).
+	 *     13: >
+	 *       If by-lines refer to other tabs or options or tables by name, that reference should be made in quotation marks:
+	 *       ‘Info’-tab /  "Info"-Reiter, button ‘Show Test Results’ / Button "Testergebnisse anzeigen",
+	 *       ‘Table of Detailed Test Results’  /  "Tabelle mit detaillierten Testergebnissen".
+	 *       Use proper quotation marks, not apostrophs.
+	 *       Use single quotation marks for english language and double quotation maks for german language.
+	 *     14: >
+	 *       By-lines MUST NOT feature parentheses since they greatly diminish readability.
+	 *     15: >
+	 *       By-lines SHOULD NOT start with terms such as: If this option is set … If this setting is active …
+	 *       Choose this setting if … This setting … Rather state what happens directly: Participants get / make  / can …
+	 *       Point in time after which…. ILIAS will monitor… Sub-items xy are automatically whatever .. Xy will be displayed at place.
+	 *
+	 *
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Item\Factory
+	 */
+	public function item();
+
+	/**
+	 * ---
+	 * description:
+	 *   purpose: >
+	 *     Validation components are used to validate various kinds of inputs.
+	 *   composition: >
+	 *     Validation components are usually placed inside of other inputs components. They can not work on their own.
+	 *   effect: >
+	 *     Validations show whether an input is (or will be) accepted by the system or is (or was) rejected.
+	 *
+	 * ----
+	 * @return  \ILIAS\UI\Component\Input\Validation\Factory
+	 */
+	public function validation();
+
+}