You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org> on 2009/02/13 19:13:02 UTC

[jira] Commented: (TRINIDAD-328) Handle Dialogs in Portal

    [ https://issues.apache.org/jira/browse/TRINIDAD-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673332#action_12673332 ] 

Scott O'Bryan commented on TRINIDAD-328:
----------------------------------------

There have actually been some changes to this framework which may make fixing this issue possible.  Likely it will only be avaialble as an external window in the portlet 2.0 timeframe, but we can possibly support an *in place* dialog scenario for portlet 1.0..

> Handle Dialogs in Portal
> ------------------------
>
>                 Key: TRINIDAD-328
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-328
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Portlet
>    Affects Versions: 1.0.1-incubating-core-SNAPSHOT
>         Environment: JSR-168
>            Reporter: Scott O'Bryan
>
> Work has been done to abstract some of the filter-functionality into Configurators (a container-agnostic service based system which can duplicate some of the functionality).  The current dialog framework is dependant on the filter and will actually execute faces twice during the close of the dialog.  The filter does this by re-executing the filter chain, but the Portlet environment has no way of re-executing the lifecycle, so an alternative approach must be found.
> Issuing a redirect is not possible in this scenario because the request comes in with post parameters on it, and generating a GET url to represent this data could quite possibly be too large. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.