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