## Roles |
|
`worker_thread` and `application` are very similar classes that gives user similar APIs but they have important differences: |
|
`worker_thread` has single instance in each worker thread or process, it is usually not used directly, but it is referenced by several `application` classes. |
|
In many cases, we need to have more then one application or sub application in our process (for example wiki and forum or users panel and administration panel). |
|
All these application share same controls like access to cache and sessions, access for HTTP requests --- all these stored in `worker_thread` class. |
|
In terms of API, both classes are very similar with the difference that `worker_thread` stores actual data and `application` stores references to this data in `worker_thread`. |
|
In most of cases developers should derive their own classes |
from `cppcms::application` and not from `cppcms::worker_thread`. |
|
## Constructors |
|
worker_thread(manager const &s); |
application(worker_thread &w); |
|
`worker_thread` and `application` constructors should receive a reference to `manager` and primary `worker_thread`. |
|
For example: |
|
class my_application : public application { |
my_application(worker_thread &w) : application(w) { |
... |
|
|
## Public Members |
|
### cppcms::application |
|
worker_thread &worker; |
url_parser &url; |
manager const &app; |
cgicc::Cgicc *&cgi; |
cgicc::CgiEnvironment const *&env; |
cgicc_connection *&cgi_conn; |
cache_iface &cache; |
session_interface &session; |
ostream &cout; |
boost::signal<void()> &on_start; |
boost::signal<void()> &on_end; |
|
### cppcms::worker\_thread |
|
url_parser url; |
manager const &app; |
cgicc::Cgicc *cgi; |
cgicc::CgiEnvironment const *env; |
cgicc_connection *cgi_conn; |
cache_iface cache; |
session_interface session; |
ostream cout; |
boost::signal<void()> on_start; |
boost::signal<void()> on_end; |
|
### Description |
|
- `url_parser url` or `url_parser &url` |
- **`url_parser url`** |
|
It is a class responsible on binding various handlers |
to different requested url. See [`cppcms::url_parser`](/wikipp/en/page/ref_cppcms_url_parser). |
to different requested url. For example: |
|
url.add("^/test$",&app::test,this); |
|
See [`cppcms::url_parser`](/wikipp/en/page/ref_cppcms_url_parser) for reference. |
|
- **`manager const &app`** -- access to [`cppcms::manager`](/wikipp/en/page/ref_cppcms_manager) class. Usually used to fetch configuration values. For example: |
|
int num=app.config.ival("my_app.number"); |
|
- **`cgicc::Cgicc *cgi`** -- access to [`cgicc::Cgicc`](http://www.gnu.org/software/cgicc/doc/classcgicc_1_1Cgicc.html) class of cgicc library that gives you a content of HTTP query. |
|
It is usually used together with form processing: |
|
some_content c; |
c.some_form.load(*cgi); |
|
- **`cgicc::CgiEnvironment const *env`** -- environment of cgicc query. See [`cgicc::CgiEnvironment`](http://www.gnu.org/software/cgicc/doc/classcgicc_1_1CgiEnvironment.html) |
|
- **`cgicc_connection *cgi_conn`** --- access to low level CGI API. Input stream, output stream environment variables. |
|
Generally it should be used only in case we need access to some CGI environment variable unsupported by cgicc. For example: |
|
string encodings=cgi_conn->env("ACCEPT_ENCODING"); |
|
- **`cache_iface cache`** -- access to cache API. See: [`cache_iface`](/wikipp/en/page/ref_cppcms_cache_iface) |
- **`session_interface session`** -- access to sessions API. See: [`session_interface`](/wikipp/en/page/ref_cppcms_session_iface) |
|
- **`ostream cout`** --- the stream for output content of the cgi process (without headers). It is generally used via templates system, however it can be used directly for creating HTML or any other output content. |
|
For example, create csv: |
|
set_header(new HTTPContentHeader("text/csv")); |
cout<<"n,n!"<<endl; |
cout<<"0, 1"<<endl; |
cout<<"1, 1"<<endl; |
cout<<"2, 2"<<endl; |
cout<<"3, 6"<<endl; |
|
- **`boost::signal<void()> on_start, on_end`** --- these are the signals that application can connect itself in order to perform certain tasks when new query comes, independently from URL. |
|
Various application running in same thread may attach |
many signals. |
|
For example: |
|
class my_app: public application { |
|
int user_id; |
string user_name; |
void start() |
{ |
if(session.is_set("user_id")) { |
user_id=session.get<int>("user_id"); |
user_name=fetch_user_name(user_id); |
} |
else { |
user_id=-1; |
user_name="visitor"; |
} |
} |
void end() |
{ // Cleanup all user data |
user_id=0; |
user_name.clear(); |
} |
... |
my_app() |
{ |
on_start.connect(bind(&start,this)); |
on_end.connect(bind(&end,this)); |
... |
} |
|
|
|
|
|
