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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
