RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

--- "Hunsberger, Peter" <Pe...@STJUDE.ORG>
wrote:
> Alex Romayev <ro...@yahoo.com> asks:
> 
> > 
> > I have a registration form implemented using
> CForms
> > inside a CachingURICoplet.  At the end of
> registration
> > process (on confirm) I need to do the following in
> my
> > flowscript:
> > 
> > 1. Write results to the database
> > 2. Log the user with the new username/passoword to
> > portal
> > 
> > Is it possible to do this from flow?  Using
> sendPage()
> > for #2 would cause the page to be displayed inside
> my
> > coplet, since it's working inside coplet's
> context. 
> > What I need to do is something like:
> > 
> > portal.sendPage(do-login?username=...)
> > 
> > Is this possible?
> 
> I didn't see any answers go by, so even though I
> don't have any
> familiarity with this part of Cocoon I will offer up
> one possibility.
> If you're ok with JavaScript on the client can you
> just generate a page
> to the coplet that would force the parent document
> to reload?
> Essentially, a one line
> onLoad="parent.document.location='XYZ'" where
> 'XYZ' is generated as needed...

Sounds like this might work, I'm not sure what portal
does with JavaScript in coplets.  However, seems like
there should be a protocol for communitating from
coplets back to portal.  Maybe Carsten would know?

Thanks,
-Alex

RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

Just re-read my e-mail and it sounds like I'm
critisizing -- I'm not and sorry if it comes across
like I was :-) 

I think the portal is great, I'm just trying to figure
my way around it.  This is the issue I've struggled
with for a while, so if I am completely off in my
approach please tell me so ;-)

-Alex

--- Alex Romayev <ro...@yahoo.com> wrote:
> 
> --- Carsten Ziegeler <cz...@s-und-n.de> 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?
> 
> -Alex

RE: [portal] Transfering control from CachingURICoplet to portal

[Carsten Ziegeler <cz...@s-und-n.de>]

Alex Romayev wrote:
> 
> > > 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.
> 
> Oh, I think I see what you're saying, I would need to place 
> my own transformer as the last step in the portal pipeline.  
> I'm a bit slow today ;-)
> 
> Last question then, I can see how I would do this with 
> "<myspeciallink>" type of tag.  Any way you can see doing the 
> same from flow?
> 
No :( Perhaps someone with more knowledge about flow can help.

Carsten

RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

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

Oh, I think I see what you're saying, I would need to
place my own transformer as the last step in the
portal pipeline.  I'm a bit slow today ;-)

Last question then, I can see how I would do this with
"<myspeciallink>" type of tag.  Any way you can see
doing the same from flow?

Thanks,
-Alex

> 
> Carsten
> 

RE: [portal] Transfering control from CachingURICoplet to portal

[Carsten Ziegeler <cz...@s-und-n.de>]

 
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

RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

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

RE: [portal] Transfering control from CachingURICoplet to portal

[Carsten Ziegeler <cz...@s-und-n.de>]

Alex Romayev wrote:
> 
> --- Carsten Ziegeler <cz...@s-und-n.de> 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

RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

--- Carsten Ziegeler <cz...@s-und-n.de> 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?

-Alex

RE: [portal] Transfering control from CachingURICoplet to portal

[Carsten Ziegeler <cz...@s-und-n.de>]

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

RE: [portal] Transfering control from CachingURICoplet to portal

[Alex Romayev <ro...@yahoo.com>]

> Yes, this should work - you only have to take care 
> if you use
> java script that this doesn't interfere with java
> script that
> you might have in other coplets.
> 
> Carsten
> 

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.

-Alex

RE: [portal] Transfering control from CachingURICoplet to portal

[Carsten Ziegeler <cz...@s-und-n.de>]

Alex Romayev wrote:
> 
> --- "Hunsberger, Peter" <Pe...@STJUDE.ORG>
> wrote:
> > Alex Romayev <ro...@yahoo.com> asks:
> > 
> > > 
> > > I have a registration form implemented using
> > CForms
> > > inside a CachingURICoplet.  At the end of
> > registration
> > > process (on confirm) I need to do the following in
> > my
> > > flowscript:
> > > 
> > > 1. Write results to the database
> > > 2. Log the user with the new username/passoword to portal
> > > 
> > > Is it possible to do this from flow?  Using
> > sendPage()
> > > for #2 would cause the page to be displayed inside
> > my
> > > coplet, since it's working inside coplet's
> > context. 
> > > What I need to do is something like:
> > > 
> > > portal.sendPage(do-login?username=...)
> > > 
> > > Is this possible?
> > 
> > I didn't see any answers go by, so even though I don't have any 
> > familiarity with this part of Cocoon I will offer up one 
> possibility.
> > If you're ok with JavaScript on the client can you just generate a 
> > page to the coplet that would force the parent document to reload?
> > Essentially, a one line
> > onLoad="parent.document.location='XYZ'" where 'XYZ' is generated as 
> > needed...
> 
> Sounds like this might work, I'm not sure what portal does 
> with JavaScript in coplets.  However, seems like there should 
> be a protocol for communitating from coplets back to portal.  
> Maybe Carsten would know?
> 
Yes, this should work - you only have to take care  if you use
java script that this doesn't interfere with java script that
you might have in other coplets.

Carsten