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

["Stephane Richard" <stephane.richard@verizon.net>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 7855 bytes --]


"Nick Roberts" <nickroberts@blueyonder.co.uk> wrote in message
news:blqbag$f1m8d$1@ID-25716.news.uni-berlin.de...
> "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]
>
>

Have you benchmarked running FastCGI and AWS ?  Running or generating
somewhat the same HTML contents?  You might be surprised with the results
you find :-).

-- 
St�phane Richard
"Ada World" Webmaster
http://www.adaworld.com