Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

formating text to html mode 1

Status
Not open for further replies.

mici

Programmer
Jun 2, 2003
36
0
0
IL
i read an email and desplay the content on the website, in a pop - up window (window.open)

the text however is being displayed there as a plain text with no paragraphs or line breaks. How do i change it to html mode as in the email .?
 
i read it by sql server

as for your reply- i can i build the html in my window if it is dynamic and each msg is different from another?
 
Yes, JavaScript provides the "document.write()" method. You pass in HTML with that method.

When you use the window.open() method, you can assign a window handler, as such:

Code:
msgWindow = window.open();

and then write to it thusly:

Code:
msgWindow.document.open();
msgWindow.document.write("<html><body>");
msgWindow.document.write("<p>An HTML paragraph!</p>");
msgWindow.document.write("</body></html>");
msgWindow.document.close();



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
beware of document.write - it won't work with XHTML, and it reduces future compatibility.

But, given mici's question, I don't think mici is using JavaScript. Mention of sql server suggests server-side code.

Mici - Is this correct? What server language are you programming with?

<marc>
 
How about going super easy and just embedding everything in <pre></pre> tags. That way the line breaks and white-space will be preserved.
 
I would also use <pre>, if they work.
If not, as you run mySQL, I guess you also have php.
Then you can try other things, like nl2br(), etc.

Olav Alexander Mjelde
Admin & Webmaster
 
I'm curious about the comment that document.write() doesn't work with XHTML... can you point to some documentation?
From the W3C on XHTML.
"window.open()" suggests JavaScript to me!
Indeed (and I missed that!)
I imagined mici to be using Javascript to cause a popup, not to populate the contents of the popup. I would expect the contents of the window to be populated using a server-side language. But that's just the way I would do it :)

<marc>
 
I try to limit server-to-browser round-trips. I would use servr-side code to create the initial window/page, and "load" it with all it needed to open/author the second window/page.

This info on document.write() concerns me. It is such a staple of client-side development. It's curious though. It seems to be saying that a document couldn't write itself, calling it a "trick". But what about the scenario in this thread, where a script in an XHTML document is used to write XHTML to a second, new document?

I have some experimenting to do. Thanks for the heads-up, you get a star for that.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
W3C said:
You can still achieve the same effects, but you have to do it by using the DOM to add and delete elements.

You use tricks like:
Code:
x = document.getElementById('itemID');
x.innerHTML = "<p>Some text</p>";

One of the things to remember is that each script action which manipulates the DOM has to do so in a compliant manner: you can't use x.innerHTML = "<p>Something" because it's missing the closing </p>.

As for document.write on a new document - that, I'm not sure of :)

<marc>
 
Why do you use client side scripting? I think that is no good!

Why dont you simply make PHP parse XHTML of the data from mySQL?

Olav Alexander Mjelde
Admin & Webmaster
 
tgreer - IIRC, it's the W3C DOM. Effectively this is the XML DOM, but it has to comply with the W3C's standards for XHTML.

If it were just XML, you could happily add any tag you like - and indeed if you were serving XML (with an xml mimetype) styled with XSLT, you could merrily play with the XML DOM. As it's XHTML, your manipulations have to comply with the XHTML DTD you declare.

<marc>
 
Check my test document again:


It validates as strict XTHML, but opens a child window and writes it's contents using document.write().

The answer is, you have to externalize your script. This is because EVERYTHING in the document is parsed content, so you cannot effectively embed HTML tags within your script.

But if you put your script into an external JS file, you can link to it.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
It validates as strict XTHML
Unfortunately, the W3C validator won't check javascript - so it doesn't know if the script is valid or not.

If it registered invalid before, you probably fell foul of XHTML's ridiculously complex script markup requirements:
Code:
<script>
  [COLOR=green]// <![CDATA[[/color]
    [i][COLOR=grey]script goes here[/color][/i]
  [COLOR=green]// ]]>[/color]
</script>
Yes, you do need the // and CDATA bits.

Most browsers are lenient on document.write, but the time will come!

<marc>
 
daButcher: Client-side script for all interface/validation/css, etc. Server-side code for business logic and data layers. That creates the most efficient program with the best user experience.
Client side validation... So, I can insert all kinds of awful things to your site -- all I have to do is turn off Java and VB script or use my favorite web browser.... lynx.

Anythinf scripted that runs on the client side is stuff that obviously can't be important, period. You never know what browser your visitor has, how every client browser will interpret the page, and if the visitor has scripting turned on in the first place. Anything that is mission critical should be done by the server, client side script should only be used anything that is just to be pretty to and browser that is newer and graphical -- and is optional to getting at content and making the site work.

Just my 2.0 * 10 ^ -2 USD.
 
I suppose it depends entirely on the context/scope of the application. There comes a point where you have to balance the usability/convenience of your core customers against the inconvenience of a few.

If I can make my site functional, efficient, and appealing to 90% of my market base, I will usually choose that route.

You took "validation" too literally, I think. Of course I prevent SQL injection, etc. and have proper safeguards in the server and database layers of my apps.

But for writing dynamic content to windows, I use client-side as I've described. I also use JavaScript to make sure all forms are properly filled-out, numbers are formatted, etc. not as a security measure for my application, but as a convenience to the vast majority of my users.

"Anythinf scripted that runs on the client side is stuff that obviously can't be important, period."

I consider my users, and their experience, very important.



Thomas D. Greer

Providing PostScript & PDF
Training, Development & Consulting
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top