[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:
StoreBuilder UPS/XML code question ... (2003)
Sendmail Woes (2002)
[WebDNA] No more SQL in 7.1? (2012)
email server and webdna (2006)
forms and variables (1998)
RE: WebCat: Access denied, but why? - The solution. (1997)
mac hack (1997)
Quit revisited (1997)
Bug Report, maybe (1997)
Multiple fields on 1 input (1997)
I'm tired of all this! (2000)
WebCatalog f2 Installation (1997)
Cookies? (1997)
# of real domains on 1 web server (1997)
Change in Host? (1999)
Error -108 (1997)
Moving encrypted fields to different boxes/platforms (2000)
OT: automating a POST (2002)
price formula (1999)
OK, here's a new one (2002)