• log out

Your Web App

The APP_DIR/web folder contains an .htaccess file that instructs Apache and Litespeed servers to use URL rewriting. For other browsers, you will have to do something similar. Regular files like images, css etc. are handled by the web server as expected, e.g. 

http://mydomain.com/coolApp/css/html.css

If URL rewriting is on, then your app's URL will look like this: 

http://mydomain.com/coolApp/welcome

But if it's not on, then your app's URLs will mostly look like this: 

http://mydomain.com/coolApp/index.php/welcome

In Qbix, when a request comes in for a URL 

http://mydomain.com/coolApp/index.php/foo/bar/baz

we would refer to

  • http://mydomain.com/coolApp/ as the "base url",
  • http://mydomain.com/coolApp/index.php as the "controller URL", and
  • foo/bar/baz as the "tail".

Dispatching the Request

When a request comes in through index.php, the Q_WebController::execute() method calls Q_Dispatcher::dispatch(), which tries to route the requested URL to an internal URI.

After routing, if the URI field Q_Dispatcher::uri()->module turns out to be empty (e.g. because no routes matched the requested URL), then the "Q/noModule" event is fired, because Qbix doesn't know what to execute next. By default, this event just fires your "$App/notFound" event.

Otherwise, the following events occur in order:

  • "Q/notFound" if there is no route or handler for the internal URI
  • "Q/prepare" giving the app an early hook for the request handling
  • "Q/validate" giving the app a chance to validate the request input
  • "Q/reroute" giving the app a hook to call Q_Dispatcher::forward()
  • "Q/objects" letting the app create internal objects to handle requests
  • "Q/$verb" for handling any HTTP verb other than GET. This is the main time to write to the database and change the state.
  • "Q/analytics" for executing any sorts of analytics. Often involves appending to a log or database.
  • "Q/response" - see more info on producing output

Out of all of these events, the only one where you should print output is Q/response (just use echo or print). That is what gets returned to the browser. If an uncaught exception ever escapes the Q/response handler, you will see an exception dump on the front page, that you need to fix. If an exception is thrown in some other event (such as Q/post), Qbix attempts to render a regular page (by calling Q/response anyway) but with the errors reported in the errors slot.

You can also override default handlers for events such as:

  • "Q/errors/native" when errors occur while trying to show errors during Q/response
  • "Q/exception/native" if an uncaught exception occurs while handling the request
  • "Q/shutdown" "before" hook happens during normal shutdown and fatal errors

Default Implementations

The default implementations of these methods usually fire "$Module/$action/$method". For example, to handle POST requests to First/welcome you just have to implement the "First/welcome/post" event handler.

The default handler for "Q/response" renders the various slots by firing "$Module/$action/response/$slotName" events, as described here.

The Q_Request Class

You can use many static methods in this class to find out more about the request, including:

  • baseUrl($extra): the base URL of the app
  • slotNames: names of slots that were requested
  • slotName: whether a given slot was requested
  • special: value of special fields starting with Q.
  • method: "GET", "POST", "PUT", "DELETE" etc.
  • isAjax: whether this was a dynamic request
  • isMobile: client is on a mobile phone
  • isTablet: client is on a tablet computer
  • isTouchscreen: client is a touchscreen device
  • formFactor: 'mobile', 'tablet' or 'desktop'
  • isIE($min, $max): client uses some IE version
  • platform: "ios", "android", "mac", "windows", etc.
  • osVersion: version of the platform