First time using an applet(AWT) within an ASP to access SQL Server 7 data.
My question has to do with the 'management' of the applet in the client browser
when a trip to the server is initiated(i.e. Submit) to perform an access,add,
mod, or delete. The ASP will be returned to the user with the respective
results(no redirect to another page). What I'm trying to eliminate is the
'flicker' when the client page is refreshed. I'm not using CORBA(may be the
next step) to perform the database interaction. All the database processing
is being done thru ASP code when it gets back to the server. So, the idea
is to have the applet simply be refreshed with new data, confirmation msg,
etc without disappearring and reappearring.
Thanks very much in advance,
Re: Applet Refresh
Instead of asp posting ur data and then feeding back to the applet u can give
variables of user request to applet through java script.
java script as such can directly call the public function of a applet class.
u can pass on the parameters to function and in result applet only gets refreshed.
i guess u got the idea how to do it, let me know theres any mess.
all the best,
Re: Applet Refresh
"Harshad Patel" <firstname.lastname@example.org> wrote:
Thanks for the response. I did discover what you are referencing with respect
to passing user data to the applet via calling public functions to 'load'
the data into combo's,etc. My primary problem was the web page(and applet
of course) being completely removed from view and then being redisplayed
with the new data(as if you had navigated to a different 'linked' page).
For data entry personnel, this process was unacceptable.
I may have overlooked a simpler solution, but w/ an offhand suggestion from
a Microsoft VJ++ technician that the use of frames may provide a workaround,
the following technique is being employed. Within the main .htm page, we
have 2 separate .asp pages embedded in 2 frames. The first frame takes up
99% of the page, the second frame takes up the remaining 1% and is therefore
'non existent' to the user. The .asp in the first frame contains the applet
and the asp code to initialize the combo boxes with 'valid' choices via the
param tags and the getParameter methods in the applet. The second frame contains
asp code for database access on the server with the 'hidden' input tags to
ultimately pass the data to the first frame.
When the user 'submits' the .htm(submit button is located in the first frame),
data from the applet is passed(via calling public functions in the applet)
to the input tags in the second frame, the second frame is submitted(carrying
the data back to the server to be processed by the resident asp code), and
onSubmit event handler. The first frame(and applet) then remains unchanged
until the return of the second frame brings back the desired data from the
server, passes this data to the applet by again calling public functions
to load the new data into the respective textareas, combo selections, etc
of the applet. The only change the user observes is the 'data' in the applet
being refreshed vs the entire applet disappearring and reappearring. So far,
it works well and as convoluted as it appears, the segregation of the tasks
performed by each frame lends itself to distinct possibilities with respect
the data elements in the frames.
This question has been posted for over a month in this newsgroup and 2 others.
I'm kinda surprised this circumstance is not a 'common' issue with respect
to using applets for data collection/maintenance. I'm heading down the applet
awt road as a standard user interface to maintain our data for various reasons(being
able to distribute work load on the workstation and server, possible use
of CORBA, and the more 'generic' aspects of java running in the respective
jvm's of the various browsers). But, based on the response(or lack thereof)
to this question, I'm concerned I may have overlooked some hidden shortcomings
of using java applets for this task. If you have an opinion(perspective)
on this issue, I'd appreciate your input.
>Instead of asp posting ur data and then feeding back to the applet u can
>variables of user request to applet through java script.
>java script as such can directly call the public function of a applet class.
>u can pass on the parameters to function and in result applet only gets
>i guess u got the idea how to do it, let me know theres any mess.
>all the best,