|
Preface
The Presentation Problem (an historic background)
The basics (CGI)
The sophisticated way (Servlets)
Embedding your code (PHP, ASP, Cold Fusion, JSP, etc)
Custom Methods (HTML Templates, External Libraries, etc)
The Future?
XML/XSL technology
webEditor functional description
Content Creation
Content Composition
Implementation
Conclusions
Preface webEditor is born with the intention to become a helpful tool for the web content management. We propose the following project objectives:
- Generate structured documents that represent complete news.
To accomplish this goal, we
are going to use XML as the primary data format. We do not
discard the use of some kind of relational database to
manage the document relationships.
- Publish the generated documents in an easy way
. For this purpose we need a system that can
easily discriminate content and presentation layers. This
system must also provide a method to change the presentation
and add new functionality with the minimum impact over the
business logic layer. We believe that this method is the XSL
Transformation.
- Manage the creation, edition, delete and many other common document operations to allow high user operability
. This doesn't mean that
the figure of the content administrator is not useful, but
the most common administration tasks are made without his
direct supervision.
The Presentation Problem (an historic background) If you have experience in web programming environments, probably you have discover that one of the most tedious and less valued task is to change the HTML design of a dynamic web page.
The basics (CGI) CGI programming model has been used for a while, so we won't try to "discover" it in this paper. A CGI is simply a stand-alone program that is invoked by the Web Server, and whose life cycle is:
1. - Call from the web server
2. - Perform some operation
3. - Generate the output in HTML
This program could be written in the programming language that you prefer (Perl, c, c++, Tcl/TK, pike, etc). It doesn't matter. Let see a classical "Hello World" CGI written in Perl:
|
hello.pl
print ("Content-type: text/html \n\n");
print ("<h1> Hello World!!
</h1>\n"); |
Simple, right? CGI is the most simple and low level way to develop web applications. You can't separate the logic of the program from its presentation. If you are familiar with "classic programming", CGI probably doesn't seems to you as an intuitive method to develop. It also has the worst functional defect that anything can have in the Web: Changes are slow. This means that if you have to change the HTML design of your CGI (maybe your manager doesn't like the <h1> tag and prefer the <h2> ;-)) you must review all the pretty code that you have written in order to change, not the program logic, but the program presentation.
The sophisticated way (Servlets) Indeed, servlets are a very clear and structured way to develop "kind of" CGI programs in java. But, despite their powerful features (such as HTTP sessions), servlets are CGI, so you will find the same problems: You have all the conceptual layers into the same programming layer.
Let's see the "Hello World" servlet:
|
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Hello extends HttpServlet
{
public void doGet (HttpServletRequest request,
HttpServletResponse response)
throws ServletBution, IOBution
{
PrintWriter out;
response.setContentType("text/html");
out = response.getWriter();
out.println("<HTML><HEAD><TITLE>");
out.println("</TITLE></HEAD><BODY bgcolor=\"#FFFFFF\">");
out.println("<H1> Hello World!!</H1>");
out.println("</BODY></HTML>");
out.close();
}
}
|
Well, you could see that you have to write more lines to get the same output and the same problems. But do not discard servlets at this point. We will show you that the servlet concept has a couple of interesting features.
Embedding your code (PHP, ASP, Cold Fusion, JSP, etc) Web embedded languages are a different approach to the dynamic pages generation. The web server, usually, not only provides these languages; they are executed into the web server process itself. That implies that you don't have the process creation overhead that you usually have with the CGI model, so you get better performance and save system resources.
That sounds good, isn't it? Also, you gain more advantages. For example, its difficult to find a faster web development framework. You don't have to compile complex programs. You only have to modify the proper page.
As before, let me show you a PHP Hello World:
|
<?
echo ("<h1> Hello World!! </h1>");
?> |
Well, this is a very simple method, but it has the very SAME problem than the previously described. You could appreciate that logic and presentation are mixed as if they were the same things (Our hope is that at this point you could understand that this is not a good idea).
Custom Methods (HTML Templates, External Libraries, etc) Once you understand the problem, the solution is closer. There are some methods that could be used to separate logic and presentation layers. The simplest one is to develop a set of custom HTML libraries for output generation. Suppose that you need to print HTML tables. You could develop a code library that, receiving some parameters (the cell values, for example), prints the output of a table with this content. Although this method separates the web layers, certainly it is an inflexible and complex way to generate HTML output.
A more desirable solution is to use HTML templates. Templates usually works in the following way: For every dynamic page, your program performs the business logic operation and then, using an HTML template file, generates the results in HTML output. That works really well when your dynamic pages have a simple structure and you don't need to perform data manipulation or programmatic logic inside the template code.
This is the real problem with templates. Simply you had to choose where to place the presentation code for your pages. You place it in different code libraries of your web application or you add more powerful functionality to your template framework?
We usually prefer to place the presentation code inside our applications, and leave the templates as simple as we can. Other people find more useful to increase the features of the templates library.
This situation could lead to template files more complex (and less maintainable) than the application itself. We strongly believe that this is a poor design solution.
All this considerations lay in the same item: There is no HTML template standard. HTML designers can't write templates because the programs that they use (FrontPage, DreamWaver, etc) don't generate the template syntax that you expect. Even if they can, designers should not generate programming logic due to unwanted situations such as infinite loops or the like. So your developers are forced to write the templates, a non trivial task if you have complex web designs.
The Future?
In a technological world like this, with so many options, it's sometimes difficult to decide what solution to adopt. That's probably the reason behind the industry efforts to create and maintain standards. The w3 consortium recommends the use of XSL transformations as web templates, so this is the way that we are going to use.
XML/XSL technology
Do you remember when, in the middle of the 90's all the people talked about HTML, Web pages, etc? During those times, it was impossible to read any tech paper whitout finding any brief description about "what is HTML". We think that we are living the same situation with XML and all the "mutations" that are appearing. If you really want to know what is XML and what can it do for you, well, you have a lot of information in a lot of places. We will focus only in what can XML do to webEditor.
In a simplistic way, XML is a portable and standard method to share and store complex information. You can see it as a File based database. The key point is that XML is standard, so you can take advantage of all its tools and related emerging standards. One of these standards is XSL, witch is the proposed solution to change the way in which an XML document is presented. That is, you have an XML document with the content and you have an XSL template with the presentation. It's important to notice that the presentation could be in any format that you desire.
You ought to remember the following: If you change the XSL template of your documents, you can dramatically change its presentation and, therefore, the use of the document. This is important because we are going to use this concept in the next chapters.
webEditor functional description webEditor users will find two different stages: Content Creation and Content Composition. With the Content Creation you can generate new documents and modify previously generated documents, using for that a standard HTML form. Content Composition allows the end users to modify the document presentation, choosing what documents to publish and in which way.
Content Creation This operation is as simple as to fill the appropriated fields on the Edition form. For every XML document of the edition system, you will find two XSL templates, one for the final presentation and the other for the content manipulation. The edition template will show the XML document in a way that allows you to edit it using only a web browser. The easiest way to accomplish this is with HTML forms. Of course, there are others more powerful tools to improve the client side capabilities, but we think that in an open environment like Internet, the nature of the clients can't affect the application functionality. Tools such as applets o Active-X must be used only when you know that your users can work with it.
Content Composition During this stage, users can compose the news main page, choosing and shorting the news that will appear. In general terms, a good interface shows the data in a similar format to the final presentation. With this kind of interfaces, we can be confident in that the user "knows" what he is doing, and when users can do they work without your intervention, then you have more time to do other more attractive things ;-)
So, we are going to develop a composition system very similar to the final presentation, adding the convenient interface features in order to allow users to perform the management operations on their own.
Implementation During the previous chapters, we have being talking a lot about XSL and XML, but we haven't explain how are we going to use Cocoon and the other software components. The reason is that we want to be, as far as we can, technologically independent.
When we explain that cocoon is a XSL transformation framework, we didn't say all the truth; in fact, cocoon is moving to become a more powerful software, including features that allows it to be, not only an XSLT system, but also a dynamic web development framework. For example, you can build pages with dynamic content using XSP, in a closer way to JSP. We recommend you to review the documentation provided at the cocoon web site for further information.
Our feeling is that webEditor don't need all these features, because we can implement all the functional requirements using servlets and XSL in a standard way. It is true that with this approach we must develop some things that cocoon provided by default. But we don't want to be tied to the future cocoon implementations. The fact is that we only need a real time XSLT method. At the present time, we think that the best method is cocoon but, who knows what it will be in the future? If we design webEditor independent in the transformation layer, we can change cocoon and use another different framework or maybe, moving all the transformation logic to the client side (when the browsers could perform correctly these operations). In conclusion, following the standards brings webEditor the chance to survive for a middle-long time (which, in these times is practically a rarity ;-)).
Conclusions As you can see, the present document doesn't talks much about the software architecture that we are going to use. This is because at this point, we think is better to explain the webEditor background. In fact, if you had to catalog this paper, you could name it the WPD or webEditor philosophical document ;-) No, it's better not to start inventing new and senseless acronyms.
But, please, don't think that this document is completely useless. This papers talks about what is webEditor, what it wont be and, the most important, why not. You will find a lot of more technical information in the architecture document.
| 
