Mark Anderson
YaBB Administrator
Offline
User - not staff!
Posts: 5689
Southsea, UK
|
[This was drafted (too slowly!)m against the first post in the thread.]
Oh brother... it's simple in concept but wordy to explain. Most legacy stuff should still work (thanks Eastgate!), but the likely breakers are things that weren't quoted should now be quoted, specifically string values including simple operators */-+ (and probably a few more). For string/set attributes, literal values are quoted. Boolean and Number type values are not quoted. Color type values are quoted. Date type values, where they are strings (literal dates and format strings) are quoted.
An exception to quoting (apparent) strings is names/paths. $Color is this note's color. $Color(Some note) is the color of a note called 'Some Note'. $Color(Alumni/2001/Fred Smith) is the name of a note called 'Fred Smith' with the path from root of 'Alumni/2001'. We don't, by convention, quote names or paths (although it seems you can do so without problem).
Placeholder names - now termed 'designators' - such as child, parent, can now also use paths. $Name(parent(parent)) returns this note's grandparent's note name. I presume (untested) you can nest further, e.g. $Name(parent(parent(parent(parent)))) and such but I suspect doing so will make things run a bit slower and anyway shouldn't really be needed in real world use (i.e. there's likely a limit but you shouldn't encounter it).
Queries are now TB "expressions" - think of that as meaning action code. Indeed there are now new action code operators of all the #query codes, so #between(... becomes between(... otherwise changed except where the first point above indicates string parameters values may now need quoting. Apart from syntax within queries, the main impact of the change is a more unified use of code
In Action code (not Export code) we now $-prefix all attribute references both sides of the expression: $Color=$MyColor or $MyString="Krusty". There is one place attribute names aren't prefixed and that is in the query-like use attrbruteName(pattern). In the latter think of it as an action operator that executes a regular expression search for the pattern against the attribute whose name is used as the operator name. Thus generically we have a figurative operator op(regexp) and to search attribute MyString's value for one or more digits, we'd use MyString(\d+) or MyString(red) to match the syllable 'red'. To target a different attribute just use its name, e.g. MyOtherString(\d+).
Export code syntax remains unchanged - you don't need to quote text (except in a few where it's expressly requested such a creating link sets) and you don't need to $-prefix attribute names (again except if/wher. Note that ^value($MyString)^ equates to ^get(MyString^ and ^value($MyString(parent)^ equals ^getFor9parent,MyString)^ and ongoing best practice is to substitute action code for export code wherever possible.
If this all seems a bit wooly it's because Eastgate have pulled of revising a lot of stuff under the hood without breaking anything much in current docs. As v4.6 shakes down, I'd expect the boundary cases above to be clarified and where legacy support conflicts with new needs it will fall away so don't adopt a policy of no change.
Oh, and I fully expect Mark B will tell me something above is wrong. I too am feeling my way!
|