Re: RE : the wait page primer

2002-02-11 Thread Tuomo Syvänperä

I want one too :)

/tuomo

Régis Brochu wrote:

> I'm really interested. Can you send it to me ! 
> 
> Thanks
> Regis 
> 
> -Message d'origine-
> De : Missine Alec [mailto:[EMAIL PROTECTED]] 
> Envoyé : Thursday, December 20, 2001 3:08 PM
> À : '[EMAIL PROTECTED]'
> Objet : the wait page primer
> Importance : Faible
> 
> For those of you folks who likes complete and concise working examples
> (who
> doesn't?:)), I have a war file that contains a Struts-based application
> that
> prototypes the wait page support for a time-consuming request (TCR).
> When a
> TCR (e.g., a database search) starts, the appropriate wait page is being
> sent to the browser after the request's ETC (Estimated Time to Complete
> :) )
> expires.
> 
> In the meantime, the corresponding action (the database search) is being
> started in the background thread on the server. If the default ETC is
> used
> (ad infinitum) or the action completes before the request's ETC expires,
> there is no wait page at all - the browser gets the result page right
> away,
> while the background thread is still busy closing the resources.
> 
> The wait page has javascript that polls the server to update the wait
> page
> with the TCR's progress. When the TCR completes, the wait page is being
> replaced with the appropriate result page.
> 
> This implementation has been tested on ApacheTomcat4.0 with Oracle 8.1.6
> database as a data source. It can be modified to run on WebSphere
> Application Server 3.5.3 - it claims it's been tested on WAS, but the
> necessary modifications haven't been made yet. Presently, the
> application
> provides read-only access to all database tables for all database
> schemas
> through extensive use of the java.sql.DatabaseMetaData object. The next
> release will support insert/update/delete functionality.
> 
> The war file is too big to attach to this message (707K). Please let me
> know
> if you'd like me to email it to you directly. It is my intent to support
> open source initiative. Thank you,
> 
> Alec Missine
> 
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> 
> 




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE : the wait page primer

2002-02-11 Thread Régis Brochu

I'm really interested. Can you send it to me ! 

Thanks
Regis 

-Message d'origine-
De : Missine Alec [mailto:[EMAIL PROTECTED]] 
Envoyé : Thursday, December 20, 2001 3:08 PM
À : '[EMAIL PROTECTED]'
Objet : the wait page primer
Importance : Faible

For those of you folks who likes complete and concise working examples
(who
doesn't?:)), I have a war file that contains a Struts-based application
that
prototypes the wait page support for a time-consuming request (TCR).
When a
TCR (e.g., a database search) starts, the appropriate wait page is being
sent to the browser after the request's ETC (Estimated Time to Complete
:) )
expires.

In the meantime, the corresponding action (the database search) is being
started in the background thread on the server. If the default ETC is
used
(ad infinitum) or the action completes before the request's ETC expires,
there is no wait page at all - the browser gets the result page right
away,
while the background thread is still busy closing the resources.

The wait page has javascript that polls the server to update the wait
page
with the TCR's progress. When the TCR completes, the wait page is being
replaced with the appropriate result page.

This implementation has been tested on ApacheTomcat4.0 with Oracle 8.1.6
database as a data source. It can be modified to run on WebSphere
Application Server 3.5.3 - it claims it's been tested on WAS, but the
necessary modifications haven't been made yet. Presently, the
application
provides read-only access to all database tables for all database
schemas
through extensive use of the java.sql.DatabaseMetaData object. The next
release will support insert/update/delete functionality.

The war file is too big to attach to this message (707K). Please let me
know
if you'd like me to email it to you directly. It is my intent to support
open source initiative. Thank you,

Alec Missine

--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




RE: the wait page primer

2001-12-21 Thread Islam, Tariq

I am interested. Please send to [EMAIL PROTECTED]

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




RE: the wait page primer

2001-12-20 Thread Matt Raible

I'm interested, please send to [EMAIL PROTECTED]

Thanks,

Matt

-Original Message-
From: Missine Alec [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 20, 2001 1:08 PM
To: '[EMAIL PROTECTED]'
Subject: the wait page primer
Importance: Low


For those of you folks who likes complete and concise working examples (who
doesn't?:)), I have a war file that contains a Struts-based application that
prototypes the wait page support for a time-consuming request (TCR). When a
TCR (e.g., a database search) starts, the appropriate wait page is being
sent to the browser after the request's ETC (Estimated Time to Complete :) )
expires.

In the meantime, the corresponding action (the database search) is being
started in the background thread on the server. If the default ETC is used
(ad infinitum) or the action completes before the request's ETC expires,
there is no wait page at all - the browser gets the result page right away,
while the background thread is still busy closing the resources.

The wait page has javascript that polls the server to update the wait page
with the TCR's progress. When the TCR completes, the wait page is being
replaced with the appropriate result page.

This implementation has been tested on ApacheTomcat4.0 with Oracle 8.1.6
database as a data source. It can be modified to run on WebSphere
Application Server 3.5.3 - it claims it's been tested on WAS, but the
necessary modifications haven't been made yet. Presently, the application
provides read-only access to all database tables for all database schemas
through extensive use of the java.sql.DatabaseMetaData object. The next
release will support insert/update/delete functionality.

The war file is too big to attach to this message (707K). Please let me know
if you'd like me to email it to you directly. It is my intent to support
open source initiative. Thank you,

Alec Missine

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




the wait page primer

2001-12-20 Thread Missine Alec

For those of you folks who likes complete and concise working examples (who
doesn't?:)), I have a war file that contains a Struts-based application that
prototypes the wait page support for a time-consuming request (TCR). When a
TCR (e.g., a database search) starts, the appropriate wait page is being
sent to the browser after the request's ETC (Estimated Time to Complete :) )
expires.

In the meantime, the corresponding action (the database search) is being
started in the background thread on the server. If the default ETC is used
(ad infinitum) or the action completes before the request's ETC expires,
there is no wait page at all - the browser gets the result page right away,
while the background thread is still busy closing the resources.

The wait page has javascript that polls the server to update the wait page
with the TCR's progress. When the TCR completes, the wait page is being
replaced with the appropriate result page.

This implementation has been tested on ApacheTomcat4.0 with Oracle 8.1.6
database as a data source. It can be modified to run on WebSphere
Application Server 3.5.3 - it claims it's been tested on WAS, but the
necessary modifications haven't been made yet. Presently, the application
provides read-only access to all database tables for all database schemas
through extensive use of the java.sql.DatabaseMetaData object. The next
release will support insert/update/delete functionality.

The war file is too big to attach to this message (707K). Please let me know
if you'd like me to email it to you directly. It is my intent to support
open source initiative. Thank you,

Alec Missine

--
To unsubscribe, e-mail:   
For additional commands, e-mail: