Intro
UU follow classical MVC pattern.
- Role of Model will be played by database encapsulating classes (i.e. User, Topic, Course, etc.)
- Controller classes will be servlets, one servlet for each page (LoginServlet, RegisterServlet, SolveProblemServlet, etc)
- View classes will be created from CSP (C++ Server Pages)
Alexey thinks that assignment of roles is slightly different:
Model is database schema itself, and controller is a set of stored procedures
in database that work with data. View, in that case, is all of the C++ code
(both servlets and themes).
I guess at this point his view of roles is closer to reality then my original proposal.
Request processing
- Controller receives request
- Controller accesses Model objects as needed, potentially altering model state
- Controller stores results in request context
- Controller determines which view to forward request to based on user preferences (think themes)
- Controller determines which language to render page in based on user preferences
- Controller forwards the request to the view object
Controller Servlets (libui)
Most of controller servlets will be derived from UuServlet class, rather then servlet::HttpServletRequest UuServlet provides standard service() function, which handles common tasks, and then forwards actual processing to service(UuRequest&, UuResponse&) function, which should be overridden by servlets.
Following common tasks are taken care of by UuServlet:
- Login to database
- Handling of common exceptions
- Forwarding to the corresponsing view based on user's choice of theme
- Language setup
- Prepare common data for request (user object, counts of available UMOs for side bar, etc.)
Following is expected from Controller servlet:
- Set view to use (exception: if servlet wants to redirect, view must be set to "")
- Retrieve servlet-specific data from database, and set it as request attributes
- Call database functions for data modifications
- Handle servlet-specific error conditions
Template organization
Template mappings
Templates (CSP pages) will have identical names, and will be mapped to subdirectories named based on theme.
I18N support for templates
All interface strings will be explicitly retrieved using something like _() gettext macro, like this:
<HEAD><TITLE><%=_("Moooo")%></TITLE></HEAD>
We will provide tools to automate message catalogue creation and translation
for templates.
Theme management
Theme management tool provides following functionality
- Compile and install a theme
- Create a skeleton for a new theme
- Set default theme for UU instance
Theme structure
Right now there are very few restrictions imposed on what theme should be coded like.
The only required thing is set of names theme provides.
There are also few things which are expected:
- Each servlet provides certain data to its view.
It's expected theme only uses that data.
- Servlet->title mappings exported from libhtmlobjects.
It's expected that top-level menu is built from them.
- libui/Environment.csinc sets up some common global variables.
It's expected that each .csp in theme includes it directly or indirectly.
- theme CSPs should not handle exceptions
Exceptions are handled by calling servlets by redirecting
to common error pages.
- theme CSPs should not access database themselves
This would conflict with "no exception handling" and would
generally make theme code messy and unreadable
Finally, there are few recommendations for organizing your theme.
- Theme should have its own external CSS, which will be installed under <UU root>/themes/<theme>/styles/
- Theme should have Header.csinc, included by each .csp, which builds common menus and such.
- Theme should have Footer.csinc, which displays any error messages accumulated during CSP execution in uniform way.
- Theme should have minimum of C++, and preferably in Header.csinc or Footer.csinc
This is meant to make theme as readable as possible.
