But php does the same "replacestrings", we just do not see it
Plus you can do it in other ways, no need to use StringReplace exclusively. It can be anything (FORMAT instruction for example if that is easier for the developer, or a TStringList and then using the TStringList.Text as replacetext if all records are added, etc.), the important thing is that at the end of the tag replacement, we have the string we want the tag to be replaced with in the response.
Taking your "wish" example, you can make that even simpler with fpweb. In the template tag handler for all database fields you can use one single
ReplaceText := SQLQuery.FieldByName(TagString).AsString;
you do not even need to check for tag string matches. The only restriction is, that in the template for all fields coming from the sql query you need use the same tag name as the field name in the table.
<table>
<tr>
<th>No.</th>
<th>Name</th>
<th>Age</th>
</tr>
<tr>
<td>{+ID+}</td>
<td>{+Name+}</td>
<td>{+Age+}</td>
</tr>
</table>
if the table record has these 3 fields (ID, Name, Age), or the sql query at least returns fields with these names.
Of course, this is only good for template values/fields that are not need to be listed from a loop (1 record only, basically). For loops you need some kind of string concatenation to return all records. It is not different with php, it is just not programmed by us directly.
For multiple records it is also a way to just return the table records as a javascript array into the web page replacing a single template tag, and then process them from inside javascript on the client side to display them. But this brings us back again on doing programming and data processing on the client side.
This will probably not beat the ExtJS framework as a gui, which is already freely available to everyone.
Additionally, with fpweb the template designers can pass some additional parameters to the back end.
For example, a current date/time field on the web page can have a tag
{+DATETIME [-FORMAT=MM/DD/YYYY hh:mm-]+}
which passes the format the screen designer wants the datetime to be in. No back-end changes are needed if they want to change the format and in the tag handling we just need to apply the format from the tag parameter. They just change it in the template, the CGI/FCGI/Apache_module does not need to be changed. Something like this can be included for all field types if necessary giving free hand to the screen designers.
AB