1 | .. _browsing_kofa: |
---|
2 | |
---|
3 | |
---|
4 | Browsing Kofa |
---|
5 | ************* |
---|
6 | |
---|
7 | The reader may ask: How do officers, applicants and students browse |
---|
8 | the portal? Where are the step-by-step operating instructions on how |
---|
9 | to use Kofa? We are always tempted to answer: The menu navigation |
---|
10 | should be self-explanatory and it's quite easy to follow the menu |
---|
11 | prompts or flash messages which appear above page titles in a green, |
---|
12 | yellow or red box. This answer seems a bit over the top. We must |
---|
13 | indeed describe some browser pages and what their clickable actions |
---|
14 | are doing with the data. The reason is, that a lot of Kofa's |
---|
15 | functionality is embedded in view and utility methods and not only |
---|
16 | provided by the functionality of content components. In the |
---|
17 | following, functionality of pages is described in subchapters called |
---|
18 | 'Browser Pages'. |
---|
19 | |
---|
20 | |
---|
21 | .. _page_layout: |
---|
22 | |
---|
23 | Page Layout |
---|
24 | =========== |
---|
25 | |
---|
26 | Kofa makes use of two different `Bootstrap`_ layouts. Anonymous |
---|
27 | users, students and applicants do see a single-column theme with |
---|
28 | only a static top navigation bar. Students can navigate to the |
---|
29 | various display form pages of their record by pulling down the 'My |
---|
30 | Data' tab in the navigation bar. |
---|
31 | |
---|
32 | Officers see a double-column theme after logging in. The left column |
---|
33 | contains a box which contains links to the user's preferences (My |
---|
34 | Preferences) and roles (My Roles). It also contains links to the |
---|
35 | various sections of Kofa depending on the permissions the officer |
---|
36 | has has obtained. Possible sections are: 'Portal Configuration', |
---|
37 | 'Officers', 'Data Center', 'Reports' and 'Access Codes'. A second |
---|
38 | box shows up in the left column when the officer accesses an |
---|
39 | applicant or student record. This box gives direct access to the |
---|
40 | pages of an applicant or student record respectively. |
---|
41 | |
---|
42 | .. image:: navbox.png |
---|
43 | :scale: 50 % |
---|
44 | |
---|
45 | |
---|
46 | .. _navigation_bar: |
---|
47 | |
---|
48 | Navigation Bar |
---|
49 | ============== |
---|
50 | |
---|
51 | The navigation bar of an anonymous user: |
---|
52 | |
---|
53 | .. image:: navbar_anon.png |
---|
54 | |
---|
55 | The navigation bar of an officer with lots of permissions: |
---|
56 | |
---|
57 | .. image:: navbar_officer.png |
---|
58 | |
---|
59 | The navigation bar of a student with drop-down menue: |
---|
60 | |
---|
61 | .. image:: navbar_student.png |
---|
62 | |
---|
63 | |
---|
64 | .. _manage_edit_pages: |
---|
65 | |
---|
66 | Views, Pages and Form Pages |
---|
67 | =========================== |
---|
68 | |
---|
69 | Views are dealing with request and response objects. Usually a view |
---|
70 | renders (produces) HTML or PDF code to be displayed in a web browser |
---|
71 | or a pdf reader respectively. Very often a view only redirects to |
---|
72 | another view or page and does not render code by itself. |
---|
73 | Views, which render pdf code, are called pdf slips in Kofa. |
---|
74 | |
---|
75 | Kofa pages are 'layout-aware' browser views, which means they know |
---|
76 | about the global page layout and render content inside it. |
---|
77 | |
---|
78 | In Kofa most pages are form pages which means they are layout-aware |
---|
79 | views on data. These pages are either used to submit data (simple form |
---|
80 | page), or to display, edit or add persistant data. The latter three |
---|
81 | are called display, edit or add form pages respectively. Kofa is |
---|
82 | using the `Zope Formlib`_ package to auto-generate these forms. |
---|
83 | |
---|
84 | .. note:: |
---|
85 | |
---|
86 | Briefly, Zope Formlib is wedded to `Zope Schema`_, it provides |
---|
87 | display and input widgets (= views) for the fields defined in the |
---|
88 | Zope Schema package. Auto-generation is done with `grok.AutoFields` |
---|
89 | which takes the fields, declared in an interface, and renders |
---|
90 | display or input widgets, according to the schema declaration, for |
---|
91 | display or edit forms respectively. |
---|
92 | |
---|
93 | Whereas display and add form pages are usually shared by officers |
---|
94 | and students, edit form pages are not. Applicants and students are |
---|
95 | not allowed to edit all of their data all the time. Edit access is |
---|
96 | restricted by workflow states or other conditions. Officers' access |
---|
97 | is much less restricted, and we therefore speak of 'managing' |
---|
98 | instead of 'editing' data. In most cases, Kofa uses two different |
---|
99 | form pages which require different permissions: An `EditFormPage` |
---|
100 | requires the |
---|
101 | :py:class:`HandleApplication<waeup.kofa.applicants.permissions.HandleApplication>` |
---|
102 | / |
---|
103 | :py:class:`HandleStudent<waeup.kofa.students.permissions.HandleStudent>` |
---|
104 | permission and a `ManageFormPage` requires the |
---|
105 | :py:class:`ManageStudent<waeup.kofa.students.permissions.ManageStudent>` |
---|
106 | permission. |
---|
107 | |
---|
108 | |
---|
109 | |
---|
110 | .. _action_buttons: |
---|
111 | |
---|
112 | Action Buttons |
---|
113 | ============== |
---|
114 | |
---|
115 | There are two kinds of action buttons which appear on pages: |
---|
116 | |
---|
117 | **Link Buttons** appear on top of the page above the page |
---|
118 | title and are decorated with an icon. These |
---|
119 | :py:class:`action |
---|
120 | buttons<waeup.kofa.browser.viewlets.ActionButton>` have a |
---|
121 | link target which means they usually refer to another Kofa |
---|
122 | page and are sending GET requests to open the page. Example: |
---|
123 | |
---|
124 | .. image:: link_button.png |
---|
125 | :scale: 50 % |
---|
126 | |
---|
127 | **Form Buttons** are submit buttons which appear below a form. |
---|
128 | They are HTML form actions which submit data by sending a |
---|
129 | POST request back to the form page. A form page method is |
---|
130 | called and processes the data or simply redirects to |
---|
131 | another Kofa page. Example: |
---|
132 | |
---|
133 | .. image:: form_buttons.png |
---|
134 | :scale: 50 % |
---|
135 | |
---|
136 | |
---|
137 | |
---|
138 | .. _bootstrap: http://getbootstrap.com/ |
---|
139 | |
---|
140 | .. _zope schema: http://docs.zope.org/zope.schema |
---|
141 | |
---|
142 | .. _zope formlib: http://bluebream.zope.org/doc/1.0/manual/schema.html#auto-generated-forms-using-the-forms-package |
---|