Difference between revisions of "Xebra About"
(→Website Development) |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
[[Category:Xebra]] | [[Category:Xebra]] | ||
+ | [[Xebra About|About]] | [[Xebra Installation|Installation]] | [[Xebra Documentation|Documentation]] | [[Xebra Tutorial|Tutorials]] | [[Xebra FAQ|Frequently Asked Questions]] | ||
=Architecture Overview= | =Architecture Overview= | ||
Line 11: | Line 12: | ||
=Website Development= | =Website Development= | ||
− | A Xebra Web Application consists of two parts: The xeb-files and the controllers. Xeb-files consist of html code with embedded xeb-tags. They are translated to servlets. Controllers are Eiffel classes that connect the servlets to the rest of the Eiffel classes. Features of controllers can be invoked from within a servlet. Typically, web designers create xeb-files with a html editor and at the same time, web developers create controllers to provide business logic to the servlets. The web application is then translated which means that the xeb-files are generated to servlet eiffel classes and the whole webappliation is compiled to an executable file. The translation and compilation of the web application is initiated by the xebra server. | + | https://svn.origo.ethz.ch/eiffelstudio/trunk/Src/framework/web/xebra/doc/XebraCreationWorkflow-small.png |
+ | |||
+ | A Xebra Web Application consists of two parts: The xeb-files and the controllers. Xeb-files consist of html code with embedded xeb-tags. They are translated to servlets. Controllers are Eiffel classes that connect the servlets to the rest of the Eiffel classes. Features of controllers can be invoked from within a servlet. Typically, web designers create xeb-files with a html editor and at the same time, web application developers create controllers to provide business logic to the servlets. The web application is then translated which means that the xeb-files are generated to servlet eiffel classes and the whole webappliation is compiled to an executable file. The translation and compilation of the web application is initiated by the xebra server. | ||
For a step by step guide on how to create a web application see [[Xebra_Tutorial|tutorials]]. | For a step by step guide on how to create a web application see [[Xebra_Tutorial|tutorials]]. |
Latest revision as of 08:30, 18 August 2009
About | Installation | Documentation | Tutorials | Frequently Asked Questions
Architecture Overview
- The Xebra HTTP Plugin (Apache Module or IIS7 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 and returns the result to the HTTP Plugin.
Website Development
A Xebra Web Application consists of two parts: The xeb-files and the controllers. Xeb-files consist of html code with embedded xeb-tags. They are translated to servlets. Controllers are Eiffel classes that connect the servlets to the rest of the Eiffel classes. Features of controllers can be invoked from within a servlet. Typically, web designers create xeb-files with a html editor and at the same time, web application developers create controllers to provide business logic to the servlets. The web application is then translated which means that the xeb-files are generated to servlet eiffel classes and the whole webappliation is compiled to an executable file. The translation and compilation of the web application is initiated by the xebra server.
For a step by step guide on how to create a web application see tutorials.
Comparison to other technologies
Some of the features of Xebra are:
- Fully XML compatible for ease of xeb file validation
- Mapping of forms to objects and validation framework
Project | Language |
MVCframework |
Testing framework(s) | DB migration framework(s) | Security Framework(s) | Template Framework(s) | Caching Framework(s) | Form Validation Framework(s) | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Can be added later on (using for instance Script.aculo.us) |
Yes |
Pull |
planned |
No |
Contracts, Unit Tests |
|
planned |
Yes |
planned |
Yes | ||
Yes | Yes | Push & Pull | Yes | Yes | |
|
Yes | |
Yes | |||
Yes | Yes | Push | |
ORM-independant | |
ASP.NETForms Auth |
pluggable (default is WebForms) | Yes | Yes (client-side via plugins) | |||
|
multiple (CCK, QCubed)[6] |
simpletest, devel | Schema API |
OG, Node Privacy By Role,ACL, Taxonomy Access List |
PHPTemplate, Smarty, XTemplate, others | Form API | ||||||
Yes | |
|
Yes | , no direct data access | No | |
|
|
| |||
Push | Localization Plug-in |
Unit Tests, Functional Tests and Integration Tests |
Yes | Plug-in | Yes | Yes | Yes | |||||
|
|
Yes |
GLORP,Gemstone/S, etc. |
Unit Tests, SUnit |
|
|
No, intentionally | |
||||
PHP5 |
Toolkit Independent | Yes | Push, supports Helpers | Yes | |
via module | plain PHP by default, can use Smarty or other | via module, APC, etc | via module | |||
|
Yes | |
Yes |
Hibernate, iBatis, etc |
|
|
Commons Tiles,Velocity, etc. |
ehcache etc. | Commons Validator | |||
PHP5 (>=5.2.4) |
Toolkit-independent | Yes | Push & Pull | Yes | Table and Row data gateway | Yes |
ACL-based |
Yes | Yes | Yes |