Please read the attached HTML file Perki ------------------------------------------------- This mail sent through IMP: imap.epfl.ch
|
Hello, Here you will find 3 "ideas" Top Variables, Libs architechture and documentation standards. I highly needs comments on those ideas. The fact is that this things (I think doesn't exists in php or mod_perl and this could be a "plus" to mod_dtcl but they affect the base of mod_dtcl, so it must be commented, accepted or rejected quickly. personnaly I'm ok to write as much lib-scripts as possible and use existing libs such as gd. I'm also up to write the documentation maker. So as soon as we've decided something I'll be up code. PM Legris aka perki VariablesTV stands for "Top Variables" Attention! If we represent a webserver with it's domains, directories and pages as a tree. A TV is unique on each way to go from the bottom of the tree to one leaf. This means that you cannot create a TV on a subdirectory or upperdirectory of an existing TV of the same name. Example of use: As flags, when you access a system ressource, and when you don't want any other scripts to access it until you're done. You would use TVs for any value that you normaly save in a database, but you have to access very often. This values could be for example a cookie table. STILL TO DEFINE a max size? a time to leave? rename del_tv to unset_tv? all the commands <*>_tv could be renamed to "tv <*> params" -commands and syntax
Scripts and libsOrganisation of scripts and libraries.Scripts and libs are stored in directories that reflect the "package" in which they are. The can be in TCL or binary libs. Here is a example of the home script directory structure
Personnaly I do like having directories in uppercase and scripts in lowercase. User defined scripts Scripts and Libs repository can be completed and scripts overwrited using the following method. In the fashion of .htaccess files, you can complete the "TTLS" repository by having ".TTLS" directories in you web site. Normally you would want only one of this directory per webserver and per user, but who knows. Anyway what's important is that the scripts used is the closer to your webpage. So if you create the file ~user/public_html/.TTLS/HTML/COMMON/hr.tcl then this file is preffered. I would like to see this the procs in hr.tcl named like this: html_common_hr_proc1 ... (naturally as I said before hr doesn't need a single file, so it would be something like "html_common_hr") Command to access libs ans scripts: require require <PATH>/<SCRIPTS> examples: "require HTML/*" (or "require HTML") will load all the scripts and libs under the HTML directory and sub directories. "require HTML/COMMON/hr" will load "hr.tcl" no need for the extension, like this a tcl lib will be updatable to a "c" library with no effects on old scripts. TTLS can use this "require" function if they source or load librequire. For example TTLS/HTML/FORMS/date_input.tcl needs some feature of TTLS/HTML/FORMS/input.tcl. The headers of date_input.tcl will looks like: load librequire.so require TTLS/HTML/FORMS/input.tcl Like this you can load an single script whithout having to care for dependencies. Naturally "require" won't load twice the same script or lib. DocumentationStandard documentation request Documentation and descriptions about variables and scripts. Where The documentation can be located in two places, in the files themselves or in .TTM files. TTD stands for TT Documentation. the TTD documentation is stored between <TTD> </TTD> tags, for scripts that are proceded by mod_dtcl anything within this tags is removed from the output. Here is an virtual TTD block. (mostly inspired from tcl documentation files) #$name is the name of the documented element #$type could be one of VAR LIB SCRIPT TTML PROC DIR #$lang specify the language for this tag <TTD NAME=$name TYPE=$type> <INFO LANG=$lang>short info about this object (title)</INFO> <SYNOPSIS>command param1 param2 ...</SYNOPSIS> <DESCRIPTION LANG=$lang>place here a comment/description </DESCRIPTION> <KEYWORDS LANG=$lang>keyworks usefull for a search machine </KEYWORDS> <VERSION>version and date </VERSION> #could be usefull for files <AUTHOR>author infos </AUTHOR> <TVS>names of the TVS used and created </VERSION> # very usefull? </TTD> This information can be anywhere in the file where the code is (for example dummy.tcl) or in the file dummy.ttd. This is very usefull to document for example a ".so" file, and for multilingual documentation. The documentation maker will first read the .tcl or .ttml file then the .ttd file. So the documentation can be splitted in this 2 files. here is the example for the documentation of the proc html_common_hr_simple in "hr.tcl" which return the string "<HR>" and tooks no parameter. The following code is in "hr.tcl" you notice the "#" necessary in .tcl files they will be remove by the documentation maker #<TTD NAME=html_common_hr_simple TYPE=proc> # <INFO>generate an horizontal line</INFO> # <SYNOPSIS>html_common_hr_simple</SYNOPSIS> # <DESCRIPTION>return a <HR> tag, takes no paramters</DESCRIPTION> # <KEYWORDS>hr,line,html</KEYWORDS> #</TTD> And this one in "hr.ttd" <TTD NAME=html_common_hr_simple> #no need to specify the type, already declared in the .tcl file <INFO LANG=FR>genere une ligne horizontale</INFO> <DESCRIPTION LANG=FR>retourne <HR> tag, ne prend pas de parametre</DESCRIPTION> <KEYWORDS LANG=FR>hr,ligne,html</KEYWORDS> </TTD> |
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
