Re: Ada Advocacy - WPG (Web Page Generation) scheme

["Nick Roberts" <nickroberts@blueyonder.co.uk>]

"Pascal Obry" <p.obry@wanadoo.fr> wrote in message
news:u8yo06nn3.fsf@wanadoo.fr...

> Well AWS has alread it's templates engine. Please have a
> look. One important point is that your template file must
> be compatible with the design tools like DreamWeaver.
> And a designer is not a programmer, the "tags" or tem-
> plate commands must be easy to use, scripting language
> are not in this category.

I wholeheartedly agree with this notion.

> [re CGI]
> But it has many many drawbacks. CGI programs run as
> differents process, this is not good for server with a lot
> of hits.

True, but the interpretation of a template page for every single page
request is also inefficient (for a server with a lot of hits). On the other
hand, a CGI program can quite easily be converted to operate as a FastCGI
program (which essentially removes the inefficiency of running and
terminating the program for every page request).

> Also there is security issues. I'm not expert here, but
> there was many exploit with CGI oriented servers
> (replacing CGI with some other programs, CGI were
> running as root on the early days, if interpreted - PERL
> CGI - it was possible to send sequence of code
> after a ';' line separator...).

There are no security risks associated with CGI itself. There are various
potential security risks associated with badly designed, badly implemented,
or inappropriately configured servers, and with any program executed in
response to a web page request (be it a CGI program or a server-side script)
which is badly designed, badly implemented, or inappropriately configured.

I have looked at the documentation for your templates parser, Pascal. For
anyone interested, the URL is:

   http://perso.wanadoo.fr/pascal.obry/archive/templates_parser.html

Overall, I like it a lot. I particularly like the way it separates the HTML
from the Ada.

However, what I particularly don't like is the way data is transmitted from
program to template. I think it's inefficient and inflexible. I'd like to
propose a different way for communication between the Ada program and the
template file, and a very much simpler syntax.

Suppose everything is put inside a package named DAW (argue about this name
if you wish!). I propose a spec something like this:

package DAW is
   type Parameter_String is access constant String;
   type Parameter_List is array (Positive range <>) of Parameter_String;
   type Macro_Interpreter is function (Parameters: in Parameter_List) return
String;
   type Condition_Interpreter is function (Parameters: in Parameter_List)
return Boolean;
   type Table_Control_Action is (Open_Table, Close_Table, Skip_Cursor);
   type Table_Controller is procedure (
         Action: in Table_Control_Action;
         Parameters: in Parameter_List;
         End_of_Data: out Boolean );
   type Interpreter_Set is private;
   procedure Add_Macro (
         Set: in out Interpreter_Set;
         Name: in String;
         Interpreter: in Macro_Interpreter );
   procedure Add_Condition (
         Set: in out Interpreter_Set;
         Name: in String;
         Interpreter: in Condition_Interpreter );
   procedure Add_Table (
         Set: in out Interpreter_Set;
         Name: in String;
         Controller: in Table_Controller );
   function Evaluate_Macro (Interpreters: in Interpreter_Set; Value: in
String) return String;
   function Evaluate_Condition (Interpreters: in Interpreter_Set; Value: in
String) return Boolean;
   procedure Parse_Template (
         Name: in String;
         Output: in Ada.Text_IO.File_Type;
         Interpreters: in Interpreter_Set;
         Left_Delimiter: in String := "@_";
         Right_Delimiter: in String := "_@";
         Command_Prefix: in String := "@@";
         Escape_Sequence: in String := "@\" );
end DAW;

For example, with the template file 'demo1.txt':

<P>Name @_NAME_@

the following Ada program 'demo1.adb':

with Ada.Text_IO;
with DAW;
procedure Demo1 is
   Translations : DAW.Interpreter_Set;
   function My_Name (Parameters: in Parameter_List) return String is
   begin return "Ada"; end;
begin
   Add_Macro( Translations, "NAME", My_Name'Access );
   Parse_Template( "demo1.txt", Ada.Text_IO.Current_Output, Translations );
end Demo;

would print out :

<P>Name Ada

In the template file, a macro can have parameters, in the familiar
(abc,pqr,xyz) format, after its name. The Ada program can therefore add any
function it wishes. For example, with the template file 'demo2.txt':

<P>My age is @_SUB(AGE,5)_@

the Ada program 'demo2.adb':

with Ada.Text_IO;
with DAW;
procedure Demo2 is
   Tr: DAW.Interpreter_Set;
   function My_Age (P: in Parameter_List) return String is
   begin return "38"; end;
   function My_Sub (P: in Parameter_List) return String is
   begin return Integer'Value(Tr,Evaluate_Macro(P(1)))-Integer'Value(P(2));
end;
begin
   Add_Macro( Tr, "AGE", My_Age'Access );
   Add_Macro( Tr, "SUB", My_Sub'Access );
   Parse_Template( "demo2.t", Ada.Text_IO.Current_Output, Tr );
end Demo;

would print out :

<P>My age is 33

Certainly DAW could provide a complete set of default utility parametised
macros. Any of these could be overridden if required.

Conditional sections could be supported by a very much simpler form of IF
command, which only took a condition name (which could be parametised):

@@IF condition_name
   ...
@@ELSE
   ...
@@END_IF

This would invoke the condition with the given name, and select which
section to (process and) output based on the result (True or False).
Incidentally, I suggest all commands are line-oriented (a line starting with
the command prefix is a command running to the end of the line); just a
little bit easier and neater, I think.

Within a TABLE command, the table would be passed as a parameter of a macro
to access a field of the table. Inside nested tables, the name of each table
would be passed as a separate parameter. A table controller procedure would
control iteration through the rows of the table, and indicate termination.

@@TABLE A
   @@TABLE B
      ... @_PROD_NAME(A,B,FULL)_@ ...
   @@END_TABLE
@@END_TABLE

This would cause table A to be opened, for each of its rows, table B to be
opened, and for each of its rows the text inside to be repeated. Within this
text, the example macro shown would cause a call to the macro interpreter
corresponding to "PROD_NAME", which might be My_Prod_Name, with the
parameter list ("A","B","FULL").

The advantage of this technique is that typically only a row-set has to
buffered in memory, rather than all the values in the whole table. This fits
the typical way in which data is pulled from a database table (row by row),
and could be a lot more efficient for larger tables.

I think @@INCLUDE could be kept, and @@SECTION, and maybe a few other
things, but I think this scheme would provide the complete funcitonality
required in a somewhat simpler form. No doubt there will be lots of other
details and things I haven't thought of.

In general, I prefer more a bit more work to be done in the Ada program, and
a little less in the template language.

What do you think, Pascal?

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]