HQU Architecture
Intro
The HQU architecture is modeled closely to many other frameworks, such as Grails and Ruby on Rails. However, since the HQ backend provides the complete model, the HQU plugins generally only serve as a small interface between the incoming request and HQ.
Exposed APIs
HQU plugins are free to call into any of the HQ classes, however the future existence of those APIs is not guaranteed. Instead, HQU provides a more simplified, intuitive interface to HQ which will be supported and deprecated as API versions periodically change. Authors should try to conform to the HQU APIs as much as possible to make sure their code is easily supported in the future.
Deployment
HQU plugins are deployed into a subdirectory of hq.war in order to safely allow regular access to static files within the context of the webapp (such as plugin-provided images, .css).
Plugins are deployed in JBOSS_HOME_/server/default/deploy/hq.ear/hq.war/hqu. A directory watcher periodically checks this directory for new additions and removals and (un)loads plugins as necessary.
Authentication
All interactions with UI plugins currently require authentication, so you'll have to login and obtain a session in order to see your plugin.
Basic Architecture
When HQU plugins are deployed, they are loaded by HQ and examined to make sure their APIs are compatable. Once a plugin is accepted, it is then free to accept requests. Requests for plugins come in the following URL form: http://localhost:7080/hqu/plugin_name/controller_name/action.hqu
- plugin_name maps to the name of your plugin (usually the same name as the directory deployed into hq.war/hqu)
- controller_name maps to a directory inside your plugin, such as hqu.war/hqu/my_plugin/app/my_controller.groovy
- action maps to a method inside the controller, which will be called when a request to the URL is made.
When the action methods are executed, they have access to query parameters and all the regular request and response objects you would ordinarily require from a J2EE web container.