Table of Contents
- 1. Yacoom
- 1.1. Vision
- 1.2. Steps to "Yacoom"
- 2. Use Cases
- 2.1. Web Portal
- 2.1.1. Retrieve a Page
- 2.2. Content Repository
- 2.2.1. Retrieve a Resource
- 2.2.2. Store a Resource
- 2.3. Content Management Client
Table of Contents
- 1.1. Vision
- 1.2. Steps to "Yacoom"
Yacoom will be a Content Management System / Web Portal solution.
Content:
Files (with associated mime-type, like graphics, videos, flash animations,...)
XML files with a transformation rule (into XHTML)
This type may contain typical content of dynamic web sites, as forums, faq, download link collections, polls, ad support, etc.)
Content Management:
Every piece of content may have different revisions, only one is marked "published", while others may be marked "archived" or "draft".
The content may be edited by (different) people which may have different access rights to the resources.
The system provides an external [offline] editor for content. This content is created by an editor team.
Content may be contributed directly at the web portal by users/visitors of the site.
Web Portal
The Web Portal shows chunks of content in web format (XHTML)
The Layout and the Design is created using XML files where applicable (e.g. it makes no sense to define an XML representation of CSS files).
The Web Portal is "skinnable", this means the same content may be displayed in different designs without processing the content itself.
The Web Portal produces XHTML/CSS compliant output.
Furthermore, Yacoom will be able to create a complete offline version of the repository (except for forms).
Interfaces will be built in to extend Yacoom or cooperate with Yacoom.
Check the following rough use case diagram:
Development Process
The development process lends its structure from Agile Modeling / Rational Process ideas. It's one target of the project to enable the team members to use notations and procedures of these quite new specification methods and UML.
Yacoom roughly follows the "Agile Modeling": Create a small, incomplete, but working piece of code as a milestone, test it, review it, get user opinions and then go on. Of course this piece of code should always be developed with the final target in mind.
The Yacoom development will follow "stages". After reaching a stage, tests will be done and the project will be driven to the next stage.
Everyone who wants to join the Yacoom development should begin here to see where this project is going. Probably some of the UML diagrams will not created before they are actually required. Nevertheless, to not run into a "blind alley", the stages to version 1.0 will be described roughly in the following list:
Stage 0.1: Getting a working environment
The *Content Repository* accepts files to be uploaded and downloaded, like a "virtual file storage".
To get files into the repository, the *Content Management Client* offers functions to upload/download files and to show the repository directory.
The challenge of this Stage is to define the way Content Management Client and Content Repository communicate. A web service standard protocol would be a good choice (e.g. SOAP).
The *Web Portal* is able to display (echo) an uploaded file by using the file path.
Example: the file example.xml will be uploaded using the Content Management Client into the (Repository) path examples/rawxml/example.xml. The Web Portal displays the file (raw) by requesting:
http://<hostname>/<root>/examples/rawxml/example.xml
Stage 0.2: XML Definitions / Authentication
The *Web Portal* is able to process a layout and create a page from this layout. This requires the definition of the document structure. Several XML/CSS files work together to create the page. To test the layout functions, XHTML files (page fragments) will be used.
The Web Portal and the Content Repository implement authentication/authorization which identifies users of the Repository and the Web Portal.
Stage 0.3: XML to XHTML transformer / versioning
To create a high performance system which will be able to process e.g. DocBook XSL, it is necessary to reduce the XML to XHTML transformations (XSL transformations) to a necessary minimum. This requires a process which is comparable to the functionality of "make". XML files will only be transformed if necessary.
The resulting XHTML (fragments) will be stored in the repository.
Subsequent requests will only test if a new transformation is necessary and return the pre-transformed XHTML if available (comparable to a cache).
The repository is now capable of holding multiple different versions of one document with one being the currently "published" document and other versions which are either "archived" or "draft".
Stage 0.4: User Management / Content Contribution / Edit Content
User account administration is possible from the Web Portal and from the Content Management client. For both parts there is one common business logic part. There is a UI for the Content Management Client and for the Portal. (This will require some research on how to minimize double development work for the UIs).
The Web Portal is extended by functions which allow to enter content in place (e.g. forum post), the Content Management Client will be extended by editors for different XML schemas.
Stage 0.5: Going Live and Reach Out
Develop dynamic extensions to offer some basic functionality. FAQ, Download section, etc.
Those extensions can be installed, activated, deactivated, deinstalled. This opens the door for "third-party" extensions.
Decide how extensions can use each other.
Create a "Getting Started" guide for interested users and start a developers' guide.
Create content from different sources than from XML. Read remote RDFs etc.
Create a backup/restore function.
Stage 0.6: Offline Site Creation
The Content Management Client is able to create a complete offline version of a (local) content repository.
This would enable users to begin with a pure local installation and then scale to a Java Servlet Hosting solution later.
Stage 0.7 to 0.9: Listen to the users
These stages should be filled by requests that the users have. 0.9 will go through the Alpha/Beta test phases which will end in going to version 1.0.
One important extension is to implement a search engine which is able to search all of the content.
This is of course a quite rough plan. The single steps will require many discussions. If you think major features are missing or the order doesn't make sense for you, please let me know and write into the forums or contact me directly at hwillenborg @ users.sourceforge.net
Table of Contents
- 2.1. Web Portal
- 2.1.1. Retrieve a Page
- 2.2. Content Repository
- 2.2.1. Retrieve a Resource
- 2.2.2. Store a Resource
- 2.3. Content Management Client
This chapter will give an overview over the use cases. The following sections will grow and will hold all the necessary specification documents.
- 2.1.1. Retrieve a Page
Retrieve and display requested information.
Scope
It's the task of the web portal to satisfy requests from web browsers.
The portal interface must be able to interpret the entered URL, filter malformed URLs and minimize security flaws.
Preconditions:
The user enters a URL into the browser. The request is sent to the server as HTTP request.
End Condition (success)
The content described by the URL is available and has been delivered as XHTML page.
End Condition (fail)
The content is not available and an error message has been delivered (XHTML).
Actors
Primary:
User (entering the URL into the browser's address line)
Description
A servlet accepts the request. The request will be tested for validity before it is passed to the next stage. (This is to reduce the danger of attacks using malformed URLs or special URL parameters).
The ContentTransformer class takes all the necessary steps from the URL to the output. In the 0.1 Stage, this is not much work. Later, there will be more work to do because a requested information may consist of multiple files which have to be transformed to get the result.
The dispatcher contacts the repository, usually directly. It is imaginable that this might possibly be a SOAP connection later (if this might make sense).
- 2.2.1. Retrieve a Resource
- 2.2.2. Store a Resource
These are use cases for the Content Repository. The following class diagram has been developped from the use cases below.
Resources, which are stored in files, are delivered on request. The request contains a path which uniquely describes the location of the resource.
Scope
The repository makes no assumptions about the content type, it delivers mime-type and file as stored.
Preconditions:
The mime-type of the file is identified by the system.
The resource is available
[The user is authorized to access the information.] > Stage 0.1
End Condition (success)
A file has been delivered to the requester.
End Condition (fail)
An error indicator is returned to the requester if the user is not authorized or the resource is not available.
Actors
Primary:
Web Portal: Requests one or more resources to assemble a web page.
Secondary:
Content Management Client: Downloads resource for editing.
Description
This use case demands a well performing file retrieval because it will probably be used for every page view once or multiple times.
Check the following sequence diagram to understand the process:
Extensions
1. The request may contain a version number of the document.
2. Other applications request information from the repository.
3. Other web sites request information from the repository.
Provide a facility to store resources with a minimal versioning system.
Preconditions:
A resource is available as file.
The user is authorized to change the information
End Condition (success)
The resource is stored successfully. Depending on input parameters, the version number has been changed and the old version has been archived.
End Condition (fail)
The system provides an error status if the user is not authorized or the resource type is not supported.
Actors
Primary:
Content Management Client Application
Secondary:
Web Portal (contributed content will be stored by the Web Portal)
Description
Check the following sequence diagram to understand the process:
Extensions
1. Content is provided by another application.
The Content Management Client is an application which runs on the desktop of the system editor or designer.
A requested resource shall be transferred to the (local) Content Management Client. The resource can be edited offline and then will be sent back to the repository.
Preconditions:
The path to the resource is known
The user has appropriate access rights.
The computer is connected to the same network like the repository
End Condition (success)
The resource is downloaded from the repository and available offline.
End Condition (fail)
The resource could not be downloaded.
Actors
Primary:
Content Editor
Trigger
Invoked by the user of the Content Management Client.
Description
The RepositoryClient class is an interface and can be used for access with either SOAP or direct local access.
Extensions
Layouts, Designs and Style Sheets are also resources.
The (edited) resource shall be transferred to the repository.
Preconditions:
1. The resource is available in the Content Management Client
2. The user is authorized to submit the edited resource to the repository
3. The computer is connected to the same network like the Repository
End Condition (success)
The resource has been uploaded and is updated.
End Condition (fail)
The resource could not be uploaded.
Actors
Primary:
Content Editor
Secondary:
Administrator
Trigger
Invoked by the Editor using the Content Management Client.
Description
The Content Management Client retrieves the file either from a remote source using SOAP or from a local repository. The RepositoryClient class is an interface for both access methods.
Extensions
Layouts, Designs and Style Sheets are also resources.