portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Schöneich <schoene...@ecooperate.de>
Subject Re: [J2] RE: Page Aggregation Design
Date Mon, 01 Dec 2003 21:29:12 GMT
I am playing with Jetspeed since project started. It was nice.

In a real-world customer project, we needed a customization and 
content-management functionality for Jetspeed 1.

We integrated it in Jetspeed 1 and played a lot with page and portlet 
aggregation (it's not based on psml, the layout is stored completly in a 
self-defined table-structure into a DB). But we are not final yet, so 
I'm very interesting in the new page aggregation design.

Maybe I can help in some way.

 From our customer perspective, I can see the following requirements, 
that affected the page aggregation module/design.

1. they want to create pages (from an administritive manner)
2. they want to modify these pages (add portlets, remove portlets, add 
menus, change images... - all things on a page in our model are treated 
as portlets, we implemented "based portlets" like image portlet, link 
portlet, menu/navigation portlet, html portlet, text portlet, article 
portlet and "container portlets" - a "container portlet" aggregates 
"base portlets" (or container portlets) and can be reused for different 
pages (think of them as templates). the page itself is a portlet 
container. a container has layout information and is constructed with a 
number of rows and cols (and the sizes for the columns). With this 
paradigm, you are able to construct every page layout (at least I can't 
image a page which couldn't be aggregated by this paradigm)
3. they want a workflow-process for these pages (at least a two-stage 
role-based process, e.g. role "editor" designs and creates pages, and a 
role "publisher" reviews these pages and publishes them, (maybe a 
"approval"-role would also make sense, which approve these pages). (in 
our implementation, you can accept changes for the whole page or only 
for part of them and give a feedback to the originator of these changes) 
3a. they want different environments for production and editor 
environment. one public/production environment and one 
editor/development environment. (there have to be at least two distinct 
servers (portals) - maybe it's sufficient if there are more db-servers, 
also maybe they have to be more servers for the different languages - 
see 6.)
3b. they want to view history of the pages and maybe make previous (old) 
versions back to the the current / public version (undo / rollback 
behaviour)
4. this tends to result in versioning pages and its parts (and a 
workflow control mechanism).
5. they want to construct multilanguage pages or whole web-sites (in an 
easy to use manner). e.g. if you change the text of "german language 
portlet", the portal, pages or portlets for other languages also have to 
be changed (users should be at least asked, if they want to change these 
pages, too). 
 From our customers perspective it is not required, that a german site 
e.g. looks completly different from an english site. most of the time 
they want same site structure (because of corporate identity), only 
content in different languages. the language is often controled by 
company-branch in that country, so they often want a server located 
there and controlled by them). the portal has to be multi-client 
(mandator) capable.
6. some pages must marked as user or role customizable, so user can add, 
remove, moving portlets and change layout (from 2 to 3 columns e.g.). 
this results in question like: What happens, if an admistrator change 
the page, will it be reflected to the user pages ? If it reflects to the 
users pages, will it destroy the individuals settings of the user ?
7. administrator must have the opputrinity to mark page fragments as 
"locked" or "fixed", so these fragments could not changed, removed or 
moved by users (e.g. the corporate identity image on top of the page).

thanks
Norman Schöneich


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message