Some examples of what this opens up are:
Have an RSS feed skin that you can change from feed site to feed site without having to use !WriteKeyValue or !Refresh the skin.
Page through large RSS feeds, without needing tons of "child" measures.
Dynamically change the location code in a weather skin, to enable multiple locations in a single skin. Again without having to use !WriteKeyValue and !Refresh.
Have the result of parsing one site provide all or part of the URL option for a second WebParser "parent". For instance, you might parse Site A for a user name, and then use that name to find and parse game statistics from Site B.
Some important things to understand:
1) If you want to use a dynamic #VariableName# on a WebParser measure, the measure must include DynamicVariables=1, just like any other measure. If you use !SetOption to change a WebParser option, then DynamicVariables=1 is not required, also just like any other measure.
2) WebParser uses UpdateRate to determine how often the plugin should actually access the site or file. While you can now dynamically change any option on a WebParser measure, the plugin will not use the changes and access the site again until the next UpdateRate is reached. Just using !Update or !UpdateMeasure will NOT override the UpdateRate.
In order to have a dynamic change make WebParser parse the site "right now", you will use the !CommandMeasure bang with the "parent" WebParser measure as the first parameter, and Update as the second. Don't forget that the default for UpdateRate is 600, so a dynamic change can take up to that long to "happen" if you don't force it with !CommandMeasure.
Example:
LeftMouseUpAction=[!SetOption WebMeasure URL "http://SomeNewSite.com"][!CommandMeasure WebMeasure Update]
3) If you dynamically change an option on a "child" WebParser measure that depends on a "parent" measure, (like StringIndex for instance) you MUST use !CommandMeasure with "Update", targeting the "parent" WebParser measure. The values of child WebParser measures are a function of the parent measure, and are only updated when the parent is. You should never use !CommandMeasure on a "child" measure, as it won't do anything.
4) The way that WebParser has always worked is that you parse a site and create StringIndex numbers with the "parent" measure, then pick off the individual values by StringIndex number in "child" measures. This has not changed.
Code: Select all
[MeasureParent]
Measure=Plugin
Plugin=WebParser
URL=http://SomeSite.com
RegExp=(?siU)<title>(.*)</title>
[MeasureChild]
Measure=Plugin
Plugin=WebParser
URL=[MeasureParent]
StringIndex=1
Code: Select all
[MeasureParent]
Measure=Plugin
Plugin=WebParser
URL=http://SomeSite.com
RegExp=(?siU)<UserName>(.*)</UserName>
StringIndex=1
[MeasureSecondParent]
Measure=Plugin
Plugin=WebParser
URL=http://SomeSite.com/[&MeasureParent]
RegExp=(?siU)<Ranking>(.*)</Ranking>
DynamicVariables=1
[MeasureChild]
Measure=Plugin
Plugin=WebParser
URL=[MeasureSecondParent]
StringIndex=1
Here are a few example skins you can install and take a look at to see how to dynamically interact with WebParser, and how those caveats described above factor in.
1) Use the value of one parent in the URL option of a second parent. This demonstrates how you would use the [&MeasureName] variant to tell WebParser to use the value of another WebParser measure as a "section variable" in the URL option.
DynaSite_1.0.rmskin
2) Dynamically change the location code in a weather skin, to have a single skin with multiple weather locations.
DynaWeather_1.0.rmskin
3) Dynamically "page" through a large RSS feed.
DynaFeed_1.0.rmskin
Taking a look at the actual code in these skins will show some ways to make things "dynamic" with WebParser. We are really pleased with this change, and hope we see some very clever uses in the near future.
