[H-GEN] need some html/javascript pointers (setting window attributes)

[Tony Nugent]

-----Original Message-----
Sent: Friday, January 06, 2006 6:52 PM
Subject: Re: [H-GEN] need some html/javascript pointers (setting window
attributes)

> On 1/6/06, Tony Nugent <tony at linuxworks.com.au> wrote:
>> Yes, this looks like the way that I'll have to resort to doing it (my raw
>> test code just about does that already).  I'll try initially opening the
>> named) target window from the form in the parent window with onSubmit()
>> - if that window doesn't already exist (perhaps testing for that isn't 
>> necessary, I'll have to experiment - is it ok to re-open an open window?)

> Using window.open(URL, name [, features]), as Glenn mentioned, is very
> similar to using the target="name" in the form tag.  Use the onSubmit
> event to call a function that uses window.open with a name.  If the
> named window does not exist it is created, if it does exist it is
> reused.  Construct the URL by grabbing the fields you need to submit
> and append them as the query part of the URL (essentially what you
> would get with a form with method="GET").  The javascript to itterate
> through a form and build a query string is relatively simple and there
> should be many good examples you can nick.  Remember to return false
> from the onSubmit function so that the browser doesn't submit the form
> as well.
> 
> Cheers,
> Michael

Thanks Michael, that's good advice (and I've seen it done something like that in
a very simple example - a way-too-simple example - in one of my javascript
textbooks).

Actually, after experimenting with a few things, I've managed to get it working
in a slightly different manner.

I found that I couldn't get the onSubmit() call to do what I wanted - I was
ending up with multiple (blank) windows being opened, and other such hassles.

So what I've done is to do it with an onClick() parameter to the <input
type=submit> form element.  The call is to a function that simply (re)opens the
named window (with none of the browser bars - which is the whole aim of the
exercise) when that submit button is clicked.  The window.open() command itself
is given a **blank** url, the child window's name, along with a (small) feature
list, but the <form action...> element itself still has the "target=" directive
in there, which nicely redirects the resulting output to the newly created child
target window.

Doing it in this way does exactly what I want to achieve, and without any need
to worry about re-building the selected values into the query string part of a
URL in the open() method.  (BTW, method=GET is a useful diagnostic tool,
although I've now had to resort to getting the php to actually print the $_GET
and $_POST values on part of the page to see them for debugging - there's no
more location bar to otherwise see it, hah!)

This approach seems to work just fine with mozilla, firefox and m$ie.

As it has turned out, the re-design in this manner has made some of the coding
somewhat less complicated.  I still have some style tweaking and editing to do
to a small collection of other scripts so that they work in a similar manner,
but I'm off and running with it.  Thanks heaps.

It's weird that I just wasn't getting it to happen like I wanted with
onSubmit(), despite experimenting with a few different things (and returning
false from the function call just made things worse).  I'm probably missing
something there.  But I'll have to revisit it again soon though, as I still have
to add the client-side js code to do basic sanity-checks on the selected form
values (eg, checking for the selection of valid dates - the 30th and 31st days
of Feb, etc, are never valid dates).

Actually, along the way with playing with this, I've discovered a way to use
onClick() in form elements to some advantage.

What I'm doing is displaying some data as a chart in a graphical format.  The
data happens to be a number of percentage values for any particular start date
over a selectable period of time.  The chart itself is created by some php code
on the web server, and delivered with an imagegif() command.

I have now added two more submit buttons to the form with "previous" and "next"
values, and they contain onClick() calls to a small javascript function that
alters the value of a hidden form attribute accordingly (which is initially
coded with a blank value).  The form's action script (which happens to be the
same one that generates the form) then picks up whether that hidden attribute is
set, and alters the start date displayed in the chart either forward or backward
in time according to the value of the period of time that was selected.

The end result is that the user can use these prev/next submission buttons to
easily "click through" the data forwards and backwards in time - and it works
very nicely indeed, ohh, very cool!  I hadn't originally had that in the
original design plan, but it is certainly there now.  The additional coding was
almost trivial.

Once again, thanks for all the help.  Always learning!  It's possible to do some
amazing things with all this stuff once you manage to get it under control :-)

Cheers
Tony Nugent
Home: +61 7 5526 8020