source: main/waeup.kofa/trunk/docs/source/userdocs/browsing.rst @ 13096

Last change on this file since 13096 was 13090, checked in by Henrik Bettermann, 10 years ago

Include some screenshots.

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