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/10/13 20:05:16 UTC
[shale] New dialog problem (with IFrame)
I have found an odd problem with my dialog and I'm not sure if its
Shale problem or a JSF problem.
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.
I'm going to file a Bugzilla ticket on this one along with a potential
fix but I wanted to get some feedback in the meantime.
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] New dialog problem (with IFrame)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 10/17/05, Craig McClanahan <cr...@apache.org> wrote:
> On 10/17/05, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
> > Some of the above might manifest into null outcomes, in which case, it
> > might make sense to not delegate to the default NavigationHandler
> > (even if the outcome is null). I believe a suitable approach here will
> > tend to be along these lines:
> >
> > * Delegate to DialogNavigationHandler when dialog is running.
> > * DialogNavigationHandler determines if the outcome was of any
> > consequence to this dialog.
>
>
> Hmm ... it's not clear how DialogNavigationHandler is supposed to make this
> determination. Wouldn't we need some special transition that dealt with a
> null outcome, and a way to say "stay where you are" in that case?
>
<snap/>
The determination can be made (as you allude to below) by ascertaining
whether the triggers have any transitions defined for them.
This is one of the things I've been meaning to add to Commons SCXML
(feedback about whether transitions were defined for a trigger,
whether any were followed -- since following is a function of what the
guard condition evaluated to, at that instance in time, if such a
condition exists etc.), so I'll do that this week. ATM, I think a
special transition may not be required, however, I need to dwell on
this (with examples).
> * Inconsequential triggers, then [since we have determined, do not
> > pertain to the dialog on hand], become suitable candidates to be
> > rewired to the default JSF NavigationHandler.
>
>
> I suppose one could generalize that to say any outcome (or, at least one
> returned by a view state) for which there is no defined transition should be
> deledgated.
>
<snap/>
I'd agree with the generalization as I don't see null outcome as a
special case w.r.t this discussion.
-Rahul
> If I have some code which we can stare at, I'll post some more later
> > in the week.
> >
> > -Rahul
> >
> > [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120
> >
> >
>
> Craig
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] New dialog problem (with IFrame)
Posted by Craig McClanahan <cr...@apache.org>.
On 10/17/05, Rahul Akolkar <ra...@gmail.com> wrote:
>
> On 10/14/05, Sean Schofield <se...@gmail.com> wrote:
> > Thanks. I have a patch but its at work and I'm working from home
> > today. So I will file the issue and patch on Monday.
> >
> <snip/>
>
> Thanks for attaching a patch to 37120 [1], in this case, it helped
> (me, atleast) to have code to look at :-) I tend to agree with your
> observation that this does not entirely address the problem.
For example, state charts notations tend to allow:
> * Event-less transitions (just guard conditions i.e. null event)
> * Self transitions (current state is transition target, requires
> re-entry i.e. calling onexit handler, followed by onentry)
> * Stay transitions (a transition that doesn't have a target, used
> primarily for executable content ontransition).
>
> Some of the above might manifest into null outcomes, in which case, it
> might make sense to not delegate to the default NavigationHandler
> (even if the outcome is null). I believe a suitable approach here will
> tend to be along these lines:
>
> * Delegate to DialogNavigationHandler when dialog is running.
> * DialogNavigationHandler determines if the outcome was of any
> consequence to this dialog.
Hmm ... it's not clear how DialogNavigationHandler is supposed to make this
determination. Wouldn't we need some special transition that dealt with a
null outcome, and a way to say "stay where you are" in that case?
* Inconsequential triggers, then [since we have determined, do not
> pertain to the dialog on hand], become suitable candidates to be
> rewired to the default JSF NavigationHandler.
I suppose one could generalize that to say any outcome (or, at least one
returned by a view state) for which there is no defined transition should be
deledgated.
If I have some code which we can stare at, I'll post some more later
> in the week.
>
> -Rahul
>
> [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120
>
>
> >
> > sean
> >
Craig
Re: [shale] New dialog problem (with IFrame)
Posted by Rahul Akolkar <ra...@gmail.com>.
On 10/14/05, Sean Schofield <se...@gmail.com> wrote:
> Thanks. I have a patch but its at work and I'm working from home
> today. So I will file the issue and patch on Monday.
>
<snip/>
Thanks for attaching a patch to 37120 [1], in this case, it helped
(me, atleast) to have code to look at :-) I tend to agree with your
observation that this does not entirely address the problem.
For example, state charts notations tend to allow:
* Event-less transitions (just guard conditions i.e. null event)
* Self transitions (current state is transition target, requires
re-entry i.e. calling onexit handler, followed by onentry)
* Stay transitions (a transition that doesn't have a target, used
primarily for executable content ontransition).
Some of the above might manifest into null outcomes, in which case, it
might make sense to not delegate to the default NavigationHandler
(even if the outcome is null). I believe a suitable approach here will
tend to be along these lines:
* Delegate to DialogNavigationHandler when dialog is running.
* DialogNavigationHandler determines if the outcome was of any
consequence to this dialog.
* Inconsequential triggers, then [since we have determined, do not
pertain to the dialog on hand], become suitable candidates to be
rewired to the default JSF NavigationHandler.
If I have some code which we can stare at, I'll post some more later
in the week.
-Rahul
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37120
>
> sean
>
> On 10/14/05, Craig McClanahan <cr...@apache.org> wrote:
> > On 10/13/05, Sean Schofield <se...@gmail.com> wrote:
> > >
> > > I have found an odd problem with my dialog and I'm not sure if its
> > > Shale problem or a JSF problem.
> > >
> > > 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.
> > >
> > > I'm going to file a Bugzilla ticket on this one along with a potential
> > > fix but I wanted to get some feedback in the meantime.
> >
> >
> > Sounds like you're on target about where the problem is ... i'll take a look
> > at the details when you file your issue.
> >
> > sean
> >
> >
> > Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] New dialog problem (with IFrame)
Posted by Sean Schofield <se...@gmail.com>.
Thanks. I have a patch but its at work and I'm working from home
today. So I will file the issue and patch on Monday.
sean
On 10/14/05, Craig McClanahan <cr...@apache.org> wrote:
> On 10/13/05, Sean Schofield <se...@gmail.com> wrote:
> >
> > I have found an odd problem with my dialog and I'm not sure if its
> > Shale problem or a JSF problem.
> >
> > 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.
> >
> > I'm going to file a Bugzilla ticket on this one along with a potential
> > fix but I wanted to get some feedback in the meantime.
>
>
> Sounds like you're on target about where the problem is ... i'll take a look
> at the details when you file your issue.
>
> sean
>
>
> Craig
>
>
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [shale] New dialog problem (with IFrame)
Posted by Craig McClanahan <cr...@apache.org>.
On 10/13/05, Sean Schofield <se...@gmail.com> wrote:
>
> I have found an odd problem with my dialog and I'm not sure if its
> Shale problem or a JSF problem.
>
> 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.
>
> I'm going to file a Bugzilla ticket on this one along with a potential
> fix but I wanted to get some feedback in the meantime.
Sounds like you're on target about where the problem is ... i'll take a look
at the details when you file your issue.
sean
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>