File.txt

[A.M.]

Hi at all,
how can I do to insert into a HTML page a file .txt stored in the same
directory of the server where is the html file that must display the text
file.txt?
Thank you very much
P.Pietro

[Joakim Braun]

Re: File.txt

"A.M." <NOSPAM@eurotim e.it> skrev i meddelandet
news:VJcJc.5072 6$GQ3.1423250@t wister2.libero. it...[color=blue]
> Hi at all,
> how can I do to insert into a HTML page a file .txt stored in the same
> directory of the server where is the html file that must display the text
> file.txt?
> Thank you very much
> P.Pietro
>
>[/color]

You can't with javascript.

With server-side PHP it's as easy as: echo file_get_conten ts('file.txt');

Joakim Braun

[Grant Wagner]

Re: File.txt

Joakim Braun wrote:
[color=blue]
> "A.M." <NOSPAM@eurotim e.it> skrev i meddelandet
> news:VJcJc.5072 6$GQ3.1423250@t wister2.libero. it...[color=green]
> > Hi at all,
> > how can I do to insert into a HTML page a file .txt stored in the same
> > directory of the server where is the html file that must display the text
> > file.txt?
> > Thank you very much
> > P.Pietro[/color]
>
> You can't with javascript.
>
> With server-side PHP it's as easy as: echo file_get_conten ts('file.txt');
>
> Joakim Braun[/color]

It's even easier with HTML:

<iframe src="file.txt"> </iframe>

(assuming browser support for <iframe>)

--
Grant Wagner <gwagner@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Dennis M. Marks]

Re: File.txt

In article <VJcJc.50726$GQ 3.1423250@twist er2.libero.it>, A.M.
<NOSPAM@eurotim e.it> wrote:
[color=blue]
> Hi at all,
> how can I do to insert into a HTML page a file .txt stored in the same
> directory of the server where is the html file that must display the text
> file.txt?
> Thank you very much
> P.Pietro
>
>[/color]
Search for information on iFrame. It is not javascript but an HTML
solution. It is basically a frame that can be inserted anywhere in a
page. I know that it will display HTML and I'm pretty sure that it will
also display a text file but I may be wrong.

--
Dennis Marks

http://www.dcs-chico.com/~denmarks/

Mail to the return email address is bounced.
Go to web site for active email address.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----

[Thomas 'PointedEars' Lahn]

Re: File.txt

Dennis M. Marks wrote:[color=blue]
> [...] A.M. [...] wrote:[color=green]
>> how can I do to insert into a HTML page a file .txt stored in the
>> same directory of the server where is the html file that must
>> display the text file.txt?[/color]
>
> Search for information on iFrame. It is not javascript but an HTML
> solution. It is basically a frame that can be inserted anywhere in a
> page. I know that it will display HTML and I'm pretty sure that it
> will also display a text file but I may be wrong.[/color]

The "iframe" element embeds da resource, not only HTML documents.
Thus it should work with any resource. If it does not, the UA is
borken.

Note that this element is not supported by Netscape 4. And it has
recently been recommended to use the "object" element instead since
it is more flexible. However, the support for the latter element
is still not properly implemented in some browsers, so a combination
of both may be a viable solution:

<object data="foo.txt" type="text/plain">
<iframe src="foo.txt">
<a href="foo.txt"> foo.txt</a>
</iframe>
</object>


PointedEars
--
$n="\e[0;40;32m";for(1 ..10){print"\ec $n\n".$"x(15)." \e[1;35mY$n".$"x15 ;for(1..8){prin t$/.$"x($a=16-$_);$c=int
rand($d=2*$_);f or(2..$d){$f=31 +int
rand(3);print($ _-$c?"X":"\e[$f;1m*$n")}prin t$"x$a}print
$/.$"x(31)."\e[0m\n".$"."Merry Christmas".$/x2;select$q,$q, $q,0.5} # ;)

[Zenon]

Re: File.txt

Hello,[color=blue]
> Note that this element is not supported by Netscape 4. And it has
> recently been recommended to use the "object" element instead since
> it is more flexible. However, the support for the latter element
> is still not properly implemented in some browsers, so a combination
> of both may be a viable solution:
>
> <object data="foo.txt" type="text/plain">
> <iframe src="foo.txt">
> <a href="foo.txt"> foo.txt</a>
> </iframe>
> </object>
>[/color]
But how can access the content of the foo.txt file via javascript? Let
assume that the foo.txt is not the well formed HTML document?
Is it possible to access the file content?

regards
maciek

[Thomas 'PointedEars' Lahn]

Re: File.txt

Zenon wrote:[color=blue]
> But how can access the content of the foo.txt file via javascript?
> Let assume that the foo.txt is not the well formed HTML document?
> Is it possible to access the file content?[/color]

Unless the UA provides a DOM for text/plain documents, this
is impossible, and I know of no UA that provides such a DOM.


PointedEars

[Thomas 'PointedEars' Lahn]

Re: File.txt

Thomas 'PointedEars' Lahn wrote:[color=blue]
> Zenon wrote:[color=green]
>> But how can access the content of the foo.txt file via javascript?
>> Let assume that the foo.txt is not the well formed HTML document?
>> Is it possible to access the file content?[/color]
>
> Unless the UA provides a DOM for text/plain documents, this
> is impossible, and I know of no UA that provides such a DOM.[/color]

I take that back. The Gecko DOM provides its HTML DOM for text/plain
documents, that is, the content of the text file can be accessed with

iframeReference .document.body. innerHTML

and in newer release versions

iframeReference .document.body. textContent

at least in my Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3)
Gecko/20040717 Firefox/0.9.1+.


PointedEars

[Jimmy Cerra]

Re: File.txt

Oh Pointed Eared One,
[color=blue]
> Zenon wrote:[color=green]
> > But how can access the content of the foo.txt file via javascript?
> > Let assume that the foo.txt is not the well formed HTML document?
> > Is it possible to access the file content?[/color]
>
> Unless the UA provides a DOM for text/plain documents, this
> is impossible, and I know of no UA that provides such a DOM.[/color]

Check out the XML HTTPRequest Object, supported by both Mozilla,
(somewhat in) Safari and Internet Explorer with ActiveX enabled
(don't know about the others). There is also an interface of the
Document Object that allows XML files to be parsed. Check out

http://jibbering.com/2002/4/httprequest.html

-- Jimmy

[Thomas 'PointedEars' Lahn]

Re: File.txt

Jimmy Cerra wrote:[color=blue]
> Oh Pointed Eared One,[color=green]
>> Zenon wrote:[color=darkred]
>>> But how can access the content of the foo.txt file via javascript?
>>> Let assume that the foo.txt is not the well formed HTML document?
>>> Is it possible to access the file content?[/color]
>>
>> Unless the UA provides a DOM for text/plain documents, this
>> is impossible, and I know of no UA that provides such a DOM.[/color]
>
> Check out the XML HTTPRequest Object, [...][/color]

I know about XMLHttpRequest. It is only supported by newer UAs (that
you mentioned) and by older ones (IE on 32 bit Windows, AFAIK not on
the Mac) using support for additional APIs (ActiveX) that is probably
disabled due to security issues. And this is not access to a DOM, so
not necessarily the desired access to the content of a text file which
may include access to certain sections and paragraphs.
[color=blue]
> There is also an interface of the Document Object that allows XML
> files to be parsed.[/color]

Yes, *XML* documents, not text/plain documents. It may work with
those, but it does not need to.


PointedEars

[Jimmy Cerra]

Re: File.txt

Dear One with Pointed Ears,
[color=blue]
> I know about XMLHttpRequest. It is only supported by newer UAs (that
> you mentioned)[/color]

Which, depending on the domain may make sense or not. Whenever I
develop web applications, I use usually assume that a web surfer will
browse with a UA released at least four years ago on Windows, and
three on other machines. This covers 99% of my audience.Not an
unreasonable assumption, if you are going to use JavaScript. That
includes all browsers that support the XMLHttpRequest object. If the
user is browsing with something older, then they are already
comfortable surfing with a good portion of web sites not rendering as
intended. Most web sites assume a browser at least that old nowadays.

[color=blue]
> the Mac) using support for additional APIs (ActiveX) that is probably
> disabled due to security issues.[/color]

Any person browsing with ActiveX completely disabled is:

1. Computer literate; normal users don't know what ActiveX means.
2. Paranoid about ActiveX security holes.

The second fact is due to the number of different levels of ActiveX
support in Internet Explorer. If "Download signed ActiveX controls"
is disabled, then the threat is eliminated while allowing built-in
behaviors to still work. Completely disabling the technology isn't
necessary at all!

[color=blue]
> And this is not access to a DOM, so
> not necessarily the desired access to the content of a text file which
> may include access to certain sections and paragraphs.[/color]

The content is downloaded: I've used the interface and implementations
make it trivial to return the file as a string. Use Regular
Expressions to parse the sections, paragraphs, and other contents;
what other way can it be done?

[color=blue][color=green]
> > There is also an interface of the Document Object that allows XML
> > files to be parsed.[/color]
>
> Yes, *XML* documents, not text/plain documents. It may work with
> those, but it does not need to.[/color]

I may have not been clear. I was referring to the interface of
XMLDocument, which has a load() method that dowloads and parses an xml
file. Thishas nothing to do with the XMLHttpRequest.

Besides, it is nice to have, just in case you want to deal with xml
files.

--
Jimmy Cerra

[Thomas 'PointedEars' Lahn]

Re: File.txt

Jimmy Cerra wrote:[color=blue]
> Dear One with Pointed Ears,[color=green]
>> I know about XMLHttpRequest. It is only supported by newer UAs (that
>> you mentioned)[/color]
>
> Which, depending on the domain may make sense or not.[/color]

It is a matter of the UA and its DOM, not of the domain. Excluding
users just because their software is not the right one is not a
successful approach in the mid-term for any Web site.
[color=blue]
> Whenever I develop web applications, I use usually assume that a web
> surfer will browse with a UA released at least four years ago on Windows,
> and three on other machines. This covers 99% of my audience.
> [...][/color]

What nonsense you have written here you maybe find out reading
<http://pointedears.de/scripts/test/whatami> and googling for
previous related discussions in this newsgroup (I think
"statistics " will do as keyword).
[color=blue][color=green]
>> the Mac) using support for additional APIs (ActiveX) that is probably
>> disabled due to security issues.[/color]
>
> Any person browsing with ActiveX completely disabled is:
>
> 1. Computer literate; normal users don't know what ActiveX means.[/color]

People *are* informed about the risks of their software, including ActiveX,
in the media (often incompletely, but that's not the point), including in
television, I have seen it even in the daily news feature (when again a
security hole was used to spread a worm). Whether they really pay attention
and draw the correct conclusions for the system they are using is a
psychological and different matter.
[color=blue]
> 2. Paranoid about ActiveX security holes.[/color]

There is no paranoia required, only common sense. IE and ActiveX have been
and still are built-in security holes in (Windows) systems by themselves:
Allowing software to be downloaded and *executed* outside of a sandbox,
especially to operate then uncontrolled on the local file system, only
relying to the user's decision about what software is good and what is bad,
is a misguided approach just because the average user (and sometimes not
even experts) cannot estimate the full impact such piece of software can
have on the system (in that instant), especially on one with a loose user
account and security management (like Win9x and WinME; even Win2k and XP
running only with Administrator because some apps won't work without that
[reconfiguring file access restrictions, possibly requiring Registry
tampering, takes much time that people are seldom willing to invest,
they simply want things to work]).

The so-called "signed controls" feature has proven unreliable and security
restriction settings can be circumvented (and have been circumented in the
not-too-far past), you may want to read Bugtraq. Which is one of the
reasons why M$ supports and pursues TCPA (again the wrong approach; they
should instead revise their interfaces).

Almost daily "security updates" for often well- and long-known bugs at
windowsupdate.c om speak chapters about the bad quality of the underlying
software, not of the expertise of those who find the security holes as
the marketing wants you to believe.
[color=blue][color=green]
>> And this is not access to a DOM, so not necessarily the desired
>> access to the content of a text file which may include access
>> to certain sections and paragraphs.[/color]
>
> The content is downloaded: I've used the interface and implementations
> make it trivial to return the file as a string. Use Regular
> Expressions to parse the sections, paragraphs, and other contents;
> what other way can it be done?[/color]

Using RegExp to parse such a text reliably can be a pain-in-the-ass,
long strings do not help if there is not enough memory available on
the client, and it does not help if the interface interprets STAGO
and ETAGO as XML markup instead of plain text. If you would have
done either one (on unknown data) before, you would not have argued
this way.

The other way you are asking about is to provide for a DOM for text/plain
documents which would include interfaces for "sections, paragraphs, and
other contents" to be implemented as ECMAScript compatible prototypes,
for example. But since text/plain is not an interoperable format
(consider different newline sequences among platforms, different
encodings, e.g.), I doubt such a DOM will be ever widely implemented.
[color=blue][color=green][color=darkred]
>>> There is also an interface of the Document Object that allows XML
>>> files to be parsed.[/color]
>>
>> Yes, *XML* documents, not text/plain documents. It may work with
>> those, but it does not need to.[/color]
>
> I may have not been clear. I was referring to the interface of
> XMLDocument, which has a load() method that dowloads and parses an xml
> file.[/color]

What part of my above statement is still unclear to *you*?
[color=blue]
> Thishas nothing to do with the XMLHttpRequest.[/color]

I know.
[color=blue]
> Besides, it is nice to have, just in case you want to deal with xml
> files.[/color]

That is your only valid point. But serving plain text als text/xml
(which AFAIK would be required for the mentioned XML parser) is
neither what the OP was looking for nor would it always work.


PointedEars

[Jimmy Cerra]

UA capibilities, ActiveX security, and related notes (Was: Re: File.txt)

Thomas 'PointedEars' Lahn,

I shouldn't have responded, since I'm going very off-topic. Perhaps
this would be better discussed via email. j i m b o l i s t at c o l
d m a i l, with "hot" replacing "cold" and the appropiate TLD concated
to the end, is a good public address to reach me.

[color=blue][color=green]
> > Which, depending on the domain may make sense or not.[/color]
>
> It is a matter of the UA and its DOM, not of the domain. Excluding
> users just because their software is not the right one is not a
> successful approach in the mid-term for any Web site.[/color]

What about ESPN.com, which excludes Netscape 4 and earlier? It is
still very sucessful. What about email services like Hotmail or
Yahoo! mail, which use JavaScript to perform various operations.
Doesn't that exclude browsers that only support the Dom level 0 common
interface? What about Trekweb.com, which requires a version 5 browser
and gets lots of traffic with few problems? There are hundreds of
sites that don't view as intended in older browsers.

It is unrealistic to support everything, otherwise everything would
still look like sites designed around 1995! Supporting the majority,
while allowing passible presentation for those still on older
browsers, is the best policy. Of course, there are exceptions to any
rule, but many sites (dare I say, most web site) don't need the amount
of backwards compatibility you are advocating. I reiterate, that the
best choice depends on the problem domain, just like any engineered
design!

[color=blue][color=green]
> > Whenever I develop web applications, I use usually assume that a web
> > surfer will browse with a UA released at least four years ago on Windows,
> > and three on other machines. This covers 99% of my audience.
> > [...][/color]
>
> What nonsense you have written here you maybe find out reading
> <http://pointedears.de/scripts/test/whatami> and googling for
> previous related discussions in this newsgroup (I think
> "statistics " will do as keyword).[/color]

Whenever I design a web site, I need to know what my users' browsers
can support. Pulling an image based on JavaScript DOM capibilities
gives you a rough estimate. 100% accuracy isn't a requirement: You
only need a rough estimate and feedback from users during a test
phase.

The capibilities that I use are generally only supported by browsers
released four-five years ago. So that's what I test with.

[color=blue][color=green]
> > Any person browsing with ActiveX completely disabled is:
> >
> > 1. Computer literate; normal users don't know what ActiveX means.[/color]
>
> People *are* informed about the risks of their software, including ActiveX,
> in the media (often incompletely, but that's not the point), including in
> television, I have seen it even in the daily news feature (when again a
> security hole was used to spread a worm). Whether they really pay attention
> and draw the correct conclusions for the system they are using is a
> psychological and different matter.[/color]

That's a paradox. They can't be informed if they didn't pat attention
and draw the "correct conclusions." I get a different picture from
talking with people; they generally don't understand what a browser is
- ActiveX, HTML and other technologies are alien terms to them.

[color=blue][color=green]
> > 2. Paranoid about ActiveX security holes.[/color]
>
> There is no paranoia required, only common sense. IE and ActiveX have been
> and still are built-in security holes in (Windows) systems by themselves:
> Allowing software to be downloaded and *executed* outside of a sandbox,[/color]

There are basically two types of ActiveX when talking about Internet
Explorer: the _built-in_ controls (such as dhtml behaviors) and the
_downloadable_ controls. The built-in controls generally don't have
significent security holes (to my knowledge). If you disable ability
to download ActiveX controls, how can a trogen be downloaded in the
first place? You can even disable running all ActiveX except for
Administrator approved controls, if you feel there is a bug disabling
ActiveX downloads. It simply isn't necessary to completely disable
the feature to prevent those kind of attacks.

Finally, the average user who thinks _all_ ActiveX is a security risk
will be running a browser that doesn't support it (like Opera or
Firefox).

[color=blue]
> especially to operate then uncontrolled on the local file system, only
> relying to the user's decision about what software is good and what is bad,
> is a misguided approach just because the average user (and sometimes not
> even experts) cannot estimate the full impact such piece of software can
> have on the system (in that instant), especially on one with a loose user
> account and security management (like Win9x and WinME; even Win2k and XP
> running only with Administrator because some apps won't work without that
> [reconfiguring file access restrictions, possibly requiring Registry
> tampering, takes much time that people are seldom willing to invest,
> they simply want things to work]).[/color]

That run-on sentence is a little confusing. Please excuse anything
that I misunderstood.

A person lax on security wouldn't touch ActiveX settings in the first
place. Why wouldn't a security conscious individual create a special
account without net access specifically for those legacy applications
which require Administratior access?

[color=blue]
> The so-called "signed controls" feature has proven unreliable and security
> restriction settings can be circumvented (and have been circumented in the
> not-too-far past), you may want to read Bugtraq.[/color]

I'm not talking about signed controls. I'm talking about controls
built-into Internet Explorer. Downloadable signed controls can be
disabled without affecting the built-in controls.

[color=blue]
> Almost daily "security updates" for often well- and long-known bugs at
> windowsupdate.c om speak chapters about the bad quality of the underlying
> software, not of the expertise of those who find the security holes as
> the marketing wants you to believe.[/color]

I never said I trust Microsoft software. I think that I understand
how it works and how to secure it.

[color=blue]
> Using RegExp to parse such a text reliably can be a pain-in-the-ass,[/color]

Sometimes. It depends on the length, the complexity, and the problem
domain. Well structured text is easy to parse. And it can be parsed
on the fly with events too.

[color=blue]
> The other way you are asking about is to provide for a DOM for text/plain[/color]

No. I was referring to a DOM implementation for a different problem
domain, namely loading XML documents. It was a note.

[color=blue]
>[color=green][color=darkred]
> >>> There is also an interface of the Document Object that allows XML
> >>> files to be parsed.
> >>
> >> Yes, *XML* documents, not text/plain documents. It may work with
> >> those, but it does not need to.[/color]
> >
> > I may have not been clear. I was referring to the interface of
> > XMLDocument, which has a load() method that dowloads and parses an xml
> > file.[/color]
>
> What part of my above statement is still unclear to *you*?[/color]

I was trying to show a related feature that the origional poster may
not have been aware of. I wasn't talking about text/plain documents,
nor was I talking about the origional request. IT WAS A ***NOTE***,
NOT A DIRECT ALTERNATIVE!!!

[color=blue]
>[color=green]
> > Thishas nothing to do with the XMLHttpRequest.[/color]
> [...]
>
> That is your only valid point. But serving plain text als text/xml
> (which AFAIK would be required for the mentioned XML parser) is
> neither what the OP was looking for nor would it always work.[/color]

Sigh, that's not what I was talking about. It was a noted related
feature, not a direct responce to the OP's problem domain. Sometimes
people don't know what they want, or they want the wrong solution to a
problem. I certainly have written my fair share of hacks. Hasn't
everyone?

--
Jimmy Cerra

Warning: This post was not checked for spelling, grammar, or accuracy.
Please correct me, where appropiate. Thanks. :-)