cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: Portal work
Date Sat, 19 Nov 2005 18:40:14 GMT


Carsten Ziegeler wrote:

>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.
>  
>
Yeah, it would.  I'm not sure why this is the case. I find the portal to 
be a great way to build any website, whether it needs the features of a 
portal or not.

>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
>portlet.
>I'm not sure if the solution from 2.1 can handle these use cases in a
>generic way?
>  
>
You make some good points here and the behavior is certainly correct. It 
seemed to me that the search layout was called for each layout as it was 
being processed, but I could be wrong. The solution I added in 2.1 was 
to essentially have the AspectRenderer and RendererContext keep track of 
the state of the portal as they traverse downwards.  I think the end 
effect could be the same, it is just the manner in which the determining 
the state of the parent(s) that is different.

>  
>
>>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.
>  
>
I don't know why I keep forgetting and saying that the preferences are 
stored in the layout.  Yes, of course they are in the instance data 
which isn't as big of a problem.

>  
>
>>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.
>  
>
Sounds good to me.  Speaking of events, have you made it so that events 
which are not convertable cannot be exposed in urls?  It looks like 
trunk is now using page labels by default, however they still appear to 
be a request parameter We had spoken about moving the page labels into 
the url path. If we know that only convertable events are coming in from 
the browser I can clean up the page label stuff some and I can look into 
moving the page labels into the path if you would like.

>  
>
>>4. Do you have any other features planned?
>>
>>    
>>
>Hehe, I have dozens of ideas - as always - most of them are not concrete
>yet.
>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.
>  
>
How will this fit in with the portal tools?  I looked at that when it 
was first submitted but I'm not using that code at all in my sites.  
However, I know that I am going to need to get into more of the portal 
management aspects pretty soon.

>The transformers need a redesign as well - we have several overlapping
>transformers - so cleaning them up is a must.
>  
>
I'd also like to make the PortalGenerator and the Transformers 
ThreadSafe components (i.e. - not poolable). Eventually, all the Cocoon 
pipeline components should be also. Right now it looks like there is 
only a ThreadSafe version of the FileGenerator in trunk.

>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.
>  
>
This sounds like a good idea and is something I'm sure I could use.

>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.
>  
>
You might consider opening jira incidents as enhancement ideas where we 
can bounce possible solutions around.

>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...
>  
>
Yeah, the Ajax stuff has become a very hot topic.  I have guys dying for 
2.2 so they can have Ajax in the portal.  Unfortunately, I haven't spent 
a lot of time working with Cocoon Forms and know even less about Ajax.

Ralph

Mime
View raw message