Every contribution, in form of code or ideas, is welcome.
These are the paths you see in the browser (AngularJS does client-side routing: no request is issued to the web server, during navigation, if not for fetching data and issuing commands):
The paths used to communicate with the Tornado web server:
Notice that the above paths are the ones used by the webapp. If you plan to use them from an external application (like the event_man barcode/qrcode scanner) you better prepend all the path with /v1.0, where 1.0 is the current value of API_VERSION. The main advantage of doing so is that, for every call, a useful status code and a JSON value is returned.
Also, remember that most of the paths can take query parameters that will be used as a filter, like GET /events/:event_id/tickets?name=Mario
Being too lazy to implement a proper MAC or RBAC, we settled to a simpler mapping on CRUD operations on paths. This will probably change in the future.
User's permission are stored in the permission key, and merged with a set of defaults, valid also for unregistered users. Operations are read, create, update and delete (plus the spcial all value). There's also the special admin|all value: if present, the user has every privilege.
Permissions are strings: the path and the permission are separated by |; the path components (resource:sub-resource, if any) are separated by :. In case we are not accessing a specific sub-resource (i.e.: we don't have a sub-resource ID), the -all string is appended to the resource name. For example:
Sometimes we have to execute one or more scripts in reaction to an action.
In the data/triggers we have a series of directories; scripts inside of them will be executed when the related action was performed on the GUI or calling the controller.
In the data/trigger directory you can create a directory named with this schema: crudAction_document[_resource], where crudAction is one in "create", "update", "delete" (there're no triggers for "read"). So, for example you can create scripts in directories named:
We also have some special triggers, which will contain more information (for example: both the old and the new ticket, updating one):
update_ticket_in_event and attends will receive these information:
In the data/triggers-available there is an example of script: echo.py.
Information are stored in MongoDB. Whenever possible, object are converted into native ObjectId.
Stores information about events and tickets.
Main field:
Notice that all the fields used to identiy a person (name, surname, email) depends on how you've edited the event's form.
Contains a list of username and associated values, like the password used for authentication.
To generate the hash, use:
import utils
print utils.hash\_password('MyVerySecretPassword')
On the list of tickets of an event, you can display one or more custom columns.
To do so, introduce into the settings collection an entry like this:
{"setting" : "ticket_custom_field", "label" : "Afternoon", "type" : "boolean", "key" : "afternoon_attended", "in_event_details" : true}
If type is not 'boolean', it's assumed to be a string.
The code is so divided:
+- eventman_server.py - the Tornado Web server
+- backend.py - stuff to interact with MongoDB
+- utils.py - utilities
+- angular_app/ - the client-side web application
| |
| +- *.html - AngularJS templates
| +- Gruntfile.js - Grunt file to extract i18n strings
| +- js/*.js - AngularJS code
| |
| +- app.js - main application and routing
| +- controllers.js - controllers of the templates
| +- services.js - interaction with the web server
| +- directives.js - stuff to interact with the DOM
| +- filters.js - filtering data
| +- i18n.js - i18n
+- data/
| |
| +- triggers/
| |
| +- triggers-available/ - various trigger scripts
| +- triggers/ enabled trigger scripts
| |
| +- attends.d/ - scripts to be executed when a person is marked as an attendee
| +- create_ticket_in_event.d/ - scripts that are run when a ticket is created
| +- update_ticket_in_event.d/ - scripts that are run when a ticket is updated
| +- delete_ticket_in_event.d/ - scripts that are run when a ticket is deleted
+- ssl/ - put here your eventman_cert.pem and eventman_key.pem certs
+- static/
| |
| +- js/ - every third-party libraries (plus eventman.js with some small utils)
| +- css/ - third-party CSS (plus eventman.css)
| +- fonts/ - third-party fonts
| +- images/ - third-party images
| +- i18n/ - i18n files
+- templates/ - Tornado Web templates (not used)
+- tests/ - eeeehhhh
Most of the time you have to edit something in angular_app/js/ (for the logic; especially controllers.js and services.js), angular_app/*.html (for the presentation) or eventman_server.py for the backend.
But, but, but... you don't use bower/npm/jam/CthulhuJS!
Yes, exactly. I'm too old for that stuff: I just downloaded the third-party libraries that I needed and put them in static/. Seems to work, by the way.
I you're a big fan of those tools, please go ahead and send me a pull request.
In the angular_app/ directory there is a Gruntfile.js; run grunt here to update the files in static/i18n/; right now to set a language you have to edit angular_app/js/i18n.js
It's enough to be consistent within the document you're editing.
I suggest four spaces instead of tabs for all the code: Python (mandatory), JavaScript, HTML and CSS.
Python code documented following the Sphinx syntax.