From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b1150caefb87348f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-05 17:00:18 PST Path: archiver1.google.com!news2.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!uni-berlin.de!82-43-33-75.cable.ubr01.croy.blueyonder.co.UK!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Ada Advocacy - WPG (Web Page Generation) scheme Date: Mon, 6 Oct 2003 01:00:13 +0100 Message-ID: References: NNTP-Posting-Host: 82-43-33-75.cable.ubr01.croy.blueyonder.co.uk (82.43.33.75) X-Trace: news.uni-berlin.de 1065398417 15784205 82.43.33.75 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Xref: archiver1.google.com comp.lang.ada:285 Date: 2003-10-06T01:00:13+01:00 List-Id: "Pascal Obry" 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':

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 :

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':

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 :

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]