Malcolm Dew-Jones wrote:
Sounds good. Just wondered if a cookie might be better.

We have hidden fields for some other information on this and other
pages, so I'm comfortable with that.

Thanks.
Ed

Shakespeare wrote:
They log in thru a .NET application. (I don't know the details, since
I haven't looked at the code. For this taks, we are only tracking
activity on a few screens/pages. There was some discussion about
trying to close the loop on broken/abandoned sessions, but it looks
like the business folks are going to just accept the possibility of
log entries with a start time but no end time.

Thanks for the help.
Ed

Shakespeare wrote:
They log in thru a .NET application. (I don't know the details, since
I haven't looked at the code. For this taks, we are only tracking
activity on a few screens/pages. There was some discussion about
trying to close the loop on broken/abandoned sessions, but it looks
like the business folks are going to just accept the possibility of
log entries with a start time but no end time.

Thanks for the help.
Ed

Shakespeare wrote:
They log in thru a .NET application. (I don't know the details, since
I haven't looked at the code. For this taks, we are only tracking
activity on a few screens/pages. There was some discussion about
trying to close the loop on broken/abandoned sessions, but it looks
like the business folks are going to just accept the possibility of
log entries with a start time but no end time.

Thanks for the help.
Ed

Shakespeare wrote:
They log in thru a .NET application. (I don't know the details, since
I haven't looked at the code. For this taks, we are only tracking
activity on a few screens/pages. There was some discussion about
trying to close the loop on broken/abandoned sessions, but it looks
like the business folks are going to just accept the possibility of
log entries with a start time but no end time.

Thanks for the help.
Ed

Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:


: Malcolm Dew-Jones wrote:
: > Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:
: > : Connected to:
: > : Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
: > : With the Partitioning and Oracle Data Mining options
: > : JServer Release 9.2.0.8.0 - Production
: >
: > : Showing my lack of User interface application skills here.
: >
: > : We have web applications built with PL/SQL. The goal is to develop a
: > : simple timing application. When the user enters the fist screen, make
: > : a log entry which include the time. When they exit that screen, note
: > : how they exited (e.g. OK or CANCEL button pressed) and update the log
: > : with a stop time. Given the stateless nature of HTML, what's the best
: > : practice to deal with this situation?
: > : Use a cookie?
: > : Use hidden HTML form fields?
: > : Other?
: >
: > As long as the hidden field does not have security issues, then I think a
: > hidden field is the easiest for simple tasks.

: Sounds good. Just wondered if a cookie might be better.

The "problem" with a hidden field is that every page of the applicaiton
has to pass it along. For example, if a user visits an html page with
instructions then they can't "continue" to the next page and keep the
hidden field unless the "html" file is actually a cgi script that
populates a hidden field (or url parameter). In a simple situation that
is not a hassle, but with multiple screens it does get to be a hassle.

A cookie is potentially more hassle to program. But if your tools /
ennvironment have simnple routines then handle cookies then a cookie
becomes simple and the only downside at all is that you have more "things"
that your code has to handle.

I think in the long run it is good for a programmer to figure out how to
use cookies in their web programming environment, because once you can use
them easily then they are convenient for every project.

: >
: > Your application will see the hidden field just as if it were a normal
: > field. In fact during test/development you could use the field as a
: > normal input field so as to test various inputs.

: We have hidden fields for some other information on this and other
: pages, so I'm comfortable with that.

: Thanks.
: Ed

--

Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:


: Malcolm Dew-Jones wrote:
: > Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:
: > : Connected to:
: > : Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
: > : With the Partitioning and Oracle Data Mining options
: > : JServer Release 9.2.0.8.0 - Production
: >
: > : Showing my lack of User interface application skills here.
: >
: > : We have web applications built with PL/SQL. The goal is to develop a
: > : simple timing application. When the user enters the fist screen, make
: > : a log entry which include the time. When they exit that screen, note
: > : how they exited (e.g. OK or CANCEL button pressed) and update the log
: > : with a stop time. Given the stateless nature of HTML, what's the best
: > : practice to deal with this situation?
: > : Use a cookie?
: > : Use hidden HTML form fields?
: > : Other?
: >
: > As long as the hidden field does not have security issues, then I think a
: > hidden field is the easiest for simple tasks.

: Sounds good. Just wondered if a cookie might be better.

The "problem" with a hidden field is that every page of the applicaiton
has to pass it along. For example, if a user visits an html page with
instructions then they can't "continue" to the next page and keep the
hidden field unless the "html" file is actually a cgi script that
populates a hidden field (or url parameter). In a simple situation that
is not a hassle, but with multiple screens it does get to be a hassle.

A cookie is potentially more hassle to program. But if your tools /
ennvironment have simnple routines then handle cookies then a cookie
becomes simple and the only downside at all is that you have more "things"
that your code has to handle.

I think in the long run it is good for a programmer to figure out how to
use cookies in their web programming environment, because once you can use
them easily then they are convenient for every project.

: >
: > Your application will see the hidden field just as if it were a normal
: > field. In fact during test/development you could use the field as a
: > normal input field so as to test various inputs.

: We have hidden fields for some other information on this and other
: pages, so I'm comfortable with that.

: Thanks.
: Ed

--

Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:


: Malcolm Dew-Jones wrote:
: > Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:
: > : Connected to:
: > : Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
: > : With the Partitioning and Oracle Data Mining options
: > : JServer Release 9.2.0.8.0 - Production
: >
: > : Showing my lack of User interface application skills here.
: >
: > : We have web applications built with PL/SQL. The goal is to develop a
: > : simple timing application. When the user enters the fist screen, make
: > : a log entry which include the time. When they exit that screen, note
: > : how they exited (e.g. OK or CANCEL button pressed) and update the log
: > : with a stop time. Given the stateless nature of HTML, what's the best
: > : practice to deal with this situation?
: > : Use a cookie?
: > : Use hidden HTML form fields?
: > : Other?
: >
: > As long as the hidden field does not have security issues, then I think a
: > hidden field is the easiest for simple tasks.

: Sounds good. Just wondered if a cookie might be better.

The "problem" with a hidden field is that every page of the applicaiton
has to pass it along. For example, if a user visits an html page with
instructions then they can't "continue" to the next page and keep the
hidden field unless the "html" file is actually a cgi script that
populates a hidden field (or url parameter). In a simple situation that
is not a hassle, but with multiple screens it does get to be a hassle.

A cookie is potentially more hassle to program. But if your tools /
ennvironment have simnple routines then handle cookies then a cookie
becomes simple and the only downside at all is that you have more "things"
that your code has to handle.

I think in the long run it is good for a programmer to figure out how to
use cookies in their web programming environment, because once you can use
them easily then they are convenient for every project.

: >
: > Your application will see the hidden field just as if it were a normal
: > field. In fact during test/development you could use the field as a
: > normal input field so as to test various inputs.

: We have hidden fields for some other information on this and other
: pages, so I'm comfortable with that.

: Thanks.
: Ed

--

Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:


: Malcolm Dew-Jones wrote:
: > Ed Prochak (edprochak (AT) gmail (DOT) com) wrote:
: > : Connected to:
: > : Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
: > : With the Partitioning and Oracle Data Mining options
: > : JServer Release 9.2.0.8.0 - Production
: >
: > : Showing my lack of User interface application skills here.
: >
: > : We have web applications built with PL/SQL. The goal is to develop a
: > : simple timing application. When the user enters the fist screen, make
: > : a log entry which include the time. When they exit that screen, note
: > : how they exited (e.g. OK or CANCEL button pressed) and update the log
: > : with a stop time. Given the stateless nature of HTML, what's the best
: > : practice to deal with this situation?
: > : Use a cookie?
: > : Use hidden HTML form fields?
: > : Other?
: >
: > As long as the hidden field does not have security issues, then I think a
: > hidden field is the easiest for simple tasks.

: Sounds good. Just wondered if a cookie might be better.

The "problem" with a hidden field is that every page of the applicaiton
has to pass it along. For example, if a user visits an html page with
instructions then they can't "continue" to the next page and keep the
hidden field unless the "html" file is actually a cgi script that
populates a hidden field (or url parameter). In a simple situation that
is not a hassle, but with multiple screens it does get to be a hassle.

A cookie is potentially more hassle to program. But if your tools /
ennvironment have simnple routines then handle cookies then a cookie
becomes simple and the only downside at all is that you have more "things"
that your code has to handle.

I think in the long run it is good for a programmer to figure out how to
use cookies in their web programming environment, because once you can use
them easily then they are convenient for every project.

: >
: > Your application will see the hidden field just as if it were a normal
: > field. In fact during test/development you could use the field as a
: > normal input field so as to test various inputs.

: We have hidden fields for some other information on this and other
: pages, so I'm comfortable with that.

: Thanks.
: Ed

--