[shale] IFrame does not work properly inside Shale dialog

• Key: SHALE-10
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: sean schofield
• Component/s: Dialog
• Fix Version/s: 1.0.4

Environment

Operating System: other
Platform: Other

Description

In my dialog I have a search button which allows the user to do a
search. The search results appear in an iframe within the dialog. I
am using Tiles but I don't think Tiles is an issue. We're also
talking about only one dialog at a time (so its not the multiple
dialog problem.)

Anyways the search results are sortable using <t:commandSortHeader> in
MyFaces. The problem is that when I click on the header, the entire
dialog is reloaded inside the IFrame. I believe this is because of
DialogNavigationHandler. There is code in there that assumes a null
outcome should be handled by the handler instead of delegated to the
decorated handler.

Comments

[sean schofield]

Created an attachment (id=16719)
[shale] Patches 37120

The problem seems to stem from the fact that DialogNavigationHandler is
handling all navigation once a dialog is underway. My patch does not entirely
address this problem but it does allow null navigation outcomes to be handled
by the decorated handler. This should produce the same result as before but it
will allow command buttons and links inside of IFrames to work properly.

[Rahul Akolkar]

Would it be possible to attach a stripped down war file or some of the source
artifacts related to the Shale dialog? I was going to reproduce this (or a
similar scenario) based on your description, but thought I'd ask before I
attempt any of that. Thanks!

[Craig McClanahan]

I suspect that this issue is a specific subcase of the general issue identified
by Bugzilla issue:

  http://issues.apache.org/bugzilla/show_bug.cgi?id=35066

However, the proposed solution here (elminate the standard handling of a null
outcome, which typically means "redisplay the same page") seems like it would
break a very large number of standard use cases. We need an overall approach
that deals with multiple simultaneous dialogs, *without* disabling the kinds of
behaviors that JSF developers are used to.

Probably useful to archive this approach in Bugzilla as well:

http://people.apache.org/~rahul/shale/dialog-delegation/

[Craig McClanahan]

To be addressed, along with 35066, in a point release subsequent to 1.0.0 that
addresses support for multiple simultaneously active dialogs.

[Craig McClanahan]

The current implementation includes the code Sean suggested to delegate handling of null values, and seems to have no ill effects, so I'm declaring this one as fixed.