Greetings,
I am trying to solve a problem that has been inflicting my self
created Order Forms for a long time, where the problem is that as I
cannot reproduce this error myself, then it is difficult to know what
is going on.
One of these Order Forms you can see here... http://www.cardman.co.uk/orderform.php3
These forms are created using HTML, JavaScript and PHP3, where it is
the JavaScript section where this problem is coming from.
What exactly is going on is that most browsers can calculate the Total
Item Weight (see my Order Form boxes) perfectly correctly, but one or
more browsers is producing the wrong answer, where they usually return
zero grams (0g) as the Total Item Weight by mistake.
The calculation steps that it goes through are quite easy as I will
now explain.
First of all the individual item weights are stored in the array
ItemW, where element zero is left as zero, when the real item weights
start from element one.
Not to forget that if a customer selects an item and then changes
their mind and deselects it, then the line change is called using this
position zero as the reference. No values here and so there is nothing
to display and the old values are blanked out.
These item weights are only used when the Order Form has to add up all
the lines and produce your end Total Item Weight.
The JavaScript code that adds up each order form line is this one...
WArray [0] = ItemW [document.Details.Code1.selectedIndex] *
document.Details.Qty1.value;
WArray is just my temporary array in order to store the combined item
weight for each line. This was defined at the start of the JavaScript
section as...
var WArray=new Array(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);
So that line of course reads the individual item weights from my ItemW
array, where it multiplies it by the Quantity that the customer
requires, which they can directly enter on my Order Form.
Sure the user could enter junk in this field instead of the required
number, but that I highly doubt is the problem here.
If you see my Order Forms, then parseInt is also included within this
line, but that was just my old attempt at solving this problem. As
that attempt failed, then that function is not needed, which is why I
removed it here.
And so we now come down to this section...
CurrWeight = WArray [0] + WArray [1] + WArray [2] + WArray [3] +
WArray [4] + WArray [5] + WArray [6] + WArray [7] + WArray [8] +
WArray [9] + WArray [10] + WArray [11] + WArray [12] + WArray [13] +
WArray [14];
document.Details.IWeight.value = CurrWeight + "g";
What happens here is that all the line weights now stored in WArray
are added together producing our required Total Item Weight, which is
first stored in CurrWeight before being inserted into the Order Form
in the Total Item Weight box.
WArray needs to be used and defined within the start global section
upon page load, when one line is modified at a time before all the
whole lot are added up upon each call.
Simple enough code you may think, but some browsers without doubt are
messing this up. The most common result is that items have been
selected on the Order Form, but the Total Item Weight has been
incorrectly calculated as zero grams.
One other problem that I noticed recently may go to help explain this
problem, when the Total Item Weight was lower than what it should have
been. After manually calculating the values, then all the item weight
lines had been included in the Total Item Weight calculation except
for the first line on the Order Form.
Combined with previous things that I have seen before, then I suspect
what may be happening is as follows...
A ten element JavaScript array should be created as...
0,1,2,3,4,5,6,7,8,9
However, the faulty browsers may be creating their ten element array
like this instead...
1,2,3,4,5,6,7,8,9,10
That if true could explain why my Total Item Weight is being
calculated incorrectly, when writes to and reading from element zero
would result in a lost value.
My first question would be if there are any known faulty browsers who
create arrays like this?
Should this not be the problem, then I am again stumped, when I would
not have a clue why this simple code is failing on some browsers.
The only other aspect I can think of is if this page is exited and
then returned to, when who can say if all the values are restored?
If it is true, then that also poses the problem of what to do to fix
it, when it is a little tricky to know the structure of the array
before you come to use it.
I think that I may be able to create larger arrays if needed and start
from position one instead of zero, but I would have to see if this can
work out.
Anyway, if anyone has a clue what is going on, then such a mention
would be much appreciated, when I am now getting very annoyed at how
the Postal Charge sometimes gets under valued.
Thanks,
Cardman http://www.cardman.com http://www.cardman.co.uk 53  5635 
Cardman wrote: Greetings,
I am trying to solve a problem that has been inflicting my self
created Order Forms for a long time, where the problem is that as I
cannot reproduce this error myself, then it is difficult to know what
is going on.
One of these Order Forms you can see here...
http://www.cardman.co.uk/orderform.php3
These forms are created using HTML, JavaScript and PHP3, where it is
the JavaScript section where this problem is coming from.
What exactly is going on is that most browsers can calculate the Total
Item Weight (see my Order Form boxes) perfectly correctly, but one or
more browsers is producing the wrong answer, where they usually return
zero grams (0g) as the Total Item Weight by mistake.
The calculation steps that it goes through are quite easy as I will
now explain.
First of all the individual item weights are stored in the array
ItemW, where element zero is left as zero, when the real item weights
start from element one.
Not to forget that if a customer selects an item and then changes
their mind and deselects it, then the line change is called using this
position zero as the reference. No values here and so there is nothing
to display and the old values are blanked out.
These item weights are only used when the Order Form has to add up all
the lines and produce your end Total Item Weight.
The JavaScript code that adds up each order form line is this one...
WArray [0] = ItemW [document.Details.Code1.selectedIndex] *
document.Details.Qty1.value;
WArray is just my temporary array in order to store the combined item
weight for each line. This was defined at the start of the JavaScript
section as...
var WArray=new Array(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0);
So that line of course reads the individual item weights from my ItemW
array, where it multiplies it by the Quantity that the customer
requires, which they can directly enter on my Order Form.
Sure the user could enter junk in this field instead of the required
number, but that I highly doubt is the problem here.
If you see my Order Forms, then parseInt is also included within this
line, but that was just my old attempt at solving this problem. As
that attempt failed, then that function is not needed, which is why I
removed it here.
And so we now come down to this section...
CurrWeight = WArray [0] + WArray [1] + WArray [2] + WArray [3] +
WArray [4] + WArray [5] + WArray [6] + WArray [7] + WArray [8] +
WArray [9] + WArray [10] + WArray [11] + WArray [12] + WArray [13] +
WArray [14];
document.Details.IWeight.value = CurrWeight + "g";
What happens here is that all the line weights now stored in WArray
are added together producing our required Total Item Weight, which is
first stored in CurrWeight before being inserted into the Order Form
in the Total Item Weight box.
WArray needs to be used and defined within the start global section
upon page load, when one line is modified at a time before all the
whole lot are added up upon each call.
Simple enough code you may think, but some browsers without doubt are
messing this up. The most common result is that items have been
selected on the Order Form, but the Total Item Weight has been
incorrectly calculated as zero grams.
One other problem that I noticed recently may go to help explain this
problem, when the Total Item Weight was lower than what it should have
been. After manually calculating the values, then all the item weight
lines had been included in the Total Item Weight calculation except
for the first line on the Order Form.
Combined with previous things that I have seen before, then I suspect
what may be happening is as follows...
A ten element JavaScript array should be created as...
0,1,2,3,4,5,6,7,8,9
However, the faulty browsers may be creating their ten element array
like this instead...
1,2,3,4,5,6,7,8,9,10
That if true could explain why my Total Item Weight is being
calculated incorrectly, when writes to and reading from element zero
would result in a lost value.
My first question would be if there are any known faulty browsers who
create arrays like this?
Should this not be the problem, then I am again stumped, when I would
not have a clue why this simple code is failing on some browsers.
The only other aspect I can think of is if this page is exited and
then returned to, when who can say if all the values are restored?
If it is true, then that also poses the problem of what to do to fix
it, when it is a little tricky to know the structure of the array
before you come to use it.
I think that I may be able to create larger arrays if needed and start
from position one instead of zero, but I would have to see if this can
work out.
Anyway, if anyone has a clue what is going on, then such a mention
would be much appreciated, when I am now getting very annoyed at how
the Postal Charge sometimes gets under valued.
Thanks,
Cardman
http://www.cardman.com
http://www.cardman.co.uk
You can not account for all possible browsers and their behaviors.
Unless it is some intranet application (where you can control the
browsers in use), do not rely on javascript to make your forms
functional. Start with a form that has no javascript and make things
work (in your example you would have an extra step to go to the server
and calculate your totals). Then see how you can use javascript to
improve user experience and/or reduce the number of round trips. This
way you have a fall-back in case the browser does not have required
functionality, or does not have javascript enabled at all...
--
Vladdy http://www.klproductions.com
On Sat, 31 Jan 2004 20:34:43 GMT, Vladdy <vl**@klproductions.com>
wrote: You can not account for all possible browsers and their behaviors.
Well, it comes very close, but perfection is only achieved through
understanding.
If I knew what browser was causing this, then I would have the exact
cause found out and fixed.
Unless it is some intranet application (where you can control the
browsers in use), do not rely on javascript to make your forms
functional.
JavaScript makes the Internet world go round. Most of all it stops my
customers making hundreds of mistakes doing their own calculations on
their order forms.
Had you seen how bad some people's basic mathematics is, then you
would understand why my order form exists. As before hand almost every
second form contained some mistake, but with my existing order form
there is no errors beyond this one problem.
Start with a form that has no javascript and make things work
Yes, I did that years ago...
The problem as explained is within a simple calculation within
JavaScript using arrays. It seems that you did not understand my
explanation, which is why I have no answer to this problem.
(in your example you would have an extra step to go to the server
and calculate your totals).
No. The PHP3 code only deals with the form submit and following
processing. As when the page is first called, then PHP3 code would
simply dump the Order Form section (HTML and JavaScript) to the user's
browser.
So it would be handled like any other HTML and JavaScript web page,
which is why I did not forward you to any of the PHP3 code.
Then see how you can use javascript to improve user experience
Yes already done that, which explains the whole section of automatic
calculations and correcting customer's mistakes. Best of all my
customer's like the on-line payment options.
Now if only I could get all browsers doing some first grade
calculations...
I would kill that screwed up browser if I knew what it was, when every
other browser works just fine.
and/or reduce the number of round trips.
Only trips here are for page collection followed by page submission.
This way you have a fall-back in case the browser does not have
required functionality,
Yes it already does that, when you get the same page without the
Ordering Codes. Try it yourself if you want by turning JavaScript off
within your browser.
The ordering codes display are handled through JavaScript, when the
Order Form would grow to a massive size had I listed all 114 items for
each of the 12 lines. (1368 codes)
However, since the purpose of my automatic order from is to avoid
customers making mistakes by making their own, then working in such a
non-JavaScript state is not recommended.
or does not have javascript enabled at all...
Then they should get themselves a real browser. Well such JavaScript
lacking browsers make use less than 1% of my site visitors, then that
is an option not worth considering.
Anyway, I have been busy working on seeing if can fix this problem
myself, which I won't know until receiving a faulty Order Form.
You can see my temporary test version here if you desire... http://www.cardman.co.uk/oftest.php3
I have been doing a major rewrite of the main JavaScript procedure in
order to remove the WArray array. That I have done, but as a result
the update of a single line at a time has changed to updating the
whole order form at a time.
So a whole load more work for the customer's computer, but this full
recalculation helps to avoid issues if they exit the page and return,
where most of all it allows me to remove the WArray.
And so the item weights are being transferred directly from the ItemW
array to the CurrWeight (Total Item Weight) variable. This is done, as
can be seen, by adding the ItemW values to CurrWeight during each line
processing.
That does make for smaller code, but my code is larger due to
including additional error checking.
Best of all is this section...
if ((CurrWeight == 18) &&
(LinesUsed > 0))
{
document.Details.DelType.value = "Calculation Halted";
SubTotal = 0;
document.Details.DelCost.value = "";
document.Details.Info12.value = "Invalid Order Form!";
alert ("ERROR: Your browser has incorrectly calculated the Total
Item Weight. Please hit reload"+
" and try again. Should this problem persist then try using a
different browser.");
}
What this does is that if the Total Package Weight is at the minimum
possible (18g = a Total Item Weight of 0g) and some items have been
selected, then that means that the error state that I am suffering
from on rare orders has been detected.
So what then happens is that the calculation is halted (stops
providing an invalid postal rate), some boxes cleared, the Order Form
marked as invalid, where the customer is then informed of the problem
and the very solution to this problem.
In other words if my change to this section, to remove the WArray
array, does not solve this problem, then my above error trap will stop
any more invalid order forms from being received.
Not quite the universe fix that I was hoping for, but I would be
surprised if I saw another invalid Order Form.
Just too bad that one day I am going to have to throw away these years
worth of slow development and improvement of these forms and get my
site a shopping basket.
Thanks for looking at it anyway, but I thought that it was a long shot
to locate the browser or exact problem causing this fault.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Sat, 31 Jan 2004 22:49:16 +0000, Cardman <do****@spam-me.com> wrote:
[snip] Then they should get themselves a real browser. Well such JavaScript
lacking browsers make use less than 1% of my site visitors, then that
is an option not worth considering.
[snip]
Before attempting to run a commercial enterprise, I would consider
revising that opinion.
The fact of the matter is that it's not browsers that don't implement
JavaScript, it's WWW users that *choose* to disable JavaScript. You have
to realise that JavaScript support isn't guaranteed, just like CSS support
isn't. Hell, even image support isn't. This doesn't mean that you don't
use any of these, the WWW would be quite dull if nobody did, but you must
not rely on them.
Most of the time, people that post to this group don't have a choice: they
use hosts that don't have the option of server-side scripting. However, as
you do, you have no excuse not to implement your site in such a way that
provides functionality for every potential user.
Vladdy summed up what JavaScript should be used for: to enhance the user's
experience. It should not be the sole basis for a site's functionality.
You alienate a good percentage of users by using it as such.
This may not be what you'd most like to hear, but I think it will be the
general consensus of the regular posters here. Even experts in the field
of web design, like Jakob Nielsen, recommend against overuse of JavaScript.
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Cardman said:
Greetings,
I am trying to solve a problem that has been inflicting my self
created Order Forms for a long time, where the problem is that as I
cannot reproduce this error myself, then it is difficult to know what
is going on.
One of these Order Forms you can see here...
http://www.cardman.co.uk/orderform.php3
These forms are created using HTML, JavaScript and PHP3, where it is
the JavaScript section where this problem is coming from.
What exactly is going on is that most browsers can calculate the Total
Item Weight (see my Order Form boxes) perfectly correctly, but one or
more browsers is producing the wrong answer, where they usually return
zero grams (0g) as the Total Item Weight by mistake.
It may not be by mistake. It may be that a few customers have
been experimenting with spoofing your form, hoping that your
server-side system was automated to the point that nobody would
notice.
That's one reason why any price-related calculations done on the
client side should only be for the client's convenience, and must
be repeated on the server before the transaction is complete.
On Sat, 31 Jan 2004 23:31:53 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: On Sat, 31 Jan 2004 22:49:16 +0000, Cardman <do****@spam-me.com> wrote:
[snip]
Then they should get themselves a real browser. Well such JavaScript
lacking browsers make use less than 1% of my site visitors, then that
is an option not worth considering.
[snip]
Before attempting to run a commercial enterprise,
I have been running a commercial enterprise for the past six years...
Also I have over 20 qualifications in commercial computer programming,
not to forget design like SSADM, where I have also done quite a bit of
imbedded industrial programming.
In other words I am not one of the newbies who drop by with a minor
question and a poor understanding of the language. I hope that you
keep that in mind.
I would consider revising that opinion.
The fact of the matter is that it's not browsers that don't implement
JavaScript, it's WWW users that *choose* to disable JavaScript.
Yes, where as my automatic order forms are clearly marked using
JavaScript (not on that page), where they have the option to turn it
back on if they want.
Most do, some do not and make their own order form.
You have to realise that JavaScript support isn't guaranteed,
MIE and NN support it (in different forms), which covers 98% of my
site visitors. And any respected browser would add JavaScript support,
when the web lives on it.
Most people turn off JavaScript due to sites abusing this system and
often spamming them. My site does not get involved in any such
annoying actions.
just like CSS support isn't. Hell, even image support isn't.
MIE and NN take up 98% of my site visitors for a reason. Most are too
lazy to change I guess, but a browser's worth is related to what it
can display.
This doesn't mean that you don't use any of these, the WWW would be quite
dull if nobody did, but you must not rely on them.
And as I mentioned JavaScript is just as important to the web as HTML
and yes even images.
Most of the time, people that post to this group don't have a choice: they
use hosts that don't have the option of server-side scripting.
Too cheap to buy some real hosting? ;-]
And yes my site hosting has major support for just about anything you
could desire including databases, where I made sure of that when I
took out these hostings.
One day I may actually make use of it...
However, as you do, you have no excuse not to implement your site in such a
way that provides functionality for every potential user.
And how do you propose I do that? No time these days to rebuild my
site from scratch, which is why it slowly evolves over time.
Vladdy summed up what JavaScript should be used for: to enhance the user's
experience. It should not be the sole basis for a site's functionality.
I take it that you have not seen my site, when I don't even use
frames. And for note my site is not dependant on JavaScript, when it
just makes everyone's lives a whole lot easier.
Some of my users certainly do not make use of my JavaScript sections,
where they seem to do well enough.
You alienate a good percentage of users by using it as such.
Most people use MIE and have no real concept of the specifics. Your
point?
This may not be what you'd most like to hear, but I think it will be the
general consensus of the regular posters here. Even experts in the field
of web design, like Jakob Nielsen, recommend against overuse of JavaScript.
And that is why I do things like ensuring that at least one of my
three prices is displayed if JavaScript is off.
Yes this automatic order form makes heavy use of JavaScript, when it
works for mostly everyone and I have not yet found a better option.
Should you wish to see what my site looks like without JavaScript,
then turn it off and click on one of the two links below.
Cardman http://www.cardman.com http://www.cardman.co.uk
On 31 Jan 2004 15:58:30 -0800, Lee <RE**************@cox.net> wrote: It may not be by mistake. It may be that a few customers have
been experimenting with spoofing your form,
I considered that option, but as it usually only goes to slow down the
dispatch of their order, not to forget that there are much greater
savings to be found, then this is extremely unlikely.
After all this only affects the Total Item Weight and nothing else has
even been out.
hoping that your server-side system was automated to the point that
nobody would notice.
No one should notice unless they checked out the source file or tried
it with JavaScript off, but my server side processing is currently in
the minimum required state.
That's one reason why any price-related calculations done on the
client side should only be for the client's convenience,
Well it is mostly, but incorrect calculations in the system, like this
long standing problem, starts to mess up the smooth flow of things.
and must be repeated on the server before the transaction is complete.
I can spot these problems quite easily anyway, where the real problem
is sorting out a correction.
Hopefully, my recent adjustments will block this problem at the
source, thereby putting my smooth running system back on track.
Nice to hear lots of recommendations, not that I have any real
problems in such areas, but not a single idea about my JavaScript
problem so far.
Cardman http://www.cardman.com http://www.cardman.co.uk
Cardman said:
On 31 Jan 2004 15:58:30 -0800, Lee <RE**************@cox.net> wrote:
It may not be by mistake. It may be that a few customers have
been experimenting with spoofing your form,
I considered that option, but as it usually only goes to slow down the
dispatch of their order, not to forget that there are much greater
savings to be found, then this is extremely unlikely.
After all this only affects the Total Item Weight and nothing else has
even been out.
That's exactly the sort of thing I would use to test your server.
If you catch it, you're not likely to suspect that I was trying
to cheat you. It's some sort of software glitch. That's one reason why any price-related calculations done on the
client side should only be for the client's convenience,
Well it is mostly, but incorrect calculations in the system, like this
long standing problem, starts to mess up the smooth flow of things.
and must be repeated on the server before the transaction is complete.
I can spot these problems quite easily anyway, where the real problem
is sorting out a correction.
As long as you're sure you would catch it if I knocked a little
off of the price of one or two items each time I ordered.
You might want to consider writing the user's browser version
and operating system into hidden form fields, if you can't get
that information easily from your server.
"Cardman" <do****@spam-me.com> wrote in message
news:qn********************************@4ax.com...
<snip> Then they should get themselves a real browser. Well such
JavaScript lacking browsers make use less than 1% of my site
visitors, then that is an option not worth considering.
That is a bit of a chicken and the egg argument: I have created a
JavaScript dependent web site but that is OK because only a tiny
percentage of visitors don't use JavaScript. In reality having only a
tiny percentage of visitors with JavaScript unavailable or disabled is
not a justification for making a JavaScript disabled site, it is a
symptom of it.
Still, its your business and if you want to design yourself out of
something like 5-20% of your potential customers that's up to you (and
potentially good news for your competitors).
<snip>You can see my temporary test version here if you desire...
http://www.cardman.co.uk/oftest.php3
<snip>
The code on that page is incredibly repetitive and could be massively
simplified by moving the repetitive code into parameterised function
calls. As it is I don't think you are in a position to attribute
intermittent failure to an unusual web browser as it might be down to a
coding error in a branch that does not get used except under unusual
conditions, or some other unconsidered coincidence of conditions.
Richard.
On Sun, 1 Feb 2004 03:50:58 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote: "Cardman" <do****@spam-me.com> wrote in message
news:qn********************************@4ax.com.. .
<snip>Then they should get themselves a real browser. Well such
JavaScript lacking browsers make use less than 1% of my site
visitors, then that is an option not worth considering.
That is a bit of a chicken and the egg argument: I have created a
JavaScript dependent web site but that is OK because only a tiny
percentage of visitors don't use JavaScript. In reality having only a
tiny percentage of visitors with JavaScript unavailable or disabled is
not a justification for making a JavaScript disabled site, it is a
symptom of it.
Yes, something like that. In many years I have only had like three
complaints and that is because they forgot to use a JavaScript
supporting browser.
And my web site is not JavaScript dependant, or at least it was not
until I handled the menu display through a JavaScript function.
Still, its your business and if you want to design yourself out of
something like 5-20% of your potential customers that's up to you (and
potentially good news for your competitors).
My competitors fear me enough already. ;-]
<snip>You can see my temporary test version here if you desire...
http://www.cardman.co.uk/oftest.php3<snip>
That is the new version by the way and may no longer be subject to
this problem. Then how do I know if I have fixed it, when I cannot
even nail down the cause in the first place?
The code on that page is incredibly repetitive and could be massively
simplified by moving the repetitive code into parameterised function
calls.
Yes, but then for people without JavaScript I would then have no real
visible Order Form at all. That I believe is good justification of why
it should not be done.
The other factor is that I am not sure if you can create your box
labels as arrays. Like I have Code1, Code2, Code3 and so on, where
things would be better if I could do Code[1], Code[2], Code[3] in
order to access them within a loop.
Maybe I should test that, or maybe I have already done so.
As it is I don't think you are in a position to attribute
intermittent failure to an unusual web browser as it might be down to a
coding error in a branch that does not get used except under unusual
conditions,
I would say that just about all the code gets used on every call to
the ShowInfo() function. There are some choices depending on how the
customer screws it up, but they have been well tested.
As I have mentioned before the problem occurs during a very simple
process of reading the weights from the ItemW array multiplying this
by the required quantity, then storing the result in the WArray.
When those 15 values in the WArray are added together, then on over
99% of Order Forms it works just fine, but on a minority it fails to
do the calculation correctly.
The code is really too simple (and repetitive as you point out) to be
a problem with my code. Maybe I should show you some of these problem
Order Forms to see if you can figure out how it came up with these
totals?
or some other unconsidered coincidence of conditions.
Like what would happen if the page was exited and returned to. Yes
there could be some other external factor at play, but a faulty
browser is my number one theory.
After all JavaScript support in browsers are known to be subject to
the rare bug. I have seen that before, but this one problem keeps
cropping up.
Cardman http://www.cardman.com http://www.cardman.co.uk
On 31 Jan 2004 19:26:15 -0800, Lee <RE**************@cox.net> wrote: That's exactly the sort of thing I would use to test your server.
If you catch it, you're not likely to suspect that I was trying
to cheat you. It's some sort of software glitch.
My best idea so far was to have the customer's browser type and
version sent to me during the PHP3 e-mail order form copy section. As
that way I can find out what browser(s) are subject to this problem.
I can spot these problems quite easily anyway, where the real problem
is sorting out a correction.
As long as you're sure you would catch it if I knocked a little
off of the price of one or two items each time I ordered.
Not all the time, but certainly usually. And as mentioned that has
never been a problem, when only the Postage Cost (a minor expense for
the customer) has been incorrectly calculated to a lower value.
And as mentioned the problem with that crops up during the Total Item
Weight calculation and nowhere else. This code is too simple to be a
bug on my behalf.
You might want to consider writing the user's browser version
and operating system into hidden form fields, if you can't get
that information easily from your server.
That I can if they submit the form back to the server when using one
of my on-line payment methods.
However, had my customers been trying to rip me off, then I would have
known about it long ago. This problem is clearly too fixed within this
one simple code section to be planned.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Sun, 01 Feb 2004 01:31:15 +0000, Cardman <do****@spam-me.com> wrote: On Sat, 31 Jan 2004 23:31:53 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
[snip]
Before attempting to run a commercial enterprise,
I have been running a commercial enterprise for the past six years...
Also I have over 20 qualifications in commercial computer programming,
not to forget design like SSADM, where I have also done quite a bit of
imbedded industrial programming.
In other words I am not one of the newbies who drop by with a minor
question and a poor understanding of the language. I hope that you
keep that in mind.
That doesn't really mean anything. There are plenty of web developers out
there that have various qualifications, and get paid to produce websites.
However, they too still come out with rubbish that violates guidelines of
good web design.
[snip]
You have to realise that JavaScript support isn't guaranteed,
MIE and NN support it (in different forms), which covers 98% of my
site visitors. And any respected browser would add JavaScript support,
when the web lives on it.
Most people turn off JavaScript due to sites abusing this system and
often spamming them. My site does not get involved in any such
annoying actions.
You can't just put up a site that says, "It's safe to use JavaScript with
my site. I promise that I won't abuse it", and expect people to
immediately re-enable JavaScript. If they want to leave it disabled, you
should design to cope with that. As I'll point out later, you don't.
just like CSS support isn't. Hell, even image support isn't.
MIE and NN take up 98% of my site visitors for a reason. Most are too
lazy to change I guess, but a browser's worth is related to what it
can display.
You just don't get it, do you?
This doesn't mean that you don't use any of these, the WWW would be
quite dull if nobody did, but you must not rely on them.
And as I mentioned JavaScript is just as important to the web as HTML
and yes even images.
JavaScript isn't important to the Web. Sites that use pure HTML Strict can
operate just fine without it, if designed correctly. The problem is that
most sites are designed badly, with overuse of JavaScript, so JavaScript
support in browsers is important.
Most of the time, people that post to this group don't have a choice:
they use hosts that don't have the option of server-side scripting.
Too cheap to buy some real hosting? ;-]
Never heard of personal pages?
[snip]
I take it that you have not seen my site, when I don't even use
frames. And for note my site is not dependant on JavaScript, when it
just makes everyone's lives a whole lot easier.
Yes, it is. Without JavaScript, your site is useless. The start page
contains a lot of text, language translation links, and on-line payment
service links. Nothing else. To actually see the items you sell, I have to
enable JavaScript, and there is nothing on your site that states that this
is required. As I stated earlier, you can have as many qualifications as
you like, but it doesn't mean that what you produce will always be
considered "good design". You alienate a good percentage of users by using it as such.
Most people use MIE and have no real concept of the specifics. Your
point?
So damn anyone else because they don't like Microsoft's products (with
good reason)? This may not be what you'd most like to hear, but I think it will be the
general consensus of the regular posters here. Even experts in the field
of web design, like Jakob Nielsen, recommend against overuse of
JavaScript.
And that is why I do things like ensuring that at least one of my
three prices is displayed if JavaScript is off.
[snip]
And as I pointed out a moment ago, without JavaScript, they won't get
anywhere near those prices.
Even if you don't have the time - make it. You *do* need to start your
site again from scratch. Unless, of course, you just want to give the
finger to that small minority of people you obviously care so little about.
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
"Cardman" <do****@spam-me.com> wrote in message
news:ui********************************@4ax.com...
<snip> And my web site is not JavaScript dependant, or at least
it was not until I handled the menu display through a
JavaScript function.
By which I assume you mean:-
<quote cite="http://www.cardman.co.uk/oftest.php3">
<TD>
<SELECT NAME="Code1" onChange="ShowInfo()">
<SCRIPT>ShowOpts();</SCRIPT>
</SELECT>
</TD>
</quote>
And that is not only JavaScript dependent and unnecessary on a system
with PHP on the back end but it is also invalid HTML 4 as SCRIPT
elements (even with type attributes) are not allowed to be
children/descendants of SELECT elements in any of the HTML 4 DTDs.
Creating tag soup HTML is never going to be a good approach towards
creating cross-browser scripts, as there can be no expectation that any
two browsers will create the same (or at least a similar) DOM using it.
<snip>The code on that page is incredibly repetitive and could
be massively simplified by moving the repetitive code into
parameterised function calls.
Yes, but then for people without JavaScript I would then have
no real visible Order Form at all. That I believe is good
justification of why it should not be done.
I don't see any relationship between my statement and your response.
The other factor is that I am not sure if you can create
your box labels as arrays. Like I have Code1, Code2, Code3
and so on, where things would be better if I could do
Code[1], Code[2], Code[3] in order to access them within a
loop.
<URL: http://jibbering.com/faq/#FAQ4_39 >
Maybe I should test that,
Learning the language you are using would be sufficient in this case.
or maybe I have already done so.
Apparently not.
As it is I don't think you are in a position to attribute
intermittent failure to an unusual web browser as it might
be down to a coding error in a branch that does not get
used except under unusual conditions,
I would say that just about all the code gets used on every
call to the ShowInfo() function. There are some choices
depending on how the customer screws it up, but they have
been well tested.
Your current code will accept fractional quantities and goes on to
present totals based on those. That does not strike me as something that
should have made it past adequate QA testing in the context of what the
code is attempting to do.
As I have mentioned before the problem occurs during a very
simple process of reading the weights from the ItemW array
multiplying this by the required quantity, then storing the
result in the WArray.
But as the main function is 450 lines of code with assignments to the
significant variable spread out among the mass of repetitive code there
won't be many willing to wade through that to find out what it is doing,
let alone work out if it is correct.
I wouldn't be so quick to dismiss Lee's suggestion either. It is
frightening to see some of the ways in which people create JavaScript
dependent commercial sites, relying on client-side code to send them
orders in a complete form. We try time and again to explain that because
client-side scripting is wide open to manipulation and modification by
users that the information coming back from the client must always be
re-verified/calculated before it is used but a lot of the time I get the
impression that dangers are not appreciated (even after the
explanation).
Knowing how vulnerable a commercial site that appears to do the work on
the client may be I have to suspect that there will be people actively
looking for such sites and probing them for weaknesses.
You may not think that package weight is something that such people
would choose to manipulate with their probing, but that might be exactly
why they would choose it as an initial target. Not wanting to arouse
suspicion that they were probing for weaknesses at all.
In the end, with a PHP back end, there is no need for the client side
calculations of totals, delivery costs and so on to be anything more
than an optional extra to aid the user when available. With the whole
thing re-done in the consistent and reliable environment of the server
without any designed dependency on client-side scripting and
considerably less vulnerability to exploitation by the unscrupulous.
Richard.
Cardman said:
On 31 Jan 2004 19:26:15 -0800, Lee <RE**************@cox.net> wrote:
As long as you're sure you would catch it if I knocked a little
off of the price of one or two items each time I ordered.
Not all the time, but certainly usually. And as mentioned that has
never been a problem, when only the Postage Cost (a minor expense for
the customer) has been incorrectly calculated to a lower value.
It sounds like there's no way for you to know whether or not
that has ever been a problem. People might be cheating you
every day.
However, had my customers been trying to rip me off, then I would have
known about it long ago. This problem is clearly too fixed within this
one simple code section to be planned.
How would you have known?
The fact that you've identified what part of your code could
cause the same symptoms doesn't mean that it isn't somebody
spoofing you, particularly since there don't seem to be any
known browsers that would cause the problem you describe.
On Sun, 1 Feb 2004 15:05:49 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote: "Cardman" <do****@spam-me.com> wrote in message
news:ui********************************@4ax.com.. .
<snip>And my web site is not JavaScript dependant, or at least
it was not until I handled the menu display through a
JavaScript function.
By which I assume you mean:-
No, that is just the Order Form, when the menu I mentioned is on the
index page. All those buttons on the left (under JavaScript
control)...
<quote cite="http://www.cardman.co.uk/oftest.php3">
<TD>
<SELECT NAME="Code1" onChange="ShowInfo()">
<SCRIPT>ShowOpts();</SCRIPT>
</SELECT>
</TD>
</quote>
And that is not only JavaScript dependent and unnecessary on a system
with PHP on the back end
Ah well my brother wrote the PHP code, where I have only briefly
modified it. Since I have never seen a PHP manual, then I am not even
sure what it can do, including the basics like functions and
procedures.
but it is also invalid HTML 4 as SCRIPT
elements (even with type attributes) are not allowed to be
children/descendants of SELECT elements in any of the HTML 4 DTDs.
Well it worked. :-]
I can always move the select elements into the JavaScript code as well
if that would please you? Or are forms also an issue?
Creating tag soup HTML is never going to be a good approach towards
creating cross-browser scripts, as there can be no expectation that any
two browsers will create the same (or at least a similar) DOM using it.
Not sure what you mean here, but I will look into doing that section
in PHP. Ideas welcome...
I don't see any relationship between my statement and your response.
Not if you used PHP to do the work. I am just doubtful that PHP can do
all the work.
The other factor is that I am not sure if you can create
your box labels as arrays. Like I have Code1, Code2, Code3
and so on, where things would be better if I could do
Code[1], Code[2], Code[3] in order to access them within a
loop.
<URL: http://jibbering.com/faq/#FAQ4_39 >
Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.
I have a feeling that you would not approve of me turning my extremely
repetitive form creation over to a JavaScript function.
Maybe I should test that,
Learning the language you are using would be sufficient in this case.
Hey i've been bitch slapped. ;-]
To an experienced programmer like myself dozens of languages come and
go all the time, where it is all about knowing enough to get the job
done. Highly efficient code, and knowing ever obscure fact, are for
those wanting to spend their life on the one language.
or maybe I have already done so.
Apparently not.
Well I did and it failed, when I was not aware that (unlike any other
language that I have seen) you can join together text sections in
parenthesis to make your label name.
I would have created it myself like linking these labels to a pointer
based array, but then JavaScript is not that advanced.
I would say that just about all the code gets used on every
call to the ShowInfo() function. There are some choices
depending on how the customer screws it up, but they have
been well tested.
Your current code will accept fractional quantities
Except that all the numbers that it makes use of are whole numbers. In
the only case that a fraction would be returned, then the Math.round
function is used to once again return a whole number.
and goes on to present totals based on those.
The repeated addition of whole numbers do not create fractions.
That does not strike me as something that
should have made it past adequate QA testing in the context of what the
code is attempting to do.
Sorry, but the CurrWeight variable can never return a fraction, when
no fractions are ever put into it.
That is proved due to the fact that only whole numbers are ever
returned at the end of these calculations. And had fractions been
used, then that is not a problem anyway.
As I have mentioned before the problem occurs during a very
simple process of reading the weights from the ItemW array
multiplying this by the required quantity, then storing the
result in the WArray.
But as the main function is 450 lines of code with assignments to the
significant variable spread out among the mass of repetitive code there
won't be many willing to wade through that to find out what it is doing,
let alone work out if it is correct.
Then let me optimise it a bit. Still, most of that code is in the HTML
section, where as mentioned there is not much to the start of the
(only place that it is used) ShowInfo function.
By the time that I have finished with it, then such repetitive
sections should no more.
I wouldn't be so quick to dismiss Lee's suggestion either. It is
frightening to see some of the ways in which people create JavaScript
dependent commercial sites, relying on client-side code to send them
orders in a complete form.
Well, since it works for just about everyone, then I believe that you
overstate the case.
The real problems with JavaScript is some very usual browsers lack of
such support, and then people who have been abusing this code and
annoying people.
Other languages could soon start of suffer the same fate, then these
same annoying people are moving to a new level of annoyance.
I have even lost Telnet access on my hosting in recent years simply
because some low life will use and abuse everything that they can.
We try time and again to explain that because
client-side scripting is wide open to manipulation and modification by
users that the information coming back from the client must always be
re-verified/calculated before it is used but a lot of the time I get the
impression that dangers are not appreciated (even after the
explanation).
That is all well and good, except that I am completely sure that I
have never suffered this problem.
As mentioned on my Order Form Information page, then any data
inaccuracy on the Order Form is caused by the clients browser, in
which case this problem order form will be pending correction.
Customers slowing down the dispatch of their order serves no real
purpose.
Knowing how vulnerable a commercial site that appears to do the work on
the client may be I have to suspect that there will be people actively
looking for such sites and probing them for weaknesses.
That may be possible, but in this case even 1 or 2 GBP inaccuracy in
the Postal Weight calculation will still make me a profit.
And larger inaccuracy, which would be the point of such a scheme,
would be very easy to spot, when I deal with my item prices all the
time.
You may not think that package weight is something that such people
would choose to manipulate with their probing, but that might be exactly
why they would choose it as an initial target. Not wanting to arouse
suspicion that they were probing for weaknesses at all.
Then I would make a profit and they would find out that it does not
work. :-]
Maybe it can work on an even larger company, but as mentioned I have
never had such a problem.
Also since all these problem Order Forms are clearly marked with zero
grams on the form, then who would advertise their false calculation?
Now that you are over your paranoia episode, then lets deal with the
problem. Not that I do not appreciate your ideas in increasing my
site's support for as many people as possible mind you.
In the end, with a PHP back end, there is no need for the client side
calculations of totals, delivery costs and so on to be anything more
than an optional extra to aid the user when available.
Well, I will have to see just what PHP can do, when clearly the
features that already exist are important. Like the automatic filling
in of data in the boxes and the end calculations.
These totals can be recalculated in the PHP section, but that is a
whole load of data that has to be duplicated. Ideally it should be
removed from JavaScript, but it would require active server-side
processing instead of waiting for an end submit.
With the whole
thing re-done in the consistent and reliable environment of the server
without any designed dependency on client-side scripting and
considerably less vulnerability to exploitation by the unscrupulous.
And I agree that this would be a step up from what I have, but at this
time I do not have the required time to make this step seeing that
there really is not a problem here.
More importantly would be to move my main menu out of JavaScript
control, but that is there when it is too much to deal with in simple
HTML.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Sun, 01 Feb 2004 13:35:20 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: That doesn't really mean anything. There are plenty of web developers out
there that have various qualifications, and get paid to produce websites.
However, they too still come out with rubbish that violates guidelines of
good web design.
The problem in that case would be browsers who allow such poor design
to work, when even Netscape once allowed direct Java function calls
from JavaScript.
You can't just put up a site that says, "It's safe to use JavaScript with
my site. I promise that I won't abuse it", and expect people to
immediately re-enable JavaScript. If they want to leave it disabled, you
should design to cope with that. As I'll point out later, you don't.
They don't even have to bother with HTML at all, when you can still
view it as pure text. Most people do not go to such extremes, when
they would be crazy.
JavaScript isn't important to the Web.
Funny how just about every web site uses it. And that even includes
Microsoft and IBM I see.
Sites that use pure HTML Strict can
operate just fine without it, if designed correctly. The problem is that
most sites are designed badly, with overuse of JavaScript, so JavaScript
support in browsers is important.
Since there is not much to fear about JavaScript, when say it does not
even support file functions, then the only real problem are those
people who use it for say window popups.
Most of the time, people that post to this group don't have a choice:
they use hosts that don't have the option of server-side scripting.
Too cheap to buy some real hosting? ;-]
Never heard of personal pages?
Sure, but have you ever heard of don't look a gift horse in the mouth?
They want to do all that CGI/Pearl/Databases stuff, then they should
get themselves a real web site. After all they are sure to get much
better support and services as well.
You get what you pay for in other words, which explains my above
statement.
Since I am here and you are recommending not using JavaScript, then I
wonder what ever happened to Netscape's server-side JavaScript
processing system that was called LiveWire?
I take it that you have not seen my site, when I don't even use
frames. And for note my site is not dependant on JavaScript, when it
just makes everyone's lives a whole lot easier.
Yes, it is. Without JavaScript, your site is useless.
Well I did consider long and hard if I should turn over my main menu
to JavaScript control, where when I did so I did not even have a
single complaint.
If you know of an alternate option, then I would be interested in
hearing it.
The start page
contains a lot of text, language translation links, and on-line payment
service links. Nothing else.
No menu in other words.
To actually see the items you sell, I have to
enable JavaScript,
To get the menu.
and there is nothing on your site that states that this is required.
True, where maybe I should have added that when I moved the menu
control over.
As I stated earlier, you can have as many qualifications as
you like, but it doesn't mean that what you produce will always be
considered "good design".
And different people have different views. I believe that the correct
answer is that JavaScript has just been superceeded by better
languages.
So damn anyone else because they don't like Microsoft's products (with
good reason)?
My site works just fine in Netscape and most over popular browsers as
well. Anyway not using such good browsers, or which there a many,
would be recommended to get a better browser.
I remember years also that I had to tell one person to upgrade their
browser version, due to missing text, when they were still sorting out
HTML at the time.
So should I not use certainly features in HTML due to old obsolete
browser versions?
And that is why I do things like ensuring that at least one of my
three prices is displayed if JavaScript is off.
[snip]
And as I pointed out a moment ago, without JavaScript, they won't get
anywhere near those prices.
Well, turning the menu back over to HTML is not an option, where I
have yet to discover a better option.
Even if you don't have the time - make it.
Customers be damned then.
You *do* need to start your site again from scratch.
The only real issues on my site as it exists would be the main menu
and the EUR and USD values.
Also, I do not see that it is helpful to say "start your site again
from scratch" simply because it does not match your favoured design,
when at most only a couple of changes need to be done.
Sure, I have huge plans for what I would like to do with my site, but
I only have to time to move slowly in that direction.
Unless, of course, you just want to give the
finger to that small minority of people you obviously care so little about.
All a matter of supply and demand to me, when by making the demand,
then you will get the support.
Maybe you should go and see how important JavaScript is to the Web,
when most sites will not function well without it.
I turned JavaScript off once, for some reason that I now forget, when
it only took about two hours before I had no choice except to turn it
back on again.
Life is simple and easy with JavaScript, even if people these days
need to get themselves a pop-up killer application.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Sun, 01 Feb 2004 19:19:19 +0000, Cardman <do****@spam-me.com>
wrote: Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.
Unless it's Flanagan Ed.4 I really would anyway, if it is that one,
avoid the old parts - you'll need to buy Ed.3 and compare...
To an experienced programmer like myself dozens of languages come and
go all the time, where it is all about knowing enough to get the job
done. Highly efficient code, and knowing ever obscure fact, are for
those wanting to spend their life on the one language.
Odd, all the experienced programmers I know tend to author highly
efficient code in all the languages - perhaps not to the extent of
knowing HTML DOM optimisations, but certainly knowing that functions
and repeating code are bad.
Well I did and it failed, when I was not aware that (unlike any other
language that I have seen) you can join together text sections in
parenthesis to make your label name.
I understood you were an experienced programmer with dozens of
languages - such functionality is near universal in the scripting
languages isn't it?
I have even lost Telnet access on my hosting in recent years simply
because some low life will use and abuse everything that they can.
The fact you were ever using telnet suggests you needed to get some
better experience, the fact you now decry the lack of it suggests you
desperately need to get some more experience.
And larger inaccuracy, which would be the point of such a scheme,
would be very easy to spot, when I deal with my item prices all the
time.
the problem comes with you accepting the order at the price they offer
- a good lawyer would have little problem in forcing you to comply and
even if not, do you really want the cost of fighting it?
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
On 1 Feb 2004 07:15:09 -0800, Lee <RE**************@cox.net> wrote: It sounds like there's no way for you to know whether or not
that has ever been a problem. People might be cheating you
every day.
Is there some purpose to this paranoia? Wanting to see me a new system
or something?
However, had my customers been trying to rip me off, then I would have
known about it long ago. This problem is clearly too fixed within this
one simple code section to be planned.
How would you have known?
I know my item prices. Not to forget that Order Forms are post
processed into my spreadsheet tracking such facts.
The fact that you've identified what part of your code could
cause the same symptoms doesn't mean that it isn't somebody
spoofing you,
And why would they clearly advertise this fact on their Order Form if
it was true? When having a Total Item Weight of zero grams is a very
easy thing to spot.
One fact is that for Inland Recorded delivery I charge £2 at minimum,
where the Total Package Weight would have to exceed 450 grams in order
to increase the cost to £3.
It would serve on purpose to manually set the Total Item Weight to
zero grams for any real Total Package Weight of less than 450g, when
the minimum postage cost will still be £2.
Such errors that do not affect the Postage Cost are the most common
occurrence of this problem that I see. In other words this problem
occurs, but the end payment total is not affected at all.
particularly since there don't seem to be any
known browsers that would cause the problem you describe.
Maybe I should go and ask these customers what they are using then,
when there may indeed be a pattern.
As mentioned this problem is not the customers doing it manually, when
all signs point to this fact. Not to mention that trying to submit a
such user modified false data to my hosting for on-line payment would
be rendered close to impossible due to the PHP code.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Sun, 01 Feb 2004 19:58:47 GMT, ji*@jibbering.com (Jim Ley) wrote: On Sun, 01 Feb 2004 19:19:19 +0000, Cardman <do****@spam-me.com>
wrote:Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.
Unless it's Flanagan Ed.4 I really would anyway, if it is that one,
avoid the old parts - you'll need to buy Ed.3 and compare...
No, the one I have is titled "Using JavaScript Second Edition (Special
Edition)". Other attached terms are "The Most Complete Reference" and
"World's Best Selling Series".
ISBN 0-7897-1138-9
I will check out your recommended choice.
Odd, all the experienced programmers I know tend to author highly
efficient code in all the languages - perhaps not to the extent of
knowing HTML DOM optimisations, but certainly knowing that functions
and repeating code are bad.
Certainly, but take my latest Order Form changes for example...
http://www.cardman.co.uk/oftest.php3
I just removed a lot of the repeating text and reduced the file size
by over 10k. Makes reading easier as well, but adding those loops now
adds more processing time to it.
In other words instead of one straight line it now does loops, which
in the end makes program execution slower.
I will have to see how I can optimise it further and make it even
smaller and slower. And you may care to notice my lack of function
calls during this new code, when pushing and popping to/from the stack
sure does slow thing down.
Just don't forget that when a program works, then that is the job
done, where optimizing it just takes lots of time and effort to have
that same job done slightly better.
Since time is money, then large work on optimization is only needed
when the project has space or speed constraints. You usually find that
when trying to cram code into a microcontroller.
I have even lost Telnet access on my hosting in recent years simply
because some low life will use and abuse everything that they can.
The fact you were ever using telnet suggests you needed to get some
better experience,
Well Telnet is useful when your hosting provider messes up your
hosting. Like one time when my FTP access was down, where I logged in
through Telnet, made a Telnet connection to my second site, then
downloaded the required files directly.
the fact you now decry the lack of it suggests you
desperately need to get some more experience.
Telnet is a tool, where it is useful depending on what you want to do.
I was thinking about Telnet recently wondering where my hosting
provider kept the Perl files (my first use), where with Telnet access
I could have answered that question myself, but now I will have to ask
them.
If you can name another method to search my hosting provider's server
for lost files, then maybe I don't need Telnet after all. Except when
my FTP or Admin access breaks down of course.
And larger inaccuracy, which would be the point of such a scheme,
would be very easy to spot, when I deal with my item prices all the
time.
the problem comes with you accepting the order at the price they offer
Orders are only accepted when the correct payment has been made.
- a good lawyer would have little problem in forcing you to comply and
even if not, do you really want the cost of fighting it?
Well that is a pointless example.
If the user's system miscalculates the total, then they are obviously
responsible for the inaccuracy.
Cardman http://www.cardman.com http://www.cardman.co.uk
<snip> Simple enough code you may think, but some browsers without doubt are
messing this up.
I'm just a self taught mid level programmer, but that is not simple code.
It's terribly convoluted and inefficient. It could easily be done in tenth
of what you have.
You shouldn't be using numerically index arrays at all. Something like this
is far easier:
var weightArray=['white':8.1,'p84':5.3...]
I would call that a hash in perl.
ditto for the descriptions.
Then loop through the form and do the calculations. You really don't need
tons of ifs
And by all means server side check.
Jeff
The most common result is that items have been
selected on the Order Form, but the Total Item Weight has been
incorrectly calculated as zero grams.
One other problem that I noticed recently may go to help explain this
problem, when the Total Item Weight was lower than what it should have
been. After manually calculating the values, then all the item weight
lines had been included in the Total Item Weight calculation except
for the first line on the Order Form.
Combined with previous things that I have seen before, then I suspect
what may be happening is as follows...
A ten element JavaScript array should be created as...
0,1,2,3,4,5,6,7,8,9
However, the faulty browsers may be creating their ten element array
like this instead...
1,2,3,4,5,6,7,8,9,10
That if true could explain why my Total Item Weight is being
calculated incorrectly, when writes to and reading from element zero
would result in a lost value.
My first question would be if there are any known faulty browsers who
create arrays like this?
Should this not be the problem, then I am again stumped, when I would
not have a clue why this simple code is failing on some browsers.
The only other aspect I can think of is if this page is exited and
then returned to, when who can say if all the values are restored?
If it is true, then that also poses the problem of what to do to fix
it, when it is a little tricky to know the structure of the array
before you come to use it.
I think that I may be able to create larger arrays if needed and start
from position one instead of zero, but I would have to see if this can
work out.
Anyway, if anyone has a clue what is going on, then such a mention
would be much appreciated, when I am now getting very annoyed at how
the Postal Charge sometimes gets under valued.
Thanks,
Cardman
http://www.cardman.com
http://www.cardman.co.uk
On Sun, 01 Feb 2004 19:59:23 +0000, Cardman <do****@spam-me.com> wrote: On Sun, 01 Feb 2004 13:35:20 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
[snip]
JavaScript isn't important to the Web.
Funny how just about every web site uses it. And that even includes
Microsoft and IBM I see.
[moved] Maybe you should go and see how important JavaScript is to the Web,
when most sites will not function well without it.
Just because many sites, including those of well-known businesses, use
JavaScript doesn't make it important to the Web. That just means that it's
popular and over-used. The two things that make the Web are mark-up
languages and style sheets. Those two, by themselves, provide both the
content and the presentation. JavaScript provides some dynamic content and
interaction, but it certainly can be done without, particularly if you
allow for server-side scripting. Other technologies can provide
interaction more reliably, and look better doing it, too.
[snip] Without JavaScript, your site is useless.
Well I did consider long and hard if I should turn over my main menu
to JavaScript control, where when I did so I did not even have a
single complaint.
If you know of an alternate option, then I would be interested in
hearing it.
Tomorrow, if I have the time, I will recreate your front page using only
HTML and CSS. There won't be a single script statement in the document.
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
On Sun, 01 Feb 2004 23:56:44 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: Just because many sites, including those of well-known businesses, use
JavaScript doesn't make it important to the Web.
One reason why it is "important to the web" is that, not unlike HTML,
it is easy for use. Kind of like a baby language that you can slap
around and it keeps on ticking.
Since it is an easy for new site owners to start doing useful things
with, then it is an important level between HTML and the much more
powerful languages.
Without JavaScript, then most web pages would not do anything beyond
moving from one page to the next, when most other popular web
languages (like Perl and CGI) are much harder to start off with.
That just means that it's popular and over-used.
And not respected it seems. As you must admit that it gets the job
done, where that is what really counts here.
The two things that make the Web are mark-up
languages and style sheets. Those two, by themselves, provide both the
content and the presentation.
Yes, just like reading a book.
JavaScript provides some dynamic content and
interaction, but it certainly can be done without,
My automatic Order Form does a wealth of features all on the single
page, where it guides, calculates, formats, displays, warns, validates
and finally prints.
My customers can make no real errors on my Order Forms, when it
handles as much of the work for them as is possible.
particularly if you allow for server-side scripting.
Well something has to do the calculation, but I am sure that involves
moving to multiple pages.
If I ever desire going that far, then it is time for the whole
shopping basket and customer database thing.
Other technologies can provide
interaction more reliably, and look better doing it, too.
Look better? My Order Form is not exactly ugly, but you do even have
those annoying flash intros these days. If you know of an alternate option, then I would be interested in
hearing it.
Tomorrow, if I have the time, I will recreate your front page using only
HTML and CSS. There won't be a single script statement in the document.
That sounds incredibly cool, where I certainly hope that you do. Fix
my EUR and USD price function at the same time, then my whole site is
good once more.
And yes I will even sort out my automatic Order Form one day, which I
planned to do anyway, but rebuilding my entire ordering process from
scratch at this time is not the best idea.
Cardman http://www.cardman.com http://www.cardman.co.uk
"Cardman" <do****@spam-me.com> wrote in message
news:mf********************************@4ax.com...
<snip> Ah well my brother wrote the PHP code, where I have only
briefly modified it. Since I have never seen a PHP manual,
then I am not even sure what it can do, including the basics
like functions and procedures.
PHP is capable of many things but one thing that it is really good at is
dynamically generating HTML.
but it is also invalid HTML 4 as SCRIPT elements
(even with type attributes) are not allowed to be
children/descendants of SELECT elements in any of
the HTML 4 DTDs.
Well it worked. :-]
It is not so much a matter of whether what you have done works as
expected in the browsers in which you have tested it. It is a design
principal for cross-browser scripting: only valid HTML justifies the
expectation that the browser will create the expected DOM with that
HTML.
I can always move the select elements into the JavaScript code
as well if that would please you? Or are forms also an issue?
The PHP should be assembling the SELECT element and its contents.
<snip><URL: http://jibbering.com/faq/#FAQ4_39 >
Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.
It is astounding how many inadequate (and often actively bad) JavaScript
books there are. Given that JavaScript is an object based language
designed to script arbitrary object models it if frankly perverse for
books on the subject not to cover both of the languages property
accessor syntaxes.
<snip>To an experienced programmer like myself dozens of languages
come and go all the time, where it is all about knowing enough
to get the job done. Highly efficient code, and knowing ever
obscure fact, are for those wanting to spend their life on the
one language.
To be honest, judging by the structure of the original code on your
order form and some of the logic you apply to your reasoning, I would
not have believed that you were an experienced programmer.
As languages go JavaScript is relatively small, because it relies on the
object model being scripted to provide the functionality that is needed
in its environment. It is learning the object models that takes time,
JavaScript is sufficiently defined in the 170 pages of the ECMA
specification.
<snip>I would have created it myself like linking these labels
to a pointer based array, but then JavaScript is not that
advanced.
What are you expecting to be able to do with a pointer that cannot be
done with an object reference?
<snip> Your current code will accept fractional quantities
Except that all the numbers that it makes use of are whole numbers.
<snip>
Not if the user enters a fraction in the quantity field. (and don't
forget that your reasoning for doing all of these calculations was
because the users cannot do the maths for themselves reliably, so you
should equally suspect them of entering meaningless values in the
quantity field.)
Richard.
On Mon, 2 Feb 2004 01:49:04 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote: "Cardman" <do****@spam-me.com> wrote in message
news:mf********************************@4ax.com.. .
<snip>Ah well my brother wrote the PHP code, where I have only
briefly modified it. Since I have never seen a PHP manual,
then I am not even sure what it can do, including the basics
like functions and procedures.
PHP is capable of many things but one thing that it is really good at is
dynamically generating HTML.
I see. Like my Item Codes select list.
Well it worked. :-]
It is not so much a matter of whether what you have done works as
expected in the browsers in which you have tested it. It is a design
principal for cross-browser scripting: only valid HTML justifies the
expectation that the browser will create the expected DOM with that
HTML.
True, but anything that can run on all the most popular browsers
cannot be that bad. Still, as you point out changing this section will
increase support, which is why that makes a good reason to do it.
I can always move the select elements into the JavaScript code
as well if that would please you? Or are forms also an issue?
The PHP should be assembling the SELECT element and its contents.
Then I may soon have it doing just that, but I can begin to foresee
one problem with this idea.
As I have always kept an eye on the size of my files, when people with
a slow modem would spend about half a minute downloading my Order Form
as it is.
By having PHP take control of the building of these sections, then the
file when sent to the user will now be ***huge***. Since JavaScript is
already important to the working of this page, then maybe JavaScript
should maintain control of this building.
I will think about that for a while before deciding, but I can see
more reasons to keep it with JavaScript than to move to PHP. Tough
one, when there are good reasons both ways.
Ah thanks, just what I need. Time to burn my useless 856 page
JavaScript manual that does not mention such useful things.
It is astounding how many inadequate (and often actively bad) JavaScript
books there are. Given that JavaScript is an object based language
designed to script arbitrary object models it if frankly perverse for
books on the subject not to cover both of the languages property
accessor syntaxes.
Then that should remind you that most experts cannot know everything,
which was obviously unhelpful in my case.
Some of my even older books have a section at the back containing
several blank lined pages, which was intended for their readers to
note down any missing details or their own useful solutions.
And certainly in more then a few books I have had to debug some of
their code examples.
In fact I do even recall a couple of books that appear to have been
created by some very odd authors, where their code examples had just
plain bad structuring.
<snip>To an experienced programmer like myself dozens of languages
come and go all the time, where it is all about knowing enough
to get the job done. Highly efficient code, and knowing ever
obscure fact, are for those wanting to spend their life on the
one language.
To be honest, judging by the structure of the original code on your
order form
It was not well optimised, but then you know the reason for that.
and some of the logic you apply to your reasoning,
Oh? Just what it that? As it still does exactly the same as it did
before, where I have just improved the error checking somewhat.
I would not have believed that you were an experienced programmer.
Then obviously your assumption is wrong, when I am not just an
experienced programmer, but one that usually impresses the other
experienced programmers, not to forget my former lecturers.
One problem these days is that I do not do nearly as much coding as
what I used to do, due to now running an unrelated company, which is
why some languages have fallen out of favour, while other new
languages have gained favour.
I even once learned COBOL...
As languages go JavaScript is relatively small, because it relies on the
object model being scripted to provide the functionality that is needed
in its environment. It is learning the object models that takes time,
JavaScript is sufficiently defined in the 170 pages of the ECMA
specification.
Then you need to point this out to book authors, when with 856 pages
they appear to have achieved less.
<snip>I would have created it myself like linking these labels
to a pointer based array, but then JavaScript is not that
advanced.
What are you expecting to be able to do with a pointer that cannot be
done with an object reference?
Just my favoured method of data access, where having a pointer to an
array allows myself and others direct memory access and to cut up and
move the data about however I please.
Except that all the numbers that it makes use of are whole numbers.
<snip>
Not if the user enters a fraction in the quantity field.
The final value is rounded anyway, where decimals are not really a
problem.
(and don't
forget that your reasoning for doing all of these calculations was
because the users cannot do the maths for themselves reliably, so you
should equally suspect them of entering meaningless values in the
quantity field.)
That it certainly possible, but never once in all these years has any
customer ever sent me a form with such an error. So they are simply
not that lacking in intelligence, when they know that a number has to
be entered here.
For that lack of a valid reason, then I have now wasted another four
lines of code in adding error checking and rounding to this Qty value
in the line processing section. And that works well enough, but it is
still subject to issues if they enter like "100a".
Before I make my own "is it a numeric value?" function to solve this
small flaw, then I will see if one already exists.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 02 Feb 2004 11:52:02 +0000, Cardman <do****@spam-me.com> wrote: On Mon, 2 Feb 2004 01:49:04 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
[snip] It is not so much a matter of whether what you have done works as
expected in the browsers in which you have tested it. It is a design
principal for cross-browser scripting: only valid HTML justifies the
expectation that the browser will create the expected DOM with that
HTML.
True, but anything that can run on all the most popular browsers
cannot be that bad.
You'd be surprised how wrong things can go when attempting to use the DOM
with an invalid document. The tree can end up looking nothing like the
input HTML, making node traversal very difficult. It's always a wise idea
to use valid HTML, especially as there is no reason, other than ignorance
or laziness, to follow the specification. The PHP should be assembling the SELECT element and its contents.
Then I may soon have it doing just that, but I can begin to foresee
one problem with this idea.
As I have always kept an eye on the size of my files, when people with
a slow modem would spend about half a minute downloading my Order Form
as it is.
By having PHP take control of the building of these sections, then the
file when sent to the user will now be ***huge***. Since JavaScript is
already important to the working of this page, then maybe JavaScript
should maintain control of this building.
I will think about that for a while before deciding, but I can see
more reasons to keep it with JavaScript than to move to PHP. Tough
one, when there are good reasons both ways.
You do realise that when a browser requests a PHP page, that file is not
returned, don't you? The data returned is the result of parsing the
document. Moving to all PHP, using JavaScript purely for interaction (not
generation), will probably reduce the amount of data downloaded by the
user. The size of a PHP file is not necessarily proportional to the size
of the result.
[snip]
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
On Mon, 02 Feb 2004 14:10:51 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: On Mon, 02 Feb 2004 11:52:02 +0000, Cardman <do****@spam-me.com> wrote:
True, but anything that can run on all the most popular browsers
cannot be that bad.
You'd be surprised how wrong things can go when attempting to use the DOM
with an invalid document. The tree can end up looking nothing like the
input HTML, making node traversal very difficult. It's always a wise idea
to use valid HTML, especially as there is no reason, other than ignorance
or laziness, to follow the specification.
Well, as you can see I have now fixed that issue, when now JavaScript
makes that whole section. I will soon do a PHP building version and
see how they compare.
I will think about that for a while before deciding, but I can see
more reasons to keep it with JavaScript than to move to PHP. Tough
one, when there are good reasons both ways.
You do realise that when a browser requests a PHP page, that file is not
returned, don't you?
As I well understand that fact, then you misunderstood my point.
The data returned is the result of parsing the
document. Moving to all PHP, using JavaScript purely for interaction (not
generation), will probably reduce the amount of data downloaded by the
user.
Er, wrong.
My Ordering Code select list is currently handled by JavaScript and
takes up 21 lines to build all 12 select lists. Or I guess you would
count that as 135 if you include the Order Code array.
Should I move this to PHP, then certainly the used code could make the
PHP file even less. However, as you point out the PHP file is not sent
to the user, when it has to be parsed first.
The result of that parsing will be that the Ordering Code select list
will be inserted into the HTML code 12 times. That means that the HTML
code will lose the existing 21/135 lines and gain another 1404 lines,
I have not counted how many lines the non-PHP code in the oftest.php3
file take up, but this could well be doubled or even tripled.
You can see why I am reluctant to have PHP build these sections, when
the file size will become huge and take ages for a user with a slow
modem to download.
The size of a PHP file is not necessarily proportional to the size
of the result.
Yes, when those "results" are going to "balloon", which explains why I
had JavaScript handle these in the first place.
Ideas on how to transfer my long list of Ordering Codes just once
instead of 12 times would be welcome.
Cardman http://www.cardman.com http://www.cardman.co.uk
Cardman said:
On 1 Feb 2004 07:15:09 -0800, Lee <RE**************@cox.net> wrote:
It sounds like there's no way for you to know whether or not
that has ever been a problem. People might be cheating you
every day.
Is there some purpose to this paranoia? Wanting to see me a new system
or something?
I'm trying to warn you about how you might be being ripped off.
If your pride gets in the way of your accepting a warning, I
guess that's not my problem.
However, had my customers been trying to rip me off, then I would have
known about it long ago. This problem is clearly too fixed within this
one simple code section to be planned.
How would you have known?
I know my item prices. Not to forget that Order Forms are post
processed into my spreadsheet tracking such facts.
Fine. Do you check each price?
Such errors that do not affect the Postage Cost are the most common
occurrence of this problem that I see. In other words this problem
occurs, but the end payment total is not affected at all.
As I said earlier, it would be a good way to test your security.
If you catch the problem, you won't believe it's deliberate.
If you don't catch it, they can move on to changing prices.
As mentioned this problem is not the customers doing it manually, when
all signs point to this fact.
You don't seem to have any signs. You've concocted an explanation
that requires that some browsers not support an array index of 0,
which seems much less likely than that somebody is playing with
your forms.
Not to mention that trying to submit a
such user modified false data to my hosting for on-line payment would
be rendered close to impossible due to the PHP code.
That would be what they were trying to find out, by submitting
forms with the weight changed. But, from what you've said
before, and from what I see in your form, I'm not convinced
that it would be difficult to slip false data past your code.
On Mon, 02 Feb 2004 14:54:53 +0000, Cardman <do****@spam-me.com> wrote: On Mon, 02 Feb 2004 14:10:51 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
On Mon, 02 Feb 2004 11:52:02 +0000, Cardman <do****@spam-me.com> wrote:
[snip]
I will think about that for a while before deciding, but I can see
more reasons to keep it with JavaScript than to move to PHP. Tough
one, when there are good reasons both ways.
You do realise that when a browser requests a PHP page, that file is not
returned, don't you?
As I well understand that fact, then you misunderstood my point.
I though you would, but at the time your reasoning didn't seem correct
(see next point).
The data returned is the result of parsing the
document. Moving to all PHP, using JavaScript purely for interaction
(not
generation), will probably reduce the amount of data downloaded by the
user.
Er, wrong.
Yes, I am. I didn't consider the fact that looping code will, in all
likelihood, be smaller than the several HTML elements it produces. My only
defense is that I'm in the middle of re-writing your front page, so I have
my mind on other things. :)
[snip]
You can see why I am reluctant to have PHP build these sections, when
the file size will become huge and take ages for a user with a slow
modem to download.
Yes, I can... The size of a PHP file is not necessarily proportional to the size
of the result.
Yes, when those "results" are going to "balloon", which explains why I
had JavaScript handle these in the first place.
Ideas on how to transfer my long list of Ordering Codes just once
instead of 12 times would be welcome.
....which is probably why the typical shopping basket method is a good
idea. By limiting the total number of items displayed to those in a
particular catagory, you don't have to transfer as much data. Once the
user finalises the order, once again the total data is limited but this
time, it is to the items ordered.
There's no way to reduce the load if all stocked items are present at
once, unless you use JavaScript (which we're trying to avoid, if possible).
Sorry again for my mistake.
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
"Cardman" <do****@spam-me.com> wrote in message
news:1s********************************@4ax.com...
<snip> True, but anything that can run on all the most
popular browsers cannot be that bad.
The argument that says that what works on some large percentage of
browsers must be the right thing to do is the argument used for writing
IE only code. So not really part of the techniques for cross-browser
scritping.
Still, as you point out changing this section will
increase support, which is why that makes a good
reason to do it.
I can't say more than it may (possibly should) increase support. There
certainly are areas where the handling of invalid HTML 4 by some
browsers will diminish cross-browser script support but I don't know
whether using SCRIPT children in SELECT elements is one of them. Without
testing on every browser in existence (and that is well over 100, not
counting versions) it would not be possible to say for sure, but the
principal still stands.
<snip>As I have always kept an eye on the size of my files, when
people with a slow modem would spend about half a minute
downloading my Order Form as it is.
As it stands 3/4 of the order form file is JavaScript, which in
principal could be in a separate JS file and maybe not need to be
downloaded more than once. And, even as modified, the script remains
repetitive and could be further reduced in size. The HTML contains a
great deal of presentational mark-up which could be done with CSS, also
in an external file that may not need downloading more than once.
Consider your:-
<BIG><BIG><BIG>PURCHASE ORDER</BIG></BIG></BIG>
- as opposed to:-
<H1>PURCHASE ORDER</H1>
- with the CSS to give the same presentation. Half the size and a better
semantic description of the content.
<snip> Ah thanks, just what I need. Time to burn my useless 856
page JavaScript manual that does not mention such useful
things.
It is astounding how many inadequate (and often actively bad)
JavaScript books there are. Given that JavaScript is an object
based language designed to script arbitrary object models it
if frankly perverse for books on the subject not to cover both
of the languages property accessor syntaxes.
Then that should remind you that most experts cannot know
everything, which was obviously unhelpful in my case.
Who says it is experts who write JavaScript books? The limiting factors
are the time required to plan and write the book and the willingness of
someone to publish the results, and the confidence on the part of the
author that what they are doing is worthwhile. But my experience is that
confidence in ones ability to script web browsers is more often the
result of not really perceiving the issues than the result of expertise.
<snip>To an experienced programmer like myself dozens of
languages come and go all the time, where it is all
about knowing enough to get the job done. Highly
efficient code, and knowing ever obscure fact,
are for those wanting to spend their life on the
one language.
To be honest, judging by the structure of the original
code on your order form
It was not well optimised, but then you know the reason
for that.
It wasn't a matter of whether it was optimised, or the evident limited
familiarity with JavaScript as a language or its application to browser
scripting. My impression was derived only form the design and resulting
structure of the code. and some of the logic you apply to your reasoning,
Oh? Just what it that? As it still does exactly the
same as it did before, where I have just improved the
error checking somewhat.
You code was not an issue in that case. Because programmers need to
understand mechanical logic in order to do their job I expect to see
more evidence of an appreciation of logic (and its limitations) in their
reasoned arguments than I would from someone who's debating experience
was exclusively rhetorical. I would not have believed that you were an experienced
programmer.
Then obviously your assumption is wrong, when I am not
just an experienced programmer, but one that usually
impresses the other experienced programmers, not to
forget my former lecturers.
But would those former lecturers and other experienced programmers have
been impressed with the code you actually wrote for your order page
(even if they lacked any specific knowledge of JavaScript or its
application to a browser DOM)?
<snip> As languages go JavaScript is relatively small, because it
relies on the object model being scripted to provide the
functionality that is needed in its environment. It is
learning the object models that takes time, JavaScript is
sufficiently defined in the 170 pages of the ECMA
specification.
Then you need to point this out to book authors, when with
856 pages they appear to have achieved less.
Beyond making statements in a public forum (which obviously carry no
more weight than the audience choose to attach to them) there isn't a
great deal that I can do to influence the behaviour of the authors of
books on JavaScript.
<snip> I would have created it myself like linking these labels
to a pointer based array, but then JavaScript is not that
advanced.
What are you expecting to be able to do with a pointer that
cannot be done with an object reference?
Just my favoured method of data access, where having a pointer
to an array allows myself and others direct memory access and
to cut up and move the data about however I please.
Having written assembly language and C I much prefer languages where I
don't have to think about the location of items of data in particular
memory structures. It was always error prone and time consuming. But I
don't see how being able to do that with JavaScript would enable you to
do anything that you cannot already do (and probably more easily).
Except maybe something like reaching into a 32bit integer and directly
pulling out only, say, the lower byte. But that is not something that
you need to do in higher level languages.
The dynamic nature of JavaScript objects means that the ability to move
data about is already virtually unrestricted, you don't even have to
worry about the type of the data involved (beyond being aware of what
type it is).
So again, what is it that you think that you would want to do in the
order form code with a pointer that cannot be done in JavaScript with an
object reference (and probably easier).
<snip> Not if the user enters a fraction in the quantity field.
The final value is rounded anyway, where decimals are not
really a problem.
<snip>
That is not really the point. You asserted that because the script had
been adequately tested the fault must lie with an unknown browser. I
proposed that adequate testing would have exposed the ability on the
part of the user to enter fractional quantities and that because the
script attempted to guarantee the integrity of the order the ability of
the user to enter fractional quantities would have been
corrected/handled (in some way, though I suspect that having the script
actively change the value in the quantity field is not the best
approach). So evidence that the testing was not adequate serves to
undermine the deduction that the problem lies with an unknown browser.
Richard.
On 2 Feb 2004 06:48:57 -0800, Lee <RE**************@cox.net> wrote: Cardman said:
Is there some purpose to this paranoia? Wanting to sell me a new system
or something?
I'm trying to warn you about how you might be being ripped off.
If your pride gets in the way of your accepting a warning, I
guess that's not my problem.
What you overlook is that for a very long time I have been monitoring
the security of my existing ordering system, which means that I well
know what is really going on.
Believe it or not, but my customers are not trying to defraud me,
where there is very little achieved in trying to do so.
I know my item prices. Not to forget that Order Forms are post
processed into my spreadsheet tracking such facts.
Fine. Do you check each price?
The purpose is more along the line of looking for inaccuracies in the
general bulk of orders. Yes, once it a while a problem is overlooked,
but mostly all problems are very easy to spot.
Such errors that do not affect the Postage Cost are the most common
occurrence of this problem that I see. In other words this problem
occurs, but the end payment total is not affected at all.
As I said earlier, it would be a good way to test your security.
If you catch the problem, you won't believe it's deliberate.
If you don't catch it, they can move on to changing prices.
And I could well change to recalculating the entire Order Form in PHP
before on-line submission and payment is done. However, nothing can be
done about orders received through the post, when indeed the
customer's system will always do that calculation.
As mentioned this problem is not the customers doing it manually, when
all signs point to this fact.
You don't seem to have any signs.
You have not examined the evidence of where this problem comes from,
which provides clear signs of what is really going on.
You've concocted an explanation
that requires that some browsers not support an array index of 0,
which seems much less likely than that somebody is playing with
your forms.
That would be all well and good had this problem only been present in
the case of one or two customers, but this problem is repeated again
and again on order forms from customers all over this planet.
Since it serves no purpose or gain for these customers, then obviously
it is a compatibility bug. And sure enough had I asked these customers
their browser type and version, then a pattern should soon emerge. Not to mention that trying to submit a
such user modified false data to my hosting for on-line payment would
be rendered close to impossible due to the PHP code.
That would be what they were trying to find out, by submitting
forms with the weight changed. But, from what you've said
before, and from what I see in your form, I'm not convinced
that it would be difficult to slip false data past your code.
And certainly false data could be slipped through my code had that
been the customer's intention, but it is quite unlikely that such data
changes would go unnoticed.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 02 Feb 2004 15:21:03 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: On Mon, 02 Feb 2004 14:54:53 +0000, Cardman <do****@spam-me.com> wrote:
Er, wrong.
Yes, I am. I didn't consider the fact that looping code will, in all
likelihood, be smaller than the several HTML elements it produces. My only
defense is that I'm in the middle of re-writing your front page, so I have
my mind on other things. :)
No problem, when I do actually think about what such changes will do
before starting on the coding.
And I will certainly look forwards to seeing your results, where I can
only wonder if you are aware of all the factors. I will find out when
you complete it I guess.
Ideas on how to transfer my long list of Ordering Codes just once
instead of 12 times would be welcome.
...which is probably why the typical shopping basket method is a good
idea. By limiting the total number of items displayed to those in a
particular catagory, you don't have to transfer as much data.
True, but moving a shopping basket feature into my site has always
been a daunting task, which is mostly why I don't have one yet. If I
make it myself, then it will take tons of time and effort.
Should I simply include a popular plug-in system, then that would also
take up a lot of time and effort. Not to forget that it is unlikely to
do what I really want, like supporting all my 21 different payment
methods.
Once the
user finalises the order, once again the total data is limited but this
time, it is to the items ordered.
Yes, but my current system is an all-in-one thing, where rebuilding
the whole system from scratch has as much appeal as jumping off a
building.
Sure a new system, working as I desire, would be a major improvement,
but getting from A to B is no easy trip.
There's no way to reduce the load if all stocked items are present at
once, unless you use JavaScript (which we're trying to avoid, if possible).
I see, which may make a good reason to leave it under JavaScript
control, but I will give the PHP code a spin first.
Sorry again for my mistake.
No problem.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 2 Feb 2004 15:25:47 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote: The argument that says that what works on some large percentage of
browsers must be the right thing to do is the argument used for writing
IE only code. So not really part of the techniques for cross-browser
scripting.
It works on Netscape and the other browsers that I have tried as well,
but as mentioned that problem is now fixed.
As I have always kept an eye on the size of my files, when
people with a slow modem would spend about half a minute
downloading my Order Form as it is.
As it stands 3/4 of the order form file is JavaScript, which in
principal could be in a separate JS file and maybe not need to be
downloaded more than once.
I do not see that this idea would help much, when it may introduce
other issues if these files are cached.
And, even as modified, the script remains
repetitive and could be further reduced in size.
It is a lot better than what it was, where it would be difficult to
improve it further. The CheckBulk() function I can improve by removing
most ifs by adding an array. The LastCard error checking section I
plan to improve anyway, there are sections near the end of the
ShowInfo() function that I can now improve, but that is just about it.
The HTML contains a
great deal of presentational mark-up which could be done with CSS,
Well since I have never heard of CSS until visiting this group, then
that explains why I did not use it. Also I would have to make sure
that my HTML editor likes the code.
also in an external file that may not need downloading more than once.
My text does not repeat that badly.
Consider your:-
<BIG><BIG><BIG>PURCHASE ORDER</BIG></BIG></BIG>
- as opposed to:-
<H1>PURCHASE ORDER</H1>
- with the CSS to give the same presentation. Half the size and a better
semantic description of the content.
I will assume that CSS is supported by mostly all browsers.
Then that should remind you that most experts cannot know
everything, which was obviously unhelpful in my case.
Who says it is experts who write JavaScript books?
I can only feel that some people here are too demanding of the vast
volume of "experts" would make use of JavaScript frequently.
The limiting factors
are the time required to plan and write the book and the willingness of
someone to publish the results, and the confidence on the part of the
author that what they are doing is worthwhile. But my experience is that
confidence in ones ability to script web browsers is more often the
result of not really perceiving the issues than the result of expertise.
Perhaps, but people cannot know everything.
and some of the logic you apply to your reasoning,
Oh? Just what it that? As it still does exactly the
same as it did before, where I have just improved the
error checking somewhat.
You code was not an issue in that case. Because programmers need to
understand mechanical logic in order to do their job
Yet most, as I am aware do not, when for example my top subject has
always been mathematics, where I have a skill for well structuring
code to produce a good result.
Overlooking the not totally optimised code and the security issues,
but that Order Form for what it is intended to do both looks great and
works great.
I expect to see
more evidence of an appreciation of logic (and its limitations) in their
reasoned arguments than I would from someone who's debating experience
was exclusively rhetorical.
The proof of the pudding is in the eating, where does not my Order
Form look good? :-]
But would those former lecturers and other experienced programmers have
been impressed with the code you actually wrote for your order page
(even if they lacked any specific knowledge of JavaScript or its
application to a browser DOM)?
They would have liked the results, pointed out how to better optimise
the code, then wondered why their own programs do not look as good or
work as well.
It is not just about writing code, even well optimised code, but
knowing what the end result should be doing. That is what I am good
at, even if this Order Form one days needs moving a full shopping
basket system.
Well this form was created to produce automatically created order
forms that my customers could send through the post, then later on
added the on-line payment options to it.
Beyond making statements in a public forum (which obviously carry no
more weight than the audience choose to attach to them) there isn't a
great deal that I can do to influence the behaviour of the authors of
books on JavaScript.
You would be surprised what you could do if you really wanted to do
it, when both publishers and authors can be informed of such standard
documents.
Just my favoured method of data access, where having a pointer
to an array allows myself and others direct memory access and
to cut up and move the data about however I please.
Having written assembly language and C I much prefer languages where I
don't have to think about the location of items of data in particular
memory structures. It was always error prone and time consuming.
It is not too bad, when if you want to know your picture file size,
then you can just use a sizeof function. Should that picture be a
series of thumbnails, then you can just divide that size by the number
of thumbnails.
But I
don't see how being able to do that with JavaScript would enable you to
do anything that you cannot already do (and probably more easily).
Well JavaScript does not really need such a powerful feature. Not to
forget that it can cause security issues.
Except maybe something like reaching into a 32bit integer and directly
pulling out only, say, the lower byte. But that is not something that
you need to do in higher level languages.
I have done that before though, but you can also assemble a 32 bit
value out say 8 bit values. Such handling tends to be useful with say
direct graphics card programming.
The dynamic nature of JavaScript objects means that the ability to move
data about is already virtually unrestricted, you don't even have to
worry about the type of the data involved (beyond being aware of what
type it is).
Yes a nice easy hard to break system, but of course some people are
not aware of what is going on in their variables.
So again, what is it that you think that you would want to do in the
order form code with a pointer that cannot be done in JavaScript with an
object reference (and probably easier).
As I said it is just my preferred method, when you can move any sized
chunk of memory to any other suitably sized location. Best of all is
that you can process this data in whatever way you desire.
It is also a fast lower level system, but as you point out it is not
too hard to get your sizes wrong.
The final value is rounded anyway, where decimals are not
really a problem.
<snip>
That is not really the point. You asserted that because the script had
been adequately tested the fault must lie with an unknown browser.
Yes.
I proposed that adequate testing would have exposed the ability on the
part of the user to enter fractional quantities and that because the
script attempted to guarantee the integrity of the order the ability of
the user to enter fractional quantities would have been
corrected/handled (in some way, though I suspect that having the script
actively change the value in the quantity field is not the best
approach).
Had you seen my original code, then you will notice that the parseInt
function was used a lot to deal with these issues. I simply decided to
remove that code in my recent testing, for various reasons, including
that it has now been improved even further.
I have also long been aware that invalid values can be entered in this
box, where I am also aware that JavaScript has it's own error
checking. Since such actions cannot produce an incorrect order total,
then I did not see it as much of an issue.
So evidence that the testing was not adequate
Except that testing had not only highlighted this fraction problem
previously, but that it had also been fixed.
You can still see this old code in the Euro and US Dollar versions of
this form if you wish.
My "beta" test versions are for working with new ideas.
serves to
undermine the deduction that the problem lies with an unknown browser.
That would be a nice idea had not your basis been invalid, where as
the lines that produce this value are quite low in number and already
well tested, then that is why I can say that the problem must be
generated outside my code.
You can see examples of these faulty Order Forms if you desire, where
if you wish to examine the original code, then you should come to the
same conclusion.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 02 Feb 2004 16:02:41 +0000, Cardman <do****@spam-me.com> wrote: And I will certainly look forwards to seeing your results, where I can
only wonder if you are aware of all the factors. I will find out when
you complete it I guess.
As you have misgivings, I've stopped development (it's all but finished,
anyway). I'd prefer to show you the current results so that we can discuss
any problems you might foresee.
You will note that it doesn't look exactly like the original page. The
first thing I did was remove the tables: your usage of them is actually
abuse of the element. Tables should not be used for layout. I replaced
them with CSS that performs the same layout, and I used the standard
borders (rather than your images) to frame the menu. The colour scheme is
also different. Finally, as this is a single demonstration page, there are
no active links.
If any of these issues are unsatisfactory, it would be quite trivial to
change.
Only one problem has shown itself so far. IE seems to have a minor display
bug. The two URIs below are screenshots from IE and Opera, respectively. http://www.mlwinter.pwp.blueyonder.co.uk/cardman/ie.gif http://www.mlwinter.pwp.blueyonder.c...dman/opera.gif
As you can see, IE misaligns the text that appears beyond the sidebars,
whereas Opera doesn't. I tried increasing the margin of the text section
to move it away from the sidebars, but it made no difference. Strange.
A disadvantage to this system is that each page has to duplicate the
menus, but this adds less than 3KBs to each page so the impact is minimal.
You'll also have to manage which item is highlighted (the blue stripe),
either through PHP or by hard-coding it. Again, hardly a serious concern.
Little extras to point out:
- You'll notice that "CAMs", "DiSEqC"[1] and "LNBs" on the menu have a
dotted underline. Mousing over will display the full titles.
- Passing the mouse over the menu items will highlight that item. This
only happens on the menu (the first sidebar): the second and third don't
display this behaviour. Unfortunately, the highlight doesn't work in IE as
it doesn't support the :hover pseudo-class. I put it in simply because
it's easy to do and a common feature in menus. If you don't want it,
remove the rule from menu.css with the selector that ends ":hover {".
- The page uses valid HTML 4 Strict and valid CSS 2.
- I added alt attributes to all of the flags at the top of the page in
their natural language. That actually occupied most of my time: looking up
the various translated names and obtaining the correct character entity
values.
I put the page up at the following address: http://www.mlwinter.pwp.blueyonder.co.uk/cardman/
Mike
[1] IE doesn't support the ABBR element for some reason so the underline
doesn't appear. However, it does support the ACRONYM element, which is
what the other two use. You could change it so that all use ACRONYM but,
from a purist point of view, that is misuse (DiSEqC is an abbreviation,
not an acronym).
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Cardman <do****@spam-me.com> wrote in message news:<vg********************************@4ax.com>. .. Without JavaScript, then most web pages would not do anything beyond
moving from one page to the next, when most other popular web
languages (like Perl and CGI) are much harder to start off with.
The first part of your sentence states the original premise behind
hypertext transfer, actually. But I know you weren't making a
generalization about the Web. In a perfect world I think you're
talking about JavaScript enhancements, not presenting a full-fledged
CGI application using JavaScript.
Regarding Perl being harder to start off with, I strongly believe
based on years of enterprise Web development that it's easier in the
longrun to immediately learn a server-side tool like Perl/php/CGI than
to try to do data processing with a client-side tool that will
ultimately give you all kinds of useability (let alone
maintainability!!!!) issues. Major waste of time IMHO.
While I agree you have a right to draw the line concerning browser
compatibility depending on the demographic you're serving, the
assumption that users should just shrug and upgrade to the latest
greatest browser doesn't make business sense. I hated worrying about
cross browser compatibility for clients that may have been used by 9
percent of the market. Again you make those choices based your known
demographic. My company wanted that 9 percent. But it's dangerous to
assume that anyone can - or worse, SHOULD - upgrade to *anything* in
order to access a product that is implemented in a non-standard way in
the first place. They won't.
Cheers
P.S.
"Q:What do you make of the branding attempt of companies, by putting
little icons on their home pages saying, "best when viewed with
Microsoft Explorer, or Navigator?"
This comes from an anxiousness to use the latest proprietary features
which have not been agreed by all companies. It is done either by
those who have an interest in pushing a particular company, or it is
done by those who are anxious to take the community back to the dark
ages of computing when a floppy from a PC wouldn't read on a Mac, and
a Wordstar document wouldn't read in Word Perfect, or an EBCDIC file
wouldn't read on an ASCII machine. It's fine for individuals whose
work is going to be transient and who aren't worried about being read
by anyone.
However, corporate IT strategists should think very carefully about
committing to the use of features which will bind them into the
control of any one company. The web has exploded because it is open.
It has developed so rapidly because the creative forces of thousands
of companies are building on the same platform. Binding oneself to one
company means one is limiting one's future to the innovations that one
company can provide. - Tim Berners Lee 1996"
On Mon, 02 Feb 2004 17:06:21 +0000, Cardman <do****@spam-me.com>
wrote: Beyond making statements in a public forum (which obviously carry no
more weight than the audience choose to attach to them) there isn't a
great deal that I can do to influence the behaviour of the authors of
books on JavaScript.
You would be surprised what you could do if you really wanted to do
it, when both publishers and authors can be informed of such standard
documents.
There's basically only a couple of authors left who'd get the money to
produce a new javascript book, but none of them are going to, since
there's nothing new to write on the subject.
Most have realised they're not much good, the good ones admitting it
(e.g. http://www.dhtml-guis.com/warning.html ) the bad ones just
letting their books rot on the shelves.
You can still see this old code in the Euro and US Dollar versions of
this form if you wish.
The Euro has very specific laws on how calculations are made on it -
I'm sure you've taken these into account?
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
On Mon, 02 Feb 2004 18:21:12 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: On Mon, 02 Feb 2004 16:02:41 +0000, Cardman <do****@spam-me.com> wrote:
And I will certainly look forwards to seeing your results, where I can
only wonder if you are aware of all the factors. I will find out when
you complete it I guess.
As you have misgivings, I've stopped development (it's all but finished,
anyway).
Well, there was no need to do that, when I said that I would check it
out anyway. My comment was just about that people may not understand
my code in the first place, thereby making assumed mistakes.
I'd prefer to show you the current results so that we can discuss
any problems you might foresee.
Whatever, when it needs to be checked in the end anyway.
You will note that it doesn't look exactly like the original page.
You got the flags, the text and nothing else.
The first thing I did was remove the tables: your usage of them is
actually abuse of the element.
Well I did that in the first place, when it is the best choice from
using frames. Your method may certainly be a better option though, but
it depends on how it handles image placement I guess.
Tables should not be used for layout.
Yet they work so well... :~(
Well I do not see issues with abusing tables as long as it is not
breaking a Universal law.
I replaced
them with CSS that performs the same layout, and I used the standard
borders (rather than your images) to frame the menu.
I must admit that it is the menu that worries me the most, when the
outer structure is nice, the text is too small, where as I will
mention below is does not work much.
The colour scheme is also different.
The lack of colours I can see as a problem, when I have always like my
colour bars...
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR VALIGN=TOP ALIGN=CENTER>
<TD COLSPAN=10 WIDTH=300 CLASS="TextObject"
STYLE="background-color: rgb(255,0,0);"><P STYLE="text-align: left;">
<BR>
</TD>
</TR>
</TABLE>
Unless that result can be duplicated without using a table, then a
table doing formatting it will have to be. After all my sections need
to be broken up, where doing this is much better than using bars.
Finally, as this is a single demonstration page, there are
no active links.
I see, where I presume that is the usual HREF thing.
If any of these issues are unsatisfactory, it would be quite trivial to
change.
The menu I can see is a problem, then the lack of colours will need
fixing, but that should be easy enough.
Only one problem has shown itself so far. IE seems to have a minor display
bug. The two URIs below are screenshots from IE and Opera, respectively.
http://www.mlwinter.pwp.blueyonder.co.uk/cardman/ie.gif
http://www.mlwinter.pwp.blueyonder.c...dman/opera.gif
As you can see, IE misaligns the text that appears beyond the sidebars,
whereas Opera doesn't. I tried increasing the margin of the text section
to move it away from the sidebars, but it made no difference. Strange.
Well you know what Microsoft it like, when if it works perfectly, then
it is not Microsoft.
A disadvantage to this system is that each page has to duplicate the
menus,
That sounds like the reason why I used JavaScript in the first place,
when do you know how many pages I have? Seventy eight is the answer to
that, which is why it was a real bugger to add a new menu option to
each and every page.
but this adds less than 3KBs to each page so the impact is minimal.
Over a small volume of 78 pages...
You'll also have to manage which item is highlighted (the blue stripe),
either through PHP or by hard-coding it. Again, hardly a serious concern.
Exactly like I used to do with my current buttons, where the problem
with this is that you now cannot just "duplicate the menus".
Little extras to point out:
- You'll notice that "CAMs", "DiSEqC"[1] and "LNBs" on the menu have a
dotted underline. Mousing over will display the full titles.
One problem is that mouse over them does not produce this text on
either MIE or Netscape. I think you may have a problem.
Since I well explain what these items are on my pages, then I doubt
that I need this feature, when these abbreviations are better known
anyway.
- Passing the mouse over the menu items will highlight that item.
It does on Netcape, but not on MIE.
This only happens on the menu (the first sidebar): the second and third
don't display this behaviour.
Can they is the more important question?
Unfortunately, the highlight doesn't work in IE as
it doesn't support the :hover pseudo-class.
I see. My current page seems more compatible at the moment.
I put it in simply because
it's easy to do and a common feature in menus. If you don't want it,
remove the rule from menu.css with the selector that ends ":hover {".
I see.
- The page uses valid HTML 4 Strict and valid CSS 2.
And it does not function much. Are you sure that this stuff is
supposed to be browser compatible? As if I normally saw results like
that, then I would not use it.
- I added alt attributes to all of the flags at the top of the page in
their natural language. That actually occupied most of my time: looking up
the various translated names and obtaining the correct character entity
values.
Yes, where that is the section that I like the most. Nice layout
across the entire page, the alt names, where it all goes together
better than what I currently have.
Netscape 7.1 does not display your alt names though.
I put the page up at the following address:
http://www.mlwinter.pwp.blueyonder.co.uk/cardman/
On your home page I see.
[1] IE doesn't support the ABBR element for some reason so the underline
doesn't appear. However, it does support the ACRONYM element, which is
what the other two use. You could change it so that all use ACRONYM but,
from a purist point of view, that is misuse (DiSEqC is an abbreviation,
not an acronym).
You know me. Go with what works...
Anyway, there are several useful changes there, but the menu I do not
think is working out.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 02 Feb 2004 19:56:14 GMT, ji*@jibbering.com (Jim Ley) wrote: You can still see this old code in the Euro and US Dollar versions of
this form if you wish.
The Euro has very specific laws on how calculations are made on it -
I'm sure you've taken these into account?
That I am sure only applies to Euro-linked currencies, when in the UK
it is still foreign rubbish.
There is a bit of a conversion issue here though, then rounding all
the Sterling values to Euro produces a value at the end that does not
add up to all the sub-figures.
All values are correct though, when it is just the rounding that
screws about with it. Since nothing can be done about that beyond
faking the figures, then that is why it is like it is.
Cardman http://www.cardman.com http://www.cardman.co.uk
"Cardman" <do****@spam-me.com> wrote in message
news:f5********************************@4ax.com...
<snip> The argument that says that what works on some large
percentage of browsers must be the right thing to do
is the argument used for writing IE only code. So not
really part of the techniques for cross-browser scripting.
It works on Netscape and the other browsers that I have
tried as well, but as mentioned that problem is now fixed.
It is not a question of whether something works on some tested sub-set
of browsers. It is a question of whether it should be expected to work
on all browsers. Valid mark-up brings the expectation of specified
handling and so consistency, invalid mark-up does not.
<snip>Well since I have never heard of CSS until visiting
this group,
Those programming qualifications weren't web related then.
then that explains why I did not use it. Also I would have
to make sure that my HTML editor likes the code.
Bad HTML editing software does not justify creating bad HTML. My
experience of programs like Dreamweaver is that unless the HTML is
created entirely by hand in its code view its output HTML is between 4
and 20 times bloated from what a knowledgeable human would produce, and
Front Page is 10 times as bad. The effect is that attempting to optimise
WSYWIG HTML editor output for download speed is actually more work than
(re)creating the HTML/CSS from scratch in a reasonably co-operative text
editor.
<snip>Who says it is experts who write JavaScript books?
I can only feel that some people here are too demanding
of the vast volume of "experts" would make use of
JavaScript frequently.
When the books omit standard (and extremely useful) language structures
and then go on teach bad practices, such as eval abuse and UA string
testing, then it seems reasonable to point out that those books are bad.
<snip>... . But my experience is that confidence in ones
ability to script web browsers is more often the
result of not really perceiving the issues than the
result of expertise.
Perhaps, but people cannot know everything.
Which represents very good grounds for suspecting yourself of being
deluded whenever you find yourself believing that you know everything.
<snip>... . Because programmers need to understand
mechanical logic in order to do their job
Yet most, as I am aware do not, when for example my top subject
has always been mathematics, where I have a skill for well
structuring code to produce a good result.
Are these programmes who have somehow omitted learning a fundamental
pre-requisite of their craft by any chance the "experienced programmers"
who you say have been impressed with your coding?
<snip>The proof of the pudding is in the eating, where does not
my Order Form look good? :-]
What has the appearance of the GUI have to do with the design of the
script code behind it?
But would those former lecturers and other experienced
programmers have been impressed with the code you actually
wrote for your order page (even if they lacked any specific
knowledge of JavaScript or its application to a browser DOM)?
They would have liked the results, pointed out how to better
optimise the code, then wondered why their own programs do not
look as good or work as well.
Incredible, we must know very different programmers (and computer
science lecturers). It might be that most of the programmers I know work
in financial services, where mistakes can cost somebody lots of money
(and/or their job), and so they care a great deal about the theory and
practice of software design.
<snip>So again, what is it that you think that you would want to
do in the order form code with a pointer that cannot be done
in JavaScript with an object reference (and probably easier).
As I said it is just my preferred method, when you can move
any sized chunk of memory to any other suitably sized location.
Best of all is that you can process this data in whatever way
you desire.
So whether or not JavaScript has no pointer has no real baring on your
order form implementation and there was no point in you raising the lack
of pointers in the first place.
<snip>Had you seen my original code, then you will notice that
the parseInt function was used a lot ...
<snip>
What exactly is the rational behind asking for help identifying a
problem with some code and then presenting code for consideration that
is not the code exhibiting the symptoms?
Richard.
On Mon, 2 Feb 2004 22:04:15 -0000, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote: Those programming qualifications weren't web related then.
No, more along the line of commercial data processing, where I then
did a fair chunk of industrial programming. I have also done a lot of
PC system programming as well.
When the books omit standard (and extremely useful) language structures
and then go on teach bad practices, such as eval abuse and UA string
testing, then it seems reasonable to point out that those books are bad.
Try to think more in degrees of badness than with a simple on/off
system, when that seems to be your problem.
Perhaps, but people cannot know everything.
Which represents very good grounds for suspecting yourself of being
deluded whenever you find yourself believing that you know everything.
Like how above I pointed out how I never heard of CSS before? Seems
that your points and the facts do not match.
Are these programmes who have somehow omitted learning a fundamental
pre-requisite of their craft by any chance the "experienced programmers"
who you say have been impressed with your coding?
Some of your questions do not even deserve an answer...
<snip>The proof of the pudding is in the eating, where does not
my Order Form look good? :-]
What has the appearance of the GUI have to do with the design of the
script code behind it?
Not just appearance, but also functionality. A program is a whole and
not just one of it's parts.
Incredible, we must know very different programmers (and computer
science lecturers). It might be that most of the programmers I know work
in financial services, where mistakes can cost somebody lots of money
(and/or their job), and so they care a great deal about the theory and
practice of software design.
Good for them, but once your program works, then that is the end of
it. Time to go home, when further optimization is just doing the same
thing slightly better.
Design and testing is of course very important in all software
development.
So whether or not JavaScript has no pointer has no real baring on your
order form implementation and there was no point in you raising the lack
of pointers in the first place.
It was only a brief unimportant comment, which someone around here
desired to interrogate.
What exactly is the rational behind asking for help identifying a
problem with some code and then presenting code for consideration that
is not the code exhibiting the symptoms?
Had you seen my original posting then you will know that all the facts
and the correct code was presented at the time. Further comments
simply pointed out the new code that I have been working on.
However, life goes on, where it is now February, where my business had
to be updated for another month.
Should you desire to see the original Sterling version, then I can
certainly put a copy on-line. Since no one seems to have an answer for
my problem, then I did not consider it work the time, when I should
have error trapped the problem anyway.
Anyway, please stop waving your manhood around.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Mon, 02 Feb 2004 21:32:33 +0000, Cardman <do****@spam-me.com> wrote: On Mon, 02 Feb 2004 18:21:12 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
[snip]
You will note that it doesn't look exactly like the original page.
You got the flags, the text and nothing else.
It's a demonstration page. :)
The layout is virtually identical: flags across the top, sidebar down the
side, and text down the right. I didn't replicate all of the sidebar, but
I showed that more than one group can exist, so it would be possible to
recreate it. With the flexibility of CSS, it would be simple to tailor the
look of this, and other elements, of the page.
[snip]
Tables should not be used for layout.
Yet they work so well... :~(
Well I do not see issues with abusing tables as long as it is not
breaking a Universal law.
Someone else might be able to argue this better than me (especially on
comp.infosystems.www.authoring.html)...
The opposition of tables for layout is both a purist, and practical one.
The practical view focuses mainly around accessibility, particularly for
blind users. Tables, when presented by aural browsers, are spoken in a
certain logical order. When presenting tabular data, this order makes
sense. When used purely for layout, it doesn't at all: columns and rows
contain disjointed information which is not related in any way. This would
break entirely the ability to convey information to people who would use
such browsers.
The purist view is that HTML elements represent specific parts of the
structure of a document. To properly maintain the correct grammar of the
document, each element should only be used for the job it was designed to
do. In the case of tables, it is to represent tabular data, not layout a
page. Whilst you could dismiss this with, "Well, it works", it should be
viewed the same way as you might view malformed grammar of a C program:
something that is inherently wrong and in need of fixing.
I replaced
them with CSS that performs the same layout, and I used the standard
borders (rather than your images) to frame the menu.
I must admit that it is the menu that worries me the most, when the
outer structure is nice, the text is too small, where as I will
mention below is does not work much.
The text size can be changed extremely easily (changing a "font-size: 80%"
string to "font-size: 90%", for example).
The colour scheme is also different.
The lack of colours I can see as a problem, when I have always like my
colour bars...
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR VALIGN=TOP ALIGN=CENTER>
<TD COLSPAN=10 WIDTH=300 CLASS="TextObject"
STYLE="background-color: rgb(255,0,0);"><P STYLE="text-align: left;">
<BR>
</TD>
</TR>
</TABLE>
Unless that result can be duplicated without using a table, then a
table doing formatting it will have to be. After all my sections need
to be broken up, where doing this is much better than using bars.
As a CSS rule:
element {
border-color: #ff0000;
border-style: solid none;
border-width: 1px;
}
This will place a 1 pixel thick, red border above and below the element,
"element". You'd want to be more selective, only making a element that
belongs to a certain class have this border but again, this is only a demo.
Finally, as this is a single demonstration page, there are
no active links.
I see, where I presume that is the usual HREF thing.
I didn't see the point of adding links to the menu as I've got nowhere for
them to go (unless I link to your site, of course).
[snip]
A disadvantage to this system is that each page has to duplicate the
menus,
That sounds like the reason why I used JavaScript in the first place,
when do you know how many pages I have? Seventy eight is the answer to
that, which is why it was a real bugger to add a new menu option to
each and every page.
That's why you use PHP to insert it. :)
but this adds less than 3KBs to each page so the impact is minimal.
Over a small volume of 78 pages...
The total doesn't really matter much. 3KBs extra on one page at a time
adds about a second on my 56K modem. Your users aren't downloading all 78
pages at one time, so I don't see the point of your argument.
Also, removing the extra mark-up due to table use will reduce the overhead
still further.
You'll also have to manage which item is highlighted (the blue stripe),
either through PHP or by hard-coding it. Again, hardly a serious
concern.
Exactly like I used to do with my current buttons, where the problem
with this is that you now cannot just "duplicate the menus".
The only thing that should change between the menus on each page is which
item is marked as current. In the menu, that is simply an id value
(id="current-menu-item").
Little extras to point out:
- You'll notice that "CAMs", "DiSEqC"[1] and "LNBs" on the menu have a
dotted underline. Mousing over will display the full titles.
One problem is that mouse over them does not produce this text on
either MIE or Netscape. I think you may have a problem.
It does on IE 5.5 and Opera 7.23. Netscape might place it in the status
bar (that's what Opera does in addition to a tooltip).
Since I well explain what these items are on my pages, then I doubt
that I need this feature, when these abbreviations are better known
anyway.
Just showing it can be done. It's sometimes nice to be reminded what
certain abbreviations mean. The W3C do the same for CSS, DOM, XML and
HTML, for example. You would think that most people (that care) would know
those too.
[snip]
This only happens on the menu (the first sidebar): the second and third
don't display this behaviour.
Can they is the more important question?
Yes.
Unfortunately, the highlight doesn't work in IE as
it doesn't support the :hover pseudo-class.
I see.
Blame Microsoft. The CSS 2 specification is almost 6 years old. You would
hope that they could implement it by now, but alas, no.
My current page seems more compatible at the moment.
Your page doesn't do this, so you can't compare.
[snip] - The page uses valid HTML 4 Strict and valid CSS 2.
And it does not function much. Are you sure that this stuff is
supposed to be browser compatible? As if I normally saw results like
that, then I would not use it.
How many times do I need to say this: it's a demonstration page. I even
said at the beginning of my previous post that I didn't finish it.
What doesn't work?
Links on the menus? That would be because there aren't any.
Hover highlighting with IE? That's because IE is crap. - I added alt attributes to all of the flags at the top of the page in
their natural language. That actually occupied most of my time: looking
up
the various translated names and obtaining the correct character entity
values.
Yes, where that is the section that I like the most. Nice layout
across the entire page, the alt names, where it all goes together
better than what I currently have.
Netscape 7.1 does not display your alt names though.
I meant to add title attributes, too. It should display those. I was only
immediately concerned with the alt attributes because they're required in
Strict HTML. I put the page up at the following address:
http://www.mlwinter.pwp.blueyonder.co.uk/cardman/
On your home page I see.
A dumping ground for things I might want to show or store on-line. There
is no home page: I can never think of useful or interesting things to
post. If I get a large number of solutions that I provided to this group,
I might host them in case they come up again in the future. Mostly it's
been corrections to scripts, rather than full, from-scratch examples, in
my posts to date.
[snip]
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
On Tue, 03 Feb 2004 00:01:24 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: It's a demonstration page. :)
Officially downgraded then. ;-]
No problem, when there are lots of useful ideas there.
The layout is virtually identical:
Cough, cough...
flags across the top,
Actually my flags do not cover the menu, when if they did, then the
menu would be out of sync to the menus on the other pages.
sidebar down the side, and text down the right.
Yes that is the same, where the non-table structuring is bound to be
useful.
I didn't replicate all of the sidebar, but I showed that more than
one group can exist, so it would be possible to recreate it.
Yes, easy enough to do.
With the flexibility of CSS, it would be simple to tailor the
look of this, and other elements, of the page.
Any good CSS reference guide around? I would look myself, but you
probably would know better.
The text size can be changed extremely easily (changing a "font-size: 80%"
string to "font-size: 90%", for example).
Somewhere around 120 to 150 sounds about right.
Unless that result can be duplicated without using a table, then a
table doing formatting it will have to be. After all my sections need
to be broken up, where doing this is much better than using bars.
As a CSS rule:
element {
border-color: #ff0000;
border-style: solid none;
border-width: 1px;
}
Good to hear that this is possible.
This will place a 1 pixel thick, red border above and below the element,
"element". You'd want to be more selective, only making a element that
belongs to a certain class have this border but again, this is only a demo.
Well my sections are divided into two around the title, one following
the page description, as many as it takes to separate items, then one
at the base of the page.
There are exceptions to this rule, like with my News page.
Finally, as this is a single demonstration page, there are
no active links.
I see, where I presume that is the usual HREF thing.
I didn't see the point of adding links to the menu as I've got nowhere for
them to go (unless I link to your site, of course).
Just checking to make sure that CSS does not have its own method.
That sounds like the reason why I used JavaScript in the first place,
when do you know how many pages I have? Seventy eight is the answer to
that, which is why it was a real bugger to add a new menu option to
each and every page.
That's why you use PHP to insert it. :)
True, but that is another one of those undesirable restructuring my
site things. As even something like changing my page format to this
new system could well take months.
I am a busy person...
but this adds less than 3KBs to each page so the impact is minimal.
Over a small volume of 78 pages...
The total doesn't really matter much. 3KBs extra on one page at a time
adds about a second on my 56K modem.
This time it is not a retrieval speed issue, but one you would know if
you try to manually update a complex menu on 78 pages, while at the
same time you have other pressing matters to attend to.
Your users aren't downloading all 78
pages at one time, so I don't see the point of your argument.
My point is that you have recreated the problem of why I moved my menu
to JavaScript in the first place, when I do not wish to HTML edit 78
pages (and growing by the day) every time that I want to add a new
main section.
Yes PHP...
You'll also have to manage which item is highlighted (the blue stripe),
either through PHP or by hard-coding it. Again, hardly a serious
concern.
Exactly like I used to do with my current buttons, where the problem
with this is that you now cannot just "duplicate the menus".
The only thing that should change between the menus on each page is which
item is marked as current. In the menu, that is simply an id value
(id="current-menu-item").
Yes, not unlike what I had before. Copy, open the file, scroll down,
delete the menu, paste the new menu, edit if needed, copy if needed,
save the file, close the file.
Seventy seven more files to go...
- You'll notice that "CAMs", "DiSEqC"[1] and "LNBs" on the menu have a
dotted underline. Mousing over will display the full titles.
One problem is that mouse over them does not produce this text on
either MIE or Netscape. I think you may have a problem.
It does on IE 5.5 and Opera 7.23.
I have MIE 6.0.2800.
I hope you know that Microsoft has broke your menu in their latest
browser versions.
Netscape might place it in the status
bar (that's what Opera does in addition to a tooltip).
It is good for Netscape I am pleased to say, when it is working now,
even if it was not before. Kind of strange, but there you go.
I will check again later and see what Netscape does then.
Unfortunately, the highlight doesn't work in IE as
it doesn't support the :hover pseudo-class.
I see.
Blame Microsoft. The CSS 2 specification is almost 6 years old. You would
hope that they could implement it by now, but alas, no.
Sounds like Microsoft want to promote their own version.
My current page seems more compatible at the moment.
Your page doesn't do this, so you can't compare.
It all depends on what the majority of browsers like.
How many times do I need to say this: it's a demonstration page. I even
said at the beginning of my previous post that I didn't finish it.
What doesn't work?
Just the things that you said would work, but it is getting better it
seems. :-]
Hover highlighting with IE? That's because IE is crap.
The world's most popular browser is crap...
It may be crap, not that it seems too crap to me, but it would not be
the best idea to ignore it.
I put the page up at the following address:
http://www.mlwinter.pwp.blueyonder.co.uk/cardman/
On your home page I see.
A dumping ground for things I might want to show or store on-line. There
is no home page: I can never think of useful or interesting things to
post.
Why you sad lonely person. ;-]
You must have hobbies or something. I of course have my business, but
I have been thinking for a while about making a site for my Charmed
(the series) items.
In fact had I wanted to, then I could come up with a good dozen site
ideas that would be of interest to me and others.
If I get a large number of solutions that I provided to this group,
I might host them in case they come up again in the future. Mostly it's
been corrections to scripts, rather than full, from-scratch examples, in
my posts to date.
Sounds like it has promise for a site though. Maybe one for all those
cool tricks that people are always looking for would be an idea.
Anyway, when I get the time, then I will see how I can fit CSS into my
site instead of using these tables. That menu still does not get my
favour though, but it may work out if I smack it around enough.
Cardman http://www.cardman.com http://www.cardman.co.uk
Cardman wrote: The Euro has very specific laws on how calculations are made on it -
I'm sure you've taken these into account?
That I am sure only applies to Euro-linked currencies, when in the UK
it is still foreign rubbish.
There is a bit of a conversion issue here though, then rounding all
the Sterling values to Euro produces a value at the end that does not
add up to all the sub-figures.
All values are correct though, when it is just the rounding that
screws about with it. Since nothing can be done about that beyond
faking the figures, then that is why it is like it is.
AFAIK the Euro procedure is that you have to perform all intermediate
(euro!) calculations with four decimals precision, and may round the
result only (two decimals).
If/when the calculation is using pound sterling, that procedure doesn't
apply. I think you round in the end, Cardman? Who cares what you did
before? I get some value with two decimal positions, convert by using my
six digit conversion factor, display the euro amount.
You shouldn't, of course, convert every intermediate result to euro, add
those up, and then get upset about missing 100ths. At least they always
taught me "don't round (convert!) your intermediate results!"
--
Bas Cost Budde http://www.heuveltop.nl/BasCB
On Tue, 03 Feb 2004 02:10:52 +0000, Cardman <do****@spam-me.com> wrote: On Tue, 03 Feb 2004 00:01:24 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
[snip]
The layout is virtually identical:
Cough, cough...
Virtually...
flags across the top,
Actually my flags do not cover the menu, when if they did, then the
menu would be out of sync to the menus on the other pages.
If CSS is disabled or overridden (users can specify their own style sheets
if they wish), the flags still appear at the top of the page, which is a
more logical location for them.
[snip]
Any good CSS reference guide around? I would look myself, but you
probably would know better.
I just use the W3C's CSS Specification. You'll probably want to do a lot
of experimentation as using style sheets can be somewhat fiddly.
http://www.w3.org/TR/CSS2/
Only CSS 1 and 2 are viable at the moment. As you've already seen, the
World's most used browser can barely manage CSS 2, so 2.1 and 3 aren't
really of much use yet. 2.1 and 3 aren't finished yet, anyway.
The text size can be changed extremely easily (changing a "font-size:
80%"
string to "font-size: 90%", for example).
Somewhere around 120 to 150 sounds about right.
The font size is relative to that of the main page text. Unless you want
the menu to be more prominent than the content, 100% would be the maximum.
[snip]
This will place a 1 pixel thick, red border above and below the element,
"element". You'd want to be more selective, only making a element that
belongs to a certain class have this border but again, this is only a
demo.
Well my sections are divided into two around the title, one following
the page description, as many as it takes to separate items, then one
at the base of the page.
The basic approach would be to place each item in a DIV with class "item",
say, then specify rules for them and the title (H1, id="title") that adds
the borders.
[snip]
That sounds like the reason why I used JavaScript in the first place,
when do you know how many pages I have? Seventy eight is the answer to
that, which is why it was a real bugger to add a new menu option to
each and every page.
That's why you use PHP to insert it. :)
True, but that is another one of those undesirable restructuring my
site things. As even something like changing my page format to this
new system could well take months.
I am a busy person...
Even if you resort to copy and paste, it should only take a couple of
hours.
but this adds less than 3KBs to each page so the impact is minimal.
Over a small volume of 78 pages...
The total doesn't really matter much. 3KBs extra on one page at a time
adds about a second on my 56K modem.
This time it is not a retrieval speed issue, but one you would know if
you try to manually update a complex menu on 78 pages, while at the
same time you have other pressing matters to attend to.
You seem to be approaching this update thing with the idea that it has to
be started and finished in the same day. Why?
The approach I take is to replicate the website on my hard disk (including
directory structure) and work on that. Once it's finished, I upload it all
in one go, closing the site first with a dummy front page and uploading
the new one last. If you needed to, you could take a year to rewrite the
site and keep the current one active until it's finished. The only thorn
in your side would be having to keep the current site up-to-date.
[snip]
You'll also have to manage which item is highlighted (the blue
stripe),
either through PHP or by hard-coding it. Again, hardly a serious
concern.
Exactly like I used to do with my current buttons, where the problem
with this is that you now cannot just "duplicate the menus".
The only thing that should change between the menus on each page is
which
item is marked as current. In the menu, that is simply an id value
(id="current-menu-item").
Yes, not unlike what I had before. Copy, open the file, scroll down,
delete the menu, paste the new menu, edit if needed, copy if needed,
save the file, close the file.
Never heard of "Find and Replace"?
- You'll notice that "CAMs", "DiSEqC"[1] and "LNBs" on the menu have a
dotted underline. Mousing over will display the full titles.
One problem is that mouse over them does not produce this text on
either MIE or Netscape. I think you may have a problem.
It does on IE 5.5 and Opera 7.23.
I have MIE 6.0.2800.
I hope you know that Microsoft has broke your menu in their latest
browser versions.
It never ceases to amaze me just how much Microsoft can manage to cock
up...
[snip]
Unfortunately, the highlight doesn't work in IE as
it doesn't support the :hover pseudo-class.
I see.
Blame Microsoft. The CSS 2 specification is almost 6 years old. You
would hope that they could implement it by now, but alas, no.
Sounds like Microsoft want to promote their own version.
No, that's problem: they don't have their own version, nor do they
implement the standard one.
How many times do I need to say this: it's a demonstration page. I even
said at the beginning of my previous post that I didn't finish it.
What doesn't work?
Just the things that you said would work, but it is getting better it
seems. :-]
Hover highlighting with IE? That's because IE is crap.
The world's most popular browser is crap...
It's vulnerable to security exploits, slow, error prone, unstable, and
can't manage to implement even basic standards properly that are several
*years* older than itself.
It may be crap, not that it seems too crap to me, but it would not be
the best idea to ignore it.
I wouldn't ignore it, but I wouldn't spend too much time making it work
with everything. Users could still easily navigate the site, but they
wouldn't see all of the presentation elements that users with other
browsers might see. They would still get the same content, and that's the
important thing.
Hopefully, Microsoft will rectify some of the problems with the next
release of IE. Then again, probably not...
A dumping ground for things I might want to show or store on-line. There
is no home page: I can never think of useful or interesting things to
post.
Why you sad lonely person. ;-]
Uh huh. *rolls eyes*
You must have hobbies or something. I of course have my business, but
I have been thinking for a while about making a site for my Charmed
(the series) items.
Plenty: sports, books, PC games, music (playing, in addition to
listening), programming (I know far more than just JS), films - enough to
fill 20 sites. However, writing a personal site for me is like writing a
story; something I've never been good at. It's just not where my creative
side lies.
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
On Tue, 03 Feb 2004 10:10:45 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: If CSS is disabled or overridden (users can specify their own style sheets
if they wish), the flags still appear at the top of the page, which is a
more logical location for them.
Yes, except as pointed out these menus should ideally line up between
pages, when it does not look right to see your menu drop.
I just use the W3C's CSS Specification. You'll probably want to do a lot
of experimentation as using style sheets can be somewhat fiddly.
http://www.w3.org/TR/CSS2/
Ok, I will take a good look at it.
Only CSS 1 and 2 are viable at the moment. As you've already seen, the
World's most used browser can barely manage CSS 2, so 2.1 and 3 aren't
really of much use yet. 2.1 and 3 aren't finished yet, anyway.
I will keep that in mind. So how well do other browsers deal with
CSS2?
The text size can be changed extremely easily (changing a "font-size:
80%"
string to "font-size: 90%", for example).
Somewhere around 120 to 150 sounds about right.
The font size is relative to that of the main page text. Unless you want
the menu to be more prominent than the content, 100% would be the maximum.
Yes, I would want that, when the menu certainly has to stand out. I
have seen sites before where I have spent a long time finding the link
I need because their pages are cluttered and this menu option is just
a small text link placed somewhere.
Well my sections are divided into two around the title, one following
the page description, as many as it takes to separate items, then one
at the base of the page.
The basic approach would be to place each item in a DIV with class "item",
say, then specify rules for them and the title (H1, id="title") that adds
the borders.
I have little understanding of what exactly has to be done, but from
your comments I should be able to figure it out quickly when I come to
do it.
True, but that is another one of those undesirable restructuring my
site things. As even something like changing my page format to this
new system could well take months.
I am a busy person...
Even if you resort to copy and paste, it should only take a couple of
hours.
The whole site? I would put that down at about a week of hard work
just to convert all the pages.
This time it is not a retrieval speed issue, but one you would know if
you try to manually update a complex menu on 78 pages, while at the
same time you have other pressing matters to attend to.
You seem to be approaching this update thing with the idea that it has to
be started and finished in the same day. Why?
The main reason is that I always have work to do, where anything
non-vital when put aside tends to get left there. So if it is not
completed in the single session, then it can take a very long time
before the next session comes around.
The approach I take is to replicate the website on my hard disk (including
directory structure) and work on that. Once it's finished, I upload it all
in one go, closing the site first with a dummy front page and uploading
the new one last.
A better idea is to change your pages names, when you can upload all
the new pages, then just swap in the new index page to have the whole
site swap over in a second or two.
The old pages should be removed within 24 hours to remove
compatibility issues with the old and new sites.
If you needed to, you could take a year to rewrite the
site and keep the current one active until it's finished. The only thorn
in your side would be having to keep the current site up-to-date.
I once had my old site translated to Swedish by a helpful person,
where it was always a problem when I updated the information.
Yes, not unlike what I had before. Copy, open the file, scroll down,
delete the menu, paste the new menu, edit if needed, copy if needed,
save the file, close the file.
Never heard of "Find and Replace"?
Since the menu is near the top of the file, then there is really no
need, when you know how far down it is. Also search and replace only
deals with single lines and not a whole (don't forget variable) menu.
The world's most popular browser is crap...
It's vulnerable to security exploits,
No doubt many browsers have such issues, where hackers prefer to
exploit the one that the most people are using.
slow,
Seems fast enough to me.
error prone,
I cannot say that I have seen errors, when my only real issue is that
box size and number of letters that will fit in that input box do not
match.
unstable,
No such problem here.
and can't manage to implement even basic standards properly that are
several *years* older than itself.
Ever complained to Microsoft about this?
It may be crap, not that it seems too crap to me, but it would not be
the best idea to ignore it.
I wouldn't ignore it, but I wouldn't spend too much time making it work
with everything.
So it begins that I should deal with the 1% of people who cannot use
JavaScript, but now to ignore 100% compatibility with the most used
browser around?
Users could still easily navigate the site, but they
wouldn't see all of the presentation elements that users with other
browsers might see. They would still get the same content, and that's the
important thing.
In my business I have learned one valuable lesson, which is that
appearance is equal to or even exceeding content.
For example, even though I completely describe items beyond what any
other supplier would, but my items simply do not sell unless I put a
photo of this item on the site first.
One picture is worth a thousand words you could say, where lets
imagine how much difference it would make between a good and bad
looking/functional site?
That is why I consider the menu to be a very important aspect, when
this is basically the control system for the whole site. Things not
working here is just not a viable option.
Hopefully, Microsoft will rectify some of the problems with the next
release of IE. Then again, probably not...
You could always point this problem out to them.
Plenty: sports, books,
Oh? What books? I am into sci-fi/fantasy myself.
PC games,
I wish I had time for PC games, but I still have games from previous
birthdays currently unplayed. The last real game I played was Ultima
8, when that first came out, where you can tell that it has been a
long time.
I do play the odd quick game now and again, like a level of the
original Settlers or an odd program called Morkin.
music (playing, in addition to listening),
I don't play too much music these days, when I prefer music videos.
programming (I know far more than just JS),
Yes, most people do. I have used so many languages now that I would
take me quite some time to recall them all.
films - enough to fill 20 sites.
Movies are one of my popular past times as well, which is why here I
have a 61" rear projection TV and DD5.1 sound system. My own home
cinema, but I plan to add DTS support one day soon.
However, writing a personal site for me is like writing a
story; something I've never been good at. It's just not where my creative
side lies.
Sounds like a computer programmer to me. :-]
One of my worst subjects at school was English, even if I read a whole
load of books, where as even my art lessons where not good, then my
artistic side was lacking.
However, although my English has now improved a lot, but I can do
great things by a different method. That method is through
mathematical precision.
That is where computers can prove very useful, when my artistically
clumsy hands can type well enough. And so through computers I can work
on achieving visual perfection.
It always seems that there is only one correct answer, where the work
done it simply working to achieve that goal. And so my whole site is
built with the aim of bringing everything together in a way that
works.
What I am doing today though is to split my Order Forms into two, when
before hand my brother created them (when he added PHP section) so
that my Order Form submitted the contents to itself for final PHP
processing.
I always though that was wrong, which is why my test today has just
successfully broke my Order Form into two files. In one is the pure
HTML and JavaScript code of my Order Form, where in the second file is
all the PHP code for on-line order processing.
Technically this Order Form section does not need to be a PHP3 file
now, but since I will soon add PHP processing to this code, then that
is why I left it that way for now.
Since I have one order forms to each currency, making three in total,
then I should now be able to combine the PHP code from them (well one)
in order to make the one online order processing file.
That would be good news, when in the future I should be able to
replace my orders forms as the method used to submit this data, which
is the step towards having a shopping basket system.
I do not predict any problems from this simple code split, but I will
test it with different browsers just to make sure.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Tue, 03 Feb 2004 10:04:07 +0100, Bas Cost Budde <ba*@heuveltop.org>
wrote: AFAIK the Euro procedure is that you have to perform all intermediate
(euro!) calculations with four decimals precision, and may round the
result only (two decimals).
Yes, it should do that, when exchange rates have four decimal places.
Since all values are calculated in Sterling, then they are transferred
to Euros at the published currency rates, where the four digit result
is then rounded to two digits.
If/when the calculation is using pound sterling, that procedure doesn't
apply.
It does the calculation in Sterling, but the Euro values still works
on four digits before rounding.
I think you round in the end, Cardman?
All values are rounded, except for the VAT value that is floored to
save my customers 1p. As allowed by Customs and Excise.
Who cares what you did before?
The problem with my Euro Order Form is that the values do not add up,
even if all the values are totally correct. After all I would need to
display four decimal places instead of two in order to show that the
values do add up.
I get some value with two decimal positions, convert by using my
six digit conversion factor, display the euro amount.
Just what do you get six digit exchange rates from?
You shouldn't, of course, convert every intermediate result to euro, add
those up, and then get upset about missing 100ths. At least they always
taught me "don't round (convert!) your intermediate results!"
No I don't do that.
I have been thinking about going back over the sub-values and slightly
adjusting them so that they add up to the total, but then that only
goes and creates other issues.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Tue, 03 Feb 2004 16:08:57 +0000, Cardman <do****@spam-me.com> wrote: On Tue, 03 Feb 2004 10:10:45 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
If CSS is disabled or overridden (users can specify their own style
sheets
if they wish), the flags still appear at the top of the page, which is a
more logical location for them.
Yes, except as pointed out these menus should ideally line up between
pages, when it does not look right to see your menu drop.
If you did use the layout, surely all pages would look alike?
[snip] Only CSS 1 and 2 are viable at the moment. As you've already seen, the
World's most used browser can barely manage CSS 2, so 2.1 and 3 aren't
really of much use yet. 2.1 and 3 aren't finished yet, anyway.
I will keep that in mind. So how well do other browsers deal with
CSS2?
Very well. IE is the only browser that I recall having major problems. CSS
1 is sufficient for most tasks, and is probably supported universally.
[snip] True, but that is another one of those undesirable restructuring my
site things. As even something like changing my page format to this
new system could well take months.
I am a busy person...
Even if you resort to copy and paste, it should only take a couple of
hours.
The whole site? I would put that down at about a week of hard work
just to convert all the pages.
A complete conversion could take a long time (I wasn't referring to that).
If you created a template for the various page types (stock item, news,
etc), you could speed it up considerably. This time it is not a retrieval speed issue, but one you would know if
you try to manually update a complex menu on 78 pages, while at the
same time you have other pressing matters to attend to.
You seem to be approaching this update thing with the idea that it has
to be started and finished in the same day. Why?
The main reason is that I always have work to do, where anything
non-vital when put aside tends to get left there. So if it is not
completed in the single session, then it can take a very long time
before the next session comes around.
I can appreciate that. The approach I take is to replicate the website on my hard disk
(including directory structure) and work on that. Once it's finished, I
upload it all in one go, closing the site first with a dummy front page
and uploading the new one last.
A better idea is to change your pages names, when you can upload all
the new pages, then just swap in the new index page to have the whole
site swap over in a second or two.
Not necessarily. If a user bookmarks a page and you change it's name, what
will they do? Changing page locations is generally a bad idea. Of course,
it might not be such a big issue for your site, but as a rule, it should
be avoided. You could simply schedule the site update late at night when
access frequency is at its lowest, close the site, and overwrite the
pages. After all, it shouldn't take too long, providing you don't use
dial-up.
[snip] Yes, not unlike what I had before. Copy, open the file, scroll down,
delete the menu, paste the new menu, edit if needed, copy if needed,
save the file, close the file.
Never heard of "Find and Replace"?
Since the menu is near the top of the file, then there is really no
need, when you know how far down it is. Also search and replace only
deals with single lines and not a whole (don't forget variable) menu.
With the CSS menu, adding a new menu item only involves adding one line.
You can "Find" the line that will appear below the new item, move to the
beginning of the row, then "Paste". To do that quickly, I'd open all of
the pages to be changed, then perform that sequence pressing Ctrl+F4 after
each page (to close the window). It would take less than 10 minutes to
update 80 pages that way (I've done that kind of tedious work a lot). The world's most popular browser is crap...
It's vulnerable to security exploits,
No doubt many browsers have such issues, where hackers prefer to
exploit the one that the most people are using.
Unfortunately for Microsoft, IE is the main target for browser exploits.
There will be others, of course, but IE takes the lion's share. It appears
that IE on XP is even worse: two friends have been the target of three
separate browser infiltrations in the past month, despite keeping up with
the latest virus updates and browser patches. I'm now dreading my own
migration to XP later this week (I'm upgrading my PC and I have to
change). Not only will I have to put up with this rubbish, I'll have to
use a bloated OS that has the annoying tendancy to dislike my old
applications.
[snip] error prone,
I cannot say that I have seen errors, when my only real issue is that
box size and number of letters that will fit in that input box do not
match.
IE always manages to load multiple pages incorrectly for me. It would load
a single image in another window that should be loading a site, and
regularly stall when loading a page. It might take 15 refreshes to load
the page properly. It has nothing to do with caching either: the target
page isn't in the cache at all. unstable,
No such problem here.
Lucky you... and can't manage to implement even basic standards properly that are
several *years* older than itself.
Ever complained to Microsoft about this?
Microsoft should be used to getting bashed about this. Adding my voice to
it won't do much. Personally, I don't care. I use Opera. It may be crap, not that it seems too crap to me, but it would not be
the best idea to ignore it.
I wouldn't ignore it, but I wouldn't spend too much time making it work
with everything.
So it begins that I should deal with the 1% of people who cannot use
JavaScript, but now to ignore 100% compatibility with the most used
browser around?
No, not at all, but I don't see why I should put significant effort into
giving support for a *minor* presentational feature that would be simple
if Microsoft got their act together. If it was a major part of the site, I
would expend every effort to make something work but if it's not, why
bother? Something like the menu highlighting is what I'd call minor:
no-one would miss it if it wasn't there. Users could still easily navigate the site, but they
wouldn't see all of the presentation elements that users with other
browsers might see. They would still get the same content, and that's
the important thing.
In my business I have learned one valuable lesson, which is that
appearance is equal to or even exceeding content.
For example, even though I completely describe items beyond what any
other supplier would, but my items simply do not sell unless I put a
photo of this item on the site first.
I would consider an illustration of a product, content. "Presentation"
referred to the general layout and look of the interface. Content is
critical; it's what people come to your site to view. Presentation just
makes the stay more pleasant. Granted, the site must look aesthetically
pleasing, so presentation is important to a degree, but it should never
outweigh content.
[snip] Plenty: sports, books,
Oh? What books? I am into sci-fi/fantasy myself.
I prefer to limit my sci-fi to the small screen. I'm currently trying to
get into a Tom Clancy book, but the slow start and my current lethargy
mean I get about 5 pages then start to yawn. I haven't been able to do
much reading in the past three or so months.
[snip]
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
On Tue, 03 Feb 2004 16:20:08 +0000, Cardman <do****@spam-me.com> wrote: Just what do you get six digit exchange rates from?
You can get rates up to 9 significant figures at the address below. Not
all currencies are shown to this degree, but the Euro and US Dollar are
shown to 6 sf. http://www.xe.com/
Mike
--
Michael Winter M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Cardman wrote: I get some value with two decimal positions, convert by using my
six digit conversion factor, display the euro amount.
Just what do you get six digit exchange rates from?
I may confuse two things here. We used to have another currency,
locally; that was converted into euro using 6 positions.
--
Bas Cost Budde http://www.heuveltop.nl/BasCB
On Tue, 03 Feb 2004 18:06:23 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: If you did use the layout, surely all pages would look alike?
It seems that you have overlooked that the flags are only used on the
welcome page.
A better idea is to change your pages names, when you can upload all
the new pages, then just swap in the new index page to have the whole
site swap over in a second or two.
Not necessarily. If a user bookmarks a page and you change it's name, what
will they do?
I tell my site visitors to bookmark my welcome page, when that is the
only one that cannot change location.
What you can do about those other bookmarks is to have a page saying
"The page you requested has been moved. Please click here to be taken
to the new location. Please updated your bookmarks".
Copy that file over the old pages changing the link each time, then
delete these pages after about six months.
Changing page locations is generally a bad idea. Of course,
it might not be such a big issue for your site, but as a rule, it should
be avoided.
Well, either update method is hardly an issue, when it only takes a
couple of minutes to upload all the new pages.
You could simply schedule the site update late at night when
access frequency is at its lowest, close the site, and overwrite the
pages. After all, it shouldn't take too long, providing you don't use
dial-up.
Nice idea, except that the world is round and I have customers over
most of it. Night time here is generally the better times, but I do
seem to get lots of hits at like 4am.
Unfortunately for Microsoft, IE is the main target for browser exploits.
There are hacks going on all over the place these days. From MIRC,
through e-mail viruses to script kiddies doing DDOS attacks and
beyond.
Sometimes you have to wonder if the Net should have its own police
force of computer experts, who are able to work with local
organizations in different countries and swoop in on these script
kiddies dragging them off kicking and screaming.
There will be others, of course, but IE takes the lion's share. It appears
that IE on XP is even worse: two friends have been the target of three
separate browser infiltrations in the past month, despite keeping up with
the latest virus updates and browser patches.
Then we all should fear that. Just what sites do they go to, when it
should not just happen by opening a browser.
I'm now dreading my own
migration to XP later this week (I'm upgrading my PC and I have to
change). Not only will I have to put up with this rubbish, I'll have to
use a bloated OS that has the annoying tendancy to dislike my old
applications.
Your old applications are the least of your problems, when you will
find out that XP will not like a lot of your hardware. I lost one
printer, my multi-CD changer during my XP upgrade, where it does not
work well with my ET6000 graphics card either.
Ok, so lightning killed my old AGP card, where I fell back on my
previous PCI card before I get in a new AGPx8 card. Oh? What books? I am into sci-fi/fantasy myself.
I prefer to limit my sci-fi to the small screen. I'm currently trying to
get into a Tom Clancy book, but the slow start and my current lethargy
mean I get about 5 pages then start to yawn. I haven't been able to do
much reading in the past three or so months.
I cannot say that I have read a book in a long time either.
Anyway, you may be interested to know that I have now got PHP to do
some HTML building instead of JavaScript. So the Code selection system
now works when Script support is off, even if that does not help too
much at the moment.
I also have the figures available, when my Order Form is 40k when
these codes are controlled by JavaScript. When PHP builds these 12
select lists, then the file size jumps to 60k.
However, by jamming the codes up together, then I can save 4k on the
file with an end result of 56k. I expect that I will leave it like
that for now.
At this time I am going to soon figure out how a shopping basket
system actually works, in terms of storing what has been ordered
without losing these values between page changes, or even leaving the
site and returning.
Maybe cookies have something to do with it, but I have a feeling that
if I go my own way, then what I do will only be incompatible with
something or other.
Cardman http://www.cardman.com http://www.cardman.co.uk
On Tue, 03 Feb 2004 18:13:06 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote: On Tue, 03 Feb 2004 16:20:08 +0000, Cardman <do****@spam-me.com> wrote:
Just what do you get six digit exchange rates from?
You can get rates up to 9 significant figures at the address below. Not
all currencies are shown to this degree, but the Euro and US Dollar are
shown to 6 sf.
http://www.xe.com/
I usually use bloomberg myself, but I only update my rates weekly
anyway.
What I wish I could do is to have my pages directly access the
currency rates from such a service, which would allow my site to
always display accurate prices ideally updated like each evening or
even hourly.
I wonder if there is some application around that can be linked into
my site in order to provide automatic currency rate updates?
It would need to add error checking on that and make sure that the
value returned is not in error, when that would be very unhelpful if
it were.
I think that I will go look into that.
Cardman http://www.cardman.com http://www.cardman.co.uk This thread has been closed and replies have been disabled. Please start a new discussion. |
