cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [portal] Transfering control from CachingURICoplet to portal
Date Tue, 04 May 2004 14:29:01 GMT
 
Alex Romayev wrote:
> 
> > > 
> > 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?
> 
No, it's a coplet but the target of the link (or forms action) does not
go directly to the portal - it goes outsite, does whatever it has to do
and then redirects into the portal.

Carsten


Mime
View raw message