|
I am relatively new to this sort of thing and I currently use a different language but reading this thread makes me wonder if there is an issue with using session variables?
I am upgrading a program that currently uses POST method to transfer small portions of data between screens and I want to reduce the number of screens and to do this I need to transfer larger data sets. Using Session variables seem like a better idea since they are more persistent and are there through the whole session.
For the original poster it would seem that it would be easy to check the session variable to see if it exists and if it doesn't then calculate it otherwise use the session variable and continue? Seems like a simple bug to fix to me. But I only have experience with PHP with this at this point and am still learning. I have not even attempted to learn ASP.
|
|
|
|
|
What you say is what should have been done. The code should check the session variable, if it is null then go to the database and 3rd party API and calculate the value needed, and store it in the session variable for later use. In this way it's basically using the session variable for caching a value that is expensive to calculate and doesn't change often.
I posted this because what the person who actually wrote this did was kind of a face-palm moment. They write the value into the session variable and then never read from the session variable again. Every time this value was needed they calculated it, then wrote the calculated value into the session variable only to never retreive it and do anything with it.
|
|
|
|
|
Our finance folks were a bit annoyed by one of our web pages, where it occasionally rounded the final total to the nearest dime. While troubleshooting a former colleague's JavaScript code that added 2% to the amount entered by the user, I found this gem. His intention, at least, was obvious by the function name.
function CurrencyFormatted(amount) {
var i = parseFloat(amount);
if (isNaN(i)) { i = 0.00; }
var minus = '';
if (i < 0) { minus = '-'; }
i = Math.abs(i);
i = parseInt((i + .005) * 100);
i = i / 100;
s = new String(i);
if (s.indexOf('.') < 0) { s += '.00'; }
if (s.indexOf('.') == (s.length - 2)) { s += '0'; }
s = minus + s;
return s;
}
Isn't that brilliant? I mean, why use the simple, single-line solution isFixed(2) when you can do the same thing in 9 lines? 
If you think 'goto' is evil, try writing an Assembly program without JMP.
modified 17-Jun-13 16:15pm.
|
|
|
|
|
Perhaps he didn't know isFixed exists
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
Well, perhaps toFixed doesn't work the way he wanted?
Does it handle NaN?
Does it do rounding?
Does it round the absolute value of the value (which would always round up, right?)
Goofing around with the W3School's Try It[^] feature (snazzy) I think everything works correctly except the NaN handling.
Marc
|
|
|
|
|
Marc Clifton wrote: Does it handle NaN?
I don't think NaN will ever arise while currency formatting (going as per method name), without exceptions. He's not doing tan 90 anywhere is he?
|
|
|
|
|
You have a good point there. 
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
The second line handles NaN.
How extensive were your tests in W3Schools Try It? The code in question ran in production for a few years, and it runs flawlessly 99.99% of the time. But that 0.01% where it didn't is why I was looking into it.
My point is this: the amount of time needed to write and test that convoluted mass of spaghetti, and to understand and troubleshoot it later, is unacceptable when a simple solution is built-in and readily available.
If he didn't know about toFixed() is not much of an excuse; one should know your tools, or at least know how Google works.
You still need a solution that catches NaN, so it makes sense to wrap isFixed in a function:
function CurrencyFormatted(amount) {
var i = parseFloat(amount);
if (isNaN(i)) { i = 0.00; }
return i.toFixed(2);
}
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Presume they are paid by the line!
|
|
|
|
|
 My exact thoughts when I saw that. But no, much as I'd like it, we're salaried here.
This fellow doesn't work here any more, and as I've gone back to maintain his code I can see that we should kick ourselves in the arse for not holding code reviews when he was here. I could teach a full semester class on Programming Best Practices and use only his code for examples of what not to do.
Not that my code is perfect, but ...
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
GregorianCalendar date = new GregorianCalendar(1888, 0, 1, 0, 0, 0);
SimpleDateFormat sdf = new SimpleDateFormat("YYYY");
String convertedstring = sdf.format(date.getTime());
System.out.println(convertedstring);
output: 1887 (on my laptop anayway)
GregorianCalendar date = new GregorianCalendar(1888, 0, 1, 0, 0, 0);
SimpleDateFormat sdf = new SimpleDateFormat("yyyy");
String convertedstring = sdf.format(date.getTime());
System.out.println(convertedstring);
output: 1888
For those who didn't notice, in sample 1 I put "YYYY", in sample 2 "yyyy".
I couldn’t immediately find something in the docs or google explaining this…
|
|
|
|
|
"YYYY" means week years.
Quote: A week year is in sync with a WEEK_OF_YEAR cycle. All weeks between the first and last weeks (inclusive) have the same week year value. Therefore, the first and last days of a week year may have different calendar year values.
For example, January 1, 1998 is a Thursday. If getFirstDayOfWeek() is MONDAY and getMinimalDaysInFirstWeek() is 4 (ISO 8601 standard compatible setting), then week 1 of 1998 starts on December 29, 1997, and ends on January 4, 1998. The week year is 1998 for the last three days of calendar year 1997. If, however, getFirstDayOfWeek() is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998; the first three days of 1998 then are part of week 53 of 1997 and their week year is 1997
SimpleDateFormat[^]
GregorianCalendar[^]
|
|
|
|
|
Quite odd, that is.
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
Unfortunately, many human systems for dealing with dates are odd, all computers can do is reflect that.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
An application that presents it's UI in html5 and runs in a browser as a regular webpage. Leveraging html5 technoligies, it can do pretty much the same thing that a standard user level application does... Like a word processor. Anyways Let me google that for you![^]
But don't tell about a disk defragmanter HTML5 App!
You're new, please read the announcement at the top, this ain't the right place for asking questions...
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
Draw.IO[^]
Remember...
Post your Best, your worst, and your most interesting. But please - no programming questions . This forum is purely for amusement and discussions on code snippets.
|
|
|
|
|
OK... But I have more questions about this topic...
What should I do
-Toywarrior
modified 21-Nov-20 21:01pm.
|
|
|
|
|
We've got programming forums here in CP, see Discussions > Web Developments
|
|
|
|
|
Message Closed
modified 21-Nov-20 21:01pm.
|
|
|
|
|
If you post then... if I get you 
|
|
|
|
|
Looks like you've pulled 
|
|
|
|
|
He was a first timer... little lax was on my part
|
|
|
|
|
I can beat that - I discovered a bug where new records were failing to be added.
After a number of false trails, I homed in on the following SQL user function:
ALTER function [dbo].[ufn_GetNextID](@IDTable as varchar(100), @IDColumn as varchar(100))
returns integer
as
begin
declare @NewID as integer
set @NewID=0
return @NewID
end
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
