cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Portal work
Date Sun, 20 Nov 2005 18:20:54 GMT
Ralph Goers wrote:
> 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.
Yes, that's true - I'll recheck my statement about the "search layout"
functionality only called onces in the next days (just to be 100% sure).

> Sounds good to me.  Speaking of events, have you made it so that events 
> which are not convertable cannot be exposed in urls?
No, in this case the numbering scheme is used, but the numbers are
unique per session and not per page anymore. And in addition, I think
not all events that could be made convertable are already implememting
the interface.

> It looks like
> trunk is now using page labels by default, however they still appear to 
> be a request parameter.
Hmm, might be that trunk is using this as default, I'm not sure. But in
any case, yes a request parameter is still used.

 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.
Yes, please - I think this stuff should be made more general- Which
means it should work with all events and there shouldn't be any need for
the special page label components anymore.

> 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.  
The deployment stuff is "tool-less" - so, it's independent from the
tools. Now we could build some tools on top of it, if required. The
whole tools topic is currently not in my focus - I personally would like
to have a cool portal for development and build the tools on top.

> You might consider opening jira incidents as enhancement ideas where we 
> can bounce possible solutions around.
Yepp, I already started with adding one or two issues there. I'll try to
add more.


Carsten Ziegeler - Open Source Group, S&N AG

View raw message