INPUT = src
HTML_OUTPUT = doc/source-cpp
EXCLUDE_PATTERNS = moc_*
-#EXCLUDE = src/zip
+#EXCLUDE = src/wob src/.ctmp
@INCLUDE = Doxyfile.inc
INPUT = www
HTML_OUTPUT = doc/source-php
-
+EXCLUDE = www/inc/Twig www/tcache
\ No newline at end of file
#change this if doxygen uses a different name or is not in your PATH
DOXYGEN = doxygen
+#this is used to compile the Twig docu into HTML
+MARKDOWN = markdown
+
+#the directory to install MagicSmoke to
+PREFIX = /usr/local
+
###########################################################
# END OF CONFIGURATION
# No editable content below this line
tzone:
cd tzone ; $(QMAKE) && $(MAKE)
-#script stuff: depends on generated CPP files
-script: qtscript/generated_cpp
- cd qtscript/qtbindings && $(QMAKE) && $(MAKE)
-
-#generated script plugins: depend on Qt version
-qtscript/generated_cpp: $(QTBIN)/qmake
- cd qtscript/generator && $(QMAKE) && $(MAKE)
- cd qtscript/generator && QTDIR=$(QTDIR) ./generator
-
dist:
@echo Distribution not implemented yet
sdoc:
$(DOXYGEN) Doxyfile-php
$(DOXYGEN) Doxyfile-cpp
+ rm -rf doc/twig ; mkdir -p doc/twig
+ echo '<html><title>Twig Index</title><h1>Twig Index</h1><ul>' >doc/twig/index.html
+ for i in twig/doc/*.markdown ; do \
+ t=`basename $$i` ; p=$${t%.markdown} ; \
+ markdown $$i >doc/twig/$$p.html ; \
+ echo '<li><a href="'$$p'.html">'$$p'</a></li>' >>doc/twig/index.html ; \
+ done
+ echo '</ul></html>' >>doc/twig/index.html
+ cd pack/phpbase ; $(DOXYGEN)
+ cd pack/qtbase ; $(DOXYGEN)
+ cd tzone ; $(DOXYGEN) Doxyfile
+
+install: install-client install-server install-doc
+
+install-client: client
+ mkdir -p $(PREFIX)/bin
+ install -D src/msmoke $(PREFIX)/lib/magicsmoke2/msmoke
+ cp src/icon.png $(PREFIX)/lib/magicsmoke2/
+ echo '#!/bin/sh' >$(PREFIX)/usr/bin/msmoke2
+ echo 'LD_LIBRARY_PATH='$(PREFIX)/lib/magicsmoke2:$LD_LIBRARY_PATH' >>$(PREFIX)/bin/msmoke2
+ echo 'export LD_LIBRARY_PATH' >>$(PREFIX)/bin/msmoke2
+ echo 'exec '$(PREFIX)'/lib/magicsmoke2/msmoke' >>$(PREFIX)/bin/msmoke2
+ chmod +x $(PREFIX)/bin/msmoke2
+
+SPREFIX=$(PREFIX)/share/magicmsoke2-server
+install-server: server
+ mkdir -p $(SPREFIX)
+ cp -rLTf www $(SPREFIX)
+ -rm -f $(SPREFIX)/config.php
+ -rm -rf `find $(SPREFIX) -name .svn`
+
+DPREFIX=$(PREFIX)/share/doc/magicsmoke2-doc
+install-doc: sdoc
+ mkdir -p $(DPREFIX)
+ cp -rLTf doc $(DPREFIX)/html
+ -rm -rf `find $(SPREFIX) -name .svn`
clean:
- rm -rf zip/Makefile* zip/*.o zip/*.a
- rm -rf src/.ctmp src/Makefile* src/msmoke src/core*
- rm -rf src/wob www/inc/wob doc/wob wob/core*
- rm -rf pack/woc/.ctmp pack/woc/woc pack/woc/core* pack/woc/Makefile*
- rm -rf pack/qtbase/.ctmp pack/qtbase/libqwbase* pack/qtbase/Makefile*
- rm -rf doc/source-php doc/source-cpp
+ -rm -rf zip/Makefile* zip/libzip* zip/.ctmp
+ -rm -rf src/.ctmp src/Makefile* src/msmoke
+ -rm -rf src/wob www/inc/wob doc/wob wob/core*
+ -rm -rf pack/woc/.ctmp pack/woc/woc pack/woc/core* pack/woc/Makefile*
+ -rm -rf pack/qtbase/.ctmp pack/qtbase/libqwbase* pack/qtbase/Makefile*
+ -rm -rf tzone/zoneinfo* tzone/libtzdata* tzone/Makefile* tzone/.ctmp
+ -rm -rf doc/source-php doc/source-cpp doc/twig
+ -rm -rf `find . -name '*~'`
+ -rm -rf `find . -name '*.bak'`
+ -rm -rf `find . -name 'core*'`
distclean: clean
1 - DocumentRoot and Web Server
--------------------------------
-The debian package installs the server PHP files in /usr/lib/magicsmoke-server
-and links them from /var/www/magicsmoke2 . You need to change that link if your
-DocumentRoot is somewhere else or you want a different name.
+The debian package installs the server PHP files in /usr/share/magicsmoke2-server.
MagicSmoke runs with any web server that can execute PHP 5 scripts. Please be
aware that the client does enforce SSL encryption, so the web server must be
configured accordingly in order to work with the Qt based client.
-2 - Database
--------------
-
-MagicSmoke can work with MySQL or Postgres.
-
-Connect to your database server using a client of your choice (I'll assume the
-command line mysql client below, commands should be similar for other clients).
-
-Create a database user - I'll assume it is called "smoke" and uses "verysecret"
-as password.
- mysql> CREATE USER smoke IDENTIFIED BY PASSWORD 'verysecret';
-
-Create a database - I'll assume it is called "smoke".
- mysql> CREATE DATABASE smoke;
-
-Give the user all rights on this database.
- mysql> GRANT ALL ON smoke.* TO smoke;
-
-MagicSmoke uses a common configurable prefix for its tables ("smoke2_*" per
-default), so you can use an existing database or even use the same database
-for multiple installations or different programs (assuming the other
-programs are as tolerant as MagicSmoke).
-
-MagicSmoke2 can be installed in parallel to the old MagicSmoke 1.0 packages, but it
-cannot access the same tables (upgrade is possible though).
-
-3 - Configuring MagicSmoke
----------------------------
-
-Execute /usr/share/magicsmoke-server/install.sh with your target directory
-as parameter.
-
-Now edit the config.php file, it is a simple PHP file. Although theoretically
-all facilities of PHP are available there, you should stick to the format of
-the template.
-
-3.1 Database Options
-- - - - - - - - - - -
-
-The database section describes which database is used for storing data and
-how the database interface behaves.
-
-The $db variable is supposed to point to an object of a class derived from
-DbEngine. There are currently two of those:
-
-MysqlEngine uses the MySQLi interface of PHP to access a MySQL 5.x database
-
-PGsqlEngine uses the PGSQL interface of PHP to access a Postgres database.
-To be compatible with MagicSmoke the server should be at least version 8.x
-
-Examples are available in the configuration file template.
-
-The $olddb variable if set can be used to upgrade a MagicSmoke 1.0 database
-to version 2.0. After upgrade you should comment it out.
-
-3.2 Dedicated Client Configuration
-- - - - - - - - - - - - - - - - - -
-
-This section configures the behavior of the server towards the
-
-There is only one option: the timeout for client sessions. It is safe to leave
-it at the default.
-
-3.3 Web Client Configuration
-- - - - - - - - - - - - - - -
-
-This section configures the behavior of the web interface.
-
-These options configure the timeouts of cookies, what features
-are available to users and what features of the template engine
-are available.
-
-4 - Creating the Database Content
-----------------------------------
-
-Open a browser and direct it to admin.php in your MagicSmoke installation
-(usually something like http://localhost/magicsmoke/admin.php).
-
-The default user name is "Admin" and the password is "SmokeInMyEye" - or
-whatever you have configured.
-
-Click the create database button.
-
-4.1 Initial Installation
-- - - - - - - - - - - - -
-
-Create an initial administrator user.
-
-Done.
-
-4.2 Upgrade from MagicSmoke 1.0
-- - - - - - - - - - - - - - - - -
-
-MagicSmoke2 is not able to import old MagicSmoke Backups, you need to
-import those with an old installation and then convert them as described
-below.
-
-If you have set up the $olddb variable in your configuration MagicSmoke will
-offer to migrate data. Do not attempt migration if your new database already
-has some data stored.
-
-Please make sure that the old and new database do not share tables - at the
-very least the database name or the table prefix should be different.
-
-Simply enter "upgrade" into the input line and click the button.
-
-The upgrade may take some time - you should make sure that PHP scripts do
-not abort too soon. On a normal workstation this will take about 2-4 minutes
-for a database with a few thousand orders. If it fails you should recreate
-the new database and start over.
-
-The format of customers in the database has changed significantly.
-The upgrade process tries to guess what part of customer names and customer
-address belong to which detail. This heuristic may fail in some cases, you
-should go through your customer list and correct any mistakes afterwards.
-
-When you are done comment out the $olddb configuration to avoid initializing it
-for every call of a script.
-
-The migration process does not touch the old tables
-
-4.3 Both
-- - - - -
-
-Comment out the "setAdminPassCode" line in config.php, so that noone
-else can abuse this interface.
-
-From now on you can access it with the MagicSmoke client. Your URL for the
-client ends in machine.php (eg. http://localhost/magicsmoke/machine.php).
-
-
-5 - Templates
---------------
-
-MagicSmoke comes with templates for the web pages visible to web users.
-It uses the Twig template engine for this. You will find some documentation
-for writing templates in the usr/share/doc/magicsmoke-server/Twig-doc .
-
-The templates are installed in /usr/share/magicsmoke-server/template .
-The install.sh script will put a copy into your target directory.
-
-Hint: install magicsmoke-doc and read the chapter about web templates.
-
-When you are ready redirect the server to your new template directory by
-editing the $template variable in config.php .
+Please install the magicsmoke2-doc package and read the installation procedure
+there to learn how to make MagicSmoke available to the web server.
Section: main
Priority: extra
Maintainer: Konrad Rosenbaum <konrad@silmor.de>
-Build-Depends: debhelper (>= 7), libqt4-dev, qt4-dev-tools, subversion, subversion-tools
+Build-Depends: debhelper (>= 7), libqt4-dev, qt4-dev-tools, subversion, subversion-tools, markdown
Standards-Version: 3.7.3
Homepage: http://smoke.silmor.de
Package: magicsmoke2-client
Architecture: any
Depends: ${shlibs:Depends}, ${local:libssl}
-Recommends: magicsmoke2-doc
-Suggests: magicsmoke2-server
+Recommends: magicsmoke2-doc, libqtscript4-core, libqtscript4-gui, libqtscript4-network, libqtscript4-xml
+Suggests: magicsmoke2-server, libqtscript4-svg, libqtscript4-webkit, libqtscript4-xmlpatterns, libqtscript4-doc
Description: MagicSmoke Ticket Sale System - Standalone Client
This package contains the MagicSmoke Ticket Sales System Client version 2.
.
Package: magicsmoke2-server
Architecture: all
-Depends: php5 (>= 5), php5-mysql (>= 5) | php5-pgsql (>= 5)
+Depends: php5 (>= 5.2), php5-mysql (>= 5) | php5-pgsql (>= 5)
Suggests: magicsmoke2-doc, magicsmoke2
Description: MagicSmoke Ticket Sale System - Server
This package contains the MagicSmoke Ticket Sales System Server version 2.
.
It can be installed in parallel to the old version 1 system, but is
incompatible with old databases.
+ .
+ This package makes MagicSmoke available on your system, but it does not
+ create a database or install it into the web server directory, please
+ refer to the documentation files for details.
\ No newline at end of file
@echo '********************'
@echo Install Client...
#client itself
- mkdir -p $(CLIENT)/usr/share/doc/magicsmoke2-client
- install -D src/msmoke $(CLIENT)/usr/lib/magicsmoke2/msmoke
- cp src/icon.png $(CLIENT)/usr/lib/magicsmoke2/
- #wrapper for /usr/bin
- echo '#!/bin/sh' >$(CLIENT)/usr/bin/msmoke2
- #echo 'LD_LIBRARY_PATH=/usr/lib/magicsmoke2:$LD_LIBRARY_PATH' >>$(CLIENT)/usr/bin/msmoke2
- #echo 'export LD_LIBRARY_PATH' >>$(CLIENT)/usr/bin/msmoke2
- echo 'exec /usr/lib/magicsmoke2/msmoke' >>$(CLIENT)/usr/bin/msmoke2
- chmod +x $(CLIENT)/usr/bin/msmoke2
- #remove the .svn dirs copied before
- rm -rf `find $(CLIENT) -name .svn`
+ make -C $(CURDIR) -f Makefile.unix install-client PREFIX=$(CLIENT)/usr
#debian docu
+ mkdir -p $(CLIENT)/usr/share/doc/magicsmoke2-client
cp -L README COPYING* $(CLIENT)/usr/share/doc/magicsmoke2-client
gzip `ls $(CLIENT)/usr/share/doc/magicsmoke2-client/* |grep -v .gz`
cp -L src/smoke*.qm $(CLIENT)/usr/lib/magicsmoke2
DOCDIR=$(CURDIR)/debian/magicsmoke2-doc
-DOCTARGET=usr/share/doc/magicsmoke2-client
DOCDOC=usr/share/doc/magicsmoke2-doc
install-doc:
@echo '********************'
@echo Install Doc...
- mkdir -p $(DOCDIR)/$(DOCTARGET)
mkdir -p $(DOCDIR)/$(DOCDOC)
- mkdir -p $(DOCDIR)/usr/lib/magicsmoke2
- cp -rL doc $(DOCDIR)/$(DOCTARGET)
- ln -sf ../../../$(DOCTARGET)/doc $(DOCDIR)/usr/lib/magicsmoke2/doc
cp -L README COPYING* $(DOCDIR)/$(DOCDOC)
gzip `ls $(DOCDIR)/$(DOCDOC)/* |grep -v .gz`
- rm -rf `find $(DOCDIR) -name .svn`
+ make -C $(CURDIR) -f Makefile.unix install-doc PREFIX=$(DOCDIR)/usr
SERVER=$(CURDIR)/debian/magicsmoke2-server
install-server:
#create docu dir
mkdir -p $(SERVER)/usr/share/doc/magicsmoke2-server
#copy and link scripts
- cp -rL www $(SERVER)/usr/share/magicsmoke2-server
- mkdir -p $(SERVER)/var/www
- ln -sf ../../usr/share/magicsmoke2-server $(SERVER)/var/www/magicsmoke2
- #clean up
- rm -rf `find $(SERVER) -name .svn`
- rm -f $(SERVER)/usr/share/magicsmoke2-server/config.php
+ make -C $(CURDIR) -f Makefile.unix install-server PREFIX=$(SERVER)/usr
#copy in docu
cp -L README COPYING* $(SERVER)/usr/share/doc/magicsmoke2-server
- mkdir -p $(SERVER)/usr/share/doc/magicsmoke2-server/Twig-doc
- cp -L twig/doc/* $(SERVER)/usr/share/doc/magicsmoke2-server/Twig-doc
gzip `ls $(SERVER)/usr/share/doc/magicsmoke2-server/* |grep -v .gz`
gzip <debian/README.server >$(SERVER)/usr/share/doc/magicsmoke2-server/README.Debian-Install.gz
--- /dev/null
+<html>
+<title>Building Magic Smoke</title>
+</head>
+<body>
+<h1>Building Magic Smoke</h1>
+
+<h2>Supported Platforms</h2>
+
+<b>Linux</b> is supported for both client and server. It is originally developed on Debian, but should work out of the box on any other distribution that provides the necessary tools.<p>
+
+<b>Windows</b> is only supported for building the client. While I'm convinced that the server would be able to work on Windows, there is no automatic support for it - you're on your own here.<p>
+
+<b>MacOS</b> is entirely untested. If all necessary tools are installed, MagicSmoke can probably be compiled and installed the Unix way, but I have no way of testing this.<p>
+
+<b>Other Unixoid systems</b> are untested, but should work just like Linux if you install the proper tools.<p>
+
+<h2>Prerequisites</h2>
+
+You need <a href="http://www.qtsoftware.com/products/">Trolltech/Nokias Qt</a> Open Source edition
+version 4.6 or any newer.<p/>
+
+You also need <a href="http://www.openssl.org/">OpenSSL</a> installed and Qt needs to be built with
+SSL-support. While the pure web-UI can run without SSL, it is highly recommended that you enable
+SSL for the complete server. The client insists on using SSL - it is not possible to connect the
+client to the server without it.<p/>
+
+You need a C++ compiler that works with Qt. I usually recommend GCC 4.x for Linux and other Unixoid systems and using the <a href="http://www.mingw.org/">MinGW</a> version that comes with the complete Qt SDK for Windows. If you happen to have a Mac please let me know what works best... ;-)<p/>
+
+The source documentation needs <a href="http://www.doxygen.org/">Doxygen</a> and <a href="http://daringfireball.net/projects/markdown/">MarkDown</a> in order to be built.
+
+<h2>Building and Installing Packages on Debian and Ubuntu</h2>
+
+You need a working Debian packaging environment, usually this amounts to:<br/>
+<tt>sh$ apt-get install fakeroot debhelper</tt><p>
+
+Additionally MagicSmoke needs some pre-requisites to build:<br/>
+<tt>sh$ apt-get install libqt4-dev qt4-dev-tools subversion subversion-tools markdown</tt><br/>
+These are the packages listed in debian/control as Build-Depends.<p>
+
+Then simply build the packages:<br/>
+<tt>sh$ fakeroot debian/rules binary</tt><p>
+
+You should then have three packages:
+<ul>
+<li>magicsmoke2-client - the Qt-based client built for your local architecture</li>
+<li>magicsmoke2-doc - documentation for MagicSmoke that will be put into /usr/share/doc/magicsmoke2-doc</li>
+<li>magicsmoke2-server - the server for MagicSmoke</li>
+</ul>
+
+You can install those packages with:<br/>
+<tt>dpkg -i <i>packagefile.deb</i></tt><p>
+
+For a server installation you need to create an empty database (mysql 5.x or postgres 8.x), configure your web server and install the server into its final web directory with:<br/>
+<tt>/usr/share/magicsmoke2-server/install.sh <i>target-directory</i></tt><p>
+
+<h2>Building</h2>
+
+Both server and client depend on some shared code that is pre-compiled into some of their components. So it is easiest to do a complete build (unless you are familiar with the sources).<p/>
+
+Make sure that the correct version of QMake is in your PATH (you can check this by executing <tt>qmake -version</tt>). Also note that MagicSmoke and Qt have to be compiled with the same compiler.<p/>
+
+Go to the main directory of MagicSmoke. There you will find a file called <tt>Makefile.unix</tt> for Linux and other Unixoid systems and <tt>Makefile.mingw</tt> for MinGW/Windows installations. There are a few lines at the start of those files that you can adjust to better match your system (defaults should be fine for most cases). I have no access to a Mac, but I would guess that the Makefile.unix should need only very few modifications to work if the GNU tools are available.<p/>
+
+There is no support for automatic builds without MinGW on Windows. I have only tested Linux and Windows/MinGW, so there is no guarantee for any other system.
+
+Unixoid systems:<br/>
+<tt>make -f Makefile.unix <i>rule</i></tt><p/>
+
+Windows with MinGW:<br/>
+<tt>mingw32-make -f Makefile.mingw <i>rule</i></tt><p/>
+
+If you omit the <tt><i>rule</i></tt> parameter make will do a complete build.<p>
+
+The following rules are available on Unixoid systems and Windows:<br/>
+<table frame="1" border="1">
+<tr><td><b>Rule</b></td><td><b>Description</b></td></tr>
+<tr><td>all</td><td>complete build</td></tr>
+<tr><td>server</td><td>everything that is necessary for the server</td></tr>
+<tr><td>client</td><td>the client</td></tr>
+</table>
+
+The following additional rules are available on Unixoid systems:<br/>
+<table frame="1" border="1">
+<tr><td>sdoc</td><td>source documentation (not included in all), requires doxygen and markdown</td></tr>
+<tr><td>install</td><td>build and installs everything: server, client, documentation</td></tr>
+<tr><td>install-client</td><td>build and installs the client</td></tr>
+<tr><td>install-server</td><td>build and installs the server components</td></tr>
+<tr><td>install-doc</td><td>build and installs documentation (including source documentation)</td></tr>
+</table>
+
+For the install targets the makefile assumes per default that everything belongs into sub-directories of /usr/local. You can change this by adding a PREFIX variable to the call, like this:<br>
+<tt>make -f Makefile.unix PREFIX=$HOME/magicsmoke install</tt><br>
+this will instead install into the magicsmoke subdirectory of the calling users home directory.
+
+<h2>Installation</h2>
+
+Use the install targets above for installation on a Unixoid system.<p>
+
+See the <a href="install.html">Installation</a> page for details.
\ No newline at end of file
+++ /dev/null
-<html>
-<title>Building Magic Smoke</title>
-</head>
-<body>
-<h1>Building Magic Smoke</h1>
-
-<h2>Prerequisites</h2>
-
-You need <a href="http://www.qtsoftware.com/products/">Trolltech/Nokias Qt</a> Open Source edition
-version 4.4 or any newer.<p/>
-
-If you want to secure your connection with HTTPS you need
-<a href="http://www.openssl.org/">OpenSSL</a> installed and Qt needs to be built with
-SSL-support.<p/>
-
-The autoupdate function of MagicSmoke needs <a href="http://gmplib.org/">GNU MP</a> for signature checks. Most Linux distributions come with GNU MP as standard packages, there are pre-compiled packages at various locations in the net - make sure you use one that matches your compiler. Make sure GNU MP is installed so that <tt>gmp.h</tt> is in the default include path of the compiler.<p/>
-
-You need a C++ compiler that works with Qt. I usually recommend GCC 4.x for Linux and other Unixoid systems and <a href="http://www.mingw.org/">MinGW</a> with GCC 3.4 for Windows. If you have a Mac please let me know what combination works best... ;-)
-
-<h2>Building</h2>
-
-Both server and client depend on some shared code that is pre-compiled into some of their components. So it is easiest to do a complete build (unless you are familiar with the sources).<p/>
-
-Make sure that the correct version of QMake is in your PATH (you can check this by executing <tt>qmake -version). Also note that MagicSmoke and Qt have to be compiled with the same compiler.<p/>
-
-Go to the main directory of MagicSmoke. There you will find a file called <tt>Makefile.unix</tt> for Linux and other Unixoid systems and <tt>Makefile.mingw</tt> for MinGW/Windows installations. There are a few lines at the start of those files that you can adjust to better match your system (defaults should be fine for most cases).<p/>
-
-Unixoid systems:<br/>
-<tt>make -f Makefile.unix <i>rule</i></tt><p/>
-
-Windows with MinGW:<br/>
-<tt>mingw32-make -f Makefile.mingw <i>rule</i></tt><p/>
-
-If you omit the <tt><i>rule</i></tt> parameter make will do a complete build. The following rules are available:<p/>
-
-<table frame="1" border="1">
-<tr><td><b>Rule</b></td><td><b>Description</b></td></tr>
-<tr><td>all</td><td>complete build</td></tr>
-<tr><td>woc</td><td>only the web object compiler</td></tr>
-<tr><td>wob</td><td>web object compiler and preprocessing of common components</td></tr>
-<tr><td>server</td><td>everything that is necessary for the server</td></tr>
-<tr><td>client</td><td>the client</td></tr>
-<tr><td>sdoc</td><td>source documentation (not included in all), requires doxygen</td></tr>
-</table>
-
-<h2>Shipping</h2>
-
-When installing Magic Smoke on another computer you have to make sure that all required libraries are there too. You can <a href="http://silmor.de/32">find out</a> what these libraries are using standard tools, like <tt>ldd</tt> (Unix/Linux), <tt>objdump -x</tt> or <tt>dumpbin /depends</tt> on Windows, or <tt>otool -L</tt> on MacOS.<p>
-
-(to be continued)
\ No newline at end of file
</head>
<body>
<h1>Magic Smoke Documentation</h1>
-<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
+<img src="logo.png" alt="logo" valign="left" align="top"/><p/>
+
+MagicSmoke is a client-server system in an almost classic 3-tier architecture:
+<ul>
+<li>Database Layer: a MySQL or Postgres database is used for storing all of its data.</li>
+<li>Server/Middleware Layer: the server component contains all the code that accesses the underlying database and the code that generates browsable pages for customers, it is based on PHP 5</li>
+<li>Client Layer: <ul>
+ <li>Customer access: the system can be accessed with a normal Web Browser, you can extensively modify the templates used for this.</li>
+ <li>Theater side: the system has a special Qt-based client that can access the server and all underlying data.</li>
+ </ul></li>
+</ul>
<h2>Using Magic Smoke</h2>
<h2>Building/Installing Magic Smoke</h2>
<ul>
-<li><a href="install_web.html">Installing the Web Components</a></li>
+<li><a href="build.html">Building MagicSmoke</a></li>
+<li><a href="install.html">Installing MagicSmoke</a></li>
+<li><a href="server.html">Creating a Server Instance</a></li>
<li>Templates:<ul>
<li><a href="template.html">Web Template Design</a></li>
<li><a href="prog_odttemplate.html">ODT Template Design</a></li>
<li><a href="prog_tickettemplate.html">Ticket and Voucher Template Design</a></li>
</ul></li>
-<li><a href="build_prog.html">Building the Program</a></li>
-<li><a href="install_prog.html">Installing the Program</a></li>
</ul>
<h2>Programmers Manual</h2>
-to be written
+Architectural Overviews:
<ul>
<li>The MagicSmoke <a href="prog_arch.html">Architecture</a></li>
-<li>Client-Server-<a href="prog_protocol.html">Protocol Documentation</a> (this version of the protocol is obsolete and only supported for a short transition period)</li>
-<li>The <a href="prog_woc.html">Web Object Compiler</a></li>
-</ul>
+</ul><p>
+External Components:
+<ul>
+<li>The <a href="pack/index.html">PACK - Persistence And Communication Kit</a></li>
+<li>The <a href="twig/index.html">Twig</a> template engine</li>
+<li>Time Zone library <a href="tzone/index.html">source documentation</a></li>
+</ul><p>
+
+Source Documentation:
+<ul>
+<li>The <a href="source-cpp/index.html">Client Classes</a></li>
+<li>The <a href="source-php/index.html">Server Classes</a></li>
+<li>The <a href="wob/index.html">Web OBject</a> interface description</li>
+</ul>
</body>
</html>
\ No newline at end of file
--- /dev/null
+<html>
+<title>Magic Smoke Installation</title>
+</head>
+<body>
+<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
+
+You need to <a href="build.html">build</a> the system first. This is also true for the server web components, since they include lots of generated sources.<p>
+
+<h1>MagicSmoke Client Installation</h1>
+
+On a Debian or Ubuntu system it is recommended to use the native installation packages for MagicSmoke - they will automatically require everything they depend upon.<p>
+
+<h2>Manual Installation on Linux and Unix Systems</h2>
+
+Install the Qt4 library so that it is usable by Qt-based programs on your system. For systems that use the ELF binary format (eg. any Linux) Qt itself will take care of storing its location in the binary (RPATH). On other systems you can solve the problem by setting LD_LIBRARY_PATH or SHLIB_PATH to Qt's lib path.<p>
+
+Make sure OpenSSL is installed and available to Qt. For the scripting interface of MagicSmoke it is also recommended to install the <a href="http://labs.trolltech.com/page/Projects/QtScript/Generator">QtScript bindings</a>.<p>
+
+Copy the <tt>src/msmoke</tt> binary to the location you want to start it from. Or call:<br>
+<tt>make -f Makefile.unix install-client</tt><br>
+The latter will per default install into <tt>/usr/local/bin</tt>.
+
+<h2>Manual Installation on Windows</h2>
+
+Copy the src/msmoke.exe binary to a path you want to start it from. Then copy the Qt DLLs to the same path. From the OpenSSL directory copy libssl32.dll and libeay32.dll to that path. You should be able to start MagicSmoke from this path on any Windows machine.<p>
+
+If you used the full SDK of Qt to compile MagicSmoke, be sure to use the DLLs from the qt/bin subdirectory of the SDK, not the ones from bin - those are incompatible.<p>
+
+It is recommended to copy the plugins directory from your Qt installation to that path as well - this will make sure that all image formats etc. are supported.<p>
+
+For the scripting interface of MagicSmoke it is also recommended to install the <a href="http://labs.trolltech.com/page/Projects/QtScript/Generator">QtScript bindings</a> - they need to be placed in plugins/script.<p>
+
+<h2>Installation Package for Windows</h2>
+
+This requires the NSIS Installer.<p>
+
+(to be completed...)
+
+<!--
+*******************************************************************************
+*******************************************************************************
+*******************************************************************************
+-->
+<h1>Magic Smoke Server Installation</h1>
+
+The steps below assume that you are using a Unixoid system. A lot of them will not work on windows, since the makefile for windows does not contain them and the symlinks used inside the server source tree are not present under Windows - you will have to do a lot of manual copying in that case.
+
+<h2>Prerequisites</h2>
+
+You need a (web-)server that has PHP and a database server:
+
+<ul>
+<li>A webserver running PHP 5:
+ <ul>
+ <li>version 5.2 or newer</li>
+ <li>One of the supported Database drivers: currently MySQLi and PostgreSQL are supported.</li>
+ <li>PCRE</li>
+ <li>XML driver: dom</li>
+ <li>The date extension for time zone support</li>
+ </ul></li>
+<li>A database server -- you need full (SELECT, INSERT, UPDATE, CREATE) access to at least one database:
+ <ul>
+ <li>MySQL 5.x, or</li>
+ <li>Postgres 8.x</li>
+ </ul></li>
+</ul>
+
+Hint: you can check what modules are active in your PHP installation by creating a script file
+(eg. <tt>test.php</tt>) that contains only this line: <tt><? phpinfo(); ?></tt> .
+When you install this file on the web server and then open its URL in a browser it will show
+you an overview of all PHP functionality. If it returns an empty page, the file was not processed
+by PHP and you still need to configure the web server.<p>
+
+The database server must be reachable by the web server, but does not need to be on the same machine.
+
+<h2>Local Installation</h2>
+
+You will have to prepare an installation directory for the server by either installing the Debian packages or by installing locally:<br>
+<tt>make -f Makefile.unix install-server</tt><p>
+
+This places the PHP sources into a a specific directory on your system instead of continuing to use the source directory. It does not activate your first server yet.<p>
+
+Please read the <a href="server.html">Server Creation</a> page on how to continue from here.
+
+<a name="isp"/>
+<h2>Installation on an ISP Account</h2>
+
+If you are using an account at an ISP you usually don't get much access to the server. You still have to make sure that you have support for all required components.<p>
+
+You also need to do a local installation first if you want to install to an external ISP account (unless you have full shell and network access there). It is also recommended to try out MagicSmoke on a local box first. If you do not want to install MagicSmoke into a system directory, just change the PREFIX:<br>
+<tt>make -f Makefile.unix install-server PREFIX=$HOME/magicsmoke</tt><p>
+
+Copy the local server installation directory to you ISP account with whatever copying mechanism your provider has given you (usually FTP or scp). Rename <tt>config.php.template</tt> to <tt>config.php</tt>.<p>
+
+Some providers install several versions of PHP in parallel and detect what version you use by the file suffic that you are using. Try the <tt>phpinfo()</tt> call from above with different file extensions (eg. .php, .php5) to find out what is needed to be interpreted as a PHP 5 (version 5.2 or newer) script. Rename exactly the scripts index.php, admin.php, and machine.php to the correct suffix. Do NOT change any other script names - these are the only ones executed directly and they rely on the other script names still being as delivered.<p>
+
+You will usually get a MySQL database and a matching user name from your provider. You can skip the basic DB creation, configure the parameters you got from the provider and then go on with the configuration as normal. See <a href="server.html">Server Creation</a> for details.<p>
+
+
+</body>
+</html>
\ No newline at end of file
+++ /dev/null
-<html>
-<title>Installing Magic Smoke</title>
-</head>
-<body>
-<h1>Installing Magic Smoke</h1>
-
-to be written...
\ No newline at end of file
+++ /dev/null
-<html>
-<title>Magic Smoke Web Installation</title>
-</head>
-<body>
-<h1>Magic Smoke Web Installation</h1>
-<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
-
-<h2>Prerequisites</h2>
-
-You need a (web-)server that has PHP and MySQL installed:
-
-<ul>
-<li>A webserver running PHP version 5.x, with at least the following modules:
- <ul>
- <li>Hash or MHash for authentication (although it is possible to work without them it is not recommended)</li>
- <li>One of the supported Database drivers: currently only MySQL is supported.</li>
- <li>PCRE</li>
- <li>XML driver: dom</li>
- </ul></li>
-<li>MySQL 4.x or 5.x -- you need full access to at least one database.</li>
-</ul>
-
-Hint: you can check what modules are active in your PHP installation by creating a script file
-(eg. <tt>test.php</tt>) that contains only this line: <tt><? phpinfo(); ?></tt> .
-When you install this file on the web server and then open its URL in a browser it will show
-you an overview of all PHP functionality. If it returns an empty page, the file was not processed
-by PHP and you still need to configure the web server.
-
-<h2>Preparation</h2>
-
-<ol>
-<li><a href="build_prog.html">Build</a> at least the server components.</li>
-<li>create a database on MySQL (eg. <tt>create database smokedb</tt>)</li>
-<li>create a database user (eg. <tt>create user smokeuser</tt>)</li>
-<li>give this user full access to this database (eg. <tt>grant all on smokedb.* to smokeuser</tt>)</li>
-<li>create a configuration (see below)</li>
-<li>create templates (see below)</li>
-</ol>
-
-All files needed for Web-Installation are in the www-subdirectory.
-
-<h3>Installation on an ISP Account</h3>
-
-If you are using an account at an ISP you usually don't get much access to the server. You still have to make sure that you have support for all required components.<p>
-
-You will usually get a MySQL database and a matching user name from your provider. You can skip the basic DB creation above, configure the parameters you got from the provider and then go on as normal.<p>
-
-Some providers install several versions of PHP in parallel and detect what version you use by the file suffic that you are using. Try the <tt>phpinfo()</tt> call from above with different file extensions (eg. .php, .php5) to find out what is needed to be interpreted as a PHP 5.x script. Rename exactly the scripts index.php, admin.php, and machine.php to the correct suffix. Do NOT change any other script names - these are the only ones executed directly and they rely on the other script names still being as delivered.
-
-<h2>Configuration</h2>
-
-Copy the <tt>config.php.template</tt> file to <tt>config.php</tt>, then modify it to suit your
-needs.
-
-<h3>Database Configuration</h3>
-
-Magic Smoke is designed to work with multiple database engines. However, currently only MySQL is
-supported (this does not support mysqli or pdo_mysql).<p>
-
-The <tt>$db</tt> variable needs to be assigned with the correct engine to open the database. Currently only the MysqlEngine exists. This is an example configuration:
-<pre>
-// create engine: server, user, password
-$db = new MysqlEngine("localhost","smokeuser","");
-// set database name
-$db->setDbName("smokedb");
-// set table-prefix (optional)
-$db->setPrefix("smoke_");
-//set this to one of the supported MySQL storage engines for DB creation
-$db->setStorageEngine("InnoDB");
-</pre>
-
-The three parameters to the MysqlEngine constructor are: first the host the database server runs on. Use "hostname:port" if it runs on a non-standard port or ":/path/to/socket" if you want to use the local socket on a Unix system. The second parameter is the username for the database server and the third one the password (empty if no password is necessary).<p>
-
-The <tt>setDbName</tt> call is used to set the database that is used by Magic Smoke. The <tt>setPrefix</tt> call can optionally be used to set a prefix for all table names -- this way a single database can be used for multiple installations of Magic Smoke or even different applications (if the other applications are guaranteed to not touch Magic Smokes tables).<p>
-
-The <tt>setStorageEngine</tt> call can be used to set the table storage engine used by MySQL. Magic Smoke relies on MySQL using a transactional table type. The default is "InnoDB". It is not recommended that you change the default unless you know exactly what you are doing.
-
-<h3>Admin Configuration</h3>
-
-There is one option stored in the DB-Engine that is only used for database creation and recovery:
-<pre>
-$db->setAdminPassCode("Admin","SmokeInMyEye");
-</pre>
-
-This call sets the web-user and web-passcode for the <tt>admin.php</tt> script. After installing the system this line should be commented to prevent anyone from destroying the database or installing more admin users. Change the second parameter (password) to something else, so I won't be able to guess your admin password in case you forget to comment it.
-
-<h3>Client Authentication and Session Configuration</h3>
-
-The remainder of the config file contains settings for the dedicated client:
-<pre>
-//Authentication algorithm
-// possible: md5, sha1, sha256, hmac-md5, hmac-sha1, hmac-sha256
-$ClientAuthAlgo="hmac-sha1";
-//hash algorithm library -- the PHP extension/module used for calculation
-// possible: string (md5, sha1 only), hash, mhash
-$HashLib="hash";
-
-//Initial timeout from start of session request to session authentication
-// usually 300s (5min) is a good value
-$ClientAuthTimeout=300;
-//Authenticated session timeout - how long an authenticated session lasts
-// this should usually be a few hours (3600s per hour)
-$ClientSessionTimeout=2*3600;
-</pre>
-
-<tt>$ClientAuthAlgo</tt> contains the algorithm that is used to authenticate the client. You have to make sure that the algorithm selected is a) available in PHP, b) secure enough for your application, and c) available in all clients that are supposed to connect. The algorithms are:
-<table frame="1" border="1">
-<tr><td>md5</td><td>Uses the MD5 hash algorith described in RFC1321. Please note that this algorithm is regarded as broken and should not be used.</td></tr>
-<tr><td>sha1</td><td>Uses the SHA-1 hash algorithm described eg. in RFC3174. Please note that this algorithm is theoretically broken, although the use of this algorithm in Magic Smoke should still be secure for a few years.</td></tr>
-<tr><td>sha256</td><td>Uses the SHA-256 hash algorithm of the SHA-2 hash family. This algorithm is currently recommended as replacement for SHA-1. However, it is currently not supported by any client.</td></tr>
-<tr><td>hmac-md5, hmac-sha1, hmac-sha256</td><td>Uses the same hash algorithms in HMAC mode (see RFC2104). This use is more secure than the plain use of the algorithms. It is recommended to use HMAC.</td></tr>
-</table><p>
-
-<tt>$HashLib</tt> defines what PHP extension is used for calculation of hash values:
-<table frame="1" border="1">
-<tr><td>string</td><td>Doesn't use any extension and instead uses the string functions md5 and sha1. This mode does not support sha256 or any of the hmac-modes.</td></tr>
-<tr><td>hash</td><td>Uses the "hash" extension. This extension supports all modes listed above.</td></tr>
-<tr><td>mhash</td><td>Uses the "mhash" extension. This extension supports all modes listed above.</td></tr>
-</table><p>
-
-The <tt>$ClientAuthTimeout</tt> and <tt>$ClientSessionTimeout</tt> set the two session timeouts. The first timeout defines how long the authentication handshake of the client may last before the handshake is terminated. The second value defines how long a session may be active before it is automatically closed.<p>
-
-<h2>Creating Templates</h2>
-
-The <tt>www/template/*</tt> directories contain collections of template files. These are used to generate the user interface that users get to see.<p>
-
-Please read the chapter about <a href="template.html">Template Design</a> and create your own set of templates (or customize an existing one).<p>
-
-Then modify the template line in your config file, eg.:
-<pre>
-$template="./template/mytemplate/";
-</pre>
-
-<h2>Installation</h2>
-
-<ol>
-<li>copy the www directory including your configuration and templates to the web server</li>
-<li>navigate to admin.php in your browser, enter the admin name and passcode you configured</li>
-<li>click to create the database</li>
-<li>create an initial admin user in the database</li>
-<li>close the browser</li>
-<li>link the <tt>index.php</tt> script from your other pages, so that customers can find it</li>
-<li>continue with the client installation</li>
-</ol>
-
-
-
-</body>
-</html>
\ No newline at end of file
--- /dev/null
+../pack/doc
\ No newline at end of file
+++ /dev/null
-<html>
-<title>Magic Smoke Protocol Documentation</title>
-<body>
-<h1>Magic Smoke Protocol Documentation</h1>
-<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
-
-The Magic Smoke Protocol is used between the Magic Smoke Server and Client. It is based on HTTP and XML. Only POST requests are allowed. All body data is presumed to be in UTF-8 encoding, headers are restricted to ASCII-127.<p>
-
-Each request must have a "x-magicsmoke-request=..." header. The actual request data is sent as POST-data. Except for the <tt>serverinfo</tt> and <tt>startsession</tt> requests all requests must also carry a "x-magicsmoke-session" header.
-
-<h2>HTTP Headers</h2>
-
-Part of the data is transmitted in headers. This section lists all possible headers used by Magic Smoke.
-
-<h3>Client Request Headers</h3>
-
-<table frame="1" border="1">
-<tr><td>x-magicsmoke-request</td><td>The request that is to be executed by the server. This header is mandatory for all requests.</td></tr>
-<tr><td>x-magicsmoke-session</td><td>The session ID of this connection. This header is mandatory for all requests except <tt>serverinfo</tt> and <tt>startsession</tt>.</td></tr>
-</table>
-
-<h3>Server Response Headers</h3>
-
-<table frame="1" border="1">
-<tr><td>x-magicsmoke-status</td><td>The status of the request execution. See table below for details</td></tr>
-</table><p>
-
-Possible status codes are:
-<table frame="1" border="1">
-<tr><td><i>(missing)</i></td><td>If the whole header is missing or contains an unknown value, this should be treated as if it contained "Error" (see below).</td></tr>
-<tr><td>Ok</td><td>The request went ok and the actual data comes as response body.</td></tr>
-<tr><td>Error</td><td>Some unspecified error occured. The response body might contain some detailed human readable information.</td></tr>
-<tr><td>NonPost</td><td>The HTTP method was not POST. The body is a simple HTML page explaining to the user that browsers are not meant to use this page.</td></tr>
-<tr><td>Unauthenticated</td><td>The session ID does not exist, authentication failed or the session expired.</td></tr>
-<tr><td>NotAllowed</td><td>The user does not have the right to execute this transaction.</td></tr>
-<tr><td>InvalidRequest</td><td>The request was not understood. There was probably a mismatch in client and server version.</td></tr>
-<tr><td>SyntaxError</td><td>There was a syntactical error in the request data. Some details might follow in the response body.</td></tr>
-</table>
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Server Info</h2>
-
-A <tt>serverinfo</tt>-request can be sent by any client in order to get basic information
-about the server.<p>
-
-The server replies with an XML document that contains the most important information:
-<pre>
-<Info>
- <ServerVersion proto="protocol-version">server-version-number</ServerVersion>
- <AuthAlgorithm>hash-algo</AuthAlgorithm>
-</Info>
-</pre>
-
-The <tt>proto</tt> argument of the ServerVersion tag returns the protocol version, which is used by the client to check whether it is compatible with the server. It consists of two blocks of four hex-digits each, separated by a space. The first block is the lowest protocol version understood by the server, while the second block contains the current protocol version implemented by the server.<p>
-
-The server version number in the ServerVersion tags text is a the software version itself. The hash-algorithm values are described below in the authentication protocol section.<p>
-
-The protocol version described in this document is <tt>0000</tt>.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Authentication protocol</h2>
-
-First the client requests the hash-algorithm from the server. Possible
-algorithms are:
-
-<table frame="1" border="1">
-<tr><td>md5, sha1, sha256</td><td>use the hash algorithm directly, the returned value is calculated by first concatenating challenge and password/hostkey and then hashing it</td></tr>
-<tr><td>hmac-*</td><td>use the same algorithm in HMAC mode with the challenge as data and the password/hostkey as key</td></tr>
-</table>
-
-<h3>Step 1: Start a Session</h3>
-
-The authentication handshake is started with the client asking for a new session using a <tt>startsession</tt>-request. The post data of this request should consist of at least 128 random bits (base64 or another ASCII encoding) which are used by the server to calculate a session ID.
-
-The server responds with a session object:
-<pre>
-<SessionStart>
- <ID>session-id-string</ID>
- <HostChallenge>host-challenge-string</HostChallenge>
- <UserChallenge>user-challenge-string</UserChallenge>
- <Timeout>seconds-till-session-timeout</Timeout>
-</SessionStart>
-</pre>
-
-The challenge strings are derived from some internal function and the clock. By no means they are meant to be secure against all kinds of attack. The challenge-response-protocol is only supposed to avoid sending the passwords in plain text over the wire.<p>
-
-The timeout of the temporary session is usually 5 minutes (300s).
-
-<h3>Step 2: Authenticating the Session</h3>
-
-This is done using a <tt>sessionauth</tt> request. The session ID header must be set.<p>
-
-The client sends its authentication data as XML:
-<pre>
-<SessionAuth>
- <HostName>host-name</HostName>
- <HostAuth>host-authentication-data</HostAuth>
- <UserName>user-name</UserName>
- <UserAuth>user-authentication-data</UserAuth>
-</SessionAuth>
-</pre>
-
-The authentication data is calculated using the hash-function mandated by the server. The HostAuth item is calculated using the HostChallenge and the hosts key. The UserAuth item is calculated using the UserChallenge and the users password. Both *Auth values are hexadecimal-encoded.<p>
-
-The status is "Ok" or "Unauthenticated" - in the latter case the session ID is deleted and the client needs to start with a <tt>startsession</tt> request again if it wants to retry. If the request succeeds, the result body contains two numeric items (separated by a newline) that state the new session timeout and the current time as a Unix timestamp (seconds sice epoch - 1Jan1970, 00:00 UTC).<p>
-
-A result of "Unauthenticated" can have multiple reasons: the timeout of the temporary session expired before the request was received, the authentication of the user failed, the user is not allowed to connect from this or an anonymous host, or the authentication of the host failed and the user is not allowed to connect from an anonymous host.
-
-<h3>Step n: Closing the Session</h3>
-
-This is done with a <tt>sessionclose</tt> request. Neither request nor response contain a body.<p>
-
-This request always yields an "Ok" status response regardless of whether the session ID was still valid or not.
-
-<h3>Note on Usernames and Roles</h3>
-
-Both, user names and roles, are restricted to letters, digits and "_". Leading and trailing whitespace is ignored (trimmed).<p>
-
-Each role corresponds to a function that can be called and executed remotely through the machine interface. Roles beginning with "_" are reserved keywords that can alter the behaviour of other roles and must not be used to name functions.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Basic Requests</h2>
-
-<h3>Getting ACL info</h3>
-
-The <tt>getmyroles</tt> transaction requests all roles from the server. A role is a transaction that needs permission to be executed (ie. all transactions except serverinfo, startsession, sessionauth, closesession, and getmyroles) or a special right. The response is a list of roles with one role per line.<p>
-
-Special rights are:<br>
-<table frame="1" border="1">
-<tr><td>_admin</td><td>The user is an administrator and can automatically execute everything.</td></tr>
-</table>
-
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Event Related Requests</h2>
-
-<h3>Getting a List of Events</h3>
-
-The <tt>geteventlist</tt> transaction requests all events from the server. The response is a simple XML structure that contains only very basic data for each event:<p>
-
-<pre>
-<EventList>
- <Event id="0" start="1190543432" sold="11" capacity="20" reserved="2">blechsalat</Event>
- <Event id="1" start="1191419769" sold="11" capacity="20" reserved="2">stringsalat</Event>
-</EventList>
-</pre>
-
-Each event is encapsulated in an <tt>Event</tt> tag. The events have no specific order. The <tt>id</tt> attribute contains the internal ID of the event that can be used to reference it in other requests. The <tt>start</tt> attribute contains the start time of the event as Unix timestamp. The text of the <tt>Event</tt> tag contains the title of the event.<p>
-
-There are 3 optional attributes: <tt>capacity</tt> contains the maximum number of seats for this event, <tt>sold</tt> the number of tickets that have been sold and <tt>reserved</tt> the number of tickets that have been reserved.<p>
-
-<h3>Getting Detailed Event Data</h3>
-
-The <tt>geteventdata</tt> transaction returns detailed data about the event. The request body contains a space separated list of event IDs. The response looks like:<p>
-
-<pre>
-<EventData>
- <Event id="0" start="1190543432" end="1190543532" capacity="25" defaultprice="1177" cancelled="false">
- <Title>blechsalat</Title>
- <Artist>Broken Blech</Artist>
- <Description>a lot of text containing encoded &lt;b&gt;HTML&lt;/b&gt; tags</Description>
- <Room>Invisible Library</Room>
- <CancelReason>a damned good one</CancelReason>
- </Event>
- <Event id="1" start="1191419769" ...>
- ...
- </Event>
-</EventData>
-</pre>
-
-Attributes and tags:<br>
-<table frame="1" border="1">
-<tr><td>id</td><td>the ID of the event</td></tr>
-<tr><td>start</td><td>the start time as Unix timestamp</td></tr>
-<tr><td>end</td><td>the end time as Unix timestamp</td></tr>
-<tr><td>capacity</td><td>how many tickets may be sold for this event</td></tr>
-<tr><td>defaultprice</td><td>the default price for tickets as integer in cent (or penny or ...)</td></tr>
-<tr><td>cancelled</td><td>optional: "true" or "false" -- shows whether the event is cancelled, default is "false"</td></tr>
-<tr><td>Title</td><td>the title of the event</td></tr>
-<tr><td>Artist</td><td>the artist appearing</td></tr>
-<tr><td>Description</td><td>a description for the web page, may contain HTML</td></tr>
-<tr><td>Room</td><td>the room it is happening in (the room must exist in the list of available rooms)</td></tr>
-<tr><td>CancelReason</td><td>optional: if the event is cancelled, the reason for it (human readable)</td></tr>
-</table>
-
-If one of the requested events does not exist, it simply does not generate an <tt>Event</tt> block. It is permissible for the server to send an empty <tt>EventData</tt> tag if no data is available for the request.<p>
-
-<h3>Changing/Creating an Event</h3>
-
-The <tt>seteventdata</tt> transaction creates/changes an event. The request data looks like:<p>
-
-<pre>
-<Event id="0" ....>
- <Title>....
-</Event>
-</pre>
-
-Attributes and tags are the same as for the <tt>geteventdata</tt> response. Except that the <tt>id</tt> attribute may contain the value <tt>"new"</tt> to create a new event, a negative integer is not allowed.<p>
-
-The response contains the ID of the new/changed event if the status is "Ok". In the case of failure the status will be "Error" and an optional reason for the failure may be in the body.<p>
-
-The request must not change the cancellation status of an event - the attribute "cancelled" is ignored and the element "CancelReason" may be ignored if it violates the current status.<p>
-
-<h3>Getting a Ticket Summary of an Event</h3>
-
-The <tt>eventsummary</tt> transaction returns summary data for an event. The request contains the ID of the event. The response contains:<p>
-
-<pre>
-<EventSummary event="eventID" reserved="numbeOfCurrentlyReservedTickets"
- cancelled="numberOfCurrentlyCancelledTickets"
- totaltickets="numberOfUsableTickets" totalmoney="totalIncomeOfEventInCent" >
- <Tickets price="priceCategoryInCent" bought="numberOfUsableTicketsInThisCategory"
- used="numberOfUsedTickets" unused="numberOfUnusedTickets" />
- <Comment customerid="customerID" customer="customers Name" orderid="orderID">comment</Comment>
- <Orders>space separated IDs of all orders for this event</Orders>
-</EventSummary>
-</pre>
-
-
-<h3>Cancelling an Event</h3>
-
-The <tt>cancelevent</tt> transaction can be used to cancel an event. This transaction is not reversible. The request contains the event-ID and the cancel reason separated by a newline, the response is empty.
-
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Room related Transactions</h2>
-
-<h3>Getting Rooms</h3>
-
-The <tt>getroomdata</tt> transaction returns data about rooms in the database. The request data looks like this:<p>
-
-<pre>
-<GetRooms detail="basic">
- <Room>ID of room</Room>
- ...
-</GetRooms>
-</pre>
-
-The <tt>detail</tt> attribute may be "basic" or "full". If no <tT><Room></tt> tags are present all rooms are returned.<p>
-
-The response data looks like:<p>
-
-<pre>
-<RoomData>
- <Room capacity="24">
- <ID>Room ID</ID>
- <Description>some encoded HTML text that describes the room</Description>
- </Room>
- ...
-</RoomData>
-</pre>
-
-The <tt>capacity</tt> attribute tells how many persons fit into the room. The <tt>ID</tt> tag contains the ID or Name of the room, the optional <tt>Description</tt> tag contains a description of the room - it is only present if full detail has been requested.
-
-<h3>Setting Rooms</h3>
-
-The <tt>setroomdata</tt> transaction is used to create/change one or more rooms, the request data looks like:<p>
-
-<pre>
-<RoomData>
- <Room capacity="24">
- <ID>Room ID</ID>
- <Description>some encoded HTML text that describes the room</Description>
- </Room>
- ...
-</RoomData>
-</pre>
-
-The response simply contains the status "Ok" or "Error".
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>ACL related Transactions</h2>
-
-<h3>Getting User Info</h3>
-
-The <tt>getusers</tt> transaction returns the names and descriptions of all users in the system. The request is empty, the response looks like:<p>
-
-<pre>
-<Users>
- <User name="loginname">Description of User</User>
- ...
-</Users>
-</pre>
-
-<h3>Adding Users and Setting New Descriptions</h3>
-
-The <tt>setuserdescription</tt> call can be used to set new descriptions for existing users. The call may silently fail for any user that does not exist, hence the client should request user data from the server to confirm whether the call succeeded.<p>
-
-The <tt>adduser</tt> call can be used to create new user accounts. Initially the new user will have no ACL and no host settings.<p>
-
-Both calls use this structure for the request:<p>
-
-<pre>
-<Users>
- <User name="loginname" passwd="initial password">Description of User</User>
- ...
-</Users>
-</pre>
-
-The passwd attribute is optional.<p>
-
-The <tt>adduser</tt> call also uses it for the response, leaving out any user name that already existed or does not conform to the syntax requirements.
-
-<h3>Deleting a User</h3>
-
-The <tt>deleteuser</tt> transaction deletes one single user. The request contains the user name to be deleted on the first line and optionally a user to assign database object to that are currently owned by the user to be deleted (eg. orders). If no second user is referenced those objects are un-assigned.<p>
-
-The response is empty or optionally contains an error message.<p>
-
-<h3>Changing a Users own Password</h3>
-
-The <tt>setmypasswd</tt> can be used to change the user of the current session. The request looks like:<p>
-
-<pre>
-<SetMyPasswd oldpwd="old password" newpwd="new password"\>
-</pre>
-
-The response is empty. Only the status counts.
-
-<h3>Changing another Users Password</h3>
-
-The <tt>setpasswd</tt> can be used to change the user of the current session. The request looks like:<p>
-
-<pre>
-<SetPasswd user="user name" newpwd="new password"\>
-</pre>
-
-The response is empty. Only the status counts.
-
-<h3>Getting User ACLs</h3>
-
-The <tt>getuseracl</tt> transaction returns the ACL of a specific user. The request contains only the login name of the user. The response looks like:<p>
-
-<pre>
-<ACL user="username">
- <Role name="rolename" set="1|0"/>
- ...
-</ACL>
-</pre>
-
-All setable roles must be listed, so that the client can use these for displaying in a dialog.
-
-<h3>Setting User ACLs</h3>
-
-The <tt>setuseracl</tt> transaction can be used to update a users ACL. The request is identical to the response of <tt>getuseracl</tt>, while the response is an empty document on success - only the status "OK" counts.<p>
-
-Any role listed in the request is changed accordingly, non-existant roles are ignored, roles not listed are left unchanged.<p>
-
-<h3>Getting a Users Hosts</h3>
-
-The <tt>getuserhosts</tt> transaction returns the allowed client hosts of a specific user. The request contains only the login name of the user. The response looks like:<p>
-
-<pre>
-<Hosts user="username">
- <Host name="hostname" set="1|0"/>
- ...
-</Hosts>
-</pre>
-
-All setable hosts must be listed, so that the client can use these for displaying in a dialog.
-
-<h3>Setting User Hosts</h3>
-
-The <tt>setuserhosts</tt> transaction can be used to update a users allowed client hosts. The request is identical to the response of <tt>getuserhosts</tt>, while the response is an empty document on success - only the status "OK" counts.<p>
-
-Any host listed in the request is changed accordingly, non-existant hosts are ignored, hosts not listed are left unchanged.<p>
-
-<h3>Creating and Changing Hosts</h3>
-
-The <tt>addhost</tt> transaction creates new hosts. The <tt>sethost</tt> transaction changes the key of existing hosts. For both the request looks like:<p>
-
-<pre>
-<Hosts>
- <Host name="hostname">hostkey</Host>
- ...
-</Hosts>
-</pre>
-
-FIXME: currently these transactions do not return any feedback about success. The <tt>sethost</tt> transaction silently ignores hosts that do not exist.
-
-<h3>Getting All Hosts</h3>
-
-The <tt>gethosts</tt> transaction returns the name and key of all hosts. There is no request body. The response looks like the request above.
-
-<h3>Deleting Hosts</h3>
-
-The <tt>deletehost</tt> transaction deletes one single host. The request contains only the name of the host as ASCII text.<p>
-
-FIXME: special hosts (beginning with "_") return errors. Non-existing hosts are silently ignored.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Customers</h2>
-
-<h3>Getting List of Customers</h3>
-
-The <tt>getcustomerlist</tt> transaction returns a short list of customers. The request is empty. The response returns this:
-
-<pre>
-<CustomerList>
- <Customer id="integer ID" name="full name"/>
- ...
-</CustomerList>
-</pre>
-
-<h3>Customer Details</h3>
-
-The <tt>getcustomer</tt> transaction returns detailed information about a customer. The request contains the ID of the customer, the response contains:<p>
-
-<pre>
-<Customer id="integer ID" name="full name" mail="login-mail-for-webinterface">
- <Address> address info</Address>
- <Contact> contact information</Contact>
- <Comment> system internal comment</Comment>
-</Customer>
-</pre>
-
-The "mail" attribute is optional - it is only reported for customers that have a web-interface account.
-
-<h3>Setting Customer Details</h3>
-
-The <tt>setcustomer</tt> transaction is used to set details of the customer. The request contains a customer XML object as listed above, but without the mail attribute. The response contains the ID of the customer.
-
-<h3>Deleting and Merging Customers</h3>
-
-The <tt>deletecustomer</tt> transaction can be used to attempt to delete a customer from the database. It will fail if this customer still has any data (eg. orders) stored in the database. The request contains the ID of the customer to be deleted. The request may optionally contain a second customer ID separated from the first with a single space - if it does, the first customer is merged into the second one. The response is empty.<p>
-
-If customers are merged, the following rules are executed:
-<ul>
-<li>the first ID is the one to be deleted
-<li>all database objects (orders, tickets, vouchers, etc.pp.) of the first customer ID are transferred to the second one
-<li>all customer data (name, address, etc.) of the second customer ID is preserved, while the data of the first ID is deleted
-<li>exception: if the second ID has no web-login associated with it, but the first one does, then the login is re-assigned to the second ID before the first ID is deleted
-</ul>
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Orders and Sales</h2>
-
-The order XML representation looks as follows:
-
-<pre>
-<Order id="orderid" customer="customerid" seller="sellerid" ordertime="timestamp" senttime="timestamp"
- totalprice="amountInCent" paid="amountInCent" status="orderstate">
- <Ticket event="eventid" id="ticketid" price="priceInCent" status="ticketstate" />
- <Voucher id="voucherid" price="priceInCent" value="remainingValueInCent" used="0|1" status=""/>
- <Shipping price="priceInCent" type="shippingtypeID">Shipping Comment</Shipping>
- <DeliveryAddress>deliver address</DeliveryAddress>
- <Comment>comment...</Comment>
-</Order>
-</pre>
-
-<table frame="1" border="1">
-<tr><td><b>Item</b></td><td><b>Description</b></td><td><b>Occurrence</b></td></tr>
-<tr/>
-<tr><td>Order</td><td>Container for one single order or sale</td><td>1</td></tr>
-<tr><td> id</td><td>ID of the order, if already known.</td><td>0-1</td></tr>
-<tr><td> customer</td><td>ID of the customer. Mandatory.</td><td>1</td></tr>
-<tr><td> seller</td><td>Login of the seller. Automatically filled in.</td><td>0-1</td></tr>
-<tr><td> ordertime</td><td>Time of the order. Automatically filled in.</td><td>0-1</td></tr>
-<tr><td> senttime</td><td>Time at which the order was shipped. Automatically filled in.</td><td>0-1</td></tr>
-<tr><td> totalprice</td><td>Total accumulated price of the order. Automatically filled in.</td><td>0-1</td></tr>
-<tr><td> paid</td><td>Amount that has already been paid. Automatically filled in.</td><td>0-1</td></tr>
-<tr><td> status</td><td>Current status of the order. Automatically filled in. See table below.</td><td>0-1</td></tr>
-<tr/>
-<tr><td>Ticket(*)</td><td>data about a single ticket bought in this order</td><td>0-unlimited</td></tr>
-<tr><td> id</td><td>ID of the ticket</td><td>1</td></tr>
-<tr><td> event</td><td>ID of the event this ticket refers to.</td><td>1</td></tr>
-<tr><td> price</td><td>Price of the ticket</td><td>1</td></tr>
-<tr><td> status</td><td>Status of the ticket (see below)</td><td>1</td></tr>
-<tr/>
-<tr><td>Voucher(*)</td><td>data about a single voucher bought in this order, vouchers that are used to pay for an order are not stored</td><td>0-unlimited</td></tr>
-<tr><td> id</td><td>ID of the voucher</td><td>1</td></tr>
-<tr><td> price</td><td>Price of the voucher (adds to price of the order)</td><td>1</td></tr>
-<tr><td> value</td><td>Value (in cent) of the voucher (does not add to the order, but refers to how much the voucher is worth)</td><td>1</td></tr>
-<tr><td> status</td><td>only in validation responses: result of the validation</td><td>0-1</td></tr>
-<tr><td> used</td><td>Flag whether the voucher has been used to pay for anything (assumed as 0 if not present)</td><td>0-1</td></tr>
-<tr/>
-<tr><td>Shipping</td><td>information about the kind of shipping used and how much it costs; if text is used it is a copy of the text from the shipping table information - it cannot be changed here</td><td>0-1</td></tr>
-<tr><td> price</td><td>Price of the shipping option</td><td>1</td></tr>
-<tr><td> type</td><td>shipping type ID</td><td>1</td></tr>
-<tr/>
-<tr><td>DeliveryAddress</td><td>the address to send the stuff to, if not present or empty the address of the customer is used</td><td>0-1</td></tr>
-<tr/>
-<tr><td>Comment</td><td>comment entered into the order by customer or seller</td><td>0-1</td></tr>
-</table>
-(*)At least one of Ticket or Voucher must be used.<p>
-
-If items that are not expected are filled in in a message, they will be ignored.<p>
-
-Order status:<br/>
-<table frame="1" border="1">
-<tr><td><b>Status</b></td><td><b>Description</b></td></tr>
-<tr><td>placed</td><td>The order has been placed, nothing has been sent or paid yet.</td></tr>
-<tr><td>sent</td><td>The order has been shipped.</td></tr>
-<tr><td>reserved</td><td>The order has been reserved. This means the tickets are blocked, but it cannot be paid or shipped.</td></tr>
-<tr><td>cancelled</td><td>The user cancelled an unshipped and unpaid order.</td></tr>
-<tr><td>closed</td><td>The order is final and cannot be altered. (State maybe not needed.)</td></tr>
-</table><p/>
-
-Ticket status:<br/>
-<table frame="1" border="1">
-<tr><td><b>Status</b></td><td><b>Description</b></td></tr>
-<tr><td>bought(1)</td><td>The ticket is valid; whether it is paid for depends on the order status.</td></tr>
-<tr><td>refund(2)</td><td>The ticket has been or needs to be refunded; eg. after the event or order was cancelled.</td></tr>
-<tr><td>used(1)</td><td>The ticket has been used.</td></tr>
-<tr><td>reserved</td><td>The ticket is reserved. This state is currently not used.</td></tr>
-</table>
-(1)bought and used tickets add to the total price of an order; only bought tickets can be used<br/>
-(2)refunded tickets add nothing to the total price of an order, this may make the paid amount higher than the amount due.<p/>
-
-<h3>Checking or Creating Orders/Sales</h3>
-
-The <tt>createorder</tt> transaction creates an open order. The initial state of the order is "placed".<br/>
-The <tt>createreservedorder</tt> transaction creates a reservation. The order looks like a normal order, but it is in the "reserved" state in which it cannot be paid or shipped - it has to be converted first<br/>
-The <tt>createsale</tt> transaction creates an order that is marked as delivered and paid. The initial state of the created order is "sent" and the amount paid is equal to the total price.<br/>
-The <tt>checkorder</tt> transaction performs all checks and lookups of an order, but does not commit it to the database.<p>
-
-The <tt>create*</tt> transactions fail with an error if a ticket cannot be reserved or if a voucher value is invalid. The <tt>checkorder</tt> transaction uses special state values to signify failure. It sets the price of a voucher to the nearest legal voucher value if the value is not allowed.<p>
-
-The request is an order object without most fields filled in, the response is a copy of that object with all relevant fields filled in:
-
-<table frame="1" border="1">
-<tr><td><b>Element</b></td><td><b>Attributes in Request</b></td><td><b>Attributes in Response</b></td></tr>
-<tr><td>Order</td><td>customer</td><td>id(1), customer, seller(3), ordertime(1,4), totalprice(5), paid(1), status(6), senttime(2,4)</td></tr>
-<tr><td>Ticket</td><td>event, price(7)</td><td>event, id(1), price, status(6)</td></tr>
-<tr><td>Voucher</td><td>value, price(7)</td><td>value, price, id(1), status(11)</td></tr>
-<tr><td>Shipping</td><td>type(8), price(9)</td><td>type(10), price, [text](10)</td></tr>
-<tr><td>DeliveryAddress</td><td>[text]</td><td>[text]</td></tr>
-<tr><td>Comment</td><td>[text]</td><td>[text]</td></tr>
-</table>
-(1)field is optional for checks and has no meaning there, it is recommended the server returns a dummy ID for checks<br/>
-(2)the field only exists for sales<br/>
-(3)the seller is automatically taken to be the session user<br/>
-(4)time stamps are automatically filled in with the current server time<br/>
-(5)the total price is the accumulated price of all tickets and vouchers in the order<br/>
-(6)the status fields have special meanings for checks, see below<br/>
-(7)the price field will only be honoured in the request, if the user also has the privilege to use the changeticketprice transaction<br/>
-(8)the shipping types that are allowed depend on whether the user has the _anyshipping privilege<br/>
-(9)price is optional, if set it is ignored if the user does not have the _repriceshipping privilege<br/>
-(10)the type in the response may be -1 if an error occurred in this case the text contains the error message, otherwise it contains a copy of the shipping option text<br/>
-(11)in validation responses if the voucher contains a non-empty state it is not deemed valid by the server, the state must be one of the status constants below<p>
-
-Order status for checks:
-<table frame="1" border="1">
-<tr><td><b>State</b></td><td><b>Description</b></td></tr>
-<tr><td>ok(1)</td><td>the order can be executed as is</td></tr>
-<tr><td>saleonly(2)</td><td>the order can only be continued as a sale, not as an open order</td></tr>
-<tr><td>orderonly(2)</td><td>the order can only be continued as an open order, not as a sale; this state also shows that there is a problem with the configuration</td></tr>
-<tr><td>fail</td><td>the order contains failed items</td></tr>
-</table>
-(1)Attention: the return code "ok" means the order would have succeeded at the time of the check, it may still fail when it is actually placed<br/>
-(2)these states are equivalent to ok if the intended transaction matches and to fail if it does not match<p/>
-
-Ticket status for checks:
-<table frame="1" border="1">
-<tr><td><b>State</b></td><td><b>Description</b></td></tr>
-<tr><td>ok(1)</td><td>the order can be executed as is</td></tr>
-<tr><td>saleonly(2)</td><td>the order can only be continued as a sale, not as an open order</td></tr>
-<tr><td>orderonly(2)</td><td>the order can only be continued as an open order, not as a sale; this state also shows that there is a problem with the configuration</td></tr>
-<tr><td>toolate</td><td>the order is not possible any more</td></tr>
-<tr><td>exhausted</td><td>there are no more tickets for this event</td></tr>
-<tr><td>cancelled</td><td>the event has been cancelled, no order is possible</td>
-<tr><td>invalid</td><td>the event does not exist in the database</td></tr>
-</table>
-(1)Attention: the return code "ok" means the order would have succeeded at the time of the check, it may still fail when it is actually placed<br/>
-(2)if two or more tickets contradict on this state the order is returned as failed<p/>
-
-Voucher status for checks:
-<table frame="1" border="1">
-<tr><td><b>State</b></td><td><b>Description</b></td></tr>
-<tr><td>[empty]</td><td>the order can be executed as is</td></tr>
-<tr><td>invalidvalue</td><td>the user is not allowed to use this value for the voucher</td></tr>
-<tr><td>invalidprice</td><td>for this user the price must equal the value (or be ommitted)</td></tr>
-</table>
-
-<h3>Getting an Overview List of Orders</h3>
-
-The <tt>getorderlist</tt> transaction can be used to get a list of all currently stored orders. The request does not contain any data, the response looks like:<p>
-
-<pre>
-<OrderList>
- <Order id="orderid" customer="customerid" status="orderstatus"
- totalprice="amountDueInCent" paid="amountPaidInCent"/>
- ...
-</OrderList>
-</pre>
-(this is a small subset of the full order object)
-
-<h3>Paying/Refunding Orders</h3>
-
-The <tt>orderpay</tt> transaction is used to add to the amount paid in an order. The <tt>orderrefund</tt> transaction is used to subtract from the amount paid of an order. In both cases the request consists of two positive numbers separated by a space: the order-ID and the amount in cent. The response contains the new amount paid after the transaction in the case of success and status error plus an explanation in case of any problem.
-
-<h3>Set Shipping State of an Order</h3>
-
-The <tt>ordershipped</tt> transaction is used to mark an order as shipped. This transaction is only legal for orders in the "placed" state. The request contains the order ID, the response contains the new shipping time (set automatically during transaction).
-
-<h3>Cancelling an Order</h3>
-
-The <tt>cancelorder</tt> transaction is used to mark an order as cancelled. It also marks all tickets inside the order as cancelled and voids any vouchers in it. This transaction is only legal for orders in the "placed" state. It will fail if any tickets or vouchers have already been used.
-
-<h3>Converting Reservations</h3>
-
-The <tt>reservationtoorder</tt> transaction marks a reservation as a normal order. From that time on it can be paid and shipped.<br/>
-The <tt>reservationtosale</tt> transaction marks a reservation as a sale. It will be marked as paid and shipped.<p>
-
-The request contains the order ID, the response is empty or contains an error message.<p>
-
-Use the <tt>cancelorder</tt> transaction (see above) to cancel a reservation.
-
-
-<h3>Searching for an Order</h3>
-
-The <tt>orderbyticket</tt> transaction can be used to find an order by a ticket ID from that order. The request contains the ticket ID, the response contains the order ID or returns as error if not found.<p>
-
-The <tt>getordersbyevents</tt> transaction can be used to return all orders that contain tickets for a specific event. The request is a space separated list of event IDs, the response has the format of the <tt>getorderlist</tt> response.
-
-<h3>Changing the Comment of an Order</h3>
-
-The <tt>setordercomment</tt> transaction is used to change the orders comment. The request is a simple XML document:<p>
-
-<pre>
-<OrderComment orderid="id">comment text...</OrderComment>
-</pre>
-
-The response body is empty or optionally contains an error message.
-
-<h3>Changing the shipping option on an order</h3>
-
-The <tt>orderchangeshipping</tt> transaction can be used to change the shipping information on an order. The request looks like:
-
-<pre>
-<OrderChangeShipping orderid="orderId" type="newShippingType" price="newPriceInCent"/>
-</pre>
-
-If <tt>type</tt> is not present, the price is taken from the new shipping type. If <tt>type</tt> is not present, it is not changed. If <tt>type</tt> is empty it is reset to none (NULL) in the Database. If a price other than 0 is used, the type in the database must be present (!= NULL).<p>
-
-The response contains the updated order object or just an error message.
-
-<h3>Creating/Changing/Deleting Shipping Options</h3>
-
-The <tt>setshipping</tt> creates or changes a shipping option. The request looks like:
-
-<pre>
-<ShippingOption type="shippingOptionID" price="priceInCent" web="0|1" anyUser="0|1">
- Text that describes the option
-</ShippingOption>
-</pre>
-
-If the <tt>type</tt> attribute is missing the server creates a new option. Otherwise it changes an existing one. The <tt>web</tt> attribute tells whether the option is available to customers using the web interface. The <tt>anyUser</tt> attribute tells whether the option can be used by anyone who can create an order/sale (=1) or only by users with the "_anyshipping" privilege (=0).<p>
-
-The response contains the new shipping option id or contains an error message.<p>
-
-The <tt>deleteshipping</tt> transaction can be used to delete a shipping option. The request contains just the ID of the option, the response is empty.
-
-<h3>Listing Shipping Options</h3>
-
-The <tt>getshipping</tt> transaction can be used to return all shipping options. If the user has the "setshipping" or "_anyshipping" privilege the list will also contain privileged options. The request is empty. The response looks like:
-
-<pre>
-<ShippingList>
- <ShippingOption type="shippingOptionID" price="priceInCent" web="0|1" anyUser="0|1">
- Text that describes the option
- </ShippingOption>
- ...
- ...
-</ShippingList>
-</pre>
-
-<h3>Adding Tickets or Vouchers to an Order</h3>
-
-tbd.
-
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Tickets</h2>
-
-<h3>Getting Tickets</h3>
-
-The <tt>getticket</tt> transaction can be used to get information about a ticket. The request contains only the ticketID, the response looks like:<p>
-
-<pre>
-<Ticket id="ticketid" status="ticketstate" order="orderid" event="eventid" price="priceincent" orderpaystate="status of the order" />
-</pre>
-
-The attribute orderid may be <0 if the ticket is not attached to an order.<p>
-
-<table frame="1" border="1">
-<tr><td><b>Attribute</b></td><td><b>Description</b></td></tr>
-<tr><td>status</td><td>can be any of reserved, bought, used, refund, error (see getorder above for details)</td></tr>
-<tr><td>orderpaystate</td><td>the payment status of the order, it can be "none" if the order is invalid or the ticket is not attached to one, "ok" if the order has been paid correctly, "cancelled" if the order was cancelled, "needpayment" if the order is not fully paid yet, or "needrefund" if too much has been paid</td></tr>
-</table>
-
-<h3>Using Tickets</h3>
-
-The <tt>useticket</tt> transaction marks a ticket as used. The request contains only the ticket ID, the response has status ok and no body if the action succeeded, it has status error and an explanatory text if it failed.<p>
-
-Only tickets that have status "bought" and whose order have payment status "ok" or "needrefund" can be used. The transaction fails for all other tickets.
-
-<h3>Changing Ticket Prices</h3>
-
-The <tt>changeticketprice</tt> transaction can be used to change the price of a ticket. The request contains the ticket-ID and the new price in cent separated by a newline. The response is empty.
-
-<h3>Returning Tickets</h3>
-
-The <tt>ticketreturn</tt> transaction can be used to return a ticket that has not been used yet. The request contains the ticket-ID, the response is empty.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Vouchers</h2>
-
-Rules for vouchers:
-<ul>
-<li>a voucher with price and value zero is cancelled (the used flag is ignored in this case)
-<li>any non-cancelled voucher that is unused can be cancelled
-<li>any non-cancelled voucher can be emptied
-<li>a voucher with non-zero value can be used
-</ul>
-
-<h3>Getting Valid Voucher Prices</h3>
-
-The <tt>getvoucherprices</tt> transaction can be used to retrieve allowed voucher prices. The request is empty. The response contains the allowed prices in cents, separated by spaces - it is empty if no voucher prices are configured.
-
-<h3>Using a Voucher</h3>
-
-The <tt>usevoucher</tt> transaction can be used to use a voucher for payment. The request contains the voucher-ID on the first line and the order to be paid on the second line.<p>
-
-On success the response contains the amount that remains on the voucher on the first line and the now current amount that has been paid for the order on the second line.
-On error the response contains an error message.
-
-<h3>Returning/Cancelling a Voucher</h3>
-
-The <tt>cancelvoucher</tt> transaction can be used to cancel a voucher. The request contains just the voucher-ID. The response is empty or contains an error message.<p>
-
-For this transaction to succeed the voucher must not have been used. The price and the value will be reset to zero. If the voucher is already cancelled the transaction will report success.
-
-<h3>Destroying a Voucher</h3>
-
-The <tt>emptyvoucher</tt> transaction can be used to void any remaining value of the voucher. The request contains just the voucher-ID. The response is empty or contains an error message.<p>
-
-This transaction simulates buying nothing for a lot of money: it sets the voucher to used and resets the remaining value to zero. The voucher will still have a price that needs to be paid and it cannot be returned/reimbursed afterwards.<p>
-
-Only privileged users should be able to do this (if anybody at all).
-
-<h3>Getting a Voucher</h3>
-
-The <tt>getvoucher</tt> transaction can be used to retrieve information about a specific voucher. The request just contains the voucher ID, the response contains the XML representation of it (see the Voucher tag in the Order XML object for details).
-
-<h3>Using a Voucher outside the system</h3>
-
-The <tt>usevoucheroutside</tt> transaction can be used to remove value from a voucher without logging it to a specific order. The request contains the voucherid in the first line and the value to take in the second line. The response contains the actual value taken in the first line and the remaining value of the voucher in the second line.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-<h2>Templates</h2>
-
-Templates are used for printouts and documents. There are several types of templates:<p>
-
-<ul>
-<li><a href="prog_odttemplate.html">Open Document Text Template</a></li>
-<li><a href="prog_tickettemplate.html">XML Ticket printer template</a></li>
-</ul><p>
-
-Base names of templates are restricted to the regular expression <tt>^[a-z0-9_]+$</tt> and are case-insensitive. They may have an extension (legal values: "od[ts]t", "xtt") and a variant ID (at the moment numeric, but may match "^[a-z0-9_]+$").<p>
-
-Below "file name" refers to the complete concatenation of base name, extension, and variant:
-<i>basename</i><b>.</b><i>extension</i>[<b>,</b><i>variant</i>]
-
-<h3>List of Templates</h3>
-
-The <tt>gettemplatelist</tt> transaction returns an informational list of templates. The request is empty, the response looks like:<p>
-
-<pre>
-<TList>
- <Template name="filename" hash="md5-hash">Description text</Template>
- ...
-</TList>
-</pre>
-
-The Hash is caculated at the server side and can be used to find out whether the template has been changed. It does not necessarily need to be MD5 or any other specific algorithm, it can be any kind of ASCII string that shows changes (hence the client must remember the string if it wants to use it).
-
-<h3>Getting a Template</h3>
-
-The <tt>gettemplate</tt> transaction returns a specific template. The request contains only the file name, the response contains the template file as content. In case of an error the content is left empty and the status code is set appropriately.
-
-<h3>Setting a Template</h3>
-
-The <tt>settemplate</tt> transaction creates a new template file. The request contains the file name terminated with a newline ("\n") and then the binary content of the template - it is important that there are no additional characters between the newline and the template content. The response contains the new hash of the template or error details. The description is initially set to NULL and can be changed later with <tt>settemplatedescription</tt>.<p>
-
-The <tt>settemplatedescription</tt> transaction sets a new description for a template. The first line of the request contains the filename, the remainder the description.
-
-<h3>Deleting a Template</h3>
-
-The <tt>deletetemplate</tt> transaction deletes a template from the database. The request contains the file name (full name). The response is empty. The transaction does not return any errors.
-
-<!-- ************************************************************************************
- ************************************************************************************
- ************************************************************************************ -->
-
-<h2>Backup</h2>
-
-The currently implemented backup function is DB scheme dependent. This may change in the future.<p>
-
-The machine interface only provides for the retrieval of the backup file. Restoration is done via admin.php.<p>
-
-The <tt>backup</tt> transaction is used to retrieve a backup file. It does not have any parameters. The response is in the special backup format:<p>
-
-<pre>
-startbackup
-backupversion 0
-dbversion 00.02
-table exampletab
-value stringcolumn str TWFnaWNTbW9rZVZlcnNpb24=
-value intcolumn int 1
-value boolcolumn bool 1
-value anothercolumn NULL NULL
-insert
-endofbackup
-</pre>
-
-The format is command oriented: each line is a specific command that can be interpreted by the restore processor:
-
-<table frame="1" border="1">
-<tr><td><b>Command</b></td><td><b>Description</b></td></tr>
-<tr><td>startbackup</td><td>marks the begin of a backup file</td></tr>
-<tr><td>backupversion</td><td>defines the format version (integer version number) of this backup file - this only shows which commands are valid, not what content can be transferred</td></tr>
-<tr><td>dbversion</td><td>version of the database scheme this data is taken from</td></tr>
-<tr><td>table</td><td>marks the start of a new table, has the (scheme-)name of the table as parameter, deletes the current dataset buffer</td></tr>
-<tr><td>value</td><td>adds a value to the current dataset buffer, parameters are the column name, encoding format and value</td></tr>
-<tr><td>insert</td><td>pushes the current dataset buffer into the current table, then empties the dataset buffer</td></tr>
-<tr><td>endofbackup</td><td>marks the end of the backup file, the processor should stop here</td></tr>
-</table><p>
-
-Table cell values are encoded according to the content in the source database. The target database must decode the values according to the format used in the backup file and then escape the value as appropriate for the target database (irrespective of the just decoded source format).<p>
-
-The following encoding formats are currently known:
-<table frame="1" border="1">
-<tr><td><b>Format</b></td><td><b>Description</b></td></tr>
-<tr><td>NULL</td><td>a NULL value, the actual value in the backup file does not matter, the target value is NULL</td></tr>
-<tr><td>int</td><td>integer, the value must be converted into an integer number</td></tr>
-<tr><td>bool</td><td>boolean, the value "1" means true, the value "0" means false, everything else is an error and should be interpreted as NULL</td></tr>
-<tr><td>str</td><td>string or blob, the content is base64 encoded - if it is a string the result of base64 decoding is in UTF-8 encoding</td></tr>
-</table>
-
-
-
-</html>
\ No newline at end of file
--- /dev/null
+<html>
+<title>Magic Smoke Server</title>
+</head>
+<body>
+<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
+
+<h1>Creating a Magic Smoke Server Instance</h1>
+
+You need to <a href="build.html">build</a> and <a href="install.html">install</a> the system first.<p>
+
+The steps below assume that you are using a Unixoid system. A lot of them will not work on windows, since the makefile for windows does not contain them and the symlinks used inside the server source tree are not present under Windows - you will have to do a lot of manual copying in that case.
+
+<h2>Prerequisites</h2>
+
+Make sure your web server, and database server work normally.
+
+<h2>Database Preparation</h2>
+
+Normally you can skip this section for ISP side installations, since your ISP will give you a database and the correct login data for it.<p>
+
+MagicSmoke can work with MySQL or Postgres. Connect to your database server using a client of your choice (I'll assume the command line mysql client below, commands should be similar for other clients).<p>
+
+Create a database user - I'll assume it is called "smoke" and uses "verysecret" as password. Create a database - I'll assume it is called "smoke". Then give the user all rights on this database.
+<pre>
+mysql> CREATE USER smoke IDENTIFIED BY PASSWORD 'verysecret';
+mysql> CREATE DATABASE smoke;
+mysql> GRANT ALL ON smoke.* TO smoke;
+</pre>
+
+MagicSmoke uses a common configurable prefix for its tables ("smoke2_*" per default), so you can use an existing database or even use the same database for multiple installations or different programs (assuming the other programs are as tolerant as MagicSmoke). If you have the possibility it is however recommended to give each MagicSmoke instance its own database, since it is easier to drop and restore entire databases insted of just parts of them.<p>
+
+MagicSmoke2 can be installed in parallel to the old MagicSmoke 1.0 packages, but it cannot access the same tables (upgrade is possible though).<p>
+
+<h2>Server Instance Creation</h2>
+
+You can skip this part for ISP side installations, instead follow the instructions for <a href="install.html#isp">Installation on an ISP Account</a>.<p>
+
+During <a href="install.html">installation</a> you copied all MagicSmoke sources into a central directory. MagicSmoke supports being run as multiple instances. For each instance you have to chose a target directory in which you want to configure it.<p>
+
+Execute <tt>/usr(/local)/share/magicsmoke2-server/install.sh</tt> with your target directory
+as parameter. This will link the current version of MagicSmoke into the target directory, if you have already made a configuration there it will not touch it.<p>
+
+If the target directory is not already inside the DocumentRoot of your server, link the target directory into your web server - either with a symlink or an Alias configuration statement.
+
+<h2>Configuring MagicSmoke</h2>
+
+
+Now edit the config.php file, it is a simple PHP file. Although theoretically
+all facilities of PHP are available there, you should stick to the format of
+the template to avoid unintended side-effects.<p>
+
+The configuration file contains several sections:
+
+<h3>Database Options</h3>
+
+The database section describes which database is used for storing data and
+how the database interface behaves.<p>
+
+The $db variable is supposed to point to an object of a class derived from
+DbEngine. There are currently two of those:
+<ul>
+<li>MysqlEngine uses the MySQLi interface of PHP to access a MySQL 5.x database
+<li>PGsqlEngine uses the PGSQL interface of PHP to access a Postgres database.
+To be compatible with MagicSmoke the server should be at least version 8.x
+</ul>
+
+Examples and directions are available in the configuration file template.<p>
+
+The $olddb variable if set can be used to upgrade a MagicSmoke 1.0 database
+to version 2.0. After upgrade you should comment it out.<p>
+
+There is one option stored in the DB-Engine that is only used for database creation and recovery:
+<pre>
+$db->setAdminPassCode("Admin","SmokeInMyEye");
+</pre>
+
+This call sets the web-user and web-passcode for the <tt>admin.php</tt> script. After installing the system this line should be commented to prevent anyone from destroying the database or installing more admin users. Change the second parameter (password) to something else (preferably something hard to guess), so I won't be able to guess your admin password in case you forget to comment it.
+
+<h3>Dedicated Client Configuration</h3>
+
+This section configures the behavior of the server towards the dedicated client.<p>
+
+There is only one option: the timeout for client sessions. It is safe to leave it at the default setting - making it short potentially confuses the client into re-establishing the connection immediately, if the clock between server and client are significantly off, making it longer does not have any effect since the client automatically renews the session when it nears its end.
+
+<h3>Web Client Configuration</h3>
+
+This section configures the behavior of the web interface.<p>
+
+These options configure the timeouts of cookies, what features are available to users and what features of the template engine are available.<p>
+
+
+<h2>Database Initialization</h2>
+
+Open a browser and direct it to admin.php in your MagicSmoke installation (usually something like <tt>http://localhost/magicsmoke/admin.php</tt>).
+
+The default user name is "Admin" and the password is "SmokeInMyEye" - or whatever you have configured above.<p>
+
+Click the create database button.
+
+<h3>Initial Installation</h3>
+
+Create an initial administrator user using the form at the bottom of the page.<p>
+
+Done.
+
+<h3>Upgrade from MagicSmoke 1.0</h3>
+
+MagicSmoke2 is not able to import old MagicSmoke Backups, you need to import those with an old installation and then convert them as described below.<p>
+
+If you have set up the $olddb variable in your configuration MagicSmoke will offer to migrate data. Do not attempt migration if your new database already has some data stored.<p>
+
+Please make sure that the old and new database do not share tables - at the very least the database name or the table prefix should be different.<p>
+
+The upgrade may take some time - you should make sure that PHP scripts do not abort too soon. On a normal workstation this will take about 2-4 minutes for a database with a few thousand orders. If it fails you should empty/recreate the new database and start over.<p>
+
+Simply enter "upgrade" into the input line and click the button.<p>
+
+The format of customers in the database has changed significantly. The upgrade process tries to guess what part of customer names and customer address belong to which detail. This heuristic may fail in some cases, you should go through your customer list and correct any mistakes afterwards.<p>
+
+When you are done comment out the $olddb configuration to avoid initializing it for every call of a script.<p>
+
+The migration process does not touch the old tables.
+
+<h3>Both</h3>
+
+Comment out the "setAdminPassCode" line in <tt>config.php</tt>, so that no one else can abuse this interface.<p>
+
+From now on you can access it with the MagicSmoke client. Your URL for the client ends in machine.php (eg. <tt>http://localhost/magicsmoke/machine.php</tt>).<p>
+
+
+<h2>Creating Templates</h2>
+
+The <tt>template/*</tt> sub-directories of your target directory contain collections of template files. These are used to generate the user interface that users get to see. Each sub-directory of <tt>template</tt> is the name of a language in <a href="http://en.wikipedia.org/wiki/ISO_639">ISO 639</a> coding - e.g. "en" stands for English, "de" for German, etc. The link "C" (upper-case) points to your fall-back language that is used if the users browser does not support one of the available languages.<p>
+
+Please read the chapter about <a href="template.html">Template Design</a> and create your own set of templates (or customize an existing one).<p>
+
+If you plan to store your templates in a different directory modify the template line in your config file, eg.:
+<pre>
+$template="/home/erwin/mytemplate/";
+</pre>
+
+
+</body>
+</html>
\ No newline at end of file
<h1>Magic Smoke Template Design</h1>
<img src="logo.png" alt="logo" valign="left" align="top"/><br/>
-The web user interface is constructed with templates with just a few dynamic values filled in. Thos templates are found in the <tt>www/template/*</tt> directories. These templates are normal HTML (actually: you chose the version of HTML that is used) with some special constructs to fill in the blanks.<p>
-
-In order to create your own templates copy one of the template directories and start to modify the files in there. Usually it should be enough to change the <tt>layout.html</tt> template. If you use relative links inside your templates they will be interpreted as relative to the <tt>index.php</tt> script.<p>
-
-<h2>Syntax</h2>
-
-The most important element of templates are variables. Variables can be set by the template itself, or by the script. Wherever the value of a variable needs to be inserted it is simply placed between two "@" characters, eg. "<tt>Variable XYZ contains @XYZ@</tt>". These value replacements can occur anywhere in the text, whereas all other syntactical elements must appear on a line of their own.<p>
-
-Variables can be set and unset using the special <tt>#set</tt> and <tt>#unset</tt> commands:
-<pre>
-#set:VARIABLE=value
-#set:LONGVARIABLE:
-some values containing anything
-#endset
-</pre>
-
-The first version of the set-syntax just assigns everything behind the "=" to the variable named before it. The second version of the set-syntax assigns everything between the <tt>#set</tt> and <tt>#unset</tt> lines without replacing any values or interpreting any syntax.<p>
-
-Conditional parts of the template text can be put between <tt>#if</tt> and <tt>#endif</tt>:
-<pre>
-#if:VARIABLE==value
-text that only appears if VARIABLE contains value
-#endif
-</pre>
-All comparisons are made as string comparisons (this eg. means "2" is greater than "100") with both the variable and the comparison value trimmed. Possible operators are:
-<table frame="1" border="1">
-<tr><td>==</td><td>matches if the variable contains exactly this value</td></tr>
-<tr><td><</td><td>matches if the variable is smaller than this value</td></tr>
-<tr><td>></td><td>matches if the variable is greater than this value</td></tr>
-<tr><td><=</td><td>matches if the variable is smaller or equal to this value</td></tr>
-<tr><td>>=</td><td>matches if the variable is greater or equal to this value</td></tr>
-<tr><td>!= or <></td><td>matches if the variable does not contain this value</td></tr>
-</table>
+The web user interface is constructed with templates with just a few dynamic values filled in. Those templates are found in the <tt>template/*</tt> directories. These templates are normal HTML or text with some special constructs to fill in the blanks.<p>
+
+Please see the <a href="twig/index.php">Twig</a> template engine documentation for syntax details.
<h2>Template Files</h2>
-<h3>layout.html</h3>
+There are template files for everything that is displayed on the web page and for all types of eMail sent by the MagicSmoke customer system.<p>
+
+Each of the example templates contains some hints what data is available. Most objects are types from the <a href="wob/index.html">Web Object</a> Interface.<p>
+
+Please see the <a href="source-php/templates.html">Templates Chapter</a> of the PHP <a href="source-php/index.html">Source</a> Documentation.
-This is the main template that contains the static parts of all pages displayed by Magic Smoke.<p>
+<h2>Template Caching</h2>
-The only variable inside it is <tt>@PAGE@</tt> which is replaced by the context created using one of the other templates.
+The Twig template engine compiles the templates into PHP code before actually displaying anything. You have to choice to discard those compiled templates or to store them for faster access next time the page is called. Allowing the web server write access to a directory opens a potential security hole. If you want to do caching securely:
+<ol>
+<li>create a storage directory in parallel to the <tt>template</tt> directory, eg. <tt>tcache</tt>, or if it already exists empty it</li>
+<li>make sure the directory is writable by the web server</li>
+<li>enter this directory into the Twig configuration:<br>
+<tt>$twigoptions=array( 'cache' => './tcache' /*...*/ );</tt></li>
+<li>make it writable for the web server</li>
+<li>uncomment the "setAdminPassCode" line in <tt>config.php</tt></li>
+<li>open <tt>index.php?mode=compile</tt> in a browser - it will ask you to enter the admin credentials</li>
+<li>the page will compile all templates it can find and store them in the configured cache directory</li>
+<li>restrict the directory access rights so the web server cannot write to it any more, make sure it can also not overwrite the files</li>
+<li>comment the "setAdminPassCode" line in <tt>config.php</tt></li>
+</ol>
</html>
\ No newline at end of file
--- /dev/null
+../tzone/sourcedoc
\ No newline at end of file
}
-/** creates the cart overview */
+/** \page templates Templates
+\section tpl_cart Cart Variables
+
+The cart.html template is used to render the current cart of the customer.
+
+\param cart an object of the web type <a href="../wob/class-WebCart.html">WebCart</a> (PHP: WOWebCart) that represents the entire cart of the user.
+\param shipping and array of web objects of type <a href="../wob/class-Shipping.html">Shipping</a> (PHP: WOShipping) which represent all available shipping types that customers can chose from.
+\param forceshipping a boolean that contains whether customers must chose a shipping type.
+
+\section tpl_carterror Cart Error Variables
+
+The carterror.html template is used to when the cart expired or the customers browser lost the cookie.
+
+Just the \ref tpl_base Base Variables
+are available.
+**/
+
+
+/** creates the cart overview
+
+for templating info see \ref tpl_cart Cart Variables
+and \ref tpl_base Base Variables
+*/
static public function createCartOverview()
{
global $twig,$basevars,$WebForceShipping;
return $p->render($list);
}
-
//end of WebCart
};
// +----------------------------------------------------------------------
//
+/**
+\page templates Templates
+\section tpl_index Event List
+The index.html template is used to render the list of events available to customers.
+
+\param events an array of the events available, starting at the current time, ordered by time; the events are of web object type <a href="../wob/class-Event.html">Event</a> (PHP: WOEvent)
+
+\section tpl_eventdetail Event Details
+
+The eventdetails.html template is used to render a single event and to offer the user to buy tickets for it.
+
+\param event the event being rendered; the event is of web object type <a href="../wob/class-Event.html">Event</a> (PHP: WOEvent)
+*/
+
+/** wrapper arount event (list) rendering for the web UI*/
class EventRender {
/** creates an list of events */
if(!$session->checkFlags($event->getflags()))continue;
//encode as array
$list['events'][]=$event;
- }
-
+ }
//pass 2: create page
return $p->render($list);
}
$twig->addExtension(new LangFilterExtension);
$twig->addExtension(new SmokeFilterExtension);
+
+/** \page templates Templates
+\section tpl_base Base Variables
+
+There are some variables available for all templates.<p>
+
+\param script.* variables contain URLs for different modes of the web site:<br>
+<table frame="1" border="1">
+<tr><td><tt>script.root</tt></td><td>root URL for the index.php script</td></tr>
+<tr><td><tt>script.this</tt></td><td>the URL of the currently called script mode</td></tr>
+<tr><td><tt>script.index</tt></td><td>URL of the list index</td></tr>
+<tr><td><tt>script.eventDetails</tt></td><td>URL for event detail pages, append the event ID to it to complete it</td></tr>
+<tr><td><tt>script.eventOrder</tt></td><td>URL for ordering tickets for a specific event, arguments are expected as POST parameters</td></tr>
+<tr><td><tt>script.cart</tt></td><td>URL of the cart, the cart must exist when calling it, otherwise a cookie error will be displayed</td></tr>
+<tr><td><tt>script.mycart</tt></td><td>URL of the cart that transparently creates the cart if it does not exist yet</td></tr>
+<tr><td><tt>script.checkout</tt></td><td>URL to check out the cart</td></tr>
+<tr><td><tt>script.setlanguage</tt></td><td>URL for setting the language cookie, add the language code to it to complete it</td></tr>
+</table><p>
+\param inputnames.* variables contain names for specific form input elements:<br>
+<table frame="1" border="1">
+<tr><td><tt>inputnames.amountTickets</tt></td><td>amount of tickets to be ordered</td></tr>
+<tr><td><tt>inputnames.event</tt></td><td>contains the event ID</td></tr>
+<tr><td><tt>inputnames.mode</tt></td><td>contains the display mode</td></tr>
+<tr><td><tt>inputnames.cartid</tt></td><td>ID of the cart of the current customer, usually the cart cookie is used instead</td></tr>
+</table><p>
+\param cartcookie variable contains the name of the cookie that contains the cart ID.<p>
+\param lang variable is an object of type LanguageManager - it represents translations done for the language the user has chosen.<p>
+
+
+\section tpl_error error.html
+
+This template is used whenever an error occurs during processing.
+
+\param ErrorText the text to be shown for an error
+\param ErrorTrace a full ASCII version of an exception trace. This is only filled if the <tt>$WebShowErrors</tt> option is set to <tt>true</tt> in the config.php file.
+**/
+
//basic variables shared by all templates
// script URLs
$basevars['script']['root']=$_SERVER['SCRIPT_NAME'];
$e["ErrorText"]=translate("WebSite","An error occured, contact the server admin for details.");
$page=$p->render($e);
}
+
//spit out completed page
header("Content-Type: text/html; charset=utf-8");
print($page);
projects / web/konrad/smoke.git / commitdiff