Nesting variables in WebParser's URL option

[Yincognito]

Say I have:

Code: Select all

[Variables]
Var=Foo
FooBar=(some actual variable value here) 

If I set FooBar=255,0,0,255 and use the alternative nesting variables syntax of [#[#Var]Bar] in, say, a Shape meter like this:

Code: Select all

Shape=Rectangle 0,0,50,50 | Fill Color [#[#Var]Bar] | StrokeWidth 0

in order to fill the rectangle with the #FooBar# color, everything works fine.

However, if I set FooBar=(some random webaddress here) and try to to the same in the URL option of a WebParser parent, nothing seems to happen, even if I use the !CommandMeasure bang to update the WebParser:

Code: Select all

URL="[#[#Var]Bar]"

I tried adding & in order to escape things, removing the quotes, use the "old" variable syntax in one of the variables, but nothing seems to work. What am I missing?

[jsmorley]

I'm not 100% sure, and brian may want to weigh in, but my suspicion is that you can't use nested measure variables with WebParser parent measures in the URL option, This is because previous to nested variables being a thing, the way you used a dynamic [SectionVariable] in the URL option was to preface the measure name with the & symbol.


URL=[&SomeOtherNonWebParserMeasure]

My assumption is that trying to nest [SectionVariables], which also requires the & character, is conflicting with this. So in a sense it is seeing the & character as meaning "go get the value of that measure, rather than assuming this is a child measure and getting the results of a WebParser parent measure", but that is then in manner of speaking "using up" the & character and the nesting then fails.

[jsmorley]

In reviewing your post, I see you are not using a measure [SectionVariable], but simply nesting variables like [#Foo[#Bar]]. I'm guessing WebParser, which has a very particular way of reading the URL option, just can't deal with that.

This in fact does not work, when logically it probably should...

Code: Select all

[Variables]
Foo=file://#CURRENTPATH#DownloadFile\
Bar=EntireSite.txt

[MeasureSiteContents]
Measure=WebParser
URL=[#Foo[#Bar]]
RegExp=(?siU)<title>(.*)</title>
DynanmicVariables=1

And this does not work.

Code: Select all

[Variables]
Foo=file://#CURRENTPATH#DownloadFile\EntireSite.txt

[MeasureSiteContents]
Measure=WebParser
URL=[#Foo]
RegExp=(?siU)<title>(.*)</title>
DynamicVariables=1

This on the other hand, does work.

Code: Select all

[Variables]
Foo=file://#CURRENTPATH#DownloadFile\EntireSite.txt

[MeasureSiteContents]
Measure=WebParser
URL=#Foo#
RegExp=(?siU)<title>(.*)</title>

[Yincognito]

I'm not 100% sure, and brian may want to weigh in, but my suspicion is that you can't use nested measure variables with WebParser parent measures in the URL option, This is because previous to nested variables being a thing, the way you used a dynamic [SectionVariable] in the URL option was to preface the measure name with the & symbol.


URL=[&SomeOtherNonWebParserMeasure]

My assumption is that trying to nest [SectionVariables], which also requires the & character, is conflicting with this. So in a sense it is seeing the & character as meaning "go get the value of that measure, rather than assuming this is a child measure and getting the results of a WebParser parent measure", but that is then in manner of speaking "using up" the & character and the nesting then fails.

I thought about this being the reason too. Just to let you know, when the URL is changed with a !SetOption bang from another measure/meter, everything works fine and the WebParser measure correctly gets the value of the variable. This was also my workaround, in the end.

[jsmorley]

My strong suspicion is that the URL option of a WebParser measure just can't deal with the nested variables format. Period... I'm guessing that the starting [ character is sending things off down a very specific WebParser rabbit-hole.

This also doesn't work.

Code: Select all

[Variables]
Foo=#CURRENTPATH#DownloadFile\
Bar=EntireSite.txt

[MeasureSiteContents]
Measure=WebParser
URL=file://[#Foo[#Bar]]
RegExp=(?siU)<title>(.*)</title>
DynamicVariables=1

[Yincognito]

My strong suspicion is that the URL option of a WebParser measure just can't deal with the nested variables format. I'm guessing that the starting [ character is sending things off down a very specific WebParser rabbit-hole.

You're probably right. I had an issue a couple of weeks ago when I tried to use [&Measure] in a WebParser's URL option, coupled with DynamicVariables=1 set on the WebParser measure, and this caused Rainmeter to hang and eventually quit. I don't remember if I was trying to nest or escape variables that time, but if that thing was not a mistake of mine in the code, then these two issues might be related. There was the same workaround for that issue as for this one (i.e. setting the URL with a !SetOption bang), by the way.

[jsmorley]

Not sure I follow that. This certainly does work as designed and intended...

Code: Select all

[MeasureURL]
Measure=String
String=file://#CURRENTPATH#DownloadFile\EntireSite.txt

[MeasureSiteContents]
Measure=WebParser
URL=[&MeasureURL]
RegExp=(?siU)<title>(.*)</title>
DynamicVariables=1

So the & character is telling the URL option to use the value of [MeasureURL], rather than looking for a "parent" WebParser measure called [MeasureURL]. That is how the & character was designed to interact with WebParser, and it does so.

I don't believe it is the & character as such that is the root of the problem. I believe it is the leading and trailing [ and ] characters in any "nested" format that is. I could easily be wrong, but I believe that when it sees [anything] in the URL of a WebParser measure, that sends it down a very specific parsing path that then asks "is the next char after [ a &?". If yes, then throw away the &, and go get the value of that measure. If no, then treat that as a parent WebParser measure, and this as a child. I think any form of nesting is going to befuddle it. At that point the meaning of [&MeasureName] is not unambiguous.

I'd like to confirm this with brian at some point, so we can then either change the behavior (which I doubt, this parsing is already hideously complicated and MUST always be unambiguous) or make an appropriate note in the documentation.

[Yincognito]

Not sure I follow that. This certainly does work as designed and intended...

I know it does. As I said, I can't remember for sure, but I might have tried to nest variables on that occasion too, and probably trying all kinds of solutions I ended up throwing a [& there as well.

Anyway, the fact is that the URL option of a WebParser handles a couple of very similar things in terms of syntax:
- URL=[WebParserChild]
- URL=[&SectionVariableWebMeasure]
- URL=[#MyNestedVar[#MyOtherNestedVar]]
- URL=[#MyNestedVar[&MyNestedMeasure]]
- URL=[&MyNestedMeasure[#MyNestedVar]]
- URL=[&MyNestedMeasure[&MyOtherNestedMeasure]]
Somewhere along the line, it probably gets "confused" and goes the wrong way (e.g. expecting [Measures] instead of [#NestedVariables]). The fact that WebParser doesn't have a very long history of supporting dynamic variables (compared to other measure types) may be a factor in the occurence of such issues. Also, the URL option probably likes everything (variables, measures) to be resolved before they get to be used in the option...

[jsmorley]

I know it does. As I said, I can't remember for sure, but I might have tried to nest variables on that occasion too, and probably trying all kinds of solutions I ended up throwing a [& there as well.

Anyway, the fact is that the URL option of a WebParser handles a couple of very similar things in terms of syntax:
- URL=[WebParserChild]
- URL=[&SectionVariableWebMeasure]
- URL=[#MyNestedVar[#MyOtherNestedVar]]
- URL=[#MyNestedVar[&MyNestedMeasure]]
- URL=[&MyNestedMeasure[#MyNestedVar]]
- URL=[&MyNestedMeasure[&MyOtherNestedMeasure]]
Somewhere along the line, it probably gets "confused" and goes the wrong way (e.g. expecting [Measures] instead of [#NestedVariables]). The fact that WebParser doesn't have a very long history of supporting dynamic variables (compared to other measure types) may be a factor in the occurence of such issues. Also, the URL option probably likes everything (variables, measures) to be resolved before they get to be used in the option...

I believe it does handle these ok:

- URL=[WebParserParentThisIsAChild]
- URL=[&AnyMeasureStringValueThisIsAParent]

But not these:

- URL=[#MyNestedVar[#MyOtherNestedVar]]
- URL=[#MyNestedVar[&MyNestedMeasure]]
- URL=[&MyNestedMeasure[#MyNestedVar]]
- URL=[&MyNestedMeasure[&MyOtherNestedMeasure]]

[Yincognito]

I believe it does handle these ok:

- URL=[WebParserParentThisIsAChild]
- URL=[&AnyMeasureStringValueThisIsAParent]

But not these:

- URL=[#MyNestedVar[#MyOtherNestedVar]]
- URL=[#MyNestedVar[&MyNestedMeasure]]
- URL=[&MyNestedMeasure[#MyNestedVar]]
- URL=[&MyNestedMeasure[&MyOtherNestedMeasure]]

Yes, indeed (I only tested nested variables though and saw they didn't work, so I'm not 100% sure about nested measures). The more I think of it, the more I'm tempted to agree with you that it's a [ and ] thing. It probably expects the "older" measure/section variable syntax after encountering the brackets, instead of the "newer" (Aug 2017, as far as I can see) nested syntax.

EDIT: Another question about nesting variables here, by the way - but you probably know about it already.