repositioning long forms after a post

[salmobytes]

After a javascript-generated post event (this is a post, not ajax
messaging)
the current screen has to be redrawn. But on *long forms*
(longer than a single screen) then the current screen positioning
is lost, and the current form ends up redrawn, with a different
vertical
positioning--after the post event.

However, If I sent the x,y mouse position as post parameters,
and if the current widget (that generated the post) had
a well-known anchor tag name, would there be a way
to combine that much information, after the post, in order to redraw
the
form close to it's original vertical positioning?

How?

[pangea33]

salmobytes wrote:

After a javascript-generated post event (this is a post, not ajax
messaging)
the current screen has to be redrawn. But on *long forms*
(longer than a single screen) then the current screen positioning
is lost, and the current form ends up redrawn, with a different
vertical
positioning--after the post event.

However, If I sent the x,y mouse position as post parameters,
and if the current widget (that generated the post) had
a well-known anchor tag name, would there be a way
to combine that much information, after the post, in order to redraw
the
form close to it's original vertical positioning?

How?

I think that can be accomplished with some dhtml, which I will try to
help with, but what is the form layout? Are there multiple ways
(buttons, links, etc) by which the user can submit this form? If not,
won't the mouse position at submit time always be right on the submit
button?

[salmobytes]

pangea33 wrote:

I think that can be accomplished with some dhtml, which I will try to
help with, but what is the form layout? Are there multiple ways
(buttons, links, etc) by which the user can submit this form? If not,
won't the mouse position at submit time always be right on the submit
button?

Thank you.
I need a generic solution. I have a java application that is, among
other things,
be a 'forms editor' that makes hierarchical forms (some widgets
can contain other widgets). The resulting forms (abstract data entry
forms,
generated from the Java application) can be saved
server side as xml, stored in Exist, Xindice, SleepyCat, Oracle, etc

That backend XML can be used to automatically generate data entry
forms, at a later date, instantiated as either Java Swing Widgets or
as html forms.

......it gets complicated. Data (from the generated forms) is stored
server side too. A servlet can splice XML form definitions together
with historical data sets (mostly for documenting complex laboratory
data)
so any historical data set can be re-displayed, at any time, as it
looked
when it was originally saved..........so data entry sessions
can finished up over a period of time.
All of that works. The Java application part is slick as schoolboy's
sleeve
in January. But the html side is still a bit clunky. Form users
can dynamically add new options to select menus in the
html data entry form, but each "new option" event generates
a post, so the server can update a tree of DefaultMutableTreeNodes,
that represent the backend XML.

So it isn't always a submit button that generates a post.
And posts from a very long form end up shifting the screen to a new
vertical position.

I think I need to track scrollbar positioning somehow, and
rebuild that scrollbar position after the post. Each hierarchical
widget
in the XML-like form has a uniquely named anchor tag.

Ajax is a possibility...............but I'd like to solve it without
Ajax if at all possible.

[salmobytes]

salmobytes wrote:

pangea33 wrote:

I think that can be accomplished with some dhtml, which I will try to
help with, but what is the form layout? Are there multiple ways
(buttons, links, etc) by which the user can submit this form? If not,
won't the mouse position at submit time always be right on the submit
button?

I found this on the net. This example assumes asp.net on the backend,
and I'm using Tomcat. But the server side isn't the problem here.
I'm a reasonably competent java programmer, but a javascript neophyte.
Maybe I can work with this.

http://patrickfoley.com/2005/01/21/scroll-saver/

[pangea33]

salmobytes wrote:

salmobytes wrote:

pangea33 wrote:

I think that can be accomplished with some dhtml, which I will try to
help with, but what is the form layout? Are there multiple ways
(buttons, links, etc) by which the user can submit this form? If not,
won't the mouse position at submit time always be right on the submit
button?

I found this on the net. This example assumes asp.net on the backend,
and I'm using Tomcat. But the server side isn't the problem here.
I'm a reasonably competent java programmer, but a javascript neophyte.
Maybe I can work with this.

http://patrickfoley.com/2005/01/21/scroll-saver/

window.scrollTo(x,y) is not specified by any particular DOM standard so
it's not guaranteed for all browsers, but support by both Mozilla and
IE is a good start.

http://developer.mozilla.org/en/docs...indow.scrollTo
http://msdn.microsoft.com/workshop/a...s/scrollto.asp
http://www.w3schools.com/js/tryit.as...indow_scrollto

[ASM]

salmobytes a écrit :

After a javascript-generated post event (this is a post, not ajax
messaging)
the current screen has to be redrawn. But on *long forms*
(longer than a single screen) then the current screen positioning
is lost, and the current form ends up redrawn, with a different
vertical
positioning--after the post event.

However, If I sent the x,y mouse position as post parameters,

if something has been send (post) it is certainly because somebody
pressed a button, no ?

so you know the place of this button and perhaps can you link to it

function redraw) {
blah
blah
location = '#myButton';
}


--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Stephane Moriaux and his (less) old Mac already out of date

[salmobytes]

function redraw) {
blah
blah
location = '#myButton';

Yes, but that puts that button at the top of the redrawn
screen, which is visually annoying and confusing,
if that button was at screen middle before the post,
especially in a long form.

So the answer (I think....it's starting to look like) is
to (somehow) persist the mouseXY position, from
before the post, and then, when back at the client,
to do a window.scrollXY(oldX, oldY).....which might
not be exactly the same vertical positioning, but it would
be close enough (I pounded nails for the Close Enough
Construction Company for 20 years, before diving into
software).