.. _student_section: Student Section :sup:`in progress` ********************************** 'Student' is a multi-purpose term in Kofa which may lead to some misconceptions. First of all 'Student' is a Python/Grok container class and student objects are the instances of this class. Sometimes we are sluggish when talking about 'creating students' and actually mean: 'creating student container objects and storing the objects (persistently) in the ``students`` container'. The latter is the parent container for all students in the portal. The :ref:`treelike storage of objects ` in the student section can be figured as follows:: Student Section (StudentsContainer) | +---> Student | +---> StudentStudyCourse | | | +-----> StudentStudyLevel | | | +-----> CourseTicket | +---> StudentPaymentsContainer | | | +-----> StudentOnlinePayment | +---> StudentAccommodation | +-----> BedTicket .. note:: Throughout Kofa we distinguish singular and plural expressions. A students container contains students (or more precisely student containers), a payments container contains payments, a courses container contains courses, a certificates container contains certificates. Furthermore, a student is also a user of the portal and the student object is a user account surrogate, see :ref:`Applicants and Students `. In the following we always refer to the student container when talking about a student. Students ======== The `Student` class is a container class which means, there are not only attributes describing the student but also content. Each student container contains exactly three sub-containers: ``studycourse`` (instance of `StudentStudyCourse`), ``payments`` (instance of `StudentPaymentsContainer`) ``accommodation`` (instance of `StudentAccommodation`). The purposes of them are described further below. Let's talk about the attributes and methods belonging to the `Student` class, the so-called 'external behaviour' of student objects specified in Zope 'interfaces'. The data stored with each student object are subdivided into three parts: base data, personal data and clearance data. Each part has its own interface. .. note:: Interfaces are one of the pillars of Zope's Component Architecture (ZCA, see also :ref:`prerequisites`). They document the 'external behaviour' of objects. In Kofa interfaces are used to specify the attributes, methods and schema fields of objects. The first two are well-known Python concepts. A Zope schema field is a bit more complicated. It's a detailed description of a field to be submitted via forms to the server, or which is processed by a batch processor. In both cases the input data are being validated against the schema. In Kofa, schema fields in interfaces are also used to automtically add `FieldProperty` attributes of the same name to most content classes. This is done by a function called :py:func:`attrs_to_fields`. These class attributes ensure that corresponding attributes of instances of this class - when being added or changed - always meet the requirements of the schema. Another big advantage of such class attributes is, that attributes with a `FieldProperty` do not need to be set in `__init__` methods. Student Study Courses ===================== Student Study Levels -------------------- Student Payments ================ Student Accommodation =====================