Another Form Question

**DJ WIce** · Jul 20 '05, 02:06 PM

Re: Another Form Question

"Tom" <sail_saba@cox. net> wrote in message
news:PrzRb.5181 $fD.2606@fed1re ad02...
: I have created the following code for a product select/payment form (don't
know if there is a better
: way) and I have been trying to make the following changes (unsuccessfully
so far):
:
: 1) Eliminate the submit button and submit the form with onchange.
: 2) Open the action php page in a new window.
:
:
: <form id="xyform" action="http://www.myurl/order.php" method="post">

change this in:

<form id="xyform" action="http://www.myurl/order.php" method="post"
target="_blank" >

and it will open in a new window.

: <select name="xyselecta mtanddesc" onchange="updat eXYform();">

change this in:

<select name="xyselecta mtanddesc"
onchange="docum ent.forms['xyform'].submit();">

Wouter

**Tom** · Jul 20 '05, 02:07 PM

Re: Another Form Question

Thanks for the help Wouter, but your solutions are also giving me problems...
[color=blue]
> : <form id="xyform" action="http://www.myurl/order.php" method="post">
>
> change this in:
>
> <form id="xyform" action="http://www.myurl/order.php" method="post"
> target="_blank" >
>
> and it will open in a new window.[/color]

As I said "The coding must be done in XHTML-Strict so I cannot use the name or target attributes
with FORM."
In XHTML-Strict, the TARGET attribute is depreciated, therefore I do not want to use code I will
have to change in a few month/years when browsers become more compliant with the standards.
[color=blue]
> : <select name="xyselecta mtanddesc" onchange="updat eXYform();">
>
> change this in:
>
> <select name="xyselecta mtanddesc"
> onchange="docum ent.forms['xyform'].submit();">[/color]

Although this code will cause the form to be submitted with the "onchange" command the form does not
go to the array and update the document for the fields 'amount' and 'description'. The command
submits the text description in the select field which is not recognized by the php page.

**Tom** · Jul 20 '05, 02:07 PM

Re: Another Form Question

Please note the following correction...
[color=blue][color=green][color=darkred]
>>> document.forms[0].product_name.v alue = Descriptions[i];[/color][/color][/color]

should be
[color=blue][color=green][color=darkred]
>>> > document.forms[0].product.value = Descriptions[i];[/color][/color][/color]

**Tom** · Jul 20 '05, 02:07 PM

Re: Another Form Question

grrrrr, typing to fast here...

Although this code will cause the form to be submitted with the "onchange" command the form does not
go to the array and update the document for the fields 'amount' and *** 'description' ***. The
command
submits the text description in the select field which is not recognized by the php page.

Should be *** 'product' ***

**@SM** · Jul 20 '05, 02:07 PM

Re: Another Form Question

Tom a ecrit :[color=blue]
>
> I have been trying to make the following changes (unsuccessfully so far):[/color]

I do not know XHTML, but ...
[color=blue]
> 1) Eliminate the submit button and submit the form with onchange.[/color]

function updateXYform(my FormSelect) {
var i = (myFormSelect.o ptions.selected Index>0)? i-1 : '' ;
if(document.get ElementById) {
document.getEle mentById('amoun t').value = Prices[i];
document.getEle mentById('produ ct_name').value = Descriptions[i];
document.getEle mentById('xyfor m').submit();
}
else
with(document.f orms['xyform']) {
amount.value = Prices[i];
product_name.va lue = Descriptions[i];
submit();
}
}

<select name="xyselecta mtanddesc" onchange="updat eXYform(this);" >
[color=blue]
> 2) Open the action php page in a new window.[/color]

<form id="xyform" name="xyform" action="http://www.myurl/order.php" method="post" target="_blank" >

--
******** (enlever/remove [OTER_MOI] du/from reply url) *******
Stéphane MORIAUX : mailto:stephane OTER_MOImoriaux @wanadoo.fr
Aide aux Pages Perso (images & couleurs, formulaire, CHP, JS)

http://perso.wanadoo.fr/stephane.moriaux/internet/

*************** *************** *************** *************** **

**Michael Winter** · Jul 20 '05, 02:07 PM

Re: Another Form Question

On Tue, 27 Jan 2004 12:59:56 -0700, Tom <sail_saba@cox. net> wrote:
[color=blue]
> I have created the following code for a product select/payment form
> (don't know if there is a better way) and I have been trying to
> make the following changes (unsuccessfully so far):
>
> 1) Eliminate the submit button and submit the form with onchange.[/color]

Why on Earth would you want to do that? It is an extremely bad idea. The
onchange event can be fired differently from each of the various elements.
For example, a SELECT menu might fire it when someone uses the mouse wheel
to scroll the options.

Users don't expect something as final as a form submission to occur when
they choose from a radio group, a series of checkboxes, or a menu. Don't
fiddle with the user's expectation of browser behaviour, especially with
something as critical as an e-commerce system. Keep the submit button - I
really don't see any reason reason for not using it.
[color=blue]
> 2) Open the action php page in a new window.[/color]

[snip]

Without specifying the target attribute, I don't think you can. The
general format is (from the FAQ):

<form ... target="wndname "
onsubmit="windo w.open('',this. target,'feature s');return true;">

The new window is created with the appropriate name. The target attribute
uses the same name, so the submission is directed there. Without the
target attribute, the results are not redirected. If it were a GET
submission, it would be possible; you would just create the query string
yourself and use that for the URI of the new window. However, this is not
possible with POST.

I would recommend altering the page layout generated by the server to keep
whatever information you need from the original page on the submission
page.

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

**@SM** · Jul 20 '05, 02:07 PM

Re: Another Form Question

Tom a ecrit :[color=blue]
>
> Thanks for the help Wouter, but your solutions are also giving me problems...
>[color=green]
> > <form id="xyform" action="http://www.myurl/order.php" method="post"
> > target="_blank" >[/color][/color]
[color=blue]
> As I said "The coding must be done in XHTML-Strict so I cannot use the name or target attributes
> with FORM."
> In XHTML-Strict, the TARGET attribute is depreciated,[/color]

I know that, but :
- or it is no more allowed to open a new window
- or there is an other way to do that in XHTML
which one ? don't know. You'll tell it.
[color=blue][color=green]
> > <select name="xyselecta mtanddesc"
> > onchange="docum ent.forms['xyform'].submit();">[/color]
>
> Although this code will cause the form to be submitted with the "onchange" command the form does not
> go to the array and update the document for the fields 'amount' and 'description'.[/color]

and doing :
onchange="yourf unctionIforgot( ); this.form.submi t();"
??

and to feed the php
would itn't be better
<form method="get"
?

--
******** (enlever/remove [OTER_MOI] du/from reply url) *******
Stéphane MORIAUX : mailto:stephane OTER_MOImoriaux @wanadoo.fr
Aide aux Pages Perso (images & couleurs, formulaire, CHP, JS)

http://perso.wanadoo.fr/stephane.moriaux/internet/

*************** *************** *************** *************** **

**DJ WIce** · Jul 20 '05, 02:07 PM

Re: Another Form Question

: Although this code will cause the form to be submitted with the "onchange"
: command the form does not
: go to the array and update the document for the fields 'amount' and
'description'.
: The command
: submits the text description in the select field which is not recognized
by the
: php page.

Hmm, why don't you put the arrays in the PHP script?
Save a bit Javascript worries..

wouter

**Richard Cornford** · Jul 20 '05, 02:07 PM

Re: Another Form Question

"Tom" <sail_saba@cox. net> wrote in message
news:PrzRb.5181 $fD.2606@fed1re ad02...[color=blue]
>I have created the following code for a product select/payment
>form (don't know if there is a better way) and I have been
>trying to make the following changes (unsuccessfully so far):[/color]

So this is a commercial project?
[color=blue]
>1) Eliminate the submit button and submit the form with
> onchange.[/color]

And you want to take something that would be capable of functioning
(i.e. taking the money from the customer) without JavaScript and render
it both JavaScript dependent and potentially difficult to use for anyone
who does not have (or prefers not to use (such as experienced lap-top
users) a mouse as their input device. In a commercial context forcing an
unnecessary dependence on JavaScript is potentially turning away 5-20%
(depending on who's figures you trust (if any)) of potential customers
at the design stage. Does the client appreciate that you are designing
him/her out of potential business?
[color=blue]
>2) Open the action php page in a new window.[/color]

And now, in addition to that JavaScript dependence you are going to turn
away customers who use pop-up blocking mechanisms and browsers that are
incapable of displaying additional windows. That may even be a bigger
proportion of potential customers than those who cannot use JavaScript
(and probably not groups that will overlap as the JavaScript
incapable/disabled won't see much need for pop-up blockers).

There are also variants on pop-up blocking mechanisms that force
attempts to open new windows to open the referred URL in the current
window. Meaning that any design that makes sense in multiple windows
should also make sense as a sequence of pages in the current window.
Significantly increasing the complexity of the coding for the back end,
but at least allowing the users of browsers that cannot open new window
to successfully make purchases on the resulting site.
[color=blue]
>I am using this code for different payment options (i.e., cc
>processing and paypal). As such, there are multiple forms
>on the page. The coding must be done in XHTML-Strict so I
>cannot use the name or target attributes with FORM.[/color]

So you wouldn't interpret the removal of target attributes in (x)HTML
strict as implying that if you write strict you should not be attempting
to open new windows at all? Surly if that wasn't the intended
consequence of removing the target attribute there would have been no
reason to remove it.

But XHTML doesn't sit well with commercial projects in a work where the
most popular browser (window IE) does not understand XHTML at all.
Presumably you are going to be writing Appendix C XHTML and serving it
as content-type: text/html so IE will respond to the content type and
error-correct the source back to HTML and build and HTML DOM for you to
script.

Indeed most browsers will respond to the content-type and error-correct
the source back to HTML and build an HTML DOM with it. Meaning the use
of Appendix C XHTML does nothing except burden the users system with the
additional task of error-correcting what the browser has no choice but
interpret as dubious HTML source code.

The problem arises when you read reports (on Usenet, so not necessarily
valid) of browsers getting Appendix C XHTML source served as text/html
and reading their DOCTYPE declarations, finding that they claim to be
XHTML and building an XHTML DOM from them. (This would seem to be a
foolish and arguably incorrect strategy for any browser to adopt, but
foolish and arguably incorrect behaviour from web browsers is something
we have all had to come to live with).

An XHTML DOM (even when they have been around long enough for consistent
patterns in their implementation to emerge) is in many respects very
different from an HTML DOM. So if authoring Appendix C XHTML can result
in the construction of both an HTML on some browsers and an XHTML DOM on
others then any script that is going to attempt to interact with
whichever DOM is created is not only going to have to do all the work to
cope with inconsistencies in HTML DOMs it is also going to have to
repeat much of that work in an XHTML style to cope with XHTML DOMs.

Personally I don't think that XHTML will be appropriate in a commercial
context until the majority of browsers can successfully interpret it
when served with its correct content type. In the mean while burdening
the user with the error-correcting overhead and yourself with the extra
work of scripting for even greater potential diversity in the
constructed DOM seems like a waste of resources without any return.

Probably better to write HTML strict and have the browsers understand it
as what it is and attempt to build only HTML DOMs from it. Though if the
strict DTD stands in the way of a design requirement something is wrong.
Either the designer doesn't understand the consequences of the
requirement to use a strict DTD (and so is not qualified to do their
job) or whoever set the requirement for the use of a strict DTD with the
design didn't appreciate that they would be irreconcilable (meaning they
were not qualified to make that decision).

<snip>[color=blue]
> function updateXYform()
> {
> var i;
> i = document.forms[0].xyselectamtand desc.selectedIn dex;
> if(i > 0) {i = (i - 1);}
> document.forms[0].amount.value = Prices[i];
> document.forms[0].product_name.v alue = Descriptions[i];
> }[/color]

Mozilla's current XHTML DOM implementation does not have any of the
convenience properties on the document object so there is no
document.forms collection.

<snip>[color=blue]
>I tried adding the following command to the function statement
>
>if(document.fo rms[0].xyselectamtand desc.selectedIn dex > 0)
> {
> window.open('ht tp://www.myURL/order.php','new Window');
> }[/color]

Not all browsers have a window.open function so calling it unverified
will generate JavaScript errors in those.
[color=blue]
>and deleting the <input type="submit".. .> command. The new
>window opens but no form data is POSTed.[/color]

If you insist that the submission is a POST then there is nothing you
can do except switch to a DTD that allows target attributes. Otherwise
you could append a GET request query string to the URL provided as the
parameter on the new window. Then you can cross your fingers and hope
that the user's system is going to be able to open the window else
that's another interested customer heading back to google to look for a
more competent retailer.

Richard.

Another Form Question

Another Form Question

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment