source: main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst @ 13178

Last change on this file since 13178 was 13170, checked in by Henrik Bettermann, 9 years ago

More docs.

File size: 5.4 KB
Line 
1.. _applicants_interfaces:
2
3Parent Containers Interfaces
4============================
5
6`IApplicantsRoot`
7-----------------
8
9Much like ``academics`` and ``students``, also ``applicants`` is a
10unique container (of type `ApplicantsRoot`) located in the
11`IUniversity` instance. It is the counterpart of the students
12(section) container. The root container has a `description` schema
13field attribute which contains human readable, multi-lingual
14information about the application procedure in HTML format. This
15description can be seen by anonymous users, when they enter the
16applicants section (by pressing the 'Application' tab in the
17navigation bar).
18
19.. _multilingual:
20
21.. note::
22
23  A multi-lingual or localized text is a sequence of human-readable
24  text strings in different languages. The languages must be separated
25  by ``>>xy<<``, whereas ``xy`` is the language code. Text parts
26  without correct leading language separator - usually the first part
27  has no language descriptor - are interpreted as texts in the
28  portal's language. The text strings can be either HTML or
29  reStructuredText (REST) formatted.
30
31.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
32   :pyobject: IApplicantsRoot
33
34`IApplicantsContainer`
35----------------------
36
37The applicants root contains the various `ApplicantsContainer`
38objects and is also a configuration object.
39
40.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
41   :pyobject: IApplicantsContainer
42
43`statistics` and `expired` are read-only property attributes.
44`description_dict` contains the same information as the
45`description`, but the sequence of language translations has been
46split up and copied into a dictionary for faster processing. In the
47base package, `local_roles` is an empty list which means, no local
48role can be assigned at applicants container level.
49
50Crucial for application are the `prefix`, `year`, `mode` and
51`application_category` schema fields. The `prefix` atribute can only
52be set when adding a container. It cannot be edited afterwards. The
53attribute determines the application type and automatically sets the
54prefix of the container code and of all applicant ids inside the
55container. The prefix is supplied by the `ApplicationTypeSource`
56(see `application types of base package
57<https://kofa-demo.waeup.org/sources#collapseAppTypes>`_). It is
58followed by the year of entry. Thus, the identifiers of applicants
59containers and the applicants inside the containers start with the
60same prefix-year sequence. Example: ``app2015`` which translates
61into 'General Studies 2015/2016'. Consequently, **applicants cannot
62be moved from one container to another.**
63
64.. _application_mode:
65
66The application mode is either ``create`` or ``update``. In create
67mode, no record exists, the applicants container is empty. The records
68are being created after submission of the first form. Applicants are
69requested to provide all data needed, including their name details.
70In update mode, the applicants container must have been prefilled by
71import, e.g. with records provided by an external board. Applicants
72can't create new records, they can only open and take possession of
73existing records. Both methods have pros and cons. This is further
74discussed below.
75
76The application category is supplied by the
77`ApplicationCategorySource` (see `application categories of base
78package <https://kofa-demo.waeup.org/sources#collapseAppCats>`_) and
79refers to a group of study programmes (certificates) which the
80applicant can apply for, read also chapter on :ref:`Certificates
81<certificate>`.
82
83Applicant Interfaces
84====================
85
86As already mentioned, the applicant objects contains all information
87necessary for application, except for the payment ticket data. The
88base set of the applicant's 'external behaviour' is described by the
89following interface.
90
91`IApplicantBaseData`
92--------------------
93
94.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
95   :pyobject: IApplicantBaseData
96
97As usual, the interface lists attributes first. Except for the
98last two attributes (`password` and `application_date`), they are all
99read-only property attributes, i.e. attributes with a getter method
100only. These properties are computed dynamically and can't be set.
101
102`IApplicant`
103------------
104
105In the base package `IApplicant` is derived from `IApplicantBaseData`
106and only two methods are added:
107
108.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
109   :pyobject: IApplicant
110
111In custom packages we have furthermore interfaces for undergraduate
112and postgraduate students, both derived from `IApplicantBaseData`.
113
114Then there is a customized interface `ISpecialApplicant` for former
115students or students who are not users of the portal but have to pay
116supplementary fees. This reduced interface is used in browser
117components only, it does not instantiate applicant objects.
118
119Applicant Payment Interfaces
120============================
121
122`IApplicantOnlinePayment`
123-------------------------
124
125Instances of this interface are called applicant payment tickets.
126They contain the data which confirm that the applicant has paid the
127application fee.
128`waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from
129`waeup.kofa.payments.interfaces.IOnlinePayment` and promises three
130additional methods which process the applicant data after successful
131or approved payment.
132
133.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
134   :pyobject: IApplicantOnlinePayment
Note: See TracBrowser for help on using the repository browser.