Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <20040526193342.61398.qmail@web90103.mail.scd.yahoo.com>
Date: Wed, 26 May 2004 12:33:42 -0700 (PDT)
From: Alex Romayev <romayev@yahoo.com>
Subject: RE: [portal] Implementing Login coplet with CForms
To: dev@cocoon.apache.org
In-Reply-To: <OF0D855CB9.98468D95-ONC1256EA0.0034A379@sundn.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


--- Carsten Ziegeler <cziegeler@s-und-n.de> wrote:
> Alex Romayev wrote:
> > 
> > Ok, I'm a bit confused and not sure where to
> start.
> > 
> > This is what I'm trying to achieve.  I'd like to
> replace 
> > portal login form with CForm (using actions, not
> flow), to 
> > use its validation.  So the most interesting use
> case is:
> > 
> > 1. User does not enter username/password 2. The
> form is 
> > re-displayed with error messages 3. User enters
> correct 
> > username/password 4. The form calls do-login url,
> which then 
> > redirects to "portal" using authentication-fw.
> > 
> > Questions.
> > 
> > 1. Initially I assumed that if I just configured
> the coplet 
> > with handleParameters = true, CForms would have
> access to 
> > request parameters.  Not true.  Does this mean
> that 
> > handleParameters only works in conjunction with 
> > html-event-link transformer?
> > 
> Yes (unfortunately I think).

:-(  I actually find that having request parameters
directly available to coplets would simplify things
quite a bit in general.  However, come to think of it,
it probably wouldn't have helped my case, since I
would still need to do the redirect to do-login inside
my portlet pipeline. 

> 
> > 2. I switched to using html-even-link trasformer 
> > configuration.  Now could get through steps 1-3. 
> > However, in step 4, calling do-login results in
> portal being 
> > displayed *inside* my login coplet.  I've looked
> at 
> > HTMLEventLinkTransformer code, and it makes
> external = 
> > true/false distinction only for links, not for
> forms.  At the 
> > same time, event if it did, I don't see how it
> would work in 
> > my case anyway, since in step
> > 2 I would need to have external=true and in step
> 4, external= 
> > false for the same form?  Am I making sense here
> at all?
> > 
> Yes, makes sense to me :)
> 
> > Seems like I'm just missing some basic
> information, but ATM 
> > completely lost :-)
> > 
> Hmm, no the problem is that your call to do-login
> happens inside
> the coplet. So it's the content of your coplet that
> you change
> with the call - not the whole portal itself.
> I'm not sure if this is possible at all - at least I
> don't see
> a solution right now (which doesn't mean that there
> isn't).

I've been thinking about this for a while, let me see
if I can collect my thoughts and make a separate post
on this topic.

Thanks,
-Alex

> For the current login coplet in the demo portal we
> used a "hack".
> The form is not processed by the coplet itself but
> directly in
> the sitemap *before* the portal is rendered. This
> allows us
> to do what you need. You could do the evaluation
> before the
> portal is rendered and put some error messages in
> the session
> and retrieve it later on when your coplet is
> rendered.
> 
> HTH
> Carsten
>