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

[Mark Parnell]

Sometime around Wed, 22 Oct 2003 02:27:29 GMT, Long is reported to have
stated:

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

Solution: http://www.allmyfaqs.com/faq.pl?Incl...ile_in_another

--
Mark Parnell
http://www.clarkecomputers.com.au

[Nick Kew]

In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite monkeys
at the keyboard of "Long" <lo***********@ rogers.com> wrote:

Problem: to insert the content of a file in an HTML document at a specific location.
Long ago solved. Many solutions available.
One possible way is to add a WebCharm tag like this:

<%@charm:text 20 0 my_include_file .txt %>
A solution that breaks as soon as some-processor is not available is a poor
solution. Doubly so when some-processor is a specific implementation
as opposed to an open spec.
This work very much like the SSI #include tag.
Nope. SSI doesn't break HTML (or XML) if the processor is not available.
However, you have more control
on how my_include_file .txt is cached.
You have more *useful* control with XBitHack.
In the above example, the file is initially cached
and then fetched after the tag is processed 20 times.
What a mindbogglingly irrelevant criterion for cacheing!
Tag caching (and template caching) increases page generation speed during server
response.
Erm, yes. True (at least so long as the overhead of your engine is less
than the saving), but by no means new.
Visit edgesoft.ca web

Now that's intriguing. Is the similarity of your name to that of Edge-Side
Includes pure coincidence? Guess I'll have to take a look when I can
get a 'net connection.

--
Nick Kew

In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Long]

"Nick Kew" <ni**@fenris.we bthing.com> wrote in message news:ru******** ***@jarl.webthi ng.com...
: In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite monkeys
: at the keyboard of "Long" <lo***********@ rogers.com> wrote:
: > Problem: to insert the content of a file in an HTML document at a specific location.
:
: Long ago solved. Many solutions available.
:
: > One possible way is to add a WebCharm tag like this:
: >
: > <%@charm:text 20 0 my_include_file .txt %>
:
: A solution that breaks as soon as some-processor is not available is a poor
: solution. Doubly so when some-processor is a specific implementation
: as opposed to an open spec.
:
We did not think this was much of a concern, since it should be used WITH
a processor (WebCharm), otherwise there would be no point. However, it is
not difficult to modify the tag to look like:

<!--@charm:text 20 0 my_include_file .txt @-->

We will consider it in the next release.

: > This work very much like the SSI #include tag.
:
: Nope. SSI doesn't break HTML (or XML) if the processor is not available.
:
: > However, you have more control
: > on how my_include_file .txt is cached.
:
: You have more *useful* control with XBitHack.
:
: > In the above example, the file is initially cached
: > and then fetched after the tag is processed 20 times.
:
: What a mindbogglingly irrelevant criterion for cacheing!
:
Consider that the template and tag is cached and you have updated the .txt file
content. How would you un-cache and force reload?

: > Tag caching (and template caching) increases page generation speed during server
: > response.
:
: Erm, yes. True (at least so long as the overhead of your engine is less
: than the saving), but by no means new.
:
: > Visit edgesoft.ca web
:
: Now that's intriguing. Is the similarity of your name to that of Edge-Side
: Includes pure coincidence? Guess I'll have to take a look when I can
: get a 'net connection.
:
Never heard of E-S I. Could you provide a link?

Long

: --
: Nick Kew
:
: In urgent need of paying work - see http://www.webthing.com/~nick/cv.html

[Steve Pugh]

"Long" <lo***********@ rogers.com> wrote:

"Nick Kew" <ni**@fenris.we bthing.com> wrote in message news:ru******** ***@jarl.webthi ng.com...
: In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite monkeys
: at the keyboard of "Long" <lo***********@ rogers.com> wrote:
: >
: > In the above example, the file is initially cached
: > and then fetched after the tag is processed 20 times.
:
: What a mindbogglingly irrelevant criterion for cacheing!
:
Consider that the template and tag is cached and you have updated the .txt file
content. How would you un-cache and force reload?

I think you missed Nick's point.
Why 20 times? Why not 19? or 21? Or 20,000?

How do you know in advance how much caching you need? One week you may
only be getting a trickle of visitors between updates, the next week
you're slashdotted.

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net > <http://steve.pugh.net/>

[Long]

"Steve Pugh" <st***@pugh.net > wrote in message news:bb******** *************** *********@4ax.c om...
: "Long" <lo***********@ rogers.com> wrote:
: >"Nick Kew" <ni**@fenris.we bthing.com> wrote in message news:ru******** ***@jarl.webthi ng.com...
: >: In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite monkeys
: >: at the keyboard of "Long" <lo***********@ rogers.com> wrote:
: >: >
: >: > In the above example, the file is initially cached
: >: > and then fetched after the tag is processed 20 times.
: >:
: >: What a mindbogglingly irrelevant criterion for cacheing!
: >:
: >Consider that the template and tag is cached and you have updated the .txt file
: >content. How would you un-cache and force reload?
:
: I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example. The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.

: How do you know in advance how much caching you need? One week you may
: only be getting a trickle of visitors between updates, the next week
: you're slashdotted.
:
: Steve
:
: --
: "My theories appal you, my heresies outrage you,
: I never answer letters and you don't like my tie." - The Doctor
:
: Steve Pugh <st***@pugh.net > <http://steve.pugh.net/>

[Steve Pugh]

"Long" <lo***********@ rogers.com> wrote:

"Steve Pugh" <st***@pugh.net > wrote in message news:bb******** *************** *********@4ax.c om...
: "Long" <lo***********@ rogers.com> wrote:
: >"Nick Kew" <ni**@fenris.we bthing.com> wrote in message news:ru******** ***@jarl.webthi ng.com...
: >: In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite monkeys
: >: at the keyboard of "Long" <lo***********@ rogers.com> wrote:
: >: >
: >: > In the above example, the file is initially cached
: >: > and then fetched after the tag is processed 20 times.
: >:
: >: What a mindbogglingly irrelevant criterion for cacheing!
: >:
: >Consider that the template and tag is cached and you have updated the .txt file
: >content. How would you un-cache and force reload?

: I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example. The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.

I know that 20 is just an example, but you are still missing the
point. What does the number of times the document has been accessed
have to do whether it should be cached or not? Why not base the
decision to cache on something more relevant such as the date, or the
freshness of the include file?

The cache we are talking about here is on the web charm enabled web
sevrer, 'cos nothing you put in the include instruction is going to
affect proxy or browser caches, right? So why not include a nice
littel control panel that let's the author flush the cache clear at
his discretion? Or have the server automatically flush the cache when
a new include file is uploaded. Why reduce it to guessing based on how
many times the final page has been accessed?

Steve

--
"My theories appal you, my heresies outrage you,
I never answer letters and you don't like my tie." - The Doctor

Steve Pugh <st***@pugh.net > <http://steve.pugh.net/>

[Alan J. Flavell]

On Wed, 22 Oct 2003, Long wrote:

"Steve Pugh" <st***@pugh.net > wrote in message news:bb******** *************** *********@4ax.c om... : I think you missed Nick's point.
: Why 20 times? Why not 19? or 21? Or 20,000?
:
Ah... 20 times is just for the example.
Now we _know_ you missed Nick's point.
The author marking up the tag can specify
an appropriate value for his/her use, base on experience or guestimate.

You evidently don't understand yet that it wasn't the specific _value_
that was at issue, but the very idea of basing cacheability on such an
irrelevant quantity, no matter *what* its value.

[Long]

"Steve Pugh" <st***@pugh.net > wrote in message news:48******** *************** *********@4ax.c om...
: "Long" <lo***********@ rogers.com> wrote:
: >"Steve Pugh" <st***@pugh.net > wrote in message news:bb******** *************** *********@4ax.c om...
: >: "Long" <lo***********@ rogers.com> wrote:
: >: >"Nick Kew" <ni**@fenris.we bthing.com> wrote in message news:ru******** ***@jarl.webthi ng.com...
: >: >: In article <lW************ ****@news01.blo or.is.net.cable .rogers.com>, one of infinite
monkeys
: >: >: at the keyboard of "Long" <lo***********@ rogers.com> wrote:
: >: >: >
: >: >: > In the above example, the file is initially cached
: >: >: > and then fetched after the tag is processed 20 times.
: >: >:
: >: >: What a mindbogglingly irrelevant criterion for cacheing!
: >: >:
: >: >Consider that the template and tag is cached and you have updated the .txt file
: >: >content. How would you un-cache and force reload?
: >
: >: I think you missed Nick's point.
: >: Why 20 times? Why not 19? or 21? Or 20,000?
: >:
: >Ah... 20 times is just for the example. The author marking up the tag can specify
: >an appropriate value for his/her use, base on experience or guestimate.
:
: I know that 20 is just an example, but you are still missing the
: point. What does the number of times the document has been accessed
: have to do whether it should be cached or not? Why not base the
: decision to cache on something more relevant such as the date, or the
: freshness of the include file?
:
: The cache we are talking about here is on the web charm enabled web
: sevrer, 'cos nothing you put in the include instruction is going to
: affect proxy or browser caches, right? So why not include a nice
: littel control panel that let's the author flush the cache clear at
: his discretion? Or have the server automatically flush the cache when
: a new include file is uploaded. Why reduce it to guessing based on how
: many times the final page has been accessed?
:
Having the author manually flush the cache is a bad idea. I centainly would
not want to do it. Within an ISP environment how would you control who
flushes what?

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.

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

[Long]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote in message
news:Pi******** *************** ********@ppepc5 6.ph.gla.ac.uk. ..
: On Wed, 22 Oct 2003, Long wrote:
:
: > "Steve Pugh" <st***@pugh.net > wrote in message
news:bb******** *************** *********@4ax.c om...
:
: > : I think you missed Nick's point.
: > : Why 20 times? Why not 19? or 21? Or 20,000?
: > :
: > Ah... 20 times is just for the example.
:
: Now we _know_ you missed Nick's point.
:
: > The author marking up the tag can specify
: > an appropriate value for his/her use, base on experience or guestimate.
:
: You evidently don't understand yet that it wasn't the specific _value_
: that was at issue, but the very idea of basing cacheability on such an
: irrelevant quantity, no matter *what* its value.

May be so. Perhaps you will change your mind after reading my reponse
to Steve's post.

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