The new portal framework: questions and thoughts

[Alex Romayev <ro...@yahoo.com>]

I have been using portal-fw for a year now.  Overall,
I�m very happy with it.  It is well designed and
contains all of the critical features you need to
build a portal.  It�s been lacking some of the nice to
have's, but I�d rather have something to work with now
and wait for the new features to come out.  So I�ve
been looking forward to the enhancements.

I have a few questions/wish list items (directed at
Carsten):

1. Can you share with us the drivers for creating the
new portal?

 - Why are you not extending the current portal-fw?
 - Is it going to be compatible with portal-fw?
 - What are the differences/new features in the new
portal? 

2. Layout

I've noticed that you are changing the layout
configuration, which is definitely a welcome change. 
The column layout worked fine, but was even behind
WebLogic/WebSpere portals, which at least allow
spanning columns.  However, I find even the spanning
design very limiting.  

I prefer to use CSS2 and take advantage of DIV tags,
so that the coplets can be placed based on the
absolute and relative positioning.  For example, there
is a place on my site where I would like the coplets
to overlap, which is currently impossible.  

In general, I'd like to be able to leave "hooks" for
the CSS classes.  For example, I would like to be able
to break down a page into areas.  When a coplet is
"DIVed" in such area, it is "styled" according to the
area's rules.  For example, all coplets in the
"related-links" area have a light-gray background and
"Helvetica" font (defined in a CSS stylesheet, but
assigned by the portal config).  A single coplet,
however, should be able to override the style.

3. Application configuration

I am probably "misusing" the portal, but in any case,
this is what I do.  I like to treat each page on the
site as a portal page.  Why?  Well, I like to be very
user-friendly, so that rather than letting the users
customize the main page only, I want the to be able to
do this on every page.  Also, I�d like to have
"site-editor" coplets on every page, which allow
editing page content.  Clearly, these coplets should
only be available to the site editors.

So, here is my problem.  For a page to be a "portal"
page, it needs to have an application configuration in
the sitemap.  So if I have 200 pages, I need to have
200 page configurations in my sitemap, which is
unwieldy.  It would be great to be able to do one of
the two:
- Make application configuration work with patterns,
just like the rest of the sitemap
- Allow this to be externalized from the sitemap into
another configuration file

By the way, at the moment adding a new application
configuration requires to bounce Tomcat, which is bad
(every time I add a page, I have to restart!)

Thoughts?

Cheers,
-Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org