> [listwords words=[t_words]&delimiters=12345][word][delimiter][/listwords] >
> > The result of this code is: > > something1some_other2one_more4 > > So, WebDNA's [delimiter] tag shows the delimiter that occurs BEFORE the > current word, not the delimiter AFTER the current word. This is > predictable, and equally as good a choice as showing the AFTER delimiter. > > Also of note here is that if there are two sequential delimiters between > words, only the last delimiter is shown. > > What I would like to see if anything is to change here is: > > 1) [delimiter] should continue to behave exactly as it does now, so no > existing code breaks. > > 2) Parameters could be added to the delimiter tag to get more specific > results: > [delimiter before] would show the delimiter (if any) before the > current word > [delimiter after] would show the delimiter (if any) that occurs > before the current word > > 3) The "tabs" parameter to listwords, is defined as: "Setting Tabs=T > causes the list of words to break at tab boundaries only, and runs of > tabs are not collapsed. This assists in parsing special formats where > two tabs in a row are important and should not be skipped." > > I would like to see the tabs parameter expanded such that if you > specify a delimiters param, then consecutive runs of the specified > delimiters would similarly not be collapsed, so you could loop through a > list of comma-delimited (or anything else) values and get blank [word] > values between consecutive delimiters. > > Brian Fries > BrainScan Software ... looks like my last post to this thread crossed with your posting. Thanks Brian, this is exactly the kind of debate that I was hoping for by asking for opinions to the list. I will do this most any time we consider changing the more popular contexts and tags. I very much agree with your later point of not collapsing consecutive delimiters. I also appreciate the idea of the before and after params, but my question is; is it adding an unnecessary complexity? Before we started working on WebDNA, we established some guide-lines about adding and changing contexts and tags. One of those guide-lines addresses superfluous changes/additions. In other words, WebDNA has always had a lot of versatility using a terse syntax. We want to keep with that trend. So, my new question to you all is, would creating parameters for [delimiter] go against these guide-lines? Is a before/after really necessary, when we *could* change the tag so that it has more common sense. Yes, this poses a backwards compatibility problem, but I would argue that it is not a problem that cannot be dealt with. Regarding your test Brian: > To get a clearer picture of what WebDNA is doing, try this code: > > [text]t_words=1something2some_other34one_more5[/text] >> [listwords words=[t_words]&delimiters=12345][word][delimiter][/listwords] >
> > The result of this code is: > > something1some_other2one_more4 Notice delimiter 5 is missing entirely. The results of changing [delimiter] to behave in a more intuitive nature (by applying them in the order that the input string has them), would output as: '1something2some_other34one_more5' (same as the input string). My inclination is to simply change the way this tag works. Regarding your later and preferred change of the non-collapsing [delimiter].. in my opinion, that makes perfect sense. I'd hear arguments against that as well. Otherwise, I consider it a no-brainer. Donovan -- Donovan Brooke WebDNA Software Corporation http://www.webdna.us **[Square Bracket Utopia]** Associated Messages, from the most recent to the oldest:
|
> [listwords words=[t_words]&delimiters=12345][word][delimiter][/listwords] >
> > The result of this code is: > > something1some_other2one_more4 > > So, WebDNA's [delimiter] tag shows the delimiter that occurs BEFORE the > current word, not the delimiter AFTER the current word. This is > predictable, and equally as good a choice as showing the AFTER delimiter. > > Also of note here is that if there are two sequential delimiters between > words, only the last delimiter is shown. > > What I would like to see if anything is to change here is: > > 1) [delimiter] should continue to behave exactly as it does now, so no > existing code breaks. > > 2) Parameters could be added to the delimiter tag to get more specific > results: > [delimiter before] would show the delimiter (if any) before the > current word > [delimiter after] would show the delimiter (if any) that occurs > before the current word > > 3) The "tabs" parameter to listwords, is defined as: "Setting Tabs=T > causes the list of words to break at tab boundaries only, and runs of > tabs are not collapsed. This assists in parsing special formats where > two tabs in a row are important and should not be skipped." > > I would like to see the tabs parameter expanded such that if you > specify a delimiters param, then consecutive runs of the specified > delimiters would similarly not be collapsed, so you could loop through a > list of comma-delimited (or anything else) values and get blank [word] > values between consecutive delimiters. > > Brian Fries > BrainScan Software ... looks like my last post to this thread crossed with your posting. Thanks Brian, this is exactly the kind of debate that I was hoping for by asking for opinions to the list. I will do this most any time we consider changing the more popular contexts and tags. I very much agree with your later point of not collapsing consecutive delimiters. I also appreciate the idea of the before and after params, but my question is; is it adding an unnecessary complexity? Before we started working on WebDNA, we established some guide-lines about adding and changing contexts and tags. One of those guide-lines addresses superfluous changes/additions. In other words, WebDNA has always had a lot of versatility using a terse syntax. We want to keep with that trend. So, my new question to you all is, would creating parameters for [delimiter] go against these guide-lines? Is a before/after really necessary, when we *could* change the tag so that it has more common sense. Yes, this poses a backwards compatibility problem, but I would argue that it is not a problem that cannot be dealt with. Regarding your test Brian: > To get a clearer picture of what WebDNA is doing, try this code: > > [text]t_words=1something2some_other34one_more5[/text] >> [listwords words=[t_words]&delimiters=12345][word][delimiter][/listwords] >
> > The result of this code is: > > something1some_other2one_more4 Notice delimiter 5 is missing entirely. The results of changing [delimiter] to behave in a more intuitive nature (by applying them in the order that the input string has them), would output as: '1something2some_other34one_more5' (same as the input string). My inclination is to simply change the way this tag works. Regarding your later and preferred change of the non-collapsing [delimiter].. in my opinion, that makes perfect sense. I'd hear arguments against that as well. Otherwise, I consider it a no-brainer. Donovan -- Donovan Brooke WebDNA Software Corporation http://www.webdna.us **[Square Bracket Utopia]** Donovan BrookeDOWNLOAD WEBDNA NOW!
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...