Hi, I have some questions regarding the portal - primary how you can use it in a more stateless way.
The reasons for this are the following: 1. It should be cached as much as possible by Squid (reverse Proxy) - Images, CSS, JS, whole portal pages, ... 2. URLs should be readable, bookmarkable and always refer to the same content 3. We don't want our users to actively configure the portal but we want the possibility to (de-)activate or exchange Coplets based on the User's data in our (own) Usermanagement 4. Channels (source for portal pages/tabs) and boxes (source for coplets) are defined in an CMS -> dynamic changes to the portal! Here are some concrete questions: * How can I pass XSL parameters to coplets, depending on the URI, the currently active channel or some other information? This is needed e.g. for styling within coplets which are depending on data which is defined for the channel. In our current implementation this is transported using the user session which is not where it should be IMHO. * Is it really required to aggregate all channels within the CMS and transform them into the tab-layout which is required by the portal? To me it seems that this aggregation is a bottle-neck which doesn't provide any benefit, since all content but the active channel (or tab) is discarded again when the portal generator has been run. * To satisfy the conflicting statements 1 & 3 from above, is it feasable to leave static coplets on the portal layout and display iframes for the dynamic ones which are then evaluated in an extra request? This way only the personalized parts of the portal are served by Tomcat/Cocoon and all static parts of the portal can be served directly from the Squid. * I read about the browser-back-button problems regarding the event ids. Is there a solution available (we are using Cocoon 2.1.9)? Are there any other things which might be of importance for us in this context? Thanks in advance, Andreas
