Difference between revisions of "XDocumentation"

Line 1: Line 1:
 
[[Category:Xebra]]
 
[[Category:Xebra]]
==Xebra Libraries==
+
 
 +
 
 +
=Architecture Overview=
 +
 
 +
  1. The XEbra HTTP plugin (Apache: Module) forwards a request from the HTTP server to the XEbra Server and waits for a response.
 +
  2. The XEbra Server forwards a request to the appropriate web application.
 +
 
 +
 
 +
 
 +
  1. The XEbra Server forwards requests to a REQUEST_HANDLER
 +
  2. The REQUEST_HANDLER sends a request to the appropriate SERVLET, which represents a xeb page.
 +
  3. 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:
 +
    1. Xeb files parsed and compiled to servlet_generators
 +
    2. servlet_generators generate servlets
 +
    3. 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===
 
===Page===
 
Templates are xeb files with so called regions which have to be implemented by extending xeb files. Templates are not compiled down to servlets. There are two ways of using templates: extending a template xeb or including it, while passing all the regions down.
 
Templates are xeb files with so called regions which have to be implemented by extending xeb files. Templates are not compiled down to servlets. There are two ways of using templates: extending a template xeb or including it, while passing all the regions down.

Revision as of 15:22, 29 June 2009


Architecture Overview

  1. The XEbra HTTP plugin (Apache: Module) forwards a request from the HTTP server to the XEbra Server and waits for a response.
  2. The XEbra Server forwards a request to the appropriate web application.


  1. The XEbra Server forwards requests to a REQUEST_HANDLER
  2. The REQUEST_HANDLER sends a request to the appropriate SERVLET, which represents a xeb page.
  3. 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:

   1. Xeb files parsed and compiled to servlet_generators
   2. servlet_generators generate servlets
   3. 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

Templates are xeb files with so called regions which have to be implemented by extending xeb files. Templates are not compiled down to servlets. There are two ways of using templates: extending a template xeb or including it, while passing all the regions down. 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>

<page:declare_region id="greeting" />

   <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