Fwd: Re: The new portal framework: questions and thoughts

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

Carsten,

You've answered section #1 and Volker section #2,
but there is also section #3 on Application
Configuration(please see below).  Could you take a
look at it as this is one of my bigger concerns.

Thanks,
-Alex

> --- Alex Romayev <ro...@yahoo.com> wrote:
> > 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
> > 
> 
> 


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

RE: Re: The new portal framework: questions and thoughts

[Carsten Ziegeler <cz...@s-und-n.de>]

Alex Romayev wrote:
> Carsten,
> 
> You've answered section #1 and Volker section #2,
> but there is also section #3 on Application
> Configuration(please see below).  Could you take a
> look at it as this is one of my bigger concerns.
> 
Ok, let's see:

> 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
> 
This is possible. One of the goals of the portal was to 
separate concerns and split logic in many areas. So, there
is now a component that builds the current profile,
the ProfileManager. There is one implementation using
the authentication framework and the application configuration.
But I think in your case, it should be simple
to write a different implementation of the ProfileManager
which does exactly what you need.

> 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!)

I thought I had fixed this some weeks ago. Are you using
latest CVS?

Carsten


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