You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sean Schofield <se...@gmail.com> on 2005/09/13 22:30:11 UTC
Fwd: [shale] Weird dialog behavior in IFrame
Sorry sent to myfaces-dev again.
sean
---------- Forwarded message ----------
From: Sean Schofield <se...@gmail.com>
Date: Sep 13, 2005 4:21 PM
Subject: [shale] Weird dialog behavior in IFrame
To: MyFaces Development <de...@myfaces.apache.org>
I'm experiencing some weird behavior in a shale dialog that uses an
iframe. One of the screens in the dialog has an iframe that contains
search results. There is also a search button in addition to the
usual "navigation" buttons (prev, next, cancel, etc.) The search
button is supposed to refine the contents of the search results based
on a search criteria.
If the search button does not specify an action that corresponds to a
transition in the dialog-config.xml then the search results are loaded
into the entire dialog page (instead of just inside the iframe.) The
work around is to specify a value for action on my search button and
then add a global transition for the dialog question.
Do you have an idea what the problem is? Is it that we're running in
an iframe or is this just b/c the navigation handler is getting
confused? or both?
Regards,
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Weird dialog behavior in IFrame
Posted by Sean Schofield <se...@gmail.com>.
Yeah its kind of related. It appears the DialogNavigationHandler
assumes that since a dialog is in progress that *any* navigation
outcome should be handled by it until the dialog is over with.
It seems the problem of having a dialog run in Tiles (or Iframe) will
occur with even one dialog. DialogNavigationHandler just takes over
b/c it thinks everything is part of a dialog.
I have an idea on this that I haven't fully explored but I'll toss it
out there since you are thinking about this problem. What if we had
special renderers associated with a <s:commandLink> and
<s:commandButton>. The renderer could automatically add "dialog:" to
the action name. This would also make things a little more consistent
since now the user has to use "dialog:foo" to kick off the dialog but
then inside the dialog, you don't use this convention. The
inconsistency is a little confusing.
This solution does not address multiple dialogs but it does allow you
to have JSF links that are not dialog links and therefore you could
probably improve DialogNavigationHandler to delegate actions that do
not begin with the "dialog" prefix.
A variation on this solution might also be possible for multiple
dialogs, but like you, I am still working on what might be a good
solution for that.
sean
On 9/14/05, Craig McClanahan <cr...@gmail.com> wrote:
> This sounds like it might be related to the overall (current) limitation of
> one active dialog per session, instead of one per window. Are you trying to
> do that? (Note that making a result from a submit to a page that is part of
> an existing dialog will likely trigger this).
>
> Robust support for multiple dialogs is on my list of things to see cleaned
> up for a 1.0.1 release ... once I get home from Beijing (tomorrow) and try
> to get 1.0.0 out the door.
>
> Craig
>
> On 9/13/05, Sean Schofield <se...@gmail.com> wrote:
> > Sorry sent to myfaces-dev again.
> >
> > sean
> >
> > ---------- Forwarded message ----------
> > Wrom:
> NVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHS
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] Weird dialog behavior in IFrame
Posted by Craig McClanahan <cr...@gmail.com>.
This sounds like it might be related to the overall (current) limitation of
one active dialog per session, instead of one per window. Are you trying to
do that? (Note that making a result from a submit to a page that is part of
an existing dialog will likely trigger this).
Robust support for multiple dialogs is on my list of things to see cleaned
up for a 1.0.1 release ... once I get home from Beijing (tomorrow) and try
to get 1.0.0 out the door.
Craig
On 9/13/05, Sean Schofield <se...@gmail.com> wrote:
>
> Sorry sent to myfaces-dev again.
>
> sean
>
> ---------- Forwarded message ----------
> Wrom:
> NVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAAFXISHJEXXIMQZUIVOTQNQEMSFDULHPQQWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVRESKPNKMBIPBARHDMNNSKVFVWRKJVZCMHVIBGDADRZFSQHYUCDDJBLVLMHAALPTCXLYRWTQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHS