> > > 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.
Well, that would be a different requirement, wouldn't it? Let me see if I can describe it better: - "Search Results" coplets lives on "Search tab" and "Edit Search" coplet exists on a different page under "Preferences" tab. - I'd like to use CForms to implement "Edit Search" coplet, so that I can validate user entry. This now means I'm also using flow. - When I'm done editing my search, the coplet displays "Save search and view results" button. Because the coplets are on different tabs, I cannot "re-use" the same coplet window. At this point, my understanding is that I can use flow to do: search.save(); sendPage(???); So, the "???" seems to be the issue. It feels like there needs to be a flow exit point for CachingURICoplets. > > 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. Exactly! > > 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). I'm not sure I understand, are you suggesting just having an "out-of-portal" page for registration and not implement it inside a coplet? Thanks, -Alex > > HTH > Carsten >
