Re: [WebDNA] Enhancements to "list" contexts ...
This WebDNA talk-list message is from 2015
It keeps the original formatting.
numero = 111819
interpreted = N
texte = On Jan 5, 2015, at 3:24 AM, christophe.billiottet@webdna.us wrote: > Hi Ken! >=20 >=20 >=20 >=20 >=20 >> - 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 >=20 >=20 > These are good ideas. OK, it sounds fine to me to add = "name=3Dxxx&exact=3DT/F" to=20 >=20 > listmimeheaders > listvariables > listdatabases > listfields > listcookies You guys may want to read the docs on this one. :-) >=20 > We will work on this, hopefully for 8.0.3 >=20 >> - 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. >=20 > If I understand, the "opposite=3DT" would sort all the results that = have no been selected by "name=3Dxxx&exact=3DT/F=94 ? Perhaps a more appropriate convention would be to use similar syntax to = the showif context. The =91not=92 comparison is a standard programming comparison. This is a significant change no = matter what you syntax you use.=20 [listvariables name!somename][/litvariables] >=20 >=20 >> - 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. >=20 >=20 > 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: I agree with Chris, but also.. that would turn our *very* efficient = [listXXX] contexts into bloatContexts. Keep them lean and mean. = However.. Ken.. Instead of returning the RAW machine sort order for = files / variables, etc.. I think it would be nice to be able to have an = alphabetic sort param. In the old days, listfiles (for example) had this = by default.. so it would be nice to reintroduce that option. Maybe something like this: [listfiles path=3Dsomepath/&AlphaSort=3DT] [/listfiles] The issue though is.. this behavior be easily produced by a custom = function. Anything easily replicated is hard to justify for WebDNA = development.=20 >=20 >=20 >> 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. >=20 >=20 >=20 > I suppose it is relatively easy to do using [listfiles] and [table] >=20 > [table name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/] > [index] [filename] [moddate] [size] > [/listfiles][/table] Exactly.. don=92t bloat our contexts please. >=20 >=20 > 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. >=20 >> - 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? >=20 >=20 > what about just changing the search definition and replace ge with ls = ?=20 Exactly=85 I can=92t imagine a need for a [notfound] > [snip] >=20 > - 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. Well, how *does* it work? You are talking to Developers.. we don=92t = believe in Magic. The only other way to create a session that I know of = is by creating / maintaining a file. We already do that. It=92s called = the order file. > - 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. I don=92t know what your goals are with our *context*, [array].. but In = our language, it seems like there would be much better use of your time = in other priorities. Our language is a classless / objectless language. = It seems to me that a programmer has been telling you that we need = arrays to work like they do in other languages. However, we already have = means upon which to move / manipulate data.. formvariables / table, = etc.. I would work on making those more efficient. JSON interaction is = great, because the world runs on it, and it interfaces with our = text-based app nicely. It is long over-due.. so, congrats on that. No = need for touching array that I know of.=20 >=20 > - A simple tag that stores variables permanently I have no idea how this could be useful at all. It=92s very easy to = store variables permanently.=20 >=20 >=20 >=20 > - chris >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us
Associated Messages, from the most recent to the oldest:
On Jan 5, 2015, at 3:24 AM, christophe.billiottet@webdna.us wrote: > Hi Ken! >=20 >=20 >=20 >=20 >=20 >> - 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 >=20 >=20 > These are good ideas. OK, it sounds fine to me to add = "name=3Dxxx&exact=3DT/F" to=20 >=20 > listmimeheaders > listvariables > listdatabases > listfields > listcookies You guys may want to read the docs on this one. :-) >=20 > We will work on this, hopefully for 8.0.3 >=20 >> - 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. >=20 > If I understand, the "opposite=3DT" would sort all the results that = have no been selected by "name=3Dxxx&exact=3DT/F=94 ? Perhaps a more appropriate convention would be to use similar syntax to = the showif context. The =91not=92 comparison is a standard programming comparison. This is a significant change no = matter what you syntax you use.=20 [listvariables name!somename][/litvariables] >=20 >=20 >> - 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. >=20 >=20 > 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: I agree with Chris, but also.. that would turn our *very* efficient = [listXXX] contexts into bloatContexts. Keep them lean and mean. = However.. Ken.. Instead of returning the RAW machine sort order for = files / variables, etc.. I think it would be nice to be able to have an = alphabetic sort param. In the old days, listfiles (for example) had this = by default.. so it would be nice to reintroduce that option. Maybe something like this: [listfiles path=3Dsomepath/&AlphaSort=3DT] [/listfiles] The issue though is.. this behavior be easily produced by a custom = function. Anything easily replicated is hard to justify for WebDNA = development.=20 >=20 >=20 >> 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. >=20 >=20 >=20 > I suppose it is relatively easy to do using
[listfiles] and
[table] >=20 > [table name=3Dlistsort&fields=3Dname,moddate,size,][listfiles = path=3D/to/server/logs/] > [index] [filename] [moddate] [size] > [/listfiles][/table] Exactly.. don=92t bloat our contexts please. >=20 >=20 > 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. >=20 >> - 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? >=20 >=20 > what about just changing the search definition and replace ge with ls = ?=20 Exactly=85 I can=92t imagine a need for a [notfound] > [snip] >=20 > - 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. Well, how *does* it work? You are talking to Developers.. we don=92t = believe in Magic. The only other way to create a session that I know of = is by creating / maintaining a file. We already do that. It=92s called = the
order file. > - 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. I don=92t know what your goals are with our *context*,
[array].. but In = our language, it seems like there would be much better use of your time = in other priorities. Our language is a classless / objectless language. = It seems to me that a programmer has been telling you that we need = arrays to work like they do in other languages. However, we already have = means upon which to move / manipulate data.. formvariables / table, = etc.. I would work on making those more efficient. JSON interaction is = great, because the world runs on it, and it interfaces with our = text-based app nicely. It is long over-due.. so, congrats on that. No = need for touching array that I know of.=20 >=20 > - A simple tag that stores variables permanently I have no idea how this could be useful at all. It=92s very easy to = store variables permanently.=20 >=20 >=20 >=20 > - chris >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us
Donovan Brooke
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:
Sami (1998)
Auto Delete EmailCompleted Files (2002)
Re:HELP - NONE STOP DIGESTS. Digest for 4/24/97) (1997)
convertchars and case? (1998)
Trouble with [Math] (1998)
[AppendFile] problem (WebCat2b13 Mac .acgi) (1997)
[ShowNext] (1997)
Shipcost formula (2004)
webcat2b12 CGI -- Date comparisons (1997)
Problem with a search context (2005)
Roundup function? (1997)
[returnraw] and form variables (1998)
PCS Frames-Default page is solution! (1997)
RE: E-mailer error codes (1997)
WebMerchant problem (1998)
Greeting Card System (2000)
Plugin or CGI or both (1997)
problems with 2 tags (1997)
This list needs a digest: rant, rave... (1997)
Setting up shop (1997)