How to include a file in an HTML doc

[Long]

Problem: to insert the content of a file in an HTML document at a specific location.

One possible way is to add a WebCharm tag like this:

<%@charm:text 20 0 my_include_file .txt %>

When the HTML template is processed by a WebCharm-aware web server, the
content of my_include_file .txt is inserted at the tag location.

This work very much like the SSI #include tag. However, you have more control
on how my_include_file .txt is cached. In the above example, the file is initially cached
and then fetched after the tag is processed 20 times. That is, fetched once per 20 requests.
Tag caching (and template caching) increases page generation speed during server
response.

Visit edgesoft.ca web site for more information on WebCharm template and tags.
In particular, www.edgesoft.ca/go/index.html?top=wc

--
Long On
Edgesoft Consulting Inc.
webcharmer @ www.edgesoft.ca/go/member/index.html
www.edgesoft.ca/go/index.html
www.edgesoft.ca

[Long]

"Bruce Lewis" <br*****@yahoo. com> wrote in message news:nm******** *****@magic-pi-ball.mit.edu...
: "Long" <lo***********@ rogers.com> writes:
:
: > "Bruce Lewis" <br*****@yahoo. com> wrote in message news:nm******** *****@magic-pi-ball.mit.edu...
: > : "Long" <lo***********@ rogers.com> writes:
: > :
: > : > "Matt" <ma**********@h otmail.com> wrote in message
: > : > news:pa******** *************** *****@hotmail.c om...
: > : > : Why not check the modification date of the included file, see if it's
: > : > : changed, and then decide if the cached page is current? That way, zero
: > : > : visitors get the outdated page! :-)
: > : > :
: > : > How is this diffent than refresh on every request? You'd still need to
: > : > access the file system at each request, to check for the modification
: > : > date. If the size of the include file is not huge, the performance
: > : > gain would be minimal to none.
: > :
: > : I think most filesystems do a certain amount of in-memory caching for
: > : file mod times.
: > :
: > Perhaps.
:
: Do a google search for "inode cache". One of your supported platforms
: (Linux) does exactly this. I doubt it's different from other Unix
: implementations . You can configure the size of your inode cache
: according to your server's needs.
:
Thanks for the pointer. Very helpful.

: > : I don't think most filesystems do in-memory caching of
: > : file contents.
: > :
: > WebCharm allows in-memory caching of templates and include files to
: > help reduce file I/O, but by no means 100%. This does depend on how a
: > template and containing tags are configured.
:
: Your question was "How is this different than refresh on every request?"
: I answered that. Matt's suggestion reduces file I/O better than
: WebCharm does.
:
Now that I know about "inode cache". In the next release, we will consider
checking for file mod timestamp, to refresh the cached content. It probably will
simplify the tag syntax as well. Thank you both.

: For example, if you're using BRL and do
:
: [(paste "my_include_fil e.txt")]
:
BRL? Never heard of it...until now. I had a quick look and it is very interesting.
BRL seems to be equivalent to WebCharm/e (enterprise edition) in terms
of functionality. One difference is in BRL's own programming language, instead
of Scheme. Whereas, WebCharm is base solely on templates and tags and
new functions in WebCharm/e are programed in Smalltalk.

: You'll get better I/O performance (and probably better overall
: performance) than with WebCharm's alternative:
:
: <%@charmcnf: pageRequestServ let , 1, *, 2, 60 %>
: <%@charm:text 20 0 my_include_file .txt %>
:
I do appreciate that you actually spend some time to evaluate WebCharm.

: I notice you left that first line out from your initial helpful post.
: Your authoring guide says it's required.
:
This is correct, I wanted to only concentrate on the #include equivalent tag. But
in practice, a WebCharm template is identified by the inclusion of a @charmcnf
signature.

: > : The Apache version of your product is hitting the filesystem for most
: > : requests anyway, to launch the CGI program.
: > :
: > Yes, this is an inherent behavior of CGI and it is out of our
: > control. Although, the CGI module (abtwsac) is only 30K in size so the
: > overhead is not too bad. WebCharm on the other hand is a separate
: > application that stays resident in memory, once launched.
:
: So don't use CGI. BRL doesn't. PHP doesn't. SSI doesn't. You're
: behind the pack. And the alternatives I mentioned are all free.
:
We do have access to a CGI alternative that is Java-based and runs within
a Java container (such as Tomcat). Performance wise, it is much better than
CGI. However it is a can of worm to install and configure. We wanted to keep
WebCharm easy to install and use as a trade-off, so we excluded the option.

Regards,

Long

[Matt]

On Wed, 22 Oct 2003 16:06:46 +0000, Long wrote:

: >: >: "Long" <lo***********@ rogers.com> wrote:
: >: >: > In the above example, the file is initially cached
: >: >: > and then fetched after the tag is processed 20 times. <snip missing-the-point> In the larger scheme, a WebCharm template can be configure to un-cache
after a period of inactivity (i.e. no page requests). This un-caches all contained
tags so everthing gets flushed automatically. A different scenario happens when
the template is so busy serving requests that it never (may be days) get flushed and
in the mean time you have changed the include content. Having the tag flush
periodically helps keep content up to date, sooner. We could have chosen to do a
time-flush at the tag level, but a count-flush work just as well.

Er... no it doesn't. What if the page is flushed, then viewed once, then I
change the content. The next _19_ (for example) visitors get an out of
date page!

Likewise with time: All visitors in the next (e.g.) 5 minutes get the
outdated page!

Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)

HTH :-) HAND

--
Matt
-----= 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! =-----

[Owen Jacobson]

Matt wrote:

Why not check the modification date of the included file, see if it's
changed, and then decide if the cached page is current? That way, zero
visitors get the outdated page! :-)

That's only really possible iff all your included content has
timestamps. If you start generating pages from database content (most
of the time; there are some CMS schema that actually have useful time
information) or output from a program, then you're pretty much stuck
assuming that the data will be fresh for a specific period of time. In
some cases with databases, the overhead of checking the timestamp is
high enough that you may as well either not bother or pull the whole
page anyways, at which point you lose the benefit of caching.

Granted, the OP isn't doing that, s/he's including a .txt file, but
it's something to think about.

Owen