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
Surprising difference in effect (Read 8474 times)
Loryn
Full Member
*
Offline



Posts: 97

Surprising difference in effect
Jul 25th, 2009, 5:29am
 
I would have thought the outcome of the following two Agent Actions would have been equivalent (TBX 4.6.2).

Code:
$Rule=$Text(TextPart)

$Rule=Text(TextPart)
 



The first statement assigns the note body of the TextPart note to the Rule attributes of all the notes matching the Query. (Expected and intended effect.)

I would have expected the second statement to do exactly the same. Yet it actually assigns the note body of the TextPart note to the note bodies of all the notes matching the Query, but does not assign to the $Rule at all. (Surprise. Big surprise.)

Why?
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Surprising difference in effect
Reply #1 - Jul 25th, 2009, 6:01am
 
$Text(TextPart) is a references to the value of attribute Text of note named 'TextPart' (i.e. the body text of that note). Text(TextPart) is a query operator returning 'true' if a note's Text contains the string 'TextPart'.

In v4.7.1, I get results as you describe - though why, except in error, would you use Text(patern) in an agent query? In the case of the use of Text() - without the $ prefix - I'd expect the Rule for a note matching the agent to be 'true' or 'false' depending on whether the body text of the note in context included the string 'TextPart'. The fact it doesn't indicates this is a glitch, likly an unintended by-product of TB v4.6. trying to support pre-v4.6 syntax.

If I try an agent action of $MyString=Text(TextPart) or $MyBoolean=Text(TextPart) the left side attribute is empty. This also tells me that whilst action code, Text(pattern) should only be used in queries or conditionals but not basic action code assignments as your trying to do. I also figure that as with the $MyString test, if targeting $Rule, the result should be no value - that would at least be consistent.
Back to top
 
 

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



Posts: 97

Re: Surprising difference in effect
Reply #2 - Jul 25th, 2009, 10:02am
 
Why?

I frequently get confused over syntactic variations between queries, actions and export codes.

The syntax is at the same time very similar yet different between all three contexts.

So, I guess I had a brain fade in using the Text(pattern) query within the agent action. In my mind, it was going to grab the text and assign it to the $Rule. Now that you've reinforced the return value is a boolean, I think I'll be a little clearer remembering the difference between the two.
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Surprising difference in effect
Reply #3 - Jul 25th, 2009, 12:02pm
 
TB eschews error messages, which means sometimes errors can be hard to spot; this is the hard part of TB.

The Export/Query/Action code triumvirate is an accident of birth. Originally, there were (I believe) export codes - for exporting - and codes for doing agent queries. Export codes then slipped into use in actions and rules. At some point a new action code (not usable in exports) crept in; in v4.0.0 it was massively expanded, duplicating most export codes. As there is a lot of under-the-hood parsing and this was throwing up issues, in v4.6, the new $-prefix method for action code (only) to define attribute references was introduced. So as not to break existing TBXs, the app supports old and new code. Which to use when is probably best covered in the current aTbRef online.

AttributeName(pattern) belongs to the query boolean set of operators (the grouping is mine from aTbRef, not Eastgate's) and it is the only one of the group not to be the analogue of an old #-prefixed query code.

My understanding is that the new $-prefixing is intended to become mandatory and export codes will disappeard or shrink to a stub set of codes used to call action code.  When this happens the picture should be clearer. Code will be action code with a small set of mark-up for inserting action code into export templates.  For instance, ^getFor(MyString,parent)^ can be replaced with ^value($MyString(parent)^. The latter is the way things are headed.

If you're a bit confused, you're not alone! I look forward to the old codes to be dropped and for a smaller, less ambiguous set of syntax(es).
Back to top
 
« Last Edit: Jul 25th, 2009, 12:02pm by Mark Anderson »  

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



Posts: 97

Re: Surprising difference in effect
Reply #4 - Jul 25th, 2009, 5:14pm
 
The other type of "irregularity" that pops up is the use of words like: child and children.

In different contexts, child can mean:
1. the first child of a note
2. all immediate descendents of a note
3. an error, i.e. where children should have been used instead

Given that, like most people, I don't code full-time in TBX, it's hard to remember which of the forms I'm supposed to be using. I frequently rely on the documentation—my reliance on the documentation feels too frequent relative to my use of documentation in Smalltalk, Python, etc.
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Surprising difference in effect
Reply #5 - Jul 25th, 2009, 5:50pm
 
'child' as a designator means only direct children. Pre v4.6 ^children^ and ^justChildren mean descendants vs immediate children, since v4.6 they both mean the latter; ^descendants^ takes on the old meaning of descendants. Thus in current TB, child/children semantically both refer to the same thing. In fairness,  - for now aTbRef is probably a better reference. I'm not aware of 'child' having a meaning of other than direct children.

In fairness, this change is not yet reflected correctly throughout the manual. Such lag is a not unusual effect when an app has regular updates and iterative enhancements. Things change.  The manual being based in a print-based doc can't really hope to keep up so more regularly updated sources such as aTbRef are probably a better primary reference for active users of thinks like action codes and export.  Disclaimer: I write aTbRef, but I'm not making a self-congratulatory reference here, merely pointing up the limitations of documentation of fast-changing apps when such docs are locked into paper-centric tools like DTP ( last century's tech!). I wrote the reference partly as a "missing manual" from which I figured others might benefit. Neither am I knocking Eastgate here, a small team can't do everything at once.  Regular user should make it a point to always read the release note that are included with the app.
Back to top
 
 

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



Posts: 97

Re: Surprising difference in effect
Reply #6 - Jul 25th, 2009, 5:54pm
 
TBX User Manual page 189.

child - refers to the first child of a note
lastChild - refers to the last child of the note
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Surprising difference in effect
Reply #7 - Jul 25th, 2009, 6:08pm
 
Ah, yes.  The child designator is contextually the first child in irem scope and all children in group scope.  Just as v4.6 changed ^justChildren^ -> ^children^ and ^chilrend^ to ^descendants^, in item scope 'child' should be 'firstChild'. That fits far better with 'lastChild' and 'firstSibling'/'lastSibling'.

I'm hoping v5 will ditch support for legacy usage.  Some one-time only pain updating old docs but hopefully we'll get clearer syntax rules. In fairness, I'm sure it's a hard tightrope for Eastgate - I don't doubt there are plenty of long term users who'll be on the horn to support when major syntax changes occur and long-user code suddenly breaks. Choosing when to stop legacy support is doubtless hard, made harder by TB's lack of error dialogs. The latter's very friendly for non tech users but can be a head scratcher when trying to push TB's envelope...and when things suddenly stop working.
Back to top
 
 

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



Posts: 133
Brazil
Re: Surprising difference in effect
Reply #8 - Jul 28th, 2009, 12:52am
 
I was thinking...
would it be too hard for Eastgate to create a side app which can convert any discrepancies between older and newer TBX syntax? Isn't it just a matter of syntactic change? Well, no, I suspect there will be some semantic problems. But, it could update correctly in most cases, couldn't it?
Back to top
 
 
Marcelo Mirage Marcelo Mirage MMUmeda misantropov@yahoo.com   IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Surprising difference in effect
Reply #9 - Jul 28th, 2009, 2:49am
 
TB v4.6+ already does this if opening pre-v4.6 files. A new TBX is created with suggested revision but the user still needs to check functionality is as intended as the app can't always guess the user's intent.

My assumption is that some forthcoming release will be the one to drop the current support for legacy usage so syntax rules can/will get tighter resolving most ambiguity. However, the $AttributeName(path) versus AttributeName(pattern) choice will remain - but in that circumstance it's up to the user to know which they intend.

If you have forgotten where you may have put code, action code is mostly in OnAdd actions, AgentAgent or a Rule and it's easy to make an action to look for those Attributes that aren't empty and then review them.  Export code can be tracked down using Find with a value '\^' (a caret '^', escaped with a backslash). Or use the same value with an agent. Whereas Find can search Name, Text and all user attributes, agents can search more widely using the AttributeName(pattern) syntax. Code - more especially export code - can be found in body text of notes and in internal or external templates.

Note that TB doesn't expect a $-prefix for attributes is ^export codes (their design predates the arrival of the prefix) though in most cases a prefix won't stop code function.  Another oddity is paths, where advice is that paths as in $AttributeName(/Some/path/notename) shouldn't be quoted whereas string parameter values in v4.6+ are double quoted. The reason for the latter discreancy isn't clear but must be presumed to be linked to TB's internal parsing of user's code. In either case, the advised syntax reflects the design concept of at app - i.e. so you're not causing it to parse syntax of a type it doesn't expect.

Also giving scope for confusion is knowing when code parameters are evaluated or not, i.e. whether a parameter must be entered as a fixed value or whether it may be an expression in it's own right (or simply another attribute value). This are tends to change a fair bit over time with a general trend to increased scope of support for evaluation of parameters. Eastgate offer the TB cookbook to help users with this. By downloading a copy and adding new tests you can experiment to see if your TB version supports a particular construct.

The manual is currently a mix of (still supported) old and new forms with the latter generally being used. In aTbRef, all examples have been revised and should use the newer syntax; it will be further revised when legacy code supprot is dropped. The wiki context are largely out of date in terms of syntax and should be reviewed by users before use. As wiki articles often discuss what does/doesn't work and there's a convention to retain reference to contributors, revising that source is less easy than imagined. Until legacy code syntax support is dropped older code examples are arguably still valid.

So, few hard and fast rules, but that's part of the story for apps which are under continual growth and refinement, like TB.
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: Surprising difference in effect
Reply #10 - Jul 28th, 2009, 9:59am
 
With respect, you're making mountains out of molehills.  I know it's hard, but it's not nearly as hard as I think you're making it seem.

1) $Attrib(something) is always the value of an attribute

2) The query, Attrib(something), is a regular expression test; it is true if "something" is found in the value of $Attrib.

3) Occasionally, people may omit the '$' when writing $Attrib(...), either because they forgot to write it or because they are using an older syntax.  Tinderbox is (fairly) tolerant of this mistake, and tries to do something sensible. For example, MyDate=Modified(parent) is interpreted as $MyDate=$Modified(parent)
Back to top
 
 
WWW   IP Logged
Pages: 1
Send Topic Print