design question

[Rafael Nami <ra...@gmail.com>]

Good afternoon everyone.
Our team is having doubts about a usecase needed in our app.
We have a page, that calls a popup that searches some stuff to add,
and adds this stuff to the parent page. The parent page have to be
responsible to save everything. What is the best practice?
Put the entire backing bean in session scope? Use x:saveState in both
parent and popup pages to save the backing bean?

Thanks

Rafael mauricio Nami

Re: design question

[Nebojsa Vasiljevic <ne...@sw4i.com>]

>> showModalDialog() is great feature, it would be great if Mozilla introduce this or similar feature.
>> 
>> Nebojsa
>> 
> No need, you can target _new in mozilla and have a timer refocus
> the window every few seconds, Mozilla does not loose the focus
> that way...
> This however does not work in IE due to formerly described
> reasons.

showModalDialog() is match better:

1.  showModalDilalog() will return when you close dialog, not before. Yo can write:
var retval = window.showModalDialog(...);
if(retval == 'OK')  return true;
else return false;

2. While modal dialog is opend, there is no way to do anything in parent window, like in any application modal dialog in Windows.

3. There is single item in taskbar and ALT-tab list.

4. In a modal dialog you can only click on links and buttons. No other way to go back and forward or reload.

It is jutst what we need for forms in Web appplications. 

The big problem is that only IE has this feature. 

Nebojsa
   

Re: design question

[Sean Schofield <se...@gmail.com>]

We use modal dialogs in IE since the client runs only IE.  This is one
rare instance where Microsoft actually got it right and Mozilla and
the standards are behind the times.

We use Shale dialogs to keep track of things between dialogs screens
(they introduce a generic #{dialog.data} that you can dump stuff in.) 
It works well.  We've had to add some steps to our dialogs that
"import" data from javascript when the dialog kicks off and "exports"
it back to javascript when it closes.  You can use the return obj to
pass back what you need.

It depends on what your underlying page needs of the info.  Our
underlying pages are not JSF and require dynamic update of HTML so the
javascript solutions works for us.

sean


On 10/12/05, Werner Punz <we...@gmx.at> wrote:
> Nebojsa Vasiljevic wrote:
> >>>Have you tried showModalDialog() from JavaScript?
> >>>
> >>>Nebojsa
> >>>
> >>
> >>Ah thanks for pointing that out, I have to admint I did not know that
> >>one and googling pushed me to the timer focus solution, which did not
> >>work out on IE.
> >>
> >>Werner
> >
> >
> > There is anather important trick.
> > When you click to any link, explorer will open new widow.
> > To avoid this, use a frameset with a single frame.
> >
> > showModalDialog() is great feature, it would be great if Mozilla introduce this or similar feature.
> >
> > Nebojsa
> >
> No need, you can target _new in mozilla and have a timer refocus
> the window every few seconds, Mozilla does not loose the focus
> that way...
> This however does not work in IE due to formerly described
> reasons.
>
>
>

Re: design question

[Werner Punz <we...@gmx.at>]

Nebojsa Vasiljevic wrote:
>>>Have you tried showModalDialog() from JavaScript?
>>>
>>>Nebojsa
>>>
>>
>>Ah thanks for pointing that out, I have to admint I did not know that
>>one and googling pushed me to the timer focus solution, which did not
>>work out on IE.
>>
>>Werner
> 
> 
> There is anather important trick. 
> When you click to any link, explorer will open new widow. 
> To avoid this, use a frameset with a single frame.
> 
> showModalDialog() is great feature, it would be great if Mozilla introduce this or similar feature.
> 
> Nebojsa
> 
No need, you can target _new in mozilla and have a timer refocus
the window every few seconds, Mozilla does not loose the focus
that way...
This however does not work in IE due to formerly described
reasons.

Re: design question

[Nebojsa Vasiljevic <ne...@sw4i.com>]

>> 
>> Have you tried showModalDialog() from JavaScript?
>> 
>> Nebojsa
>> 
> Ah thanks for pointing that out, I have to admint I did not know that
> one and googling pushed me to the timer focus solution, which did not
> work out on IE.
> 
> Werner

There is anather important trick. 
When you click to any link, explorer will open new widow. 
To avoid this, use a frameset with a single frame.

showModalDialog() is great feature, it would be great if Mozilla introduce this or similar feature.

Nebojsa

Re: design question

[Werner Punz <we...@gmx.at>]

Nebojsa Vasiljevic wrote:
>>>Modal dialogs in IE 5.5+ are very good solution, but it is restricted to IE. We use it in an classic bussines appli cation.
>>>
>>
>>How do you do modal forms in IE 5.5+ I could not pull that off in my
>>last app. A simple modal message window is no problem, but having a
>>modal form was rather problematic, because every time I pushed the
>>window into the front I lost focus.
>>
> 
> 
> Have you tried showModalDialog() from JavaScript?
> 
> Nebojsa
> 
Ah thanks for pointing that out, I have to admint I did not know that
one and googling pushed me to the timer focus solution, which did not
work out on IE.

Werner

Re: design question

[Nebojsa Vasiljevic <ne...@sw4i.com>]

>> Modal dialogs in IE 5.5+ are very good solution, but it is restricted to IE. We use it in an classic bussines appli cation.
>> 
> How do you do modal forms in IE 5.5+ I could not pull that off in my
> last app. A simple modal message window is no problem, but having a
> modal form was rather problematic, because every time I pushed the
> window into the front I lost focus.
> 

Have you tried showModalDialog() from JavaScript?

Nebojsa

Re: design question

[Werner Punz <we...@gmx.at>]

Nebojsa Vasiljevic wrote:
> Modal dialogs in IE 5.5+ are very good solution, but it is restricted to IE. We use it in an classic bussines appli cation.
> 
How do you do modal forms in IE 5.5+ I could not pull that off in my
last app. A simple modal message window is no problem, but having a
modal form was rather problematic, because every time I pushed the
window into the front I lost focus.


> If you want easy programming in JSF, use session beans. But there are issues with session states. 
> Decision is on you.
> 
Well there are other possibilities than session beans ;-)
but session beans is a viable approach for many things as well.

Re: design question

[Nebojsa Vasiljevic <ne...@sw4i.com>]

Modal dialogs in IE 5.5+ are very good solution, but it is restricted to IE. We use it in an classic bussines appli cation.

If you want easy programming in JSF, use session beans. But there are issues with session states. 
Decision is on you.

Nebojsa

----- Original Message ----- 
From: "Werner Punz" <we...@gmx.at>
To: <us...@myfaces.apache.org>
Sent: Tuesday, October 11, 2005 11:26 PM
Subject: Re: design question


> Rafael Nami wrote:
>> Good afternoon everyone.
>> Our team is having doubts about a usecase needed in our app.
>> We have a page, that calls a popup that searches some stuff to add,
>> and adds this stuff to the parent page. The parent page have to be
>> responsible to save everything. What is the best practice?
>> Put the entire backing bean in session scope? Use x:saveState in both
>> parent and popup pages to save the backing bean?
>> 
> Best practice is not to use popups at all, you might run into loads
> of trouble that way, the problem with popups is, there
> is no dedicated modal dialog mechanism in browsers, I once
> tried a solution which worked on Mozilla (setting the window into the front)
> which caused me to lose focus in IE.
> 
> The best approach to this issue so far is the one jenia4faces uses
> by simulating modal popups with iframes.
> That way you are pretty safe of all issues related to popups (double window
> problem, pending not closed popups etc...).
> 
> As for the rest, using saveState for state saving in the parent and the popup works
> fine, or at least should (I had such a situation once, where I could not use it
> due to heavy ajax usage outside of the jsf scope)
> 
> Also you might check out various dialog systems like seam (seam seems to be tailored
> exactly for such a situation) or shale dialog.
> 
> ---
> As for your stuff, you basically describe a classical master detail problem...
> the last time I solved it by using a popup (I should beat myself for that) for the input
> which dumped the thing into the session (savestate did not work due to heavy ajaxing)
> and then I was rerendering the master part of the form with an ajax request
> on html level, but believe me implementing this is not a walk in the park
> it did cost me almost two days fighting as usual with IE most of the time until it ran
> to a satisfying degree.
> If I had more time I probbably would have opted for a cleaner solution than I did.
> 
> 
> 
>

Re: design question

[Werner Punz <we...@gmx.at>]

Rafael Nami wrote:
> Good afternoon everyone.
> Our team is having doubts about a usecase needed in our app.
> We have a page, that calls a popup that searches some stuff to add,
> and adds this stuff to the parent page. The parent page have to be
> responsible to save everything. What is the best practice?
> Put the entire backing bean in session scope? Use x:saveState in both
> parent and popup pages to save the backing bean?
> 
Best practice is not to use popups at all, you might run into loads
of trouble that way, the problem with popups is, there
is no dedicated modal dialog mechanism in browsers, I once
tried a solution which worked on Mozilla (setting the window into the front)
which caused me to lose focus in IE.

The best approach to this issue so far is the one jenia4faces uses
by simulating modal popups with iframes.
That way you are pretty safe of all issues related to popups (double window
problem, pending not closed popups etc...).

As for the rest, using saveState for state saving in the parent and the popup works
fine, or at least should (I had such a situation once, where I could not use it
due to heavy ajax usage outside of the jsf scope)

Also you might check out various dialog systems like seam (seam seems to be tailored
exactly for such a situation) or shale dialog.

---
As for your stuff, you basically describe a classical master detail problem...
the last time I solved it by using a popup (I should beat myself for that) for the input
which dumped the thing into the session (savestate did not work due to heavy ajaxing)
and then I was rerendering the master part of the form with an ajax request
on html level, but believe me implementing this is not a walk in the park
it did cost me almost two days fighting as usual with IE most of the time until it ran
to a satisfying degree.
If I had more time I probbably would have opted for a cleaner solution than I did.