Index
Downloads
Documentation
Technologies
Architecture
Screenshots
Release Notes
API Docs
Install
Installation on JServ
Installation on Tomcat
Installation on Resin
Code Repository
Mail Lists
Live Demo
Credits
SourceForge Logo
Sourceforge Project Page

About this document

Overview

How it works?

The core layer
The interfaces layer
The dispatcher layer

Conclusions

 

About this document

The present document tries to explain the current webEditor software architecture. You must assume that at the present time, webEditor is not mature software. We are playing with a handle of brand-new technologies, so we want to gain a real knowledge about these technologies before making a "real" design.

 

Overview

webEditor is a java servlet that manages the creation, edition and composition of a news-based web site. Our intention is to use, as much as possible, standard technologies. For example, we are going to store the documents in XML format, so we can take advantage of all the software libraries that are available. In fact, one of the reasons for use java servlets, instead of other great technologies such as PHP, is that we can use all the XML enabled software that we have in java.

The other standard technology that we use is XSL. XSL it's the proposed standard for presentation logic management in a web environment. Using XSL, you can transform an XML document into another format, for example HTML, WML, etc.

 

So, when we use this method, we change the usual way in which people works with web documents. We have a clear separation between content and presentation.

Another benefit is that we can use thirty-part tools in order to edit our documents. For example, you can use your favorite XML editor (I suppose it's vim ;-)) if you want to change something into your documents.

 

How it works?

As an application, webEditor tries to do it work in a modular way. We have three separated application layers:

  • The dispatcher layer
  • The interfaces layer
  • The core layer

Going down to top, the core level implements all the application logic. The software interfaces are user functionality-oriented, so they implement the proper actions for the user request, using for this the core classes. Finally, the dispatcher handles the client request and redirects these petitions to the proper interface.

 

The core layer

Core layer package contains the application logic of webEditor. We do this by creating classes that manages the low-level objects of the application, that is, articles, pages, etc.

 

Configuration Class

This class provides a common interface for the configuration values of webEditor. It allows the application to work with groups of values, instead of individual values. With this approach, we can manage webEditor as a modular application.

 

Image class

Image class handles the management of graphic content. It also implements the document upload capabilities of webEditor.

 

Article class

This is the "heaviest" class in the package. With this you can control the creation, and modification of a news single document. It also provides the methods needed to export the XML data to other formats, such as HTML.

 

Page class

webEditor understand pages as groups of articles. With this class you can manage all the operations related to this item, that is, add, remove, changes into the order, etc

 

Presentation class

This class manages the presentation operations. That is, you can show the edition form for a given document. It also handles the presentation of the home page file and single news documents.

 

The interfaces layer

This package manages the user request operations. This means that when a user performs an action (for example, save a document), the dispatcher component redirects this petition to the proper interface (in this case, the editMode interface) with all the given parameters. Then, the interface does the work by calling the convenient methods of the core classes.

 

ConfigMode interface

It's the simplest interface. We use this option for testing only. It returns to the calling servlet the internal application configuration. Future webEditor versions will provide the ability to change the configuration from this screen, instead of change the XML document by hand.

EditMode interface

This interface is called when the user creates or manipulates a single document. It can do that by calling the low-level methods of the article and presentation classes, mainly.

 

ImageMode interface

This is a component of the previous interface. It performs the same operations over the graphical content of the articles.

 

CompositionMode interface

A composition operation implies changes in the document presentation or format. You use it when you rise or lower a document, or when you decide to remove a document from the home page. You also use it when you insert a new document in the home page.

 

PresentationMode interface

This interface begins to work when you want to see (or preview, if you prefer) the content of a document as a user. It also manages the final exportation of the XML documents to the HTML (by de moment) format that every visitor of your web site will see.

 

The dispatcher layer

The dispatcher component is the single class that you can see on the top of the classes hierarchy, the wEd class. This class decides what interface to call, through the mode HTTP parameter. For example, when you use the "config" mode, wEd knows that the configMode interface needs to be called. That's all that the dispatcher does, redirections to the proper interface. We think this is an elegant way to implement a lot of functionality with a single point of entry.

 

Conclusions

As webEditor gains in functionality, and the development team gain also in knowledge with all the technologies involved, we feel more confident about the future developments. The idea is to maintain the current code as the application core, while we develop the rest of the required functionality as application modules.

The first module will be related to database interaction. Our intention is to maintain a relational database with the relationships of the articles. This feature will allows us to implement a simple and efficient search method.

The second stage in this module design is to perform a low level user management. It will provide a good interface between webEditor and a Naming service such as LDAP.

Once we have this, we will add to webEditor the ability to become a weblog system.

As a long-term goal, we would like to transform webEditor into a fully customizable Portal system.

Ah, to dream is so cheap :-)