cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Romayev <roma...@yahoo.com>
Subject The new portal framework: questions and thoughts
Date Wed, 02 Jul 2003 14:16:40 GMT
Hi,

I've posted this on the users list a few days ago, but
got no replies, so I'm re-posing it here, especially
hoping to get Carsten's attention.

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



Mime
View raw message