Re: [WebDNA] Enhancements to "list" contexts ...
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 111818
interpreted = N
texte = --Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ken! > - Since [formvariables] and [listfiles] both offer the optional > parameters "name=3Dxxx&exact=3DT/F" as a way to limit what they find, > it would be nice to have the same optional parameters in a few of > our other "list" contexts too, such as: >=20 > listmimeheaders > listvariables > listdatabases > listfields > listcookies These are good ideas. OK, it sounds fine to me to add = "name=3Dxxx&exact=3DT/F" to=20 listmimeheaders listvariables listdatabases listfields listcookies We will work on this, hopefully for 8.0.3 > - For all contexts that offer the "name=3Dxxx&exact=3DT/F" options, a > new "opposite=3DT" parameter would be useful when we want to return > the opposite results. If I understand, the "opposite=3DT" would sort all the results that have = no been selected by "name=3Dxxx&exact=3DT/F" ? > - Sorting options would be useful in these list contexts, too. We > already use these sort options in our searches, so adding them to > our list contexts would keep the syntax consistent: >=20 > asnamesort=3D1/2/3/etc. > denamesort=3D1/2/3/etc. > assizesort=3D1/2/3/etc. > desizesort=3D1/2/3/etc. > asmoddatesort=3D1/2/3/etc. > demoddatesort=3D1/2/3/etc. This would probably be more complicated to do as we enter the database = syntax, lowering the space between databases and lists, which could be = confusing for some. Your next idea is exactly this, merging the list = syntax and database syntax: > BY THE WAY, TO GET REALLY SERIOUS ABOUT THIS KIND OF ENHANCEMENT: >=20 > Just add an optional "search=3DT" parameter to all our list > contexts. This would tell WebDNA to recognize the same parameters > we already use in our regular database/table searches. This would > allow us to do things like this: >=20 > [listfiles > = path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror.log&gemoddatedatar= q=3D12/21/2014&moddatetype=3Ddate&gesizedatarq=3D1200000&assizesort=3D1&as= moddatesort=3D2] >=20 > Obviously this is a far more powerful enhancement than simply > adding the "name=3Dxxx&exact=3DT/F" and "opposite=3DT" parameters to = our > list contexts, and for this reason it may be a little "too much". > But it would definitely make the WebDNA syntax more consistent > across all contexts that create lists. I suppose it is relatively easy to do using [listfiles] and [table] [table name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/] [index] [filename] [moddate] [size] [/listfiles][/table] We could write an automatic process to do this but does it really worth = it? Also, keep in mind that, in order to keep backward compatibility, we = would need to replace the name [listfiles] by a new name. > - Another thought I have is to add a new [notfound] context to our > searches. This would list all the database/table records that are > not listed in the [founditems] context. Would this feature be > useful to anyone other than me? what about just changing the search definition and replace ge with ls ? = it would be more flexible than just listing everything that was not = found. [listfiles = path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror.log&lsmoddatedatar= q=3D12/21/2014&moddatetype=3Ddate&lssizedatarq=3D1200000&assizesort=3D1&as= moddatesort=3D2] I think we can add tons of features to WebDNA, however this application = is extremely light (7MB), fast, easy to debug and flexible, in a sense = that a lot of features can easily be built by the developer. The more we = add, the more complicated the syntax, at the expense of the flexibility, = the number of tags to remember and the creativity of the developers. I explained last year :-) that we were working on three features; I = believe these features can add power to WebDNA, and if they can be built = on developer side, they would greatly simplify the developer task by = providing three new tools: - A tag [session] that will not make use of any cookie. The session will = be created at login with a unique ID and will follow the user until a = specific number of minutes after he leaves, or keep the session active = with a "lifetime" This works without any cookie at all. - With JSON compatibility in mind, a tag [array] with capability to = store arrays with unlimited dimensions in a much simpler way than = anything before. Arrays storage will be either in "permanent" or = "temporary" state. - A simple tag that stores variables permanently - chris --Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Ken!
- Since [formvariables] and [listfiles] both offer the = optional
parameters "name=3Dxxx&exact=3DT/F" as a way = to limit what they find,
it would be nice to have the same = optional parameters in a few of
our other "list" contexts = too, such as:
listmimeheaders
= listvariables
listdatabases
= listfields
listcookies
These are good ideas. = OK, it sounds fine to me to add "name=3Dxxx&exact=3DT/F" = to
= listmimeheaders
listvariables
= listdatabases
listfields
= listcookies
We will work on this, hopefully for 8.0.3
- = For all contexts that offer the "name=3Dxxx&exact=3DT/F" options, = a
new "opposite=3DT" parameter would be useful when we = want to return
the opposite results.
If I understand, the "opposite=3DT" would sort all the = results that have no been selected by "name=3Dxxx&exact=3DT/F" = ?
- Sorting options would be useful in these list = contexts, too. We
already use these sort options in = our searches, so adding them to
our list contexts would = keep the syntax consistent:
= asnamesort=3D1/2/3/etc.
= denamesort=3D1/2/3/etc.
= assizesort=3D1/2/3/etc.
= desizesort=3D1/2/3/etc.
= asmoddatesort=3D1/2/3/etc.
= demoddatesort=3D1/2/3/etc.
This would probably be more complicated to do as we enter the = database syntax, lowering the space between databases and lists, which = could be confusing for some. Your next idea is exactly this, merging the = list syntax and database syntax:
BY = THE WAY, TO GET REALLY SERIOUS ABOUT THIS KIND OF ENHANCEMENT:
Just add an optional "search=3DT" parameter to = all our list
contexts. This would tell WebDNA to = recognize the same parameters
we already use in our = regular database/table searches. This would
allow us = to do things like this:
[listfiles
path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror= .log&gemoddatedatarq=3D12/21/2014&moddatetype=3Ddate&gesizedat= arq=3D1200000&assizesort=3D1&asmoddatesort=3D2]
Obviously this is a far more powerful enhancement than = simply
adding the "name=3Dxxx&exact=3DT/F" and = "opposite=3DT" parameters to our
list contexts, and for = this reason it may be a little "too much".
But it would = definitely make the WebDNA syntax more consistent
across = all contexts that create lists.
I suppose it is relatively easy to do = using [listfiles] and [table]
[table = name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/]
[index] = [filename] [moddate] [size]
[/listfiles][/table]
We = could write an automatic process to do this but does it really worth it? = Also, keep in mind that, in order to keep backward compatibility, we = would need to replace the name [listfiles] by a new name.
- Another thought I have is to add a new [notfound] context = to our
searches. This would list all the = database/table records that are
not listed in the = [founditems] context. Would this feature be
useful = to anyone other than me?
what about just changing = the search definition and replace ge with ls ? it would be more flexible = than just listing everything that was not found.
[listfiles
path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror= .log&lsmoddatedatarq=3D12/21/2014&moddatetype=3Ddate&= amp;lssizedatarq=3D1200000&assizesort=3D1&asmodd= atesort=3D2]
I think we can add tons of features to = WebDNA, however this application is extremely light (7MB), fast, easy to = debug and flexible, in a sense that a lot of features can easily be = built by the developer. The more we add, the more complicated the = syntax, at the expense of the flexibility, the number of tags to = remember and the creativity of the developers.
I explained last year :-) that we were = working on three features; I believe these features can add power to = WebDNA, and if they can be built on developer side, they would greatly = simplify the developer task by providing three new tools:
- A tag = [session] that will not make use of any cookie. The session will be = created at login with a unique ID and will follow the user until a = specific number of minutes after he leaves, or keep the session active = with a "lifetime"
This works without any cookie at = all.
- With = JSON compatibility in mind, a tag [array] with capability to store = arrays with unlimited dimensions in a much simpler way than anything = before. Arrays storage will be either in "permanent" or "temporary" = state.
- A = simple tag that stores variables permanently
- chris
= --Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE--
Associated Messages, from the most recent to the oldest:
--Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Ken! > - Since
[formvariables] and
[listfiles] both offer the optional > parameters "name=3Dxxx&exact=3DT/F" as a way to limit what they find, > it would be nice to have the same optional parameters in a few of > our other "list" contexts too, such as: >=20 > listmimeheaders > listvariables > listdatabases > listfields > listcookies These are good ideas. OK, it sounds fine to me to add = "name=3Dxxx&exact=3DT/F" to=20 listmimeheaders listvariables listdatabases listfields listcookies We will work on this, hopefully for 8.0.3 > - For all contexts that offer the "name=3Dxxx&exact=3DT/F" options, a > new "opposite=3DT" parameter would be useful when we want to return > the opposite results. If I understand, the "opposite=3DT" would sort all the results that have = no been selected by "name=3Dxxx&exact=3DT/F" ? > - Sorting options would be useful in these list contexts, too. We > already use these sort options in our searches, so adding them to > our list contexts would keep the syntax consistent: >=20 > asnamesort=3D1/2/3/etc. > denamesort=3D1/2/3/etc. > assizesort=3D1/2/3/etc. > desizesort=3D1/2/3/etc. > asmoddatesort=3D1/2/3/etc. > demoddatesort=3D1/2/3/etc. This would probably be more complicated to do as we enter the database = syntax, lowering the space between databases and lists, which could be = confusing for some. Your next idea is exactly this, merging the list = syntax and database syntax: > BY THE WAY, TO GET REALLY SERIOUS ABOUT THIS KIND OF ENHANCEMENT: >=20 > Just add an optional "search=3DT" parameter to all our list > contexts. This would tell WebDNA to recognize the same parameters > we already use in our regular database/table searches. This would > allow us to do things like this: >=20 > [listfiles > = path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror.log&gemoddatedatar= q=3D12/21/2014&moddatetype=3Ddate&gesizedatarq=3D1200000&assizesort=3D1&as= moddatesort=3D2] >=20 > Obviously this is a far more powerful enhancement than simply > adding the "name=3Dxxx&exact=3DT/F" and "opposite=3DT" parameters to = our > list contexts, and for this reason it may be a little "too much". > But it would definitely make the WebDNA syntax more consistent > across all contexts that create lists. I suppose it is relatively easy to do using
[listfiles] and
[table] [table name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/] [index] [filename] [moddate] [size] [/listfiles][/table] We could write an automatic process to do this but does it really worth = it? Also, keep in mind that, in order to keep backward compatibility, we = would need to replace the name
[listfiles] by a new name. > - Another thought I have is to add a new [notfound] context to our > searches. This would list all the database/table records that are > not listed in the
[founditems] context. Would this feature be > useful to anyone other than me? what about just changing the search definition and replace ge with ls ? = it would be more flexible than just listing everything that was not = found. [listfiles = path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror.log&lsmoddatedatar= q=3D12/21/2014&moddatetype=3Ddate&lssizedatarq=3D1200000&assizesort=3D1&as= moddatesort=3D2] I think we can add tons of features to WebDNA, however this application = is extremely light (7MB), fast, easy to debug and flexible, in a sense = that a lot of features can easily be built by the developer. The more we = add, the more complicated the syntax, at the expense of the flexibility, = the number of tags to remember and the creativity of the developers. I explained last year :-) that we were working on three features; I = believe these features can add power to WebDNA, and if they can be built = on developer side, they would greatly simplify the developer task by = providing three new tools: - A tag
[session] that will not make use of any cookie. The session will = be created at login with a unique ID and will follow the user until a = specific number of minutes after he leaves, or keep the session active = with a "lifetime" This works without any cookie at all. - With JSON compatibility in mind, a tag
[array] with capability to = store arrays with unlimited dimensions in a much simpler way than = anything before. Arrays storage will be either in "permanent" or = "temporary" state. - A simple tag that stores variables permanently - chris --Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Ken!
- Since [formvariables] and [listfiles] both offer the = optional
parameters "name=3Dxxx&exact=3DT/F" as a way = to limit what they find,
it would be nice to have the same = optional parameters in a few of
our other "list" contexts = too, such as:
listmimeheaders
= listvariables
listdatabases
= listfields
listcookies
These are good ideas. = OK, it sounds fine to me to add "name=3Dxxx&exact=3DT/F" = to
= listmimeheaders
listvariables
= listdatabases
listfields
= listcookies
We will work on this, hopefully for 8.0.3
- = For all contexts that offer the "name=3Dxxx&exact=3DT/F" options, = a
new "opposite=3DT" parameter would be useful when we = want to return
the opposite results.
If I understand, the "opposite=3DT" would sort all the = results that have no been selected by "name=3Dxxx&exact=3DT/F" = ?
- Sorting options would be useful in these list = contexts, too. We
already use these sort options in = our searches, so adding them to
our list contexts would = keep the syntax consistent:
= asnamesort=3D1/2/3/etc.
= denamesort=3D1/2/3/etc.
= assizesort=3D1/2/3/etc.
= desizesort=3D1/2/3/etc.
= asmoddatesort=3D1/2/3/etc.
= demoddatesort=3D1/2/3/etc.
This would probably be more complicated to do as we enter the = database syntax, lowering the space between databases and lists, which = could be confusing for some. Your next idea is exactly this, merging the = list syntax and database syntax:
BY = THE WAY, TO GET REALLY SERIOUS ABOUT THIS KIND OF ENHANCEMENT:
Just add an optional "search=3DT" parameter to = all our list
contexts. This would tell WebDNA to = recognize the same parameters
we already use in our = regular database/table searches. This would
allow us = to do things like this:
[listfiles
path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror= .log&gemoddatedatarq=3D12/21/2014&moddatetype=3Ddate&gesizedat= arq=3D1200000&assizesort=3D1&asmoddatesort=3D2]
Obviously this is a far more powerful enhancement than = simply
adding the "name=3Dxxx&exact=3DT/F" and = "opposite=3DT" parameters to our
list contexts, and for = this reason it may be a little "too much".
But it would = definitely make the WebDNA syntax more consistent
across = all contexts that create lists.
[table = name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/]
[index] = [filename] [moddate] [size]
[/listfiles][/table]
We = could write an automatic process to do this but does it really worth it? = Also, keep in mind that, in order to keep backward compatibility, we = would need to replace the name
[listfiles] by a new name.
- Another thought I have is to add a new [notfound] context = to our
searches. This would list all the = database/table records that are
not listed in the = [founditems] context. Would this feature be
useful = to anyone other than me?
what about just changing = the search definition and replace ge with ls ? it would be more flexible = than just listing everything that was not found.
[listfiles
path=3D/to/server/logs/&search=3DT&bwnamedatarq=3Derror= .log&lsmoddatedatarq=3D12/21/2014&moddatetype=3Ddate&= amp;lssizedatarq=3D1200000&assizesort=3D1&asmodd= atesort=3D2]
I think we can add tons of features to = WebDNA, however this application is extremely light (7MB), fast, easy to = debug and flexible, in a sense that a lot of features can easily be = built by the developer. The more we add, the more complicated the = syntax, at the expense of the flexibility, the number of tags to = remember and the creativity of the developers.
I explained last year :-) that we were = working on three features; I believe these features can add power to = WebDNA, and if they can be built on developer side, they would greatly = simplify the developer task by providing three new tools:
- A tag =
[session] that will not make use of any cookie. The session will be = created at login with a unique ID and will follow the user until a = specific number of minutes after he leaves, or keep the session active = with a "lifetime"
This works without any cookie at = all.
- With = JSON compatibility in mind, a tag
[array] with capability to store = arrays with unlimited dimensions in a much simpler way than anything = before. Arrays storage will be either in "permanent" or "temporary" = state.
- A = simple tag that stores variables permanently
- chris
= --Apple-Mail=_DFAB1C45-F848-4E3A-9DD2-4695DEE006DE--
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:
Single Link browsing (1997)
[Sum] function? (1997)
Images (2000)
Almost a there but..bye bye NetCloak (1997)
WebCat2b13MacPlugIn - [include] (1997)
Loops and [index] (1998)
Listing Words Backwords (2001)
Newbie Help (2003)
Bug alert! (1997)
ListVariables Problem (2003)
problems with 2 tags shakur (1997)
Virtual hosting and webcatNT (1997)
Too Much Rootbeer Free Offer (1997)
[WebDNA] Issue with including functions (2011)
Webcat Manual and TeaRoom Examples Uses Different Examples. (1997)
[WebDNA] Authorize.net and [tcpconnect] (2016)
WebDNA vars parsed in FLASH (ActionScript) (2004)
[FoundItems] solved - thanks (1997)
OK, here goes... (1997)
SAVECART (1997)