Changeset 12858 for main/waeup.kofa/trunk/docs/source
- Timestamp:
- 16 Apr 2015, 12:03:32 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
main/waeup.kofa/trunk/docs/source/userdocs/datacenter.rst
r12857 r12858 13 13 Kofa's persistent data are stored in a native object database designed for the Python programming language, the so-called ZODB_. An object database stores objects with attributes and not records as rows with columns in tables. These persistent objects can hold any kind of information in attributes and must not adhere to a specific schema like records in tables of a relational database. 14 14 15 The ZODB_ also supports a hierarchical, treelike storage of objects. Objects can contain other objects if they are declared as containers. Objects are stored like folders and files in a filesystem. This makes the object handling very fast and transparent because we can access objects, or more precisely views of objects, by indicating their path in the database, i.e. by traversing the database tree to find an object. Furthermore, we are accessing the views of objects through a web browser by entering a URL (Uniform Resource Locator). This publication path corresponds more or less to the traversal path of our objects. In Kofa the path always contains the object identifiers of all objects which are passed when traversing the database tree. Example:15 The ZODB_ also supports a hierarchical, treelike storage of objects. Objects can contain other objects if they are declared as containers. Objects are stored like folders and files in a filesystem. This makes the object handling very fast and transparent because we can access objects, or more precisely views of objects, by indicating their path in the database, i.e. by traversing the database tree to the object's location. Furthermore, we are accessing the views of objects through a web browser by entering a URL (Uniform Resource Locator). This publication path corresponds more or less to the traversal path of our objects. In Kofa the path always contains the object identifiers of all objects which are passed when traversing the database tree. Example: 16 16 17 17 https://kofa-demo.waeup.org/students/K1000000/studycourse/100/DCO 18 18 19 is the URL which requests a display view of a course ticket with id 'DCO'. This object is stored in a study level container object with id '100', stored in a study course container object with id 'studycourse', stored in the student container object with id 'K1000000', stored in the students root container, stored in the root container of the application, stored in the root of the database itself.19 is the URL which requests a display view of a course ticket with id ``DCO``. This object is stored in a study level container object with id ``100``, stored in a study course container object with id ``studycourse``, stored in the student container object with id ``K1000000``, stored in the students root container, stored in the root container of the application, stored in the root of the database itself. 20 20 21 21 This kind of storage requires that each object gets a unique object identifier (object id) within its container. The id string is visible in the browser address bar. Though it's technically possible for ids to contain spaces or slashes we do not allow these kinds of special characters in object ids to facilitate the readability of URLs. … … 26 26 =========== 27 27 28 Regular data exporters (1) collect objects from specific containers, (2) iterate over the collected objects, (3) extract and mangle information from each object, (4) write the information of each object into a row of a CSV file and (5) finally provide the file for download. The CSV file is neither stored in the database nor archived in the filesystem. (3) and (4) is a flattening of the hierarchical data structure, i.e. a mapping of objects to flat relational data stored in a CSV table. The extracted information must not necessarily be based only on static attributes of the collected object. The data, finally stored in the CSV file, can also be derived from parent or child objects, or dynamically computed by the object's methods and property attributes. These methods and properties can retrieve information from everywhere in the portal's database. 28 Regular data exporters (1) collect objects from specific containers, (2) iterate over the collected objects, (3) extract and mangle information from each object, (4) write the information of each object into a row of a CSV file and (5) finally provide the file for download. The CSV file is neither stored in the database nor archived in the filesystem. (3) and (4) means a flattening of the hierarchical data structure, i.e. a mapping of objects to flat relational data to be stored in a CSV table. The extracted information must not necessarily be based only on static attributes of the collected object. The data, finally stored in the CSV file, can also be derived from parent or child objects, or dynamically computed by the object's methods and property attributes. These methods and properties can retrieve information from everywhere in the portal's database. 29 30 In the following we list all exporter classes including the two attributes and a method description. The `fields` attribute contain the column titles of the export file. These are not necessarily only attributes of the exported objects. The `title` attribute unveils the name of the exporter under which this exporter will be displayed in the user interface. The `mangle_value()` method shows how some of fields are being dynamically computed. 31 32 Academic Section Exporters 33 -------------------------- 29 34 30 35 .. autoclass:: waeup.kofa.university.export.FacultyExporter() … … 33 38 .. autoattribute:: waeup.kofa.university.export.FacultyExporter.fields 34 39 .. autoattribute:: waeup.kofa.university.export.FacultyExporter.title 35 36 40 .. automethod:: waeup.kofa.university.export.FacultyExporter.mangle_value() 37 41 38 42 43 .. autoclass:: waeup.kofa.university.export.DepartmentExporter() 44 :noindex: 45 46 .. autoattribute:: waeup.kofa.university.export.DepartmentExporter.fields 47 .. autoattribute:: waeup.kofa.university.export.DepartmentExporter.title 48 .. automethod:: waeup.kofa.university.export.DepartmentExporter.mangle_value() 49 50 .. autoclass:: waeup.kofa.university.export.CourseExporter() 51 :noindex: 52 53 .. autoattribute:: waeup.kofa.university.export.CourseExporter.fields 54 .. autoattribute:: waeup.kofa.university.export.CourseExporter.title 55 .. automethod:: waeup.kofa.university.export.CourseExporter.mangle_value() 56 57 .. autoclass:: waeup.kofa.university.export.CertificateExporter() 58 :noindex: 59 60 .. autoattribute:: waeup.kofa.university.export.CertificateExporter.fields 61 .. autoattribute:: waeup.kofa.university.export.CertificateExporter.title 62 .. automethod:: waeup.kofa.university.export.CertificateExporter.mangle_value() 63 64 .. autoclass:: waeup.kofa.university.export.CertificateCourseExporter() 65 :noindex: 66 67 .. autoattribute:: waeup.kofa.university.export.CertificateCourseExporter.fields 68 .. autoattribute:: waeup.kofa.university.export.CertificateCourseExporter.title 69 .. automethod:: waeup.kofa.university.export.CertificateCourseExporter.mangle_value() 70 71 72 Application Section Exporters 73 ----------------------------- 74 75 76 Student Section Exporters 77 ------------------------- 39 78 40 79
Note: See TracChangeset for help on using the changeset viewer.