Maybe this is a pattern, maybe even a new one. I'll just write out my experiences and see if others have solved the same problem in similar ways ...

When you're programming a website, often it makes sense if a non-programmer can change text without asking you to do it. The common solution for this is to use a language that allows you to imbed small pieces of code into markup: AllaireColdFusion, PhpLanguage, RubyLanguage .rhtml parsing,
JavaServerPages, JakartaStruts
etc.

When I first started using this stuff, I thought it would be enough to have the markup lie on top, and then strive for a clean separation between the markup and the code it calls. The relationship between the two, however, is strictly subservient: Code serves text.

I'm realizing it's more complex than that. There are a number of cases where the client needs direct access to text that's deeply embedded inside of your logic. Examples I've encountered include:

	* The text of the "Thank you for your order" letter that gets emailed to the customer of an ecommerce site when the credit card transaction clears.
	* Random teaser ads that get displayed to a Web site user.
	* Very specific HTML design requirements for code-generated forms.

The solution I'm starting to use is:

	1 Isolate the text in an external text file, perhaps in the /inc/ directory.
	1 Have the code load in that text at runtime.
	1 Tell the client where the external text file is.

That is, TextInsideOfCodeInsideOfText.

Have other people done this? What have your experiences been like?

----

This sounds a lot like the i18n problem - you know the intent of the messages, but not the content, so you provide the hooks to allow user alteration of content at code-specified points of intent.

----

In some cases the "inside text" can be a parameter to an embedded function call.

''But one of the requirements I'm trying to satisfy is giving a non-programmer the ability to change the text parts -- inside or outside -- without knowing how to program and without asking a programmer to do it for em. Making them parameters often isn't sufficient.''

----

In many programming environments, this is solved using "resources" -- (lines of) files, each of which contains a text string or image. For example, Windows resource files.

----
Similar in spirit?: AlternateHardAndSoftLayers

----
See CeePreprocessorStatements ("accepted" example #5)