Return-Path: 
 <dev-return-60423-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 45213 invoked from network); 4 May 2004 14:10:22 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 4 May 2004 14:10:22 -0000
Received: (qmail 6264 invoked by uid 500); 4 May 2004 14:10:14 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 6222 invoked by uid 500); 4 May 2004 14:10:13 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 6209 invoked from network); 4 May 2004 14:10:13 -0000
Received: from unknown (HELO web90104.mail.scd.yahoo.com) (66.218.94.75)
  by daedalus.apache.org with SMTP; 4 May 2004 14:10:13 -0000
Message-ID: <20040504141015.15146.qmail@web90104.mail.scd.yahoo.com>
Received: from [64.242.240.2] by web90104.mail.scd.yahoo.com via HTTP;
 Tue, 04 May 2004 07:10:15 PDT
Date: Tue, 4 May 2004 07:10:15 -0700 (PDT)
From: Alex Romayev <romayev@yahoo.com>
Subject: RE: [portal] Transfering control from CachingURICoplet to portal
To: dev@cocoon.apache.org
In-Reply-To: <OF4B17B098.DB007264-ONC1256E8A.00268B9B@sundn.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


> > 
> 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
>