Struts: popups, this can't be right.

Dave · Aug 9, 2004

I've been slowly learning struts in my spare time and I've been trying
to do a simple popup. I wanted to display some data along with an edit
button. If you click on the edit button you get a new window on which
the values are editable. When you click save of the new window, it
should disappear and the editted values should appear in the original
window.

It was easy enough creating the 2 views. It was even easy to get the
edit button to bring up the new window. It didn't work from that point
though. The Save button painted the original view (with the new values)
into the popup window while leaving the original window stiff alive in
the background.

The solution I found has two problems for me.

1 - it works only in IE.

2 - It feels very un struts like. Navigation is coded in the page
instead of in struts-config.xml.

Here are the views. First the main page:

<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>
<jsp:useBean id="DataForm"
scope="session"
type=
"com.flashline.strutsexample.popup.forms.DataForm" />

<html:html locale="true">
<head>
<html:base/>
</head>
<body bgcolor="white" OnLoad="window.name='MainWindow';">
Data

<html:form action="Edit" target="Popup" >

Str1 : <bean:write name="DataForm" property="str1"/>
Str2 : <bean:write name="DataForm" property="str2"/>
<html:submit styleClass="button" value="Edit" />

</html:form>

</body>
</html:html>

The javascript in the onload attribute of the body tag gives the main
window a name that can be targeted by the edit window.

The target attribute of the form tag causes the results of the submit to
appear in a new window (or reused window if the popup window already
exists).

Now the edit view:

<%@ taglib uri="/tags/struts-bean" prefix="bean" %>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<%@ taglib uri="/tags/struts-logic" prefix="logic" %>

<html:html locale="true">

<head>
<html:base/>
</head>

<body bgcolor="white">
Edit

<html:form action="Data"
onsubmit="window.close();"
target="MainWindow">

<html:text property="str1"/>
<html:text property="str2"/>
<html:submit styleClass="button" value="Save" />

</html:form>

</body>
</html:html>

The javascript in the onsubmit attribute of the form tag causes the edit
window to close.

The target attribute of the form tag refers to the name set in the main
page using javascript. It causes the results to appear there (as long
as the browser is IE)

This seems like a bad solution (even apart from not working in other
browsers) because the edit window is aware of the name of the launching
window. If the launching window should change names or I want to reuse
this edit window from another window I'd have to edit it.

Also, as a navigation issue it seems to me that this should be handled
in the struts-config.xml file.

can it be?

Any thoughts?

Andrew Thompson · Aug 9, 2004

I've been slowly learning struts in my spare time and I've been trying
to do a simple popup. ....
The javascript in the onsubmit attribute of the form tag causes the edit
window to close.

Can you replicate this problem in pure HTML and JS?

If so, this is the wrong group..

If not, pleases check that first. Create two
HTML pages for your editing and tie them together
with the JS. Validate the HTML, (any relevant) CSS
and check your .JS does not prodce any errors in that.

HTH

Sudsy · Aug 10, 2004

Dave wrote:

2 - It feels very un struts like. Navigation is coded in the page
instead of in struts-config.xml.

<snip>

I think the problem is that you're trying to use a browser to produce
something which looks more like a Java application. It's the wrong
model.
Trying to pop-up an edit window and then viewing the modifications in
a window "underneath" isn't what most people would expect to see in
a web app.
Struts enables a "flow". It's great for collecting information (e.g.
resume data) over multiple pages. One page might allow you to add
jobs. Another might permit entry of education details. You can use
buttons or other means of navigation (menu bar?) to move between
forms.
I just can't imagine a web application which would pop-up a window
or dialog which requires data entry. Even user authentication is
handled directly by the browser.
Perhaps you need to revisit your design.

Sebastian Millies · Aug 10, 2004

Dave said:
I've been slowly learning struts in my spare time and I've been trying
to do a simple popup. I wanted to display some data along with an edit
button. If you click on the edit button you get a new window on which
the values are editable. When you click save of the new window, it
should disappear and the editted values should appear in the original
window.

It was easy enough creating the 2 views. It was even easy to get the
edit button to bring up the new window. It didn't work from that point
though. The Save button painted the original view (with the new values)
into the popup window while leaving the original window stiff alive in
the background.

This is a purely HTML/Browser issue. Struts can give you absolutely no
control over what happens at the client side - the next "view" from the
server's perspective is simply the contents of the next HTTP response.
What window it is displayed in, if at all, has nothing to do with Struts.

I believe your solution is as good as it gets when you require popups,
and you can strive to make your JS/HTML work on different browsers.
However, in general, I prefer to avoid using popups in web application.

-- Sebastian

Dave · Aug 10, 2004

Can you replicate this problem in pure HTML and JS?

I think there's some confusion here. The part you quoted is not the
problem.

I have an application coded in HTML and JS that works correctly. I'm
trying to evaluate if struts could do the job better.

If so, this is the wrong group..

I searched google groups for struts info and it seemed that this was the
most frequently used group for struts discussion. I realize it still
might be the wrong group but, that's why I posted here.

Thanks for your help.

Andrew Thompson · Aug 10, 2004

I think there's some confusion here. The part you quoted is not the
problem.

The posts of Sebastion, and *particularly* Sudsy
confirmed a vague (ding-a-ling) warning bell that
there was something awry about your web-app...

Trust me, (or perhaps) trust Sudsy, that the
*design is wrong*. That Sudsy identifies a
(possible) problem with the workflow of your app.
is something you need to consider, indentify and
quantify before your proceed.

Honestly, I am not the most experienced person
at designing web-apps, but Sudsy is OTOH, *very*
experienced at same. Ignore me if you will, but
listen very carefully to what he has to say.

[ I not only would, but actually *do* listen
carefully to what Sudsy advocates, he has steered
me right on many occasions.. ]

Dave · Aug 10, 2004

Dave wrote:

<snip>

I think the problem is that you're trying to use a browser to produce
something which looks more like a Java application. It's the wrong
model.

I grant that that's a legitimate argument. In my case, we have a web
based application that already behaves this way. Customers are already
using it and liking it. I'm just figuring out if struts can help us do
the kinds of things we're doing.

Trying to pop-up an edit window and then viewing the modifications in
a window "underneath" isn't what most people would expect to see in
a web app.

We're just trying to develop the most efficient workflow for our users.
We try not to let the technology dictate the UI to the extent possible.
Popups are good sometimes whether the client is thick or thin.

Struts enables a "flow". It's great for collecting information (e.g.
resume data) over multiple pages. One page might allow you to add
jobs. Another might permit entry of education details. You can use
buttons or other means of navigation (menu bar?) to move between
forms.
I just can't imagine a web application which would pop-up a window
or dialog which requires data entry.

If you can imagine any app behaving in such a way, why not a web app?

Even user authentication is
handled directly by the browser.
Perhaps you need to revisit your design.

It's too late for that. The application is delivered.

There is a huge list of features to add though. Struts might be able to
help us control the complexity in implementing new features. Of course
a UI precedence has been set and will constrain UI choices for the new
features.

Thank you for the discussion thus far tough.

Dave · Aug 10, 2004

This is a purely HTML/Browser issue. Struts can give you absolutely no
control over what happens at the client side - the next "view" from the
server's perspective is simply the contents of the next HTTP response.
What window it is displayed in, if at all, has nothing to do with Struts.

Is there another technology that would better serve me on the client
side? Java Server Faces perhaps?

I believe your solution is as good as it gets when you require popups,
and you can strive to make your JS/HTML work on different browsers.
However, in general, I prefer to avoid using popups in web application.

They are a pain. I thought struts would help.

-- Sebastian

Thanks a lot for your comments.

Andrew Thompson · Aug 10, 2004

I prefer to avoid using popups in web application.

They are a pain. I thought struts would help.

Pop-Ups are inherently problematic, moreso as time
goes by. There are not only browsers, but a slew of
plug-ins that can, and do, suppress pop-ups.

While web-desingers love them, and can inherently
understand the 'sense' of them, users cannot..

[ ..and please do not take the attitude that "it's
the users fault and problem". It is *your* potentially
money making web-app they are surfing the hell out of
when it does not act as they expect.. They do not give
a toss, it is *you* that needs to care.. ]

To futureproof your web-app. I strongly recommend
you drop the entire concept of pop-up windows..

A user that meets a linear, logical web-app they
understand is more likely to invest business
with you than a company that 'forces' pop-ups
on them (Even assuming some obscure bit of
software does not suppress pop-ups silently)..

Sudsy · Aug 10, 2004

Dave wrote:

We're just trying to develop the most efficient workflow for our users.
We try not to let the technology dictate the UI to the extent possible.
Popups are good sometimes whether the client is thick or thin.

<snip>

In that case Struts can definitely help: it's great for workflow.
I've written many web apps of different types which utilize the
framework. It saves a lot of time and effort (save the learning
curve) and can be modified quite easily.
But I'd still design an app to run in a single browser window.
Based on your description, here's how I would see it flow:
- user navigates to a window which displays an uneditable view
- there's a button on the page which is labelled "Edit"
- user clicks button and is presented another view with editable
fields
- there are buttons labelled "Submit" and "Cancel"
- both buttons return to the first view, but the "Submit" button
updates the model
No need for a pop-up window or trying to coordinate views. In
fact, on some systems it's possible to fire up two or more
browsers or instances of browsers. If someone uses a second
instance to edit the data, how is the view in the first
instance going to be notified?
It's fine if you have server push, otherwise you're going to
get into a quagmire with periodic pull updates. Then your users
are going to complain that the data in the window doesn't
update immediately, yadda, yadda, yadda...
To much pain for me. YMMV.

Dave · Aug 10, 2004

Pop-Ups are inherently problematic, moreso as time
goes by. There are not only browsers, but a slew of
plug-ins that can, and do, suppress pop-ups.

Oh yeah. We've faced that issue. In fact several bugs consumed hours
of work only to be traced to a tester running the google tool bar or
some other popup blocker.

While web-desingers love them, and can inherently
understand the 'sense' of them, users cannot..

[ ..and please do not take the attitude that "it's
the users fault and problem". It is *your* potentially
money making web-app they are surfing the hell out of
when it does not act as they expect.. They do not give
a toss, it is *you* that needs to care.. ]

I don't talk to users directly but I think they're OK with the popups.

We use popups because we felt they gave a more reasonable user
experience. We certainly didn't do it because it was easier for us. In
fact they create a lot of extra work. So we've definately not taken
that attitude.

We're in a different situation than alot of web app developers. Our app
is not exposed to the general public. Our customers buy our app and
install it for their internal use. As such we get to specify some
details of the environment such as which versions of which browsers we
will support. We also specify that we do not support browsers with
popup blockers.

Does that cost us sales? Maybe. I'm just a tech guy and I have to go
by what the marketing people tell me. Support for popup blockers or
eliminating popups are never mentioned as concerns or requests.

To futureproof your web-app. I strongly recommend
you drop the entire concept of pop-up windows..

I think the advice you're giving is reasonable.

Dave · Aug 10, 2004

But I'd still design an app to run in a single browser window.
Based on your description, here's how I would see it flow:
- user navigates to a window which displays an uneditable view
- there's a button on the page which is labelled "Edit"
- user clicks button and is presented another view with editable
fields
- there are buttons labelled "Submit" and "Cancel"
- both buttons return to the first view, but the "Submit" button
updates the model
No need for a pop-up window or trying to coordinate views.

That's certainly a good alternative design. It's negative is that you
lose access to the data that was on the original screen which you might
want to reference while working on the item you've chosen to edit.

In
fact, on some systems it's possible to fire up two or more
browsers or instances of browsers. If someone uses a second
instance to edit the data, how is the view in the first
instance going to be notified?
It's fine if you have server push, otherwise you're going to
get into a quagmire with periodic pull updates. Then your users
are going to complain that the data in the window doesn't
update immediately, yadda, yadda, yadda...

All I can say is we don't see these issues except when some runs two
independent browsers. Our edit window closes and the views that contain
the information just editted are updated. The closing edit window
causes its parent to reload. Just like in the example I posted.

Of course, in the case of the multiple independent browsers it doesn't
work. Only the window that launched the editor window gets updated.
But that's independent of the popup issue. Two independent browser
instances don't know about each other.

Also if two different users are observing a view of the same data and
one guy edits it, the other guy will not be aware that the edit has
occured. That's just the way it is. The data you see is only fresh at
the time the page is rendered.

To much pain for me. YMMV.

Oh, it was painful. It IS painful to maintain. That's why I'm looking
at struts.

Sudsy · Aug 10, 2004

Dave wrote:

That's certainly a good alternative design. It's negative is that you
lose access to the data that was on the original screen which you might
want to reference while working on the item you've chosen to edit.

But then it just becomes a design issue. I know exactly what you're
talking about and address the problem by having the edit window
consist of two panels: the top one is non-editable and contains the
"reference" data. The lower panel contains the editable fields. One
of the really nice things with Struts is that you can go ahead and
pre-populate the editable panel so the user can chose which fields
need to change and which can stay the same.
Again, I'm in complete agreement with Andrew with regard to the
necessity of pop-ups. Even without the pop-up killer issue, it's
not the way people generally expect a website to behave.

Posting data from .jsp to execute( ) method	2	Oct 13, 2009
Jsp, Struts, and Tomcat 5.5.20	1	Oct 6, 2006
encoding problem with Struts	2	Jul 25, 2003
Struts - Getter method	6	Jun 25, 2008
statements in the<logic:equal> tags are not evaluated	1	Oct 22, 2008
Struts Tomcat 5 Taglib issue	3	Sep 19, 2004
Struts - Problem with nested iteration or double iteration	5	Sep 30, 2008
cannot find bean in any scope error	3	Feb 28, 2005

Struts: popups, this can't be right.

Dave

Andrew Thompson

Sudsy

Sebastian Millies

Dave

Andrew Thompson

Dave

Dave

Andrew Thompson

Sudsy

Dave

Dave

Sudsy

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads