Does it bother you that fusetalk sends your password as plain text to your browser, where it's cached to disk?

[rh71]

ColdFusion is tag based, just like HTML as you know. You insert the CF code where you want it (aside from code for: ie. preparing DB connections, etc.). For CF code (CFLOOP using your array example), wherever you place it... the outputted data would be in its place (even in view source). No whitespaces (unless you specify code for whitepspaces in a loop).

HOWEVER, as in my example with preparing DB connections (like at the top of the page), that turns into whitespace when you do a view source after the page is rendered. On the webpage, you don't see the whitespace.

 

[notfred]

Originally posted by: rh71
ColdFusion is tag based, just like HTML as you know. You insert the CF code where you want it (aside from code for: ie. preparing DB connections, etc.). For CF code (CFLOOP using your array example), wherever you place it... the outputted data would be in its place (even in view source). No whitespaces (unless you specify code for whitepspaces in a loop).

HOWEVER, as in my example with preparing DB connections (like at the top of the page), that turns into whitespace when you do a view source after the page is rendered. On the webpage, you don't see the whitespace.

So are you saying you can or you cannot control whitespace? when you do "view source", that IS your webpage. The way it looks in IE or Netscape or Mozilla is entirely dependant upon the browser. The only thing the programmer has control over is what it says on that "view source" page. If he can't control the whitespace there, then he doesn't have control over whitespace. Let's take an example: http://ca.water.usgs.gov/archive/waterdata/2001/11532500.html

the way that page looks is entirely dependant upon the formatting of the source code. If there was whitespace randomly inserted all theough there, then the page would NOT look right. Does the coldfusion programmer have control over that or not?

 

[MaxDSP]

dang, this went from a simple "yes" or "no" thread to a head-on battle. if only we didnt have language filters...

 

[rh71]

Yes we do. You're using an example that uses the PRE tags. Obviously anything in the PRE tags will be shown, including white spaces. As before, CF code that retrieves data and throws the output do not produce whitespace. CF code that PREPARES for retrieval of data (like stating the DSN for a DB) DOES produce whitespace and such code need not be placed in the PRE section anyway.

A source page (your code) and view source ARE NOT THE SAME. View source is only what the browser receives after the application server (backend) is done with your source code. Remember, it's a server-side language.

Whitespaces (if produced by CF's code) seen in view source do not mean whitespaces on the rendered HTML page. When you said "when you do "view source", that IS your webpage." .. this is NOT true UNLESS you use the PRE tag where it is literally line by line rendered.

 

[Rallispec]

Originally posted by: MaxDSP
dang, this went from a simple "yes" or "no" thread to a head-on battle. if only we didnt have language filters...

haha.. maybe this would be a good time for me to say "php is better!!"

 

[MaxDSP]

Originally posted by: Rallispec

Originally posted by: MaxDSP
dang, this went from a simple "yes" or "no" thread to a head-on battle. if only we didnt have language filters...

haha.. maybe this would be a good time for me to say "php is better!!"

especially for the price...

 

[notfred]

Originally posted by: rh71
Yes we do. You're using an example that uses the PRE tags. Obviously anything in the PRE tags will be shown, including white spaces. As before, CF code that retrieves data and throws the output do not produce whitespace. CF code that PREPARES for retrieval of data (like stating the DSN for a DB) DOES produce whitespace and such code need not be placed in the PRE section anyway.

But, if the database connection IS needed inside the <pre> tag, then you're screwed, right?

A source page (your code) and view source ARE NOT THE SAME. View source is only what the browser receives after the application server (backend) is done with your source code. Remember, it's a server-side language.

From the point of fiew of the browser, they're exactly the same. The browser does not care whether the filename ends in .html, .cfm, .php, .asp, or .cgi. The browser does not see a line of the code until after the server is done preparing it. the browser has no idea whether a page it recieves was a static page that was jsut grabbed off a hard drive, or if was a dynamically generated page. The browser does all it's rendering based on what's in that "view source" document.

Whitespaces (if produced by CF's code) seen in view source do not mean whitespaces on the rendered HTML page. When you said "when you do "view source", that IS your webpage." .. this is NOT true UNLESS you use the PRE tag where it is literally line by line rendered.

The html spec compresses all whitespace down to a single space, it has nothing to do with cold fusion. A non-compliant browser could very easily decide it wanted to display ALL whitespace. Then, all that extraneous space in the page source would be visible.

 

[bizmark]

yes, it definitely bothers me.

 

[rh71]

Database connections are ideally set at the top of the page. Data retrieval from that database afterward can be done via CF code anywhere within the same page, including within the PRE tag. As you can see, you have no reason to put non-data-producing code (that would produce whitespace, for example) in a PRE tag. You have control.

From the point of fiew of the browser, they're exactly the same. The browser does not care whether the filename ends in .html, .cfm, .php, .asp, or .cgi. The browser does not see a line of the code until after the server is done preparing it. the browser has no idea whether a page it recieves was a static page that was jsut grabbed off a hard drive, or if was a dynamically generated page. The browser does all it's rendering based on what's in that "view source" document.

Look at this way... Source File(server) --> App Server(server) --> Web Browser(you) --> View Source(you) ... but NOT: View Source --> Web Browser which is what you're trying to say (right?). You'd think it's the same thing, but obviously white space found in View Source (like 3 blank lines) does not produce white space in the browser (3 blank lines). Rendering is not "based on View Source". It's based on Source File(server). What you see in View Source IS what you see in your browser (aside from extraneous whitespaces) - yes, but not BASED from it.

The html spec compresses all whitespace down to a single space, it has nothing to do with cold fusion. A non-compliant browser could very easily decide it wanted to display ALL whitespace. Then, all that extraneous space in the page source would be visible.

From my explanation above, multiple white spaces found within View Source is produced by the app server (ColdFusion). Your first sentence is correct... but only after it's rendered in a browser.

 

[notfred]

Originally posted by: rh71
Look at this way... Source File(server) --> App Server(server) --> Web Browser(you) --> View Source(you) ... but NOT: View Source --> Web Browser which is what you're trying to say (right?). You'd think it's the same thing, but obviously white space found in View Source (like 3 blank lines) does not produce white space in the browser (3 blank lines). Rendering is not "based on View Source". It's based on Source File(server). What you see in View Source IS what you see in your browser (aside from extraneous whitespaces) - yes, but not BASED from it.

No, you're wrong. The "source" (would you like to look up the definition of source?) of the page is what the browser uses to render the pretty page you see with colors and tables and graphics. the browser gets the document that you can see under thew "view > source" menu. When the browser sees the code <hr> it draws a line across the screen, when it sees the code <b> it makes text bold, when it sees <a href=""> it makes a link, and when it sees a string of whitespace, it draws a single space. Everything that you see in a browser is based on the html in the source document, that you can look at via "view source".

edit for clarity:
What you seem to be saying, is that the server sends a document containing coldfusion code to the browser, then, when you you hit "view source" the browser shows you a document in which the cold fusion code has been replaced with whitespace.

What I'm saying is that the coldfusion code has been replaced by whitespace by the time it leaves the cold fusion interpreter. As it comes fro mthe webserver to your browser, the extraneuos whitespace is already there. The webbrowser doesn't modify the source document and convert coldfusion code into whitespace, it just shows you the whitespace that was already there when it recieved the document.

 

[dakata24]

not really. if it were my online banking account on the otherhand.. hell yeah!

 

[Jfur]

It does not bother me, but only becasue I am aware that it is not secure and have a completely unique password for this account. For things that require security I would not find it acceptable.

 

[rh71]

What you seem to be saying, is that the server sends a document containing coldfusion code to the browser, then, when you you hit "view source" the browser shows you a document in which the cold fusion code has been replaced with whitespace.

No, that's not what I'm saying. CF code (source code) is processed by CF APP Server. This App Server sits logically on top of the web server (ie. IIS). When a client browser loads a webpage (requests the .cfm file from the web browser), it is processed: .cfm --> APPSERVER --> IIS --> Your browser (as html source). I never said the browser converts/renders CF code to whitespace (seen in view source). CF APPSERVER --> IIS creates the whitespace. The browser renders what is handed to it by the webserver. It's not CF code at that point anymore.

THat was my original point in my very first response in this thread (probably short-cutted to that point) and you basically (and rudely) said I was speaking out of my @$$.

"Source code" according to you is what you see in "view source" ? Well, if you want to look at it that way, but technically source code in the dynamic web page world is not the same as if Windows OS source code was decompiled (that produces the same exact source code used to create the Windows OS). What something is rendered as, is not really source code. That's why I say source code is different from what you see in View Source.

 

[Smolek]

Originally posted by: Imported

Originally posted by: guyver01
wow... that's kinda... weird.

but i'm the only one who uses this machine.. so no it dont bother me.

 

[SSP]

Not really.

 

[mpitts]

Meh.

 

[notfred]

Originally posted by: rh71

What you seem to be saying, is that the server sends a document containing coldfusion code to the browser, then, when you you hit "view source" the browser shows you a document in which the cold fusion code has been replaced with whitespace.

No, that's not what I'm saying. CF code (source code) is processed by CF APP Server. This App Server sits logically on top of the web server (ie. IIS). When a client browser loads a webpage (requests the .cfm file from the web browser), it is processed: .cfm --> APPSERVER --> IIS --> Your browser (as html source). I never said the browser converts/renders CF code to whitespace (seen in view source). CF APPSERVER --> IIS creates the whitespace. The browser renders what is handed to it by the webserver. It's not CF code at that point anymore.

THat was my original point in my very first response in this thread (probably short-cutted to that point) and you basically (and rudely) said I was speaking out of my @$$.

"Source code" according to you is what you see in "view source" ? Well, if you want to look at it that way, but technically source code in the dynamic web page world is not the same as if Windows OS source code was decompiled (that produces the same exact source code used to create the Windows OS). What something is rendered as, is not really source code. That's why I say source code is different from what you see in View Source.

At least we agree on something now, I was just calling the html output from cf the source (as it's the source for the rendered page), and you were calling the cf code the source (as it's the source of what I was calling the source).

Still though, that doesn't explain html that looks like this:

<select name="url" class="ftinputtext" style="font-size:9px;" OnChange="if(form.url.options[form.url.selectedIndex].value != 0){location.href=form.url.options[form.url.selectedIndex].value;}">
<option value="0">Select


<option value="whoson.cfm">WHO'S ON: 2:02 PM






<option value="categories.cfm?catid=27&zb=1745239" >General Hardware








<option value="categories.cfm?catid=44&zb=5450965" >AnandTech Articles








<option value="categories.cfm?catid=46&zb=3283593" >AnandTech News








<option value="categories.cfm?catid=34&zb=5632763" >Operating Systems








<option value="categories.cfm?catid=45&zb=2992915" >For Sale/Trade








<option value="categories.cfm?catid=40&zb=3899289" >Hot Deals








<option value="categories.cfm?catid=38&zb=383925" selected>Off Topic








<option value="categories.cfm?catid=50&zb=7351664" >Highly Technical








<option value="categories.cfm?catid=37&zb=276144" >Cases & Cooling








<option value="categories.cfm?catid=28&zb=3615806" >CPU/Processors and Overclocking








<option value="categories.cfm?catid=39&zb=349890" >Distributed Computing








<option value="categories.cfm?catid=29&zb=1034436" >Motherboards








<option value="categories.cfm?catid=36&zb=8778284" >Networking








<option value="categories.cfm?catid=30&zb=4539074" >Peripherals








<option value="categories.cfm?catid=33&zb=5139246" >Software - Applications, Programming and Games








<option value="categories.cfm?catid=32&zb=4402040" >Technical Support








<option value="categories.cfm?catid=31&zb=5807496" >Video








<option value="categories.cfm?catid=42&zb=3068455" >Forum Issues


</select>

What cold fusion feature would possibly cause so much space between each of those lines?
The only thing I can figure is that the programmer added 6 blank lines to the end of his "for each category - print 'option'" loop.

 

[Jason Clark]

Ok, this is getting a bit annoying, but why not respond.

1) Spacing, no the programmer does not add whitepace. Notfred, you are wrong, coldfusion replaces logic code with whitespace, which does nothing for client-side formatting. All it does is add a bit of space in the code, which if you calcluate out, is next to nothing.
2) The spacing issue is null and void, and is an uninformed complaint. All pages on this network use GZIP compression so spacing is not an issue.
3) Passwords are frequently stored on peoples machines, remember password feature in IE anyone? Welcome to the internet people, this is not abnormal, secure your own pc's thats the responsibility of the end user
4) CSS, HTML Spec, I'm even going to bother commenting on this.

Nuff said.

 

[notfred]

So, coldfusion really does insert whitespace wherever it wants for no reason?

I'd find that really annoying....


RH71 - you get to call me a moron now.

 

[Jason Clark]

Yes, it can be, and we all try to reduce it where we can, but in some code blocks it's just not possible. Not a big deal really, blown a bit out of proportion by most.

 

[tweakmm]

If someone has access to the file where the password is stored on your computer, they can do a lot worse than steal your fuse talk password.

 

[narzy]

Originally posted by: Czar

Originally posted by: narzy
what bothers me more is Fusetalk's poorly coded HTML or CSS tho its alot of code, run w3c's validators on it and you can see. better yet open customized pages in Opera or Mozilla, they don't render properly :disgust:

agreed, and all the anoying spaces in the code, probably around 20-30% of all the html code you download with each pageview are just spaces
:disgust:

you really don't know what your talking about, I on the other hand do...these pages are compressed, all the spaces are removed when sent to your computer...the code is flaky, missing end brackets, uncommon calls, ect. big bloody mess. hopefully in the next release(es) it will get better / fixed to become W3C compliant.

 

[narzy]

Originally posted by: Zuni
Ok, this is getting a bit annoying, but why not respond.

1) Spacing, no the programmer does not add whitepace. Notfred, you are wrong, coldfusion replaces logic code with whitespace, which does nothing for client-side formatting. All it does is add a bit of space in the code, which if you calcluate out, is next to nothing.
2) The spacing issue is null and void, and is an uninformed complaint. All pages on this network use GZIP compression so spacing is not an issue.
3) Passwords are frequently stored on peoples machines, remember password feature in IE anyone? Welcome to the internet people, this is not abnormal, secure your own pc's thats the responsibility of the end user
4) CSS, HTML Spec, I'm even going to bother commenting on this.

Nuff said.

ummm why not touch on the specs? you quote that browsers that use spec's should render the page properly. are you saying that the only browser in the world that is spec strict is IE? HAHAHAHAHAHAHAH! LMFAO DUDE that is the FUNNIEST thing I have read all day...for a multi platform, multi user interface such as fusetalk it should ALWAYS be your number 1 priority to code as close to spec. as humanly possible. IE does a great job of covering up mistakes in code, and some allowace should be in place to deal with rouge code because even I understand that mistakes are made wile coding, I make them all the time. that being said, I have tried my custom pages in multiple browsers and the only one that seems to do it correctly is IE. its because of 1 stupid missing bracket. but running w3c's validators on the pages alot more error is code pop up, unspeced tags, uncorrectly written CSS, ect. not bashing you as a coder because 98% of your work is execellent, but unfortunatly that 2% does effect page rendering. If you would like to know my page settings I would be happy to share them with you, and then you can open it in mozilla and see just the one glaring fault that has me twinkied, or even in Mac OSX IE.

 

[rh71]

Originally posted by: notfred
So, coldfusion really does insert whitespace wherever it wants for no reason?

I'd find that really annoying....


RH71 - you get to call me a moron now.

NO WAY! Do I really? Nah, I have respect for most of the people here.

 

[rh71]

Originally posted by: narzy

Originally posted by: Zuni
Ok, this is getting a bit annoying, but why not respond.

1) Spacing, no the programmer does not add whitepace. Notfred, you are wrong, coldfusion replaces logic code with whitespace, which does nothing for client-side formatting. All it does is add a bit of space in the code, which if you calcluate out, is next to nothing.
2) The spacing issue is null and void, and is an uninformed complaint. All pages on this network use GZIP compression so spacing is not an issue.
3) Passwords are frequently stored on peoples machines, remember password feature in IE anyone? Welcome to the internet people, this is not abnormal, secure your own pc's thats the responsibility of the end user
4) CSS, HTML Spec, I'm even going to bother commenting on this.

Nuff said.

ummm why not touch on the specs? you quote that browsers that use spec's should render the page properly. are you saying that the only browser in the world that is spec strict is IE? HAHAHAHAHAHAHAH! LMFAO DUDE that is the FUNNIEST thing I have read all day...for a multi platform, multi user interface such as fusetalk it should ALWAYS be your number 1 priority to code as close to spec. as humanly possible.

Umm... it should be a well-known fact to anybody who's even remotely close to being a programmer that IE is the least restrictive when it comes to coding. I think Zuni knows that pretty well out of anyone here - he's the webmaster. Still, you can't leave out end brackets (like you stated above)... unless you MEANT to say closing tags instead.