Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Embarrassingly basic question, on .contains() (Read 3052 times)
J Fallows
Full Member
*
Offline



Posts: 418

Embarrassingly basic question, on .contains()
Sep 24th, 2014, 4:07pm
 
I have a data base with a user attribute $Section. I am trying to create a query that will bring up all items with $Section starting with "1"  . For instance:

   1 Finances
   1A F22
   1B F35
   1B1 International

I am using this query, which is as best I can figure it out from aTBRef, Regex guides, and so on:

   $Section.contains("^1")

This is not bringing up any of the expected results. What is the obvious thing I am missing? Thanks!
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Embarrassingly basic question, on .contains()
Reply #1 - Sep 24th, 2014, 4:26pm
 
If $Section is a String-type attribute, $Section.contains("1 Section") matches both values "1 Section" and "1 Section July". If $Section is list-type or set-type then there are no matches.

List and Set attributes only match .contains() on complete literal strings of individual vqlues.  Regex patterns can't be used.

This may not be the issue but if not could you clarify further what sort of attribute you are trying to query?  Smiley
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
J Fallows
Full Member
*
Offline



Posts: 418

Re: Embarrassingly basic question, on .contains()
Reply #2 - Sep 24th, 2014, 5:20pm
 
Quote:
List and Set attributes only match .contains() on complete literal strings of individual vqlues.  Regex patterns can't be used.


Ah, OK, that explains it. In this case $Section is a Set attribute. I had not realized (item #1824 on the "hadn't realized" list) that Regex-style matching patterns do not work with sets.

For my purposes, it's useful for this attribute be a set rather than a string. So I'll set up some mirror attribute, of string rather than set type, and then use that for the queries!

Next mystery that I will discover for myself:

 As a set attribute, $Section now has some multiple values, like  "1 Intro; 3 Conclusion"  If I set up a mirroring rule, with $SectionString=$Section, I'll see what that turns up for strings!  You probably know already, but I'll learn as I go.
Back to top
 
 
  IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Embarrassingly basic question, on .contains()
Reply #3 - Sep 24th, 2014, 5:32pm
 
The problem here is that it's not entirely clear whether the query ^1 should match a note where $Section is

      appendix 3; 1A; 2B

or not.  As I recall, when first introducing sets we found it easy for people to get confused by regex.

If you coerce $Section to a string, you can search for ^1|;1
Back to top
 
 
WWW   IP Logged
J Fallows
Full Member
*
Offline



Posts: 418

Re: Embarrassingly basic question, on .contains()
Reply #4 - Sep 24th, 2014, 5:50pm
 
Quote:
If you coerce $Section to a string, you can search for ^1|;1


Anticipating my next question! Thanks, and all is now well on this front.

Created my mirrored $SectionString attribute; set up a rule $SectionString=$Section; did a query with the syntax above; and mirabile dictu, it does what I want! Appreciate it.
Back to top
 
« Last Edit: Sep 24th, 2014, 5:59pm by J Fallows »  
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Embarrassingly basic question, on .contains()
Reply #5 - Sep 25th, 2014, 3:52am
 
Spotting 'bad' values has cropped up in a number of places recently and is worth noting here that values() can help. Make a note and set its rule to:

$Text = values("Section").format("\n")

N.B. the values() input is the target attribute name without a $ prefix. The result is a note with $Text with one $Section value per line. You can then easily scan the list by eye.

If you need to pull $Section value data from a sub-section of the doc, use collect() instead. The first input in this case will be a group designator:

$Text = collect(group, $Section).format("\n")
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
J Fallows
Full Member
*
Offline



Posts: 418

Re: Embarrassingly basic question, on .contains()
Reply #6 - Sep 25th, 2014, 9:17am
 
Thanks, also very useful. The reminder to leave off the "$" before the attribute name also goes on the list of Things I Hadn't Realized.

Sorry to pile on with questions, Mark A: But is there a section in aTbRef on the general circumstances in which one omits the otherwise-obligatory $ prefix for attributes? I imagine there is, but I haven't seen it recently.

Thank you once more.
Back to top
 
« Last Edit: Sep 25th, 2014, 10:12am by J Fallows »  
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Embarrassingly basic question, on .contains()
Reply #7 - Sep 25th, 2014, 10:31am
 
For those readers wondering to what JF refers, 'AttributeName' in action code is citing the name of the attribute, wheras '$AttributeName' is citing the value of an attribute of that name. Confusingly, back pre-v5, the $-prefix was optional so many old code examples can be confusing. Generally, always use a $prefix with attribute names in code unless you definitely simply want to use that name as a literal piece of text.  If $MyString has the value "Hello Jim", then these rules have different results:

$Text = MyString;   - gives 'MyString'
$Text = $MyString;  - gives 'Hello Jim'

In fact the first only works due to legacy support.  In v5+ what you'd write if you wanted that outcome would be:

$Text = "MyString";  <- Note is the quote implying this is a string literal.

In the aTbRef documentation there are some inconsistencies where attributes need to be cited as a name - anomalies are marked thus **:

collect(group,$AttributeName)**
collect_if(group,$AttributeName)**
links[(item|group)].kind.[linkType].$AttributeName**
List.isort($AttributeName)**
List.nsort($AttributeName)**
List.nsort($AttributeName)**
values("AttributeName")

** In all these cases "AttributeName" would be a more logical format to boar the literal string vs $-prefix rule.

There are some system Set-type attributes where the input is a list of attribute names: $KeyAttributes, $TableHeading

To show $Color and $Border as Key Attributes for a note (in that order in the KA table):

Correct:   $KeyAttributes = "Color;Border"
WRONG!:  $KeyAttributes = "$Color;$Border"
WRONG!:  $KeyAttributes = $Color;$Border


Both the latter two are wrong, in part because as you could be trying to do something like this to get the right result:

$MySet = "Color;Border";
$KeyAttributes = $MySet;


If anyone gets stuck, don't forget you can always ask here if the forum (in a new thread please!).
Back to top
 
« Last Edit: Sep 25th, 2014, 10:32am by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
J Fallows
Full Member
*
Offline



Posts: 418

Re: Embarrassingly basic question, on .contains()
Reply #8 - Sep 25th, 2014, 12:17pm
 
Thanks Mark A.

Again this makes me feel somewhat less bad for not knowing this wrinkle in the syntax! And glad to have asked in public, for anyone else reading along.
Back to top
 
« Last Edit: Sep 25th, 2014, 12:19pm by J Fallows »  
  IP Logged
Pages: 1
Send Topic Print