RE: [portal] Transfering control from CachingURICoplet to portal
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 wrote: --- Carsten Ziegeler [EMAIL PROTECTED] 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
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
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
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
--- Hunsberger, Peter [EMAIL PROTECTED] wrote: Alex Romayev [EMAIL PROTECTED] 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 wrote: --- Hunsberger, Peter [EMAIL PROTECTED] wrote: Alex Romayev [EMAIL PROTECTED] 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
RE: [portal] Transfering control from CachingURICoplet to portal
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
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
--- Carsten Ziegeler [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote: --- Carsten Ziegeler [EMAIL PROTECTED] 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
Alex Romayev [EMAIL PROTECTED] 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...
