RE: [J2] RE: Page Aggregation Design

["Weaver, Scott" <Sw...@rippe.com>]

> -----Original Message-----
> From: Tim Reilly [mailto:tim.reilly@consultant.com]
> Sent: Thursday, November 27, 2003 8:08 PM
> To: Jetspeed Developers List
> Subject: [J2] RE: Page Aggregation Design
...

> > Im wondering if we should force any structure on pages.
> > I have modeled pages so that they are all contained in a big page
> > bucket.
> 
> The big page bucket sounds good. I wrote a CMS system a couple of years
> ago
> that is still in use, but in retrospect I wish I'd decoupled the content
> more like you mention - along these lines:
> - content in a big bucket
> - an administrative tree/heirarchy to manage what's in the bucket (the
> administrator's view to the contents of the bucket for organizing -
> content
> only allowed in one node of the tree.)
> - another tree/heirarchy that is the site map (same content can appear in
> multiple nodes of this tree)
> 
> I'm not suggesting for J2 or maybe? Just commenting on the low coupling is
> probably better.

I am also a +1 on using the BPB (Big Page Bucket) for decoupling content from the final hierarchy.  Wow!  Look everybody we have a brand new acronym!

Regards,
*================================* 
| Scott T Weaver                 |
| <we...@apache.org>            | 
| Apache Jetspeed Portal Project |
| Apache Pluto Portlet Container |
*================================*

Re: [J2] RE: Page Aggregation Design

[Norman Schöneich <sc...@ecooperate.de>]

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