cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Portal work
Date Sat, 19 Nov 2005 11:12:32 GMT
Ralph Goers wrote:
> Carsten,
> I have looked at some of the work you have been doing (and it has been a 
> lot). I haven't had a chance to review the latest deployment stuff but I 
> do have some items for discussion.
It would be great if more than the two of us would be interested in the
portal stuff. But I think we are very near to a cleanup version which
I'll start to document around christmas (hopefully) and then others will
hopefully join in.

> 1. I have looked at some of the changes for the minimize/fullscreen 
> handling.  I'm OK with a lot of it, but I don't like the "search layout" 
> methods that recurse through their parents.  I'd prefer to do something 
> similar to what I did in 2.1 to manage the state while traversing the 
> subtree as I believe it is less expensive.
Hmm, I'm not sure but I think the current approach is more flexible. You
can expand (maximize) a portlet within any composite layout (tab,
column, row etc.). The "search layout" method is only called once when
the event is fired. It traverses the parents (which might be two or
three objects) and I think this is pretty fast. For example if you have
the use case that the tab is your root layout and it contains three
columns. Now the first column is "static" which means its always
visible. You can now maximize one of the portlets in the other two
columns. In this case, the tab is visible, the first column is rendered
unchanged and the remaining two columns are "replaced" by the maximized
I'm not sure if the solution from 2.1 can handle these use cases in a
generic way?

> 2. I was thinking more about the issue of writing out the layouts when 
> preferences are changed and I think the right way to handle that is to 
> not save the "dynamic" preferences with the layout.  I think we should 
> save them as something similar but not change the layout for that. I 
> think that that should handle the problem I mentioned to you where 
> layouts are dynamically generated.  WDYT?
Hmm, sorry, I can't follow you here. The preferences are part of the
coplet instances, so whenever the preferences change, the coplet
instances change while the layout remains the same.

> 3. I'm just curious on if you borrowed the deployment code or ended up 
> writing it all yourself.
I started borrowing the code from jetspeed-2 but while adapting the code
I found out that it contained some bugs and seemed to be incomplete
(undeployment). So I used that code as a frame and rewrote most parts of
it. For example, j2 uses listeners for deployment, we use our event
mechanism. There are still some parts containing the original code, but
I'll rewrite them as well to make them better fit.

> 4. Do you have any other features planned?
Hehe, I have dozens of ideas - as always - most of them are not concrete
I'll finish the deployment stuff hopefully before the ApacheCon. Then
you can deploy jsr 168 portlets, wsrp portlets, Cocoon pipeline based
stuff etc. by just droping a an archive or a configuration file into the
deploy directory.
The transformers need a redesign as well - we have several overlapping
transformers - so cleaning them up is a must.
Finally I would like to rewrite the profile handling. One of the
original ideas was to a profile that consists of several profiles which
are linked (through the link layout). For example, you will have a
portal page where some portlets are "static" which means they are always
available for all users and only one area is customizable by the user.
With linked layouts you end up having one static layout shared by all
users and one customizable layout for each user. This would reduce load
time amd memory usage.

But for most things I don't have any clear designs etc. - I've just some
ideas that I start to implement/discuss when I have time to.

Ah yes, and there is of course all this ajax stuff - I would like to
have a portal which has the same nice features like windows live with
drag and drop and so on...but I fear this will take some time to
implement correctly...

Carsten Ziegeler - Open Source Group, S&N AG

View raw message