CodEx – Design Manual

8/8/2019 CodEx Design Manual

1/101

CodEx Design ManualBy the CodEx Team. Revision: 1453

Martin MaresTomas GavenciakMartin KrulisJiri Svoboda

Lukas Turek

Copyright 2008 The CodEx Team.

CodEx is ree sotware; you can redistribute it and/or modiy it under the terms o the GNUGeneral Public License as published by the Free Sotware Foundation; either version 2, or (atyour option) any later version.

CodEx is distributed in the hope that it will be useul, but WITHOUT ANY WARRANTY;without even the implied warranty o MERCHANTABILITY or FITNESS FOR A PARTICU-LAR PURPOSE. See the GNU General Public License or more details.

You should have received a copy o the GNU General Public License along with CodEx; see thele COPYING. I not see .


2/101

i

Table o Contents

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11.1 An Introduction to Automatic Grading Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Overview o the CodEx System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Development Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 CodEx Components and Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4.1 Components o the CodEx Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4.2 Third-party Components Distributed with CodEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4.3 External Dependencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Assessment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Web User Interace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42.1 Page Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.1 Page Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 Deault Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Module groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3.1 Module groups/tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.4 Module exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.4.1 Module exercises/solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.5 Module exercises/comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.1.6 Module users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.7 Module news . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.8 Query Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1.8.1 Session Data Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.8.2 JavaScript Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.9 Main menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Component Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.1.1 PageComponentAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.1.2 Component Session Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Menu Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2.2 Generic Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2.3 CodEx Menu Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 Table Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3.1 ITableModel Interace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3.2 DBTableModel Abstract Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.4 Form Component. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5 File Manager Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5.2 Browsing Files and Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.5.3 Creating Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.5.4 Uploading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.5.5 Downloading Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.5.6 Renaming, Moving and Deleting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.5.7 File Manager Error Handling and Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.5.8 File Manager Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.1 The Trusted Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


3/101

ii

2.3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.3.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.3.1 Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3.2 Protected Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.3.3 Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.3.4 Delegated Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.3.4 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1 Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.1.1 Client Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.1.2 Service Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.2 Services Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Creating New Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.1 Debugging and Security Matters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Implemented Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1 add_user Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.1.1 Query Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.1.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3.2 edit_user Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2.1 Query Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.3 list_group_results Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3.1 Query Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.3.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.4 change_membership Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.4.1 Query Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.4.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1 MVC (Model-View-Controller) Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.1 MVC General Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.1.1 Processing Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.1.2 Bootstrap (index.php) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.1.3 Page Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.1.4 Routing and Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.2 PageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1.2.1 Page Paths and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.2.2 Component Paths and Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.2.3 Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.3 Dispatcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.4 PageAbstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1.4.1 Initialization and Rights Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.4.2 Filtering GET (URL) Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.4.3 Creating URLs and Redirects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4.4 CSS and JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4.5 Page Rendering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4.6 Error and Inormational Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1.5 ParamFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.6 View Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.7 Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.7.1 Implementation Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39


4/101

iii

4.1.7.2 Data Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.8 Other parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.8.1 Application Conguration and Constants. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.8.2 Log and Error Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.1.8.3 Translations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.8.4 HtmlHelper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 CFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1 Introduction to CFI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2 CFI Interaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.2.1 File-system Interace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2.2 Directory Interace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.3 Entry Interace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.4 File Interace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.3 CFI Semantics and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.3.1 File-system Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.3.2 File-system Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.4 Filesystem-based Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.4.1 File-system Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.4.2 Filename Checking and Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.5 Archive-based Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.6 File Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.6.1 Contracting Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.6.2 Compression and Decompression Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.6.3 Text File Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.7 CFI Utilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.8 CFI Helper Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Data Access Library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.1 Select Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3.2 Table Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3.3 File Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.4 Entity Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4 Mailing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.1 Generic Mailer Class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.1.1 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.1.2 Email_Encode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.1.3 Email_Funmail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.1.4 Email_Dump . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.2 CodEx Mailer Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.3 Event Notier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5 Database Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1 Database Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.2 Database Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.3 Table users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4 Table groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.5 User-group Relation Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.5.1 Table users_in_groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.5.2 Table bonus_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.6 Table exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535.6.1 Table texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.7 Table tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.8 Table task_points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.9 Table submits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.9.1 Table solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


5/101

iv

5.10 Table exercise_comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.11 Table exercise_ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.12 Table news . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.13 Table delegations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.14 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.14.1 View group_interested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.15 Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.16 Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.16.1 Triggers Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.16.2 Triggers Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Data in Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.1 Directory structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.2 Exercise Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3 Metadata File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.1 Generic Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2 Attribute Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.4 Exercise Export And Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.4.1 Package Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.4.2 XML Contents File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.4.3 Exporting/Importing Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.1 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1.1 Denition o Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.1.2 Protocol Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.2 Evaluation Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.3 Modications or CodEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8 Queue Manager (qman) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758.1.2 Submit Storage Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8.1.2.1 Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.1.2.2 Input Job Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

8.1.3 Job Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768.1.3.1 Job Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1.3.2 Job Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.1.3.3 Job Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.1.4 Worker Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788.1.4.1 Worker Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788.1.4.2 Worker Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.1.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.1.5.1 Resource regulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.1.6 Locking and Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 798.2 Interace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.2.1 Conguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 808.2.1.1 Conguration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

8.2.1.2 Command-line Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 828.2.1.3 List o Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.2.2 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 848.2.2.1 Metadata Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


6/101

v

8.2.2.2 Attributes or CodEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858.2.3 Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.2.4 Status Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 868.3.1 The libucw Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

8.3.2 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.3.2.1 job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.3.2.2 worker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 888.3.2.3 inbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 898.3.2.4 status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.3.2.5 metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 908.3.2.6 conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.3.2.7 log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 918.3.2.8 qman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Appendix A Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Appendix B Database Schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95


7/101

Chapter 1: Introduction 1

1 Introduction

1.1 An Introduction to Automatic Grading Systems

Since checking programs written by studens as their homework is very tedious and time-consuming, the idea o automating this process has been around or quite some time. In 1965G. E. Forsythe and N. Wirth o Stanord University devised a system where the students wrotesub-routines in a dialect o Algol, submitted them on punch cards and these were evaluated byan automatic grading program.

Kassandra was an automatic grading system developed at ETH Zurich in the 1990s. Similarto Forsythe and Wirths design, it had improved security, as the tested program ran seperatelyrom the grader and communicated with it through network sockets. It also sported a window-

based GUI or ease o use. It was able to evaluate solutions written in Matlab, Maple andOberon (a descendant o Modula-2). A slight drawback o the system was that the studentsneeded to use a special module provided by Kassandra to communicate with the grader.

Generally an automatic grading system can evaluate the source code statically (i.e. by

examining the code without running it, or example assessing the coding style) or dynamically,

running the code on some testing data. The testing data can be provided by the author o the

problem, or sometimes even generated on the y.

1.2 Overview o the CodEx System

CodEx is a system or automatic evaluation o source code based on dynamic analysis. Via itsuser interace, algorithmic problems can be entered or solving by other users (e.g. students),who submit their solutions to the problem in the orm o a source-code le. The solutions arecompiled and run in a sandboxed environment (MO-Eval) on a series o test inputs (providedby the author o the problem). The solutions are graded depending on whether they producethe correct output within the prescribed time and memory limits.

For evaluation we make use o the MO Contest Environment a.k.a. MO-Eval, used at theCzech Olympiad in programming (http://mo.mff.cuni.cz/p/index.html.en ), which isolatesthe tested program rom the system by running it in a sandbox, measures the time and memoryconsumed and makes sure the program does not exceed the imposed time and memory limits.

The system can currently evaluate solutions written in the C, C++, C#, GNU Pascal andFree Pascal languages, but as adding more languages is airly easy, support or more languagesis expected in the uture.

In CodEx, some users create exercises which represent the problems to be solved and creategroups which tie together a set o exercises (called tasks) and users (the members o the group).The members solve tasks or which they are awarded points. I they obtain the prescribednumber o points and complete all obligatory tasks, then they have met the group requirements.

Among the main strengths o CodEx is its comortable web-based interace, allowing the

users to enter and solve problems rom practically anywhere. CodEx is very modular and it

can be easily run in a distributed ashion, making it highly scalable. Finally, having its security

based on a sandboxing/virtualization principle, CodEx allows the users to solve the problems in

a standard programming environment, bypassing the need or them to get aquainted with any

special libraries or protocols.
http://mo.mff.cuni.cz/p/index.html.enhttp://mo.mff.cuni.cz/p/index.html.en


8/101


1.3 Development Timeline

October 2007

Agreed upon using the Zend Framework. MVC development started.

November 2007 February 2008Development o C# evaluation support.

February April 2008Architecture design.

April - July 2008Preliminary work. Implementation o libraries and components.

July 9th, 2008Principal development started.

July 2008 Implementation o individual modules and pages.

August 2008Debugging, testing, documentation, translation.

1.4 CodEx Components and Dependencies

From a birds-eye perspective, CodEx consists o a WWW ront-end (running on the LAMPplatorm) and an evaluation back-end that runs asynchronously rom the ront-end. A moredetailed view o its components and other soware packages employed by the system ollows.

1.4.1 Components o the CodEx Project

All components o CodEx project are licensed under GNU General Public License version 2 orlater (http://www.gnu.org/copyleft/gpl.html ).

WWW ront-endUser interace, written in PHP.

Queue Manager (Qman)Schedules jobs or evaluation, written in C.

Judges and FiltersSimple programs in C which veriy the output o evaluated programs.

pthread-akeLibrary that replaces pthread in GNU libc. Required or C# evaluation.

1.4.2 Third-party Components Distributed with CodEx

Zend Framework 1.5.3PHP development ramework. Contains essential libraries used by the WWW ront-end. Available at http://framework.zend.com/ , licensed under the 3-clause BSDlicense.

libucw Library rom Sherlock Holmes Search Engine (http://www.ucw.cz/holmes/ ), li-censed under the GNU Lesser General Public Licence (LGPL). Required by Qman.

The MO Contest Environment (a.k.a. MO-Eval)Available at http://mj.ucw.cz/mo-eval/ , licensed under the GNU General PublicLicense version 2. CodEx uses a slightly modied version o MO-Eval as a workerthat evaluates submitted source code.
http://www.gnu.org/copyleft/gpl.htmlhttp://framework.zend.com/http://www.ucw.cz/holmes/http://mj.ucw.cz/mo-eval/http://mj.ucw.cz/mo-eval/http://www.ucw.cz/holmes/http://framework.zend.com/http://www.gnu.org/copyleft/gpl.html


9/101


Mono 1.2.5.1C# compiler and MSIL interpreter, available at http://www.mono-project.com/ .Required or C# evaluation. CodEx uses a slightly patched version, the original

version is not compatible with sandbox.

Reader and WrapperC# classes that are linked to every evaluated C# program. Released as publicdomain.

1.4.3 External Dependencies

Linux kernel 2.6.13 or later

Apache WWW server 2.0 or later

PHP 5.1.6 or later (both CLI and the Apache module)

MySQL 5.0.32 or later

GCC 4.1 or later

Free Pascal compiler 2.0.0 or later

GNU Pascal Compiler 3.4.6 or later

1.5 Assessment

The major goal o this project was to create a stable application that will be used or the rst-year programming course at the Faculty o Mathematics and Physics, Charles University. Theseambitions were met quite completely, since CodEx has already been used and tested on SummerSchool or Teachers o Inormatics and will be deployed at the aculty during the next scholaryear.

The main goal has been accomplished, however many issues were let unnished and willbe attended in the uture. GUI ergonomics are insucient and graphic design is poor. Someunimportant issues were let undocumented or the time being and there are minor redundanciesin the written code. All these issues were caused by lack o time and will be solved in the nearestuture.

Even though there are some unnished bits and pieces the application is ully operationaland ready to be used in production. Thanks to huge experience rom the previous version othe CodEx application that was in use on MFF last scholar year, the developement was smoothand we did not walk into any serious obstacles.
http://www.mono-project.com/http://www.mono-project.com/


10/101

Chapter 2: Web User Interace 4

2 Web User Interace

2.1 Page Hierarchy

2.1.1 Page Overview

2.1.2 Deault Module

index This page only contains a login orm. It is displayed when the user is not logged inor when his session expires. The login orm triggers a login action handled by thisorm.

This orm also handles a logout action triggered by a logout button that is displayedin the page header when the user is logged in.

This page also acts as a sink. I user wants to access another page but does not havesucient rights, he/she is transered to allback page. Index is transitive allbackor all pages. Thereore it respects given URI and tries to keep it in case user is justre-logging.

I this page is accessed and user is logged in, the browser is redirected to welcomepage so the user will not try to log in again.

welcome The rst page displayed to user when he/she logs in. The page contains a wel-come message, recent news, some other useul inormation and links (to help pages,tutorials, FAQ, etc.).

The welcome page does not have any actions since it is only meant or reading.

settings A page with the users personal settings. It contains a orm where the user maychange his/her account properties (including password).

Besides the properties user may yield his/her delegations. Delegations are displayedin two separated tables (one or groups and one or exercises). Every delegation isequipped with check box. A yield button that removes all selected delegations isplaced beneath the table. It triggers yieldQuery action which displays conrmationdialog and (i yielding is conrmed) calls yield action. Both actions are handledby this page.

mail A page enabling a user to send a bug report or a message to another CodEx user (ormultiple users). It displays a orm allowing the user to enter the subject and text othe message. It also displays a xed list o recipients that cannot be modied here

(it is determined by the arguments o the page) and the automatically generatedsubject prex and body preamble.

When used to report a bug, the page takes one GET parameter, bugUrl. All Reporta Bug links are generated with this argument set to the (server-relative) URL othe current page. The URL is attached to the message and allows the administratorto see rom which page the bug was issued.

When used or sending messages to other users, the page takes the parameterrecipients instead. It is an array o IDs o users who are to receive the message.

When the user is logged in, his name and e-mail address are set automatically andcannot be changed. When he is not logged in, he must ll these in.

A user who is not logged in can only send a bug report (which will be delivered toadmin). A user who is logged in but has no special rights can send a message to asingle recipient. A user possessing RIGHT READ or users may send a message toan arbitrary number o recipients.


11/101


2.1.3 Module groups

All pages in this module are intended or displaying and managing groups and everything related

such as tasks, submits, points etc.Only group members or users with at least RIGHT_READ or a given group may see the ollowing

pages (except or the index page). Some o these pages also require additional rights.

index List o available groups. Groups are displayed in three separated lists:

member groups (i.e. groups where the user has membership)

owned groups

other groups (Naturally, the user can only see public groups or groups or whichhe/she has at least RIGHT_READ.)

A join button is displayed next to public groups which the user is not a member o.This button generates a join action that is handled by this page.

I the user has sucient rights or a group (at least RIGHT_DELETE) he/she may alsosee a delete button next to the group. It generates a delete action that is alsohandled by this page.

create A orm or creating new groups. The creation itsel is handled by this page and, icompleted successully, the browser is redirected to the index page.

This page is only visible or users with at least RIGHT_CREATE_PRIVATE general rightor groups.

results A table displaying an overview o results. One row is displayed or each groupmember, showing the points or every task in the group, bonus points and nalpoint totals.

This page is only visible i the group is not discreet (see the groups.discreetdatabase eld) or by users who have at least RIGHT_READ or this group.

I the user has RIGHT_EDIT or the group, a Remove button is displayed in each rowo the table, allowing to renive the user rom the group. This button generates aremove action that is also handled by this page.

The page requires the GET parameter groupId to hold the ID o the group beingdisplayed. I this ID is omitted, the results rom all groups (more precisely, allgroups visible to the logged user) are displayed.

properties

A orm where group properties (point limit, ags, comment ...) can be edited. It also

displays a table o users holding some delegations or this group. Each delegationline is equipped with a revoke button that triggers a revoke action (handled by thispage). Delegations can only be revoked here. The only place where they can begranted is at the users/rights page.

At the bottom o the page, there is an additional orm that allows changing theowner o the group. This orm is visible only to users with RIGHT_ADMIN or thegroup. When the owner is changed and Keep Admin Rights box is checked, adminrights are delegated to ormer owner. Granter o these rights is implicitly an actor.I the actor is also the ormer owner, rights are delegated by admin (since nobodymay grant rights to himsel/hersel).

This page is only visible or users with at least RIGHT_EDIT and the delegation part

requires even RIGHT_ADMIN since only the admin or owner can grant and revokedelegations. The page also requires the GET parameter groupId to hold the ID othe group being displayed. I this parameter is omitted or invalid, the browser isredirected to the index page.


12/101


bonusPoints

A list o bonus points or all users and a simple orm that allows granting bonuspoints to multiple users at once. Bonus points are arranged in a table where each

row represents one user and columns are bonus points aggregated by their comments(bonus points with the same comment are displayed in one column).

I the user has no special rights and the group is discreet (see groups.discreetdatabase eld), he/she can only see his/her bonus points. Users with RIGHT_READcan see all bonus points and users with RIGHT_EDIT may even grant and revokethem.

Users with RIGHT_EDIT can see the points in text edit boxes so they can edit andrevoke them. Theres also a simple orm underneath that allows to create a newcolumn (comment group) in the table. The new column is created empty and it willnot be saved into database unless some points are entered into it.

2.1.3.1 Module groups/tasksAll the ollowing pages require the GET parameter groupId to hold the ID o the group being op-erated on. I this parameter is omitted or invalid, the browser is redirected to the groups/indexpage.

These pages are only visible to group members or users with RIGHT_READ or the selectedgroup.

index A list o tasks assigned to the selected group. The user can select a task by clickingon, so that he/she can see its specication, submit a solution etc.

I the user has at least RIGHT_EDIT or the selected group, a delete button is displayedat each task. This button generates a delete action which is handled by this page.

specification

Page displaying the specication o the task (exercise). The specication an XHTMLtext with all instructions necessary or a user who wants to solve this task (problemdescription, input/output ormat, etc).

This page requires the GET parameter taskId that species the ID o the taskwhose specication is being displayed. I omitted, the browser is redirected to theindex page.

newSubmit

A orm that allows the user to submit a new solution or this task. The page isresponsible or receiving the submitted source code, creating a new entry in the

database and inserting int into the eval queue.The user can only submit one source le with the proper extension. The le caneither be uploaded or its content can be entered directly into a text eld. I thesubmit is received successully, the browser is redirected to the submits page.

This page is only visible or group members. When an operator wants to test theexercise beore it is being assigned he/she may use exercises/solutions page to doso.

properties

Overview o the tasks properties (points, deadline, comment, etc). Properties aredisplayed in a orm, thus they can be directly edited and saved. The page is respon-

sible or saving the properties into the database.This page is only visible or users with RIGHT_EDIT. It also requires the GETparameter taskId to hold the ID o the task whose parameters are displayed andedited. I omitted, the browser is redirected to the index page.


13/101


submits A list o all submits that the user is allowed to see. Group members with no specialrights can only see their own submits. Users with RIGHT_READ (or the selected task)can see all submits rom all group members, and nally, users with RIGHT_EDIT may

even delete and re-evaluate submits.

I the GET parameter taskId is specied, only submits related to that task aredisplayed. Otherwise, all submits or all tasks in the selected group are displayed.On this page, the user can also change which task is selected by selecting anothertask rom a pull-down list.

The table o submits is equipped with a lter orm, where the selected task may bechanged and other lter restrictions applied. It is possible to restrict the listing justto submits rom a given user, time period or points range.

A checkbox is displayed next to each submit or users with RIGHT_EDIT. Thesecheckboxes mark submits that are afected by delete and reevaluate buttons be-

neath the orm. Both buttons are part o the same orm that encapsulates also thecheckboxes. This orm is also handled by this page.

submitInfo

More detailed inormation about one submit. It is visible or all users with RIGHT_READ or the submit. Users with RIGHT_EDIT may even change attached bonuspoints, delete the submit or send it or re-evaluation. Changing the amount o bonuspoints is handled by a orm component. Re-evaluation and deletion is handled bythe actions reevaluate and delete that are handled by this page.

The page displays summary inormation (time, points...), the evaluation log and thesubmitted source code. A user with RIGHT_EDIT can also see additional inormationrom eval (such as consumed time and memory or each test, results rom judges

etc.) Some data (e.g. the evaluation log) will not be available i the submit has notbeen evaluated yet.

This page requires the GET parameter submitId to point to the submit that isbeing displayed. I omitted, the browser is redirected to the submits page.

2.1.4 Module exercises

Pages in this module display and manage exercises, their specications and exemplary solutions.The user must have at least RIGHT_READ or exercises in order to see these pages (even the indexpage).

index A list o all exercises that are visible to the user. The user may open an exercise by

clicking on it, which brings him to the specifcation page and sets the exerciseIdargument, allowing him to access other exercise-specic pages.

The user can see all public exercises and those private exercises or which he/shehas RIGHT_ADMIN. Each exercise or which the user has RIGHT_DELETE is equippedwith a delete button that triggers a delete action. This action is also handled bythis page.

create A orm or creating new exercises. Creation itsel is handled by this page and, i com-pleted successully, the browser is redirected to the editText page with exerciseIdset to the ID o the newly created exercise.

This page is visible only or users with a general RIGHT_CREATE or exercises.

propertiesA orm where properties o the exercise are displayed and edited and a list o dele-gated rights or the selected exercise. Submission o the properties orm is handledby this page.


14/101


Delegations are displayed in a table and each delegation is equipped with a revokebutton that triggers a revoke action (which is also handled by this page). This isthe only place where delegations can be revoked. The only place where they can be

granted is the users/rights page.

At the bottom o the page, there is an additional orm that allows changing theauthor o the exercise. This orm is visible only to users with RIGHT_ADMIN or theexercise. When the author is changed and Keep Admin Rights box is checked, adminrights are delegated to ormer author. Granter o these rights is implicitly an actor.I the actor is also the ormer author, rights are delegated by admin (since nobodymay grant rights to himsel/hersel).

The properties page is only visible or users with at least RIGHT_READ or the selectedexercise. To edit the properties, however, one needs at least RIGHT_EDIT. Userswith RIGHT_ADMIN can also see the delegations. The Page also requires the GETparameter exerciseId to hold the ID o the exercise or which the properties aredisplayed. I omitted, the browser is redirected to the index page.

specification

The text o the current exercise specication and a list o all specication versions,identied by their date o creation. The user can also examine the texts o otherversions by clicking on their captions in the list. With RIGHT_EDIT or the selectedexercise the user may also delete versions and change which version is the currentone. Corresponding buttons in the list generate delete and setActual actions thatare handled by this page.

Specication versions can be also be edited. An edit button directs the browser onthe editText page with the proper GET parameters set.

The page requires the GET parameter exerciseId to hold the ID o the exercisewhose specication is being displayed. Also the page may receive the GET parame-ter textId that holding the ID o the specication version that should be displayed.I this parameter is omitted, the current version is displayed.

I there are no specications o the exercise yet, the browser is redirected to theeditText page.

editText A orm or editing the selected version o the specication. Modications submittedby this orm are handled by this page. The orm may be submitted either in twoways: simply a save (modications are saved into the existing specication version)or saved as new version (which creates new version o the specication and makesit the current one). I the exercise has no specication versions yet, the orm canonly be saved as a new version.

This page is only visible or users with at least RIGHT_EDIT or the selected exercise.The page also requires the GET parameters exerciseId and textId that reer tothe exercise and its specication that is being edited. ItextId is omitted, the ormis blank and can be only used or creating new text.

attachedFiles

List o les attached to a given specication. Each specication can have its owndirectory tree with pictures, les or download etc. These are managed with a lemanager component on this page.

Only users with at least RIGHT_EDIT may modiy les in the directory. The page

also requires the GET parameter exerciseId pointing to the exercise and optionallytextId pointing to the specication version to which the displayed directory belongsto. ItextId is not set, the les attached to the current version are displayed. Ithe exercise does not have any specication, the page is inaccessible.


15/101


configuration

A orm or editing basic test congurations. All general test properties may be mod-ied here except points and resource limits. Conguration parameters are parsed

directly rom evals cong test le and when editing orm is submitted the le isatomically replaced.

This page is visible or all users (with RIGHT_READ o course) but only users withat least RIGHT_EDIT may edit parameters and save them. The page also requiresGET the parameter exerciseId which holds the ID o the exercise whose testsconguration is being edited.

limits Special orm or modiying points per test, time limit and memory limit values. Thispage can either edit general limits or all extensions or limits that are designed orone extension only.

At the top o the page there are text boxes or editing general values or all tests (in

given extension). They are ollowed by table where individual values or each testmay be dened. These values are combined in ollowing order (ordered rom mostto least important:

- Values dened or individual test and individual extension.

- Values dened or individual test and all extensions.

- General values or all tests in individual extension.

- General values or all test and all extensions.

The page also contains special interace that allows experts add and modiy extra(non-standard) parameters to cong les.

All values displayed on this page are parsed directly rom exercises cong le and

i the orm is submitted, the le is atomically replaced.Every user with RIGHT_READ has access to this page but only user with RIGHT_EDIT or given exercise may change its values. Page also requires exerciseId GETparameter that holds id o an exercise whose cong le is being edited and optionalextension parameter that holds the extension (dening programming language) orwhich the limits applies. I omitted, general limits are edited.

testFiles

Contents o the directory attached to the exercise. This directory contains lesused or testing submitted solutions o the exercise (input data and correspondingoutput). How these les are used is dened by test conguration (see configurationpage).

This page is visible or all users (with RIGHT_READ, o course) but only users withat least RIGHT_EDIT may modiy the les. The page requires the GET parame-ter exerciseId that species the exercise whose test-les are being displayed (oredited). I omitted, the browser is redirected to the index page.

assignTasks

Assigning exercises (creating tasks) to groups. This page displays some inormationabout the exercise that might be useul or a group owner who wants to use thisexercise, and a list o all groups to which the user has at least RIGHT_EDIT. Theuser may check groups to which he wishes to assign the task (thus, multiple tasksmay be created at a time).

The page also contains a orm with basic task parameters (the deadline, points etc.)that are used as deaults or newly created tasks.

The page requires the GET parameter exerciseId to hold the ID o the exercisethat is being assigned.


16/101


2.1.4.1 Module exercises/solutions

This module contains pages managing solutions o one exercise. All the ollowing pages require

the GET parameter exerciseId, which holds a reerence to the exercise whose solutions arebeing displayed and managed.

index List o all solutions belonging to the selected exercise. The user can only see publicsolutions and all o his own solutions. Users with RIGHT_ADMIN or the currentexercise can also see all private solutions.

Every solution or which the user has at least RIGHT_EDIT is equipped with a check-box. These checkboxes can be used to select solutions afected by the reevaluateand delete buttons. The checkboxes and the buttons are part o a orm that is alsohandled by this page.

newSolution

A orm that allows the user to create (submit) a new solution. The page is respon-sible or processing submitted source code (saving it into a le, creating a databaserecord and sending the solution to the evaluation system). This page is similar tothe groups/tasks/newSubmit page.

The user can only submit one source le with the proper extension. The le caneither be uploaded or its content can be entered directly into a text eld. I thesolution is received successully, the browser is redirected to the index page.

This page is visible only users with at least RIGHT_EDIT_BASIC or the selectedexercise. However, only users with RIGHT_EDIT can make their solutions public.

solutionInfo

More detailed inormation about one particular solution. Users with RIGHT_EDIT

or the solution may send it or re-evaluation or delete it. Actions reevaluate anddelete are triggered by corresponding buttons. Both are handled by this page.

The page contains summary inormation (time, points...), the evaluation log (withadditional inormation such as time consumed) and the submitted source code. Somedata (e.g. the evaluation log) will not be available i the solution is not evaluatedyet.

I the user has RIGHT EDIT or the solution, he can change the comment and thepublic ag.

This page requires the GET parameter solutionId, which points to the solutionthat is being displayed. I omitted, the browser is redirected to the index page.

2.1.5 Module exercises/commentsThis module encapsulates all unctions related to exercise comments. Exercise comments aretext written by operators which contains inormation or other operators, experience and bestpractices to share.

All pages in this module requires GET parameter exerciseId that points to an exercise towhich all comments belongs to. Furthermore all the pages are visible only to users with at leastRIGHT_READ or selected exercise.

index Displays table with all exercise comments. The whole comment text content isdisplayed in the table. It also contains link to edit page and delete button thattriggers the delete action which is embedded in the page.

The delete action requires commentId GET parameter and is protecte bydeleteQuery query action. The query action is bypassed by JavaScript query asall the action queries are. The delete action may be perormed only by users withat least RIGHT_EDIT or selected exercise or by comment author.


17/101


create Page with general orm that creates new comments. Data rom the orm are pro-cessed by the page and ater successull submit the browser is redirected to theindex page o current module.

Only users with at least RIGHT_EDIT_BASIC or selected exercise may see this page.

edit Page with the very same module as the create page. Except the orm is lled bydata rom selected comment and when submitted the comment is updated. Sub-mitted data are also handled by this page. Ater submit or cancel operation, thebrowser is redirected back to index page.

This page requires GET parameter commentId which points to exercise commentthat is being edited.

Access to this page is restricted only or users with RIGHT_EDIT or selected exerciseor or author o the comment.

2.1.6 Module usersThis module contains pages or viewing and managing user accounts, their rights and usersmemberships in groups. All the ollowing pages require at least the RIGHT_READ general rightor users.

Since the word user becomes little overused in this module we will call the user who is loggedin and perorms all the actions the actor. Furthermore, only general rights are considered everytime when speaking about rights (since there are no other rights or users anyway).

index A listing o all users. The list can be sorted and ltered by various attributes (userrole, study program, study group, study year). Any group or which the actor hasRIGHT READ can be selected and only members o that group will be displayed.

This condition can also be negated, so that only users not belonging to a group canbe displayed. A text-search based lter is also available, displaying only those userswhose login name, e-mail address or ull name (i.e. name middleName surname) contain the specied text as a substring.

Every user entry is equipped with a checkbox or selecting it. I the actor has RIGHT_DELETE right or users, a delete button is displayed that deletes all the selected users.Every entry is also equipped with two links, Edit and Rights, provided that theactor has sucient rights to edit the users properties and rights, respectively.

This page is also used or assigning users to groups. I the actor has RIGHT_EDITor at least one group, he/she may add selected users to this group rom here.

create A orm or creating new users. Submitted data are handled by this page, which isresponsible or creating the new user. A new user is always created with zero rights.

This page is visible i the actor has at least RIGHT_CREATE or users. Ater successulcreation, the browser is redirected to the index page. I the actor has at leastRIGHT_EDIT, the browser is redirected to the rights page instead, so rights ornewly created user can be edited.

properties

A orm where basic properties o the selected user (such as login, password, e-mail,etc.) are displayed and edited. Modications are handled by this page and savedinto the database.

An actor with RIGHT_EDIT_BASIC may edit properties o any other user with no

general rights. With RIGHT_EDIT he/she may edit any user who has strictly lessrights (using vector comparison, i.e. all components are less than or equal and atleast one component is strictly less than). A user with RIGHT_ADMIN the actor mayedit any user except the administrator (i.e. the user with id == 1).


18/101


Also, any user having access to this page (i.e. general RIGHT_READ or users) includ-ing admin may edit his own properties.

This page requires a GET parameter userId that holds the ID o the user who isbeing edited.

rights Overview o general rights and delegations. Rights are displayed in a orm wherethe actor can select rom prepared roles or set general rights manually.

Delegations are displayed in two tables one or groups and one or exercises. Actormay see only those delegations he/she may also revoke. Every delegation is equippedwith a check box. A revoke button that removes all selected delegations is placedbeneath the table. It triggers a revokeQuery action that shows query dialog and iconrmed triggers revoke action. Both actions are handled by this page.

This page is also the only place in the system where delegations can be granted.There are also two orms (or groups and exercises) where the actor can select a

group/exercise or which he/she has RIGHT_ADMIN and delegate rights or it. Datarom these orms are also handled by this page.

This page is accessible or an actor having RIGHT_EDIT_BASIC. The actor musthave at least RIGHT_EDIT to edit general rights, although he/she may never grantnor revoke right that he/she does not have. An actor with RIGHT_ADMIN or usersmay edit general rights without restrictions.

Nobody can modiy his/her own rights.

This page requires a GET parameter userId that holds the ID o the user whoserights are edited.

2.1.7 Module news

All pages in this module are related to news items and their management. News items are shortmessages rom administrator or group owners to other users.

index Overview o the news. News items are typically sorted by their time o creation andmay be ltered by groups.

The user can only see those news items that are visible or everyone or that are visibleor members o some group and the user is a member o this group, its owner or atrustee. The user must also have sucient general rights. That means groupRight,exerciseRights and usersRights dened or each news must be lesser or equalto the users general rights. The administrator (the user with id == 1) may see allnews items. See Section 2.3 [Security], page 21

I the user has sucient rights, he/she may also see buttons or news editing (RIGHT_

EDIT) or deletion (RIGHT_DELETE). The edit button leads to the edit page and thedelete button perorms action a delete action that is handled by this page.

create A orm or creating a new news item. Only a user with general right RIGHT_CREATE_PRIVATE or news (or higher) can see this page. User with RIGHT_CREATE_PRIVATEmay only create news or his own groups and a user with RIGHT_CREATE may alsocreate global news.

Data rom this orm are handled by this page. I the news item is successullycreated, the browser is redirected back to the index page.

edit A orm or editing the news. This orm is similar to the orm on the new page. Thispage is also responsible or saving the modied data into the database. I the data

are correctly saved, the browser is redirected back to the index page.The page requires a GET parameter newsId that species the ID o the news itemthat is being edited. I this ID is omitted or invalid, the browser is redirected to theindex page.


19/101


2.1.8 Query Dialog

Time to time user needs to perorm serious operation such as delete an object (group, exercise

etc.). Since this operation may be perormed by one-click action, the user should be asked toconrm his/her decision. Thereore a query dialog was introduced.

Query dialog is technically a page. It has its controller and template and uses MVC routingand dispathing system as any other page. However there are some diferences since multipledialogs with diferent messages may be shown at the same time.

Protocol or showind dialog is quite simple. Page that requires users conrmation ollowsthese steps.

1. Aquire the dialog controller object via getDialogObject method o the page manager.

2. Initializes the dialog (method initializeDialog) and speciy allback page. When thevalidity o session data or created dialog instance has expired, the dialog redirects browserto the allback page. Thereore this page SHOULD be the page that creates the dialog.

Initialization also generates random ID or the instance. Each instance has its own ID thatidenties data in the session.

3. Set dialog parameters using controllers public methods setDialogName and setMessage.These methods prepares given values into special session storage room used or given dialoginstance.

4. Add dialog buttons using addButton method. This method can add both action and linkbuttons. That means buttons that are perormed as POST actions (thus not indempotent)and simple links. In act all the buttons are rendered as action buttons but link-like buttonsare dirrected to the redirect action o the dialog. This si explained more thoroughly inSession Data Management subsection.

5. Perorm a redirect to the dialog page.

6. Dialog page is displayed. User may leave dialog page by clicking on one o the given buttons.

7. Ater clicking on some o the buttons taget action is executed or the browser is redirectedto given URL.

Here is a trivial sample o PHP code that uses query dialog:

public function testQueryAction()

$dialog = PageManager::getInstance()->getDialogObject(query);

$dialog->initializeDialog($this->createUrl(, array(), true, false));

$dialog->setDialogName(tr(Important Decision));

$dialog->setMessage(tr(Do you wish to perform %s action?), Test);

$dialog->addButton(tr(Yes), $this->createUrl(test));$dialog->addButton(tr(No), $this->createUrl(, array(), false), false);

$dialog->redirect();

public function testAction()

// Perform the real action...

2.1.8.1 Session Data ManagementSince multiple instances o the dialog may be shown simultaneously, dialog may not use commonpage namespace and persistent namespace and more sophisticated approach is required. Whenthe dialog is initialized, unique ID is assigned. This ID is used to identiy session storage.


20/101


ID is passed to the dialog along with allback page URL via GET parameters dialogQueryIdand fallbackUrl. Both parameters are mandatory since dialog can not work properly withoutthem.

Described approach brings one severe problem session growth. Every time new dialog iscreated, new session storage is allocated and lled with data. Thereore a mechanism must existto unset storages that are no longer needed. This storage is released when user conrmes orejectes the dialog.

All buttons are action buttons thereore any users decision will invoke a POST request.Link-like buttons are directed to the redirect action o dialog controller which releases thesession storage and preorms the redirect. Other buttons are slightly modied and URL oeach one is provided with extra GET parameter (_dialogQueryId) that carries ID o the dialoginstance. When action is perormed this parameter is intercepted by MVC dispatcher who isresponsible or removing the data storage.

I the user leaves dialog page by other means (e.g. by Back button in his/her browser), thedata will endure until user logs out. This problem is known yet unattended or the time being.

Whole dialog matter has been afected by spaghetti design and code injection pattern. How-ever re-actorization is not planed since the dialog is unctional and quite separated.

2.1.8.2 JavaScript Bypass

The dialog query adds at least one client-server round trip to every conrmed operation. Thismight be little rustrating or users with slow Internet connection thereore a JavaScript bypasswas implemented or every conrmation.

Principle o the bypass is to intercept mouse clicking (or orm submitting) event by JS,displaying simple conrmation dialog directly in users browser and then updating URL o action

button, so that the slow dialog query is skipped. In act a jsConfirmed=1 GET parameter isadded into URL and query action handler is programmed to skip dialog i this parameter isound.

Thereore users with operational JavaScript may speed up their work with CodEx and users

witout it will not be deprived o the original unctionality.

2.1.9 Main menu

Welcome Page

News

Create News

Groups Create Group

Tasks

Specication

New Submit

Properties

Submits

Properties

Results

Bonus Points

Exercises

Create Exercise

Properties


21/101


Specication

Attached Files

Tests Conguration Tests Files

Assign Tasks

Solution Database

Submit Solution

Users

Create User

Properties

Rights

Personal Settings

2.2 Components

2.2.1 Component Overview

Since we try to implement every piece o unctionality only once, the component system wasintroduced. This system is tightly integrated with MVC. Thereore, we recommend reading theMVC section rst. See undened [MVC], page undened

Components are very similar to pages. They have a controller class that must be derived romPageComponentAbstract and a template. Both the controller and the template are stored inthe components/component name directory in the les controller.php and template.php.

Access to these les is managed by the PageManager class.

Each component must be registered in the the controller class o the page where it is sup-posed to be displayed. Upon registration a unique ID is assigned to the component. Multiplecomponents o the same type can be placed simultaneously on the page.

2.2.1.1 PageComponentAbstract

The controller o a component must be derived rom the PageComponentAbstract class. Muchlike the page controller, the component controller is responsible or rendering and handlingactions.

The component can dene a list o internal GET parameters and their ltering rules. General

rules are stored in the $getParams member variable and action GET parameter rules are in$getActionParams. These two elds are ormatted the same way as the corresponding elds inthe page controller object. When a component is registered, the GET parameter rules o thecomponent are merged with GET parameter rules o the page.

The GET parameters live in separate namespace. A simple name-mangling scheme is applied,composing the nal name o the parameter as Ccomponent Id_. I.e.m i the component 42 hasa parameter named foo, this parameter will have the real name C42_foo). The mangling isperormed automatically by the registerComponent method.

Ater registration, the initialize method is called. This method does nothing, however itcan be redened in derived classes. The initialization routine can also hold code that cannot gointo the constructor or some reason (or in the constructor the component is still not registered).

It is strongly recommended to put as much code as possible here instead o the constructor, sinceinitialization is called only when its clear that the component will really be needed.

The component can also handle actions. Component actions are handled the very same wayas page actions. The only diference is that the action GET parameter should be ormatted


22/101


as an array. The key o this array is the component ID and the value is the action name. Forexample, a request with the parameter action[42]=delete parameter will be dispatched tothe component with ID 42 on which the deleteAction method will be called.

Rendering is perormed by the renderView method. This method prepares the view objectand renders it using the component template. Relative path to the template is dened in the$template member variable. I no template is dened, the deault template.php is used romthe directory o the component. Ater the view object is created, the prepareView method iscalled. This method does nothing, but descendant classes can use it or additional initializationo view data.

Each component has its own list o CSS and JavaScript les. They are stored in the css andjs member variables as arrays. When the component is registered, these lists are merged withlists on the page. Scripts and styles should be written with respect to the independent natureo components. For example, the CSS selectors should only use general classes (not selectors or

individual IDs).

2.2.1.2 Component Session Storage

There can be a special eld inside the session namespace o a page (both normal and persistent)called components. This eld is an array indexed with component IDs and its values are alsoarrays. Each array acts as the private storage o a component and it is passed to the componentreerence. This way the components have their own storage that will not collide with storage oother components even i there is more than one component o the same type on the page.

For example, i the component with ID 42 attempts to save parameter offset to the session,it will be stored in:

pageNamespace ->components[42][offset]

Access to component session storage is provided by the getSessionStorage and

getPersistentSessionStorage methods that return a reerence to the storage array. These

methods must not be called beore the component is registered, since unregistered components

do not have access to any page session namespace.

2.2.2 Menu Component

2.2.2.1 Overview

The Menu Component provides a generic hierarchical menu and, together with the CodEx menumodel, provides the main menu or the CodEx ront-end.

2.2.2.2 Generic Menu

The Menu Component displays a list o menu entries. Each entry has the ollowing properties:a caption, the URI it links to, a hint (usually displayed when the mouse hovers over it) and anactive ag. There should be always exactly one entry with the active ag enabled, correspondingto the current page. Also, each entry can have an arbitrary number o sub-entries and entriescan be nested to an arbitrary level.

The actual list o entries is provided by the model. Any model must implement the in-terace IMenuModel which contains a single unction getMenuItems() that returns an array o

MenuItemAbstract objects. These have the ollowing public properties: caption, url, hint,active and a public method hasSubItems(). I this method returns true, then the entryhas sub-entries and these can be obtained by iterating the entry object (as it implements theIterator interace).


23/101


2.2.2.3 CodEx Menu Model

When the user logs into CodEx, only a ew menu entries are displayed at rst. As he navigates

the menu, entries appear and disappear depending on the users actions. Typically, only entriesrelated to the users current module and a ew others are displayed.

The idea behind the magic is relatively simple. Most pages require some GET parametersspeciying the object they are working with. For example, most pages in the groups modulerequire the parameter groupId, i.e. the ID o the selected group. An entry is only displayed ithe parameters required by the corresponding page are present and valid.

The required parameters are specied directly in the denition o the menu and they aretwo-old. When switching rom one page to another using the menu, these parameters also getpreserved, while others are swept. Thus while browsing pages working with a group, the groupremains selected. When the user opens a page not working with a group, the selected group isorgotten and the entries o the pages working with a specic group are hidden).

The model, implemented in the MenuModel class, constructs the list o entries on the yrom an internal representation. It is a list o numbered-array entries, each containing theollowing elds: caption, module name, page name, list o GET parameters used, the hint, a listo sub-entries and a hidden ag.

An entry is only visible i all required GET parameters are present and the user has sucient

rights to display the page. (veried with checkRights()). Also, i the entry is marked as hidden,

it will not be displayed unless it is active (i.e. unless it corresponds to the current page).

2.2.3 Table Component

Component table is ment or displaying plain ordinary data tables (like list o all users). Similarissues are attended every time a table is rendered in the page, such as HTML rendering, odderingby selected columns or displaying table with huge amoun o data per parts. Thereore it is useullto have a component that will attend this issues.

As all other components the table implements Model-View-Controller pattern. Controller isrepresented by class that handles common issues (i.e. data paging) and prepares the data orvisualisation. Data are stored inro view object and rendered into HTML by common template.Model is impelemented by separated class and each table has its own model.

2.2.3.1 ITableModel Interace

Every table model implements this interace. This interace is dened that the table controllerwill not know anything about data storage, however it will have means how to get required data.

Model also provides way to other inormation about the table such as list o columns, theircaptions, alignment etc.

2.2.3.2 DBTableModel Abstract Class

Komponenta Table ================ Komponenta table slou k zobrazovn tabulekdat a k jejich ppadnmu nastrnkovn. Ke sv innosti potebuje datov model (objekt implementujcinterace ITableModel), kter slou jako zdroj dat (poskytuje inormace o sloupcch a na podn vrtdan poet dk ve zvolenm uspodn).

Konstruktor oekv reerenci na model a ppadn i dal (nepovinn) parametry. Parametry se uvdjv tomto poad: - $showHeader - bool ag, zda se m zobrazovat header (1. dek tabulky) - $paging- zda se m pout strnkovn dat - $cssClass - tda CSS, kter se nastav tabulce. - $noRowsMessage

- textov zprva, kter se zobraz, kdy v tabulce nejsou dn data.Tabulka si ukld potebn inormace do persistentnho loit v session: amount - poet zznam

zobrazovanch na strnce ofset - ofset prvnho zznamu na strnce sorting column - alias sloupce,podle kterho se td sorting desc - bool. ag, zda se td sestupn, i nikoli.


24/101


ITableModel =========== Interace, kter mus implementovat model tabulky. Jed-notliv metody jsou popsny ve zdrojovm kdu.

Soust denice interace je i tda TableModelColumn, jej objekty uchovvaj inormace vdy ojednom sloupci tabulky. Objekt m pouze konstruktor a adu poloek pro ten: $caption - popiseksloupce (me obsahovat i jednoduch XHTML (nap ) $align - XHTML hodnota stejnojmenhoatributu (let, right, center), kterm smrem budou ormtovny vechny buky sloupce (vchoz je let)$valign = XHTML hodnota stejnojmenho atributu (top, bottom, middle); nastavuje vertiklnzarovnn vech bunk (vchoz je top) $nowrap - boolean ag, kter kdy je nastaven na true, zakezalamovn obsahu bunk (vchoz je alse) $expand - boolean ag, kter nastavuje, zda se m sloupecautomaticky rozthnout, pokud je msto (vchoz je alse) $sortable - boolean ag, kter uruje, zdalze podle poloek ve sloupci tdit dky (vchoz je alse) $sorting - uruje, jak je tento sloupec pouitke tdn (0 = vbec, 1 = vzestupn, -1 = sestupn)

DbTableModel ============ Model, kter erp data pro tabulku pmo z databze.

V ppad jednoduchch dotaz (kter neobsahuj agregan unkce, ani klauzuli where), lze tabulkunavrhnout velice rychle (i kdy je dotaz sloen z vce tabulek pes standardn operac join). Rozhranje ale dostaten exibiln, aby sneslo jakkoli SQL SELECT dotaz.

Pi vytven modelu je teba pedat konstruktoru adu parametr, kter zinicializjuj model:

$caption - Popisek tabulky, kter se zobraz v HTML.

$columnParams - denice sloupc a jejich mapovn na SQL sloupce. Vce viz "Denice sloupc".

$deaultTable - Nzev "vchoz" DB tabulky. V ppad, e se nepouv vce tabulek (spojench operacJOIN), tak je to tak jedin DB tabulka. Zde me bt uloen bu etzec (nzev tabulky), nebo pole s

jednm prvkem (alias => nzev), pokud potebujeme tabulku pejmenovat. Na tabulku se pak vdyodkazujeme jejm aliasem (pokud nen denovn, je aliasem jmno tabulky samotn).

$joinTables - Pole "ostatnch" tabulek, kter se s vchoz spojuj operac JOIN. Kad poloka jedvouprvkov pole: array(selektorTabulky, podmnka). Podmnka je SQL etzec, kter se pouije jakospojovac podmnka ("ON") u klauzule JOIN v SQL dotazu. Selektor tabulky m stejn ormt,

jako u vchoz tabulky (me to bt jmno tabulky, nebo pole alias => jmno).

$dbColumnFilters - Pole ltr, kter se aplikuj po naten dat z DB. Vce viz "Filtry".

$orderBy - Pole sloupc, podle kterch se bude tabulka tdit v ppad, e nen vybrn dn sloupecke tdn. Toto pole je jako argument rovnou pedno metod order() objektu Zend Db Select, takemus dodrovat jeho syntax. Vchoz hodnota je array(id).

SQL dotaz pro ten z DB se automaticky poskld z uvedench parametr a specikac jednotlivchsloupc. V ppad, e je poteba pout sloitj dotaz, je mon (unkc setSQLQuery) pedenovat vnitnobjekt Zend Db Select a pout tak v podstat libovoln dotaz. Takto pidan objekt by neml mtnastaveny limity pro zobrazen (LIMIT) ani klauzuli ORDER BY. Rovn je teba zachovat kore-spondenci mezi nzvy sloupc uvedenmi v SQL dotazu a ve specikaci sloupc modelu tabulky.

Pi zavoln unkce loadData() se nejprve piprav a zavol SQL dotaz. Na zskan data se pouij ltrydenovan v dbColumnFilters a nsledn se kad dek proene renderovacmi unkcemi vech sloupc.dek se pak ulo do novho objektu typu stdClass, jeho poloky jsou pojmenovny po nzvech sloupc(objekty se narozdl od pole nekopruj, ale pedvaj reerenc).

Denice sloupc: Sloupce jsou v modelu uloeny v promnn $columns jako poleobjekt DbTableModelColumn (co je tda pmo odvozen od TableModelColumn). Zachovv vechnydosavadn lensk promnn a navc pidv nkter dal:

$template - Triviln XHTML template, kter je pouit pro renderovn dat do buek pslunho

sloupce. Obsahovat sm pouze prost text (krom znaku dolar - $) a promnn ve ormtu $nazevS-loupce. V nzvu sloupce se sm vyskytovat pouze psmena, sla a znak podtrtko. Jedn se o nzevDB sloupce (nikoli sloupce tabulky) - viz dle. Pklad: $name $surname - zobraz jmnoa pjmen, kde pjmen je tun.


25/101


$dbCols - Seznam databzovch sloupc, kter jsou poteba k renderovn tohoto tabulkovhosloupce. Kad sloupec je denovn v poli jako alias => deniceSloupce. Pokud je alias vynechn,pouije se nzev sloupce z SQL. deniceSloupce me bt jednoduch (jen etzec pro SQL), nebo pole

array(aliasTabulky, sloupec), kde alias tabulky je odkaz na nkterou z tabulek denovanou v $de-aultTable a $joinTables. Pokud je alias tabulky vynechn, bere se automaticky $deaultTable.SQL alias sloupce (ppadn jeho DB jmno - pokud nem alias) pak lze pout uvnit $template.

$orderBy a $orderByDesc - Ukldaj nastaven poloky ORDER BY, pokud se pouije tdn podletohoto sloupce. Nastaven je uloeno v

Documents

CodEx – Design Manual