[WebDNA] Announcing the new features for the next WebDNA version
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 112064
interpreted = N
texte = Here is a short description of some new tags in the next version of = WebDNA (March-April 2015) In March, we will need some Beta testers for the FastCGI version (faster = to build and fix, if needed). The final build will be for CentOS 6, = CentOS 7, Debian 7, Ubuntu 12 and Ubuntu 14, Yosemite and Yosemite = Server. The FastCGI will run on any linux flavor and any OSX. The FastCGI will = have its own installer. There will be a new installer for the fastCGI + lighttpd or nginx = (Debian 7 and CentOS 7). The installer will remove apache, install = lighttpd or nginx and WebDNA.fcgi plus all the dependencies and = configuration. By default, the installers are setup for .dna Other suffix extensions will need to be setup manually: if we want to = exist, we do not have to hide behind static files suffixes. There will be more to come: 2015 will be an interesting year for WebDNA = :-) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 [realIP] shows the IP of the visitor=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =20 [regex] is the full implementation of GREP built in WebDNA. Extensive = documentation already exists. However, WebDNA interprets the search string and special characters will = not be usable by regex. A small trick bring the solution: [regex search=3D\b0+&replace=3D]080.010.001.305[/regex] The + is converted into a space by WebDNA. However, if replaced with %2B = then it works just fine. For example, this works correctly: [text]value=3D\b0%2B[/text] [regex search=3D[value]&replace=3D]080.010.001.305[/regex] Result is: 80.10.1.305 And this demonstrates the space conversion occurs when the parameters = are read in by WebDNA: [text]value=3D\b0+[/text] [regex search=3D0&replace=3D[value]]TEST0TEST[/regex][value] Result is: TEST\b0 TEST\b0+ The best way is by using [url][/url] [text]value=3D\b0+[/text] [regex search=3D[url][value][/url]&replace=3D]080.010.001.305[/regex] =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 "[break]" is now available with all the looping cells: If the cell sees the [break] tag while executing a loop, it will stop = looping, once it finishes the current loop. Thus the [break] tag should = only appear in a [showif] statement that is evaluated at the end = (bottom) of the loop. [founditems] [listwords] [listvariables] [listdatabases] [formvariables] [listpath] [listfiles] [listchars] =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 "CalcCRC32" computes the CRC32 of a string. It gives the same = [calcfilecrc32 file=3Dtest.txt] result as if the string is stored in a = test.txt file=20 [text]stringX=3Dbalh blah blah blah[/text] [CalcCRC32][stringX][/CalcCRC32] returns 345965317 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Extended comparisons for the [switch] cell. The comparison features are = the same as for the [if][then][else] http://webdna.us/page.dna?numero=3D241 We have created something very powerful here, that needs much better = documentation built on exemples. English is not my mother tongue and = what I write is sometimes not interpreted as I would like :-) The most difficult part has been to keep backward compatibility: if the = [case] statement sets the parameter "value" as in this example: [case value=3D13] Then it assumes they are the old-style switch statements. However, if it doesn=E2=80=99t see "value=3D", it assumes there is an = equation to evaluate, just like with [if]. You can also mix/match both types in the same switch block and it works = just fine. [text]x=3D3[/text] [switch value=3D[x]] [case [x]=3D1] The value of x was 1 [/case] [case [x]>2] The value of x was > 2 [/case] [case value=3D3] The value of x was 3 [/case] [default] The value of x was neither 1 nor 3 nor greater than 2; it was [x] [/default] [/switch] This code outputs: The value of x was > 2 The value of x was 3 If you set value=3D in the [switch] statement, then that is used only = for the [case] statements where you also set value=3D. The value=3D you = set in the [switch] statement is completely ignored for any [case] = statements where you don't set value=3D. So as an example, this does NOT work at all: [switch value=3D[x]] [case value>23] Because you are literally comparing the text "value" to the number 23. Also, this does NOT work either: [switch value=3D[x]] [case [value]>23] value is a parameter, it is not defined as a variable. So [value] = doesn't evaluate as anything in the equation. However, this DOES work: [text]value=3D24[/text] [switch value=3D[x]] [case [value]>23] This works because value was defined as a variable outside of the = switch. This works too: [text]value=3D24[/text] [switch] [case [value]>23] If you don=E2=80=99t use value=3D statements in the [case] statements, = you don't have to set it in the [switch] statement. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 [store] and [recall]: we have created a cell that stores variables = permanently. This has to survive a reboot, the variable can be as long = as wanted: it will save the hassle of writing the code to keep those in = a database. However, to avoid "overheating", we would have only one name = per variable, meaning that if we store name3 as "pink", and later store = name3 as "black", then only the last value will remain and "pink" will = be overwritten by "black" The process would use [store] and [recall] + the name of the variable + = the variable itself [store]var1=3DJoe[/store] The data will be stored in a reserved.db database, with two columns: = "from" and "to", so, the very same database will be usable with = [convertwords] If such a database does not exist, it will be automatically created at = the same level the creating code file is located. from to var1 Joe var2 Biden In fact, [store]var1=3DJoe[/store] will do the same as [replace = db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]var1=3DJoe[/replace] [convertwords] can be easily used to widen the scope of this new cell, = like this: [convertwords db=3Dreserved.db] The Vice President, Mr. var1 var2, will visit China next month. [/convertwords] There are 4 options: 1.) show (optional) "T" or "F". Default behavior is to hide the value = when assigning to a variable. If we want the value to be shown at the = same time it is assigned to a variable, we may set Show=3DT (There is no = reason to ever use show=3Df, as this is default behavior.) [store show=3DT]var1=3DJoe[/store] 2.) the second option allows to store multiple variables in one cell multi (optional) "T" or "F". Allows to assign more than one text = variable in a single cell. [store multi=3DT]var1=3DJoe&var2=3DFred[/store] simultaneously assigns = the two variables. (There is no need to use multi=3DF for single = variables.) 3.) The third option is the optional path of the database, in case a = user wants to use another reserved.db than the one found at the same = level. The name must remain "reserved.db" with "from" and "to" column = headers. [store path=3D../../admin/reserved.db]var1=3DJoe[/store] Look for "reserved.db" two levels up, in /admin 4.) an option "interpret o no" tags: [store parse=3DT]var1=3DToday is [date][/store] would give from to var1 Today is 01/16/2015 var2 Fred [store parse=3DF]var1=3DToday is [date][/store] would give from to var1 Today is [date] var2 Fred The defaut behavior being parse=3DF This can be compared to [function] with preparse and post-parse [recall var1] will just get the codon replaced by the variable. [recall] = will be basically a [lookup] [lookup db=3Dreserved.db&value=3Dvar1&lookInField=3Dfrom&returnField=3Dto]= The database, once it exists, will store the data without limit other = than what the programer decides. So, there is no need to initialize it. = It will be initialized at creation, then no more. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 best regards, - chris
Associated Messages, from the most recent to the oldest:
Here is a short description of some new tags in the next version of = WebDNA (March-April 2015) In March, we will need some Beta testers for the FastCGI version (faster = to build and fix, if needed). The final build will be for CentOS 6, = CentOS 7, Debian 7, Ubuntu 12 and Ubuntu 14, Yosemite and Yosemite = Server. The FastCGI will run on any linux flavor and any OSX. The FastCGI will = have its own installer. There will be a new installer for the fastCGI + lighttpd or nginx = (Debian 7 and CentOS 7). The installer will remove apache, install = lighttpd or nginx and WebDNA.fcgi plus all the dependencies and = configuration. By default, the installers are setup for .dna Other suffix extensions will need to be setup manually: if we want to = exist, we do not have to hide behind static files suffixes. There will be more to come: 2015 will be an interesting year for WebDNA = :-) =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 [realIP] shows the IP of the visitor=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 =20
[regex] is the full implementation of GREP built in WebDNA. Extensive = documentation already exists. However, WebDNA interprets the search string and special characters will = not be usable by regex. A small trick bring the solution: [regex search=3D\b0+&replace=3D]080.010.001.305[/regex] The + is converted into a space by WebDNA. However, if replaced with %2B = then it works just fine. For example, this works correctly:
[text]value=3D\b0%2B[/text] [regex search=3D[value]&replace=3D]080.010.001.305[/regex] Result is: 80.10.1.305 And this demonstrates the space conversion occurs when the parameters = are read in by WebDNA:
[text]value=3D\b0+[/text] [regex search=3D0&replace=3D[value]]TEST0TEST[/regex][value] Result is: TEST\b0 TEST\b0+ The best way is by using
[url][/url]
[text]value=3D\b0+[/text] [regex search=3D
[url][value][/url]&replace=3D]080.010.001.305[/regex] =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 "[break]" is now available with all the looping cells: If the cell sees the [break] tag while executing a loop, it will stop = looping, once it finishes the current loop. Thus the [break] tag should = only appear in a
[showif] statement that is evaluated at the end = (bottom) of the loop.
[founditems] [listwords] [listvariables] [listdatabases] [formvariables] [listpath] [listfiles] [listchars] =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 "CalcCRC32" computes the CRC32 of a string. It gives the same = [calcfilecrc32 file=3Dtest.txt] result as if the string is stored in a = test.txt file=20
[text]stringX=3Dbalh blah blah blah[/text] [CalcCRC32][stringX][/CalcCRC32] returns 345965317 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Extended comparisons for the
[switch] cell. The comparison features are = the same as for the
[if][then][else] http://webdna.us/page.dna?numero=3D241 We have created something very powerful here, that needs much better = documentation built on exemples. English is not my mother tongue and = what I write is sometimes not interpreted as I would like :-) The most difficult part has been to keep backward compatibility: if the = [case] statement sets the parameter "value" as in this example: [case value=3D13] Then it assumes they are the old-style switch statements. However, if it doesn=E2=80=99t see "value=3D", it assumes there is an = equation to evaluate, just like with
[if]. You can also mix/match both types in the same switch block and it works = just fine.
[text]x=3D3[/text] [switch value=3D[x]] [case [x]=3D1] The value of x was 1 [/case] [case [x]>2] The value of x was > 2 [/case] [case value=3D3] The value of x was 3 [/case] [default] The value of x was neither 1 nor 3 nor greater than 2; it was [x] [/default] [/switch] This code outputs: The value of x was > 2 The value of x was 3 If you set value=3D in the
[switch] statement, then that is used only = for the [case] statements where you also set value=3D. The value=3D you = set in the
[switch] statement is completely ignored for any [case] = statements where you don't set value=3D. So as an example, this does NOT work at all: [switch value=3D[x]] [case value>23] Because you are literally comparing the text "value" to the number 23. Also, this does NOT work either: [switch value=3D[x]] [case [value]>23] value is a parameter, it is not defined as a variable. So [value] = doesn't evaluate as anything in the equation. However, this DOES work:
[text]value=3D24[/text] [switch value=3D[x]] [case [value]>23] This works because value was defined as a variable outside of the = switch. This works too:
[text]value=3D24[/text]
[switch] [case [value]>23] If you don=E2=80=99t use value=3D statements in the [case] statements, = you don't have to set it in the
[switch] statement. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94
[store] and [recall]: we have created a cell that stores variables = permanently. This has to survive a reboot, the variable can be as long = as wanted: it will save the hassle of writing the code to keep those in = a database. However, to avoid "overheating", we would have only one name = per variable, meaning that if we store name3 as "pink", and later store = name3 as "black", then only the last value will remain and "pink" will = be overwritten by "black" The process would use
[store] and [recall] + the name of the variable + = the variable itself
[store]var1=3DJoe[/store] The data will be stored in a reserved.db database, with two columns: = "from" and "to", so, the very same database will be usable with =
[convertwords] If such a database does not exist, it will be automatically created at = the same level the creating code file is located. from to var1 Joe var2 Biden In fact,
[store]var1=3DJoe[/store] will do the same as [replace = db=3Dreserved.db&eqFROMdata=3Dvar1&append=3DT]var1=3DJoe[/replace]
[convertwords] can be easily used to widen the scope of this new cell, = like this: [convertwords db=3Dreserved.db] The Vice President, Mr. var1 var2, will visit China next month. [/convertwords] There are 4 options: 1.) show (optional) "T" or "F". Default behavior is to hide the value = when assigning to a variable. If we want the value to be shown at the = same time it is assigned to a variable, we may set Show=3DT (There is no = reason to ever use show=3Df, as this is default behavior.) [store show=3DT]var1=3DJoe[/store] 2.) the second option allows to store multiple variables in one cell multi (optional) "T" or "F". Allows to assign more than one text = variable in a single cell. [store multi=3DT]var1=3DJoe&var2=3DFred[/store] simultaneously assigns = the two variables. (There is no need to use multi=3DF for single = variables.) 3.) The third option is the optional path of the database, in case a = user wants to use another reserved.db than the one found at the same = level. The name must remain "reserved.db" with "from" and "to" column = headers. [store path=3D../../admin/reserved.db]var1=3DJoe[/store] Look for "reserved.db" two levels up, in /admin 4.) an option "interpret o no" tags: [store parse=3DT]var1=3DToday is
[date][/store] would give from to var1 Today is 01/16/2015 var2 Fred [store parse=3DF]var1=3DToday is
[date][/store] would give from to var1 Today is
[date] var2 Fred The defaut behavior being parse=3DF This can be compared to
[function] with preparse and post-parse [recall var1] will just get the codon replaced by the variable. [recall] = will be basically a
[lookup] [lookup db=3Dreserved.db&value=3Dvar1&lookInField=3Dfrom&returnField=3Dto]= The database, once it exists, will store the data without limit other = than what the programer decides. So, there is no need to initialize it. = It will be initialized at creation, then no more. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94 best regards, - chris
christophe.billiottet@webdna.us
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
RE: protect tag on NT (1997)
Webcat/Webmerchant part II (1998)
Emailer (WebCat2) (1997)
Summing fields (1997)
2.0.1 new commands and contexts (1997)
WC2b15 File Corruption (1997)
Changing Date Format in Field (1999)
Not really WebCat (1997)
WebDNA quitting (2008)
Shell traceroute (2001)
[WebDNA] jQuery validation and webdna (2015)
WebCatalog NT beta 18 problem (1997)
WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997)
Page Breaks (1999)
Pgp&emailer (1997)
Less than or equal to........ (1997)
URGENT - Server dying on me.... (2004)
NT 4.0/IIS WebCat Installation (1998)
WebCat2 - [format thousands] (1997)
Word Breaks (1998)