Ignore:
Timestamp:
21 May 2015, 07:38:15 (10 years ago)
Author:
Henrik Bettermann
Message:

Add StudentUnpaidPaymentExporter? to export only unpaid tickets. This exporter is designed for finding and finally purging outdated payment ticket.

Location:
main/waeup.kofa/trunk/docs/source/userdocs
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • main/waeup.kofa/trunk/docs/source/userdocs/datacenter/export.rst

    r12953 r12971  
    213213  .. automethod:: waeup.kofa.students.export.StudentPaymentExporter.mangle_value()
    214214
     215Student Unpaid Payment Exporter
     216-------------------------------
     217
     218.. autoclass:: waeup.kofa.students.export.StudentUnpaidPaymentExporter()
     219
     220  .. autoattribute:: waeup.kofa.students.export.StudentUnpaidPaymentExporter.title
     221
    215222Bed Ticket Exporter
    216223-------------------
  • main/waeup.kofa/trunk/docs/source/userdocs/students.rst

    r12969 r12971  
    3939The `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.
    4040
    41 Let's talk about the attributes and methods belonging to the `Student` class, the so-called 'external behaviour' of student objects. The data stored with each student object are subdivided into three parts: base data, personal data and clearance data.
     41Let'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.
    4242
    43 Now comes the point where we have to briefly introduce Zope's (see :ref:`prerequisites`) concept of 'interfaces'.
     43.. note::
     44
     45  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<waeup.kofa.utils.helpers.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.
    4446
    4547
Note: See TracChangeset for help on using the changeset viewer.