RE: Is Struts (or browser based applications in general) useable to build maintenance-applications?

[Edgar Dollin <ed...@blue-moose.net>]

I have resolved all my Web Application issues (it did take a while).

The back button can be solved by subclassing the ActionForm and having a
standard sequence field.  In all your JSP make sure there is a hidden field
for the sequencer.  Then before any action occurs (write to the db) check
the sequencer to make sure it is the value expected.

If you only use POST methods in JSP the bookmark issue is moot.

Hope that helps

Edgar


-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Tuesday, November 26, 2002 3:10 AM
To: Struts Users Mailing List
Subject: RE: Is Struts (or browser based applications in general)
useable to build maintenance-applications?


Well I dont know what the issues with maintenance apps in particular are,
but for any web app (which is an application rather than just some trivial
website or portal with dynamic bits) you will have a lot of issues with
users doing things like using back buttons, bookmarks, etc... which can
really upset your server side sense of application state. Managing this can
be a real pain.

As soon as you go beyond trivial UI needs (ie: anything more complex than a
very basic example app) you also have to deal with a myriad of issues
related to browser compatibilities, container portability issues, etc...
Some ppl will tell you to develop code that meets the 'standards' and runs
on all broswers without using javascript. Unless your users are happy with a
very minimalist UI (Ive yet to meet one who is) thats something of an
impossibility so you have a lot of decisions to make in terms of what and
what not to support.
A lot of things that might take only a few lines of code to achieve in a
Swing based client can be fiendishly complex in html (keeping your state
maintained correctly in relation to what the user is seeing on their screen,
fancy widgets, modal stuff...)

On the positive side, your users wont need to install a client application
onto their machines which makes rolling out changes a lot easier (and for a
big organisation a LOT cheaper).
In addition a lot of things that require tons of code in Swing can be
achieved relatively easily from a browser UI. (For example printing a fancy
report just means forwarding to a page that presents the info nicely and
telling the user to click 'print' ;->)

-----Original Message-----
From: Martin Kuhn [mailto:martin.kuhn@gmx.at]
Sent: Tuesday, November 26, 2002 15:46
To: struts-user@jakarta.apache.org
Subject: Is Struts (or browser based applications in general) useable to
build maintenance-applications?


We are in a decision-process about the front-end for
a maintenance-application in insurance-domain.

The communication with the backend (mainframe)
happens via XML.

This front-end infrastructure should be the base structure
for new applications (not only for the maintenance-application).

So my preference is to build a browser-based front end
with Struts :-)

But I'm unsure about the useability of a browser based
front-end in maintenance context ( -> keyboard-navigation,
etc.). I know, several things can resolved with Javascript.

Is it a risky way to develop a browser-based front-end for
a maintenance app.

Can someone share experience to build maintenance-apps
with struts (or a browser based front-end in general)?

TIA

Martin Kuhn




--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Is Struts (or browser based applications in general) useable to build maintenance-applications?

[Andrew Hill <an...@gridnode.com>]

Ive a quite lot of links that look like
"thingAction.do?method=edit&uid=1234". As I go along Im rather coming to the
view that I should just try and use POST for everything and eliminate GETs
altogether. The browser just takes far too many liberties with them...

The sequencer idea has merit (seems similar in concept to the token token
support struts already provides), but the problem is that they want the damn
back button to actually work. Given that the app needs to maintain fifty
tons of state (including state of various ui widgets, workflows and other
wierdities) to meet all the other requirements its very hard to figure out a
suitable way to handle this short of incorperating a TARDIS in my
application.

The basic problem of course is the app vs website dilema. In a website the
back button is very useful as your just navigating round a bunch of
relatively stateless pages and a request is a direction for which page you
want next. In a web app however you arent navigating round a bunch of pages,
but rather firing events to the server that cause changes in server state
which are reflected in the response page. Clicking the back button would
cause the last 'event' to be fired again, or a snapshot of an earlier
response page to be shown, but the server is already in a different state.
The last event was already processed. Database writes have been commited.
Objects created or destroyed. Widgets toggled and workflows woggled.

Keeping a token gives you a chance to tell if the user is submitting from an
earlier page cached in the browser, and you can show an error message and
perhaps even direct them back on track - but when your requirement is that
that old page work again just like it did before, its nearly impossible. It
will work in some cases, but in others you can end up with all sorts of
problems if there are things that depend on server side state as well as
client side state - and in all but the most trivial of cases this will be
true. What to do?
:-(

Its hard enough to try an explain this problem to the (more experienced
technical) people who give me these requirements. I hate to think how the
concept can be imparted to users...

-----Original Message-----
From: Edgar Dollin [mailto:edgar@blue-moose.net]
Sent: Tuesday, November 26, 2002 19:02
To: 'Struts Users Mailing List'; 'andrew.david.hill@gridnode.com'
Subject: RE: Is Struts (or browser based applications in general)
useable to build maintenance-applications?


I have resolved all my Web Application issues (it did take a while).

The back button can be solved by subclassing the ActionForm and having a
standard sequence field.  In all your JSP make sure there is a hidden field
for the sequencer.  Then before any action occurs (write to the db) check
the sequencer to make sure it is the value expected.

If you only use POST methods in JSP the bookmark issue is moot.

Hope that helps

Edgar


-----Original Message-----
From: Andrew Hill [mailto:andrew.david.hill@gridnode.com]
Sent: Tuesday, November 26, 2002 3:10 AM
To: Struts Users Mailing List
Subject: RE: Is Struts (or browser based applications in general)
useable to build maintenance-applications?


Well I dont know what the issues with maintenance apps in particular are,
but for any web app (which is an application rather than just some trivial
website or portal with dynamic bits) you will have a lot of issues with
users doing things like using back buttons, bookmarks, etc... which can
really upset your server side sense of application state. Managing this can
be a real pain.

As soon as you go beyond trivial UI needs (ie: anything more complex than a
very basic example app) you also have to deal with a myriad of issues
related to browser compatibilities, container portability issues, etc...
Some ppl will tell you to develop code that meets the 'standards' and runs
on all broswers without using javascript. Unless your users are happy with a
very minimalist UI (Ive yet to meet one who is) thats something of an
impossibility so you have a lot of decisions to make in terms of what and
what not to support.
A lot of things that might take only a few lines of code to achieve in a
Swing based client can be fiendishly complex in html (keeping your state
maintained correctly in relation to what the user is seeing on their screen,
fancy widgets, modal stuff...)

On the positive side, your users wont need to install a client application
onto their machines which makes rolling out changes a lot easier (and for a
big organisation a LOT cheaper).
In addition a lot of things that require tons of code in Swing can be
achieved relatively easily from a browser UI. (For example printing a fancy
report just means forwarding to a page that presents the info nicely and
telling the user to click 'print' ;->)

-----Original Message-----
From: Martin Kuhn [mailto:martin.kuhn@gmx.at]
Sent: Tuesday, November 26, 2002 15:46
To: struts-user@jakarta.apache.org
Subject: Is Struts (or browser based applications in general) useable to
build maintenance-applications?


We are in a decision-process about the front-end for
a maintenance-application in insurance-domain.

The communication with the backend (mainframe)
happens via XML.

This front-end infrastructure should be the base structure
for new applications (not only for the maintenance-application).

So my preference is to build a browser-based front end
with Struts :-)

But I'm unsure about the useability of a browser based
front-end in maintenance context ( -> keyboard-navigation,
etc.). I know, several things can resolved with Javascript.

Is it a risky way to develop a browser-based front-end for
a maintenance app.

Can someone share experience to build maintenance-apps
with struts (or a browser based front-end in general)?

TIA

Martin Kuhn




--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>