|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | [[Category:Xebra]]
| |
| | | | |
| − |
| |
| − | =Architecture Overview=
| |
| − | #The Xebra HTTP plugin (Apache Module or IIS Handler) forwards a request from the HTTP server to the Xebra Server and waits for a response.
| |
| − | #The Xebra Server forwards a request to the appropriate web application.
| |
| − |
| |
| − | (image)
| |
| − |
| |
| − | #The Xebra Server forwards requests to a REQUEST_HANDLER
| |
| − | #The REQUEST_HANDLER sends a request to the appropriate SERVLET, which represents a xeb page.
| |
| − | #The SERVLET renders an XHTML page. Depending on the xeb file it derives from, it will delegate calls to the controller (3).
| |
| − |
| |
| − |
| |
| − |
| |
| − | SERVLETs ans REQUEST_HANDLERs are generated from the xeb files, while the controller is implemented by the developer and has to inherit from XWA_CONTROLLER. The controller contains business logic for a servlet class (aka xeb file).
| |
| − | (Detailed steps from a xeb file to a rendered html file:
| |
| − | #Xeb files parsed and compiled to servlet_generators
| |
| − | #servlet_generators generate servlets
| |
| − | #servlets generate html)
| |
| − |
| |
| − | =Website creation work flow=
| |
| − |
| |
| − |
| |
| − |
| |
| − | The translation part works in two steps. First of all the .xeb-files are compiled to servlet generators and the classes for request handling and application launching. Servlet generators generate servlet classes for the final web app (second step).
| |
| − | The double generation is needed because tags generate code which renders html and do not render html themselves. Since we can't load the classes at run time (since we only get the name of a tag class) we have to first generate servlet generators.
| |
| − |
| |
| − | =Xebra Libraries=
| |
| − | ===Page===
| |
| − | The ''page'' libraries consists of the core tags needed for page configuration and composition. The Tags are:
| |
| − |
| |
| − |
| |
| − | * page:fragment
| |
| − | If used the page is not transformed to a servlet
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | ! Tag
| |
| − | ! Description
| |
| − | |-
| |
| − | |
| |
| − | <xml>
| |
| − | <page:controller class="..." />
| |
| − | </xml>
| |
| − | |
| |
| − | Defines the controller which should be used for the ''xeb'' page
| |
| − | |-
| |
| − | |
| |
| − | <xml>
| |
| − | <page:declare_region id="..." />
| |
| − | </xml>
| |
| − | |
| |
| − | Declares a region at the specific point in the xeb page
| |
| − | |-
| |
| − | |
| |
| − | <xml>
| |
| − | <page:define_region id="...">
| |
| − | ...
| |
| − | </page:define_region>
| |
| − | </xml>
| |
| − | |
| |
| − | Defines a region from a template, can only be used inside a page-include tag
| |
| − | |-
| |
| − | |
| |
| − | <xml>
| |
| − | <page:include id="..." />
| |
| − | </xml>
| |
| − | |
| |
| − | Includes a template
| |
| − | |}
| |
| − |
| |
| − |
| |
| − | With these techniques we would be able to minimize duplicated code and hence errors in the xeb files, which are difficult to debug.
| |
| − |
| |
| − | Example:
| |
| − |
| |
| − | master.xeb
| |
| − |
| |
| − | <html>
| |
| − | <page:controller class="DEFAULT_CONTROLLER"/>
| |
| − | <body>
| |
| − | <h1>
| |
| − | <page:declare_region id="greeting" />
| |
| − | </h1>
| |
| − | <page:declare_region id="form" />
| |
| − | </body>
| |
| − | </html>
| |
| − |
| |
| − |
| |
| − | The master page is "deferred", since there are page:declare_region tags.
| |
| − |
| |
| − | slave1.xeb
| |
| − |
| |
| − | <page:include template="master">
| |
| − | <page:define_region id="greeting">
| |
| − | Hello, I'm Slave 1
| |
| − | </page:define_region>
| |
| − | <page:define_region id="form">
| |
| − | Other region
| |
| − | </page:define_region>
| |
| − | </page:include>
| |
| − |
| |
| − |
| |
| − | slave2.xeb
| |
| − |
| |
| − | <html>
| |
| − | <page:controller class="SLAVE2_CONTROLLER" />
| |
| − | <page:include template="master"
| |
| − | <page:define_region id="form">
| |
| − | Other region 2
| |
| − | </page:define_region>
| |
| − | </page:include>
| |
| − | </html>
| |
| − |
| |
| − |
| |
| − | slave3.xeb
| |
| − |
| |
| − | <page:include template="slave2.xeb">
| |
| − | <page:controller class="SLAVE2_CONTROLLER" />
| |
| − | <page:define_region id="greetings">
| |
| − | </page:define_region>
| |
| − | </page:include>
| |
| − |
| |
| − |
| |
| − | This code will generate exactly three servlets, SLAVE1_SERVLET.e , SLAVE2_SERVLET.e and SLAVE3_SERVLET.e. master.xeb and form.xeb are fragments. SLAVE1_SERVLET inherits the controller from the master page, while SLAVE2_SERVLET "overwrites" this definition and uses SLAVE2_CONTROLLER. All the pages which are deferred (like master.xeb) are not compiled to servlets. Neither are pages which are denoted with the tag page:fragment.
| |
| − | Template pages could be used to differentiate views based on roles. For instance one could think of roles like 'guest', 'user' and 'admin'. 'guest' and 'user' would then have pages which inherit from a 'master_page', implementing their own menus. 'admin' in contrast would inherit from 'user', since it is a user with additional rights. So it would have to extend the menu and contents. Sub pages which have been added through page:include could act as master pages as well, further encouraging code reuse.
| |
| − |
| |
| − | ===Xeb===
| |
| − | ===Form===
| |
