Difference between revisions of "Xebra About"

(Website Development)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:Xebra]]
 
[[Category:Xebra]]
[[Image:Xebra_logo_head1.png|right]]
+
[[Xebra About|About]] | [[Xebra Installation|Installation]] |  [[Xebra Documentation|Documentation]] |  [[Xebra Tutorial|Tutorials]] | [[Xebra FAQ|Frequently Asked Questions]]
  
 
=Architecture Overview=
 
=Architecture Overview=
Line 12: 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

XEbraArchitecture2-1_small.png


  1. 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.
  2. The Xebra Server forwards a request to the appropriate web application and returns the result to the HTTP Plugin.

Website Development

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 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

Ajax

MVCframework

MVC Push/Pull

i18n & l10n

ORM

Testing framework(s) DB migration framework(s) Security Framework(s) Template Framework(s) Caching Framework(s) Form Validation Framework(s)

Xebra

Eiffel

Can be added later on (using for instance Script.aculo.us)
Yes
Pull
planned
No
Contracts, Unit Tests

planned
Yes
planned
Yes

Apache Struts

Java

Yes Yes Push & Pull Yes Yes

Unit Tests



Yes
Yes

ASP.NET MVC

ASP.NET

Yes Yes Push
ORM-independant

Unit Tests


ASP.NETForms Auth

pluggable (default is WebForms) Yes Yes (client-side via plugins)

Drupal

PHP

jQuery

Yes[2][3]


Yes[4][5]

multiple (CCK, QCubed)[6]

simpletest, devel Schema API

OG, Node Privacy By Role,ACL, Taxonomy Access List

PHPTemplate, Smarty, XTemplate, others

builtin,memcache,APC

Form API

Google Web Toolkit

Java,Javascript

Yes

Yes , no direct data access

JUnit(too early),jsUnit(too difficult),Selenium(best)

No



Ruby on Rails

Ruby

Prototype,script.aculo.us

ActiveRecord,Action Pack

Push Localization Plug-in

ActiveRecord

Unit Tests, Functional Tests and Integration Tests

Yes Plug-in Yes Yes Yes

Seaside

Smalltalk

Prototype,script.aculo.us, etc.



Yes

GLORP,Gemstone/S, etc.

Unit Tests, SUnit



No, intentionally

Magritte

Sphere

PHP5

Toolkit Independent Yes Push, supports Helpers Yes

Active Record Pattern

Unit Tests


via module plain PHP by default, can use Smarty or other via module, APC, etc via module

Spring

Java


Yes
Yes

Hibernate, iBatis, etc



Spring Security (formerly Acegi)

Commons Tiles,Velocity, etc.

ehcache etc. Commons Validator

Zend

PHP5 (>=5.2.4)

Toolkit-independent Yes Push & Pull Yes Table and Row data gateway

Unit Tests

Yes

ACL-based

Yes Yes Yes