Alex Romayev wrote: > > --- Carsten Ziegeler <[EMAIL PROTECTED]> wrote: > > Alex Romayev wrote: > > > > > > Carsten, is there another way of doing this, say > > directly > > > from flow? I really don't see this as a one-off > > case, where > > > a client JavaScript workaround is good enough. > > > > > Hmm, I think not - you have to do a global redirect there > and this is > > imho not possible with the portal. > > > > Carsten > > > > Seems like a fairly common use case though, registration is > one example. A couple of others: > > - "Edit saved search": on submit, write the edited search to > the database, open another page which would run the search > and display the results. > - "Edit user preferences", on submit save info to the > database and open a portal page reflecting the new preferences. > > Is there another way of implementing these types of coplets, > other than CachingURICoplet, which work better within portal? > Hmm, I think you can simply use flow for your two "Edit" use cases. But then this requires that you display the "result" in a coplet and not instead of the whole portal page. So, for example the search result will be displayed in the coplet. This should work.
For thinks like registration coplets etc., you have to go another way. The main problem, if you're using the CachingURICoplet and the provided pipeline, is that all links (and form actions) inside the coplet are rewritten to point to the portal. So you can only influence the contents of the coplet but not the whole page. If you influence the way, the links (form actions) are generated, you can do what you want. So, for example, you could generate a <myspeciallink href="registration-pipeline"/> and replace this tag lateron on the "portal" pipeline to a <a href="registration-pipeline"/>. So, when the user clicks the link, the request is not targetting the portal but a different pipeline. You can do there whatever you want and finally redirect to the portal (if wanted). HTH Carsten
