You're right balala, however the section starts with "script" and everything is nested inside...
I was thinking of adding a "disclaimer" just to be sure:
Are you planning to use WebParser and using an RSS Feed?
Well, ok, do it.
Are you thinking to use WebParser with a web page?
Think about it:
Be aware that if you need to be registered on the site, forget it;
If you want to download an image or some informations, they must be easily accessible, no script, java or redirection will work;
The page can change frequently, you'll have to follow the changes and update your code.
...but of course it's just a suggestion.
It is currently March 29th, 2024, 9:53 am
Question
-
- Moderator
- Posts: 1387
- Joined: April 11th, 2013, 8:08 pm
- Location: Italy
-
- Developer
- Posts: 22628
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: Question
The simplest and most accurate way to think about WebParser is that is a "web-enabled text parser".
When used on a local file, it is purely a text parser. It reads a text file, and allows you to use regular expression to parse the text into an array of separate bits of information, that you use with StringIndex to display in meters.
When it connects to a remote site, it uses a URL with the HTTP or FTP protocols to connect with the site, then asks for a particular site resource. Whatever is returned by the site is simply treated as text, exactly the same as above with a local file.
It's not a web-browser. It can't react to anything the site sends in the output as client-side commands to do something. It has no "engine", it can't run client-side javascript, or react to anything in CSS or HTML5, other than treating it all as just more text.
It's simply a text parser than can connect to a remote resource to get the text.
When used on a local file, it is purely a text parser. It reads a text file, and allows you to use regular expression to parse the text into an array of separate bits of information, that you use with StringIndex to display in meters.
When it connects to a remote site, it uses a URL with the HTTP or FTP protocols to connect with the site, then asks for a particular site resource. Whatever is returned by the site is simply treated as text, exactly the same as above with a local file.
It's not a web-browser. It can't react to anything the site sends in the output as client-side commands to do something. It has no "engine", it can't run client-side javascript, or react to anything in CSS or HTML5, other than treating it all as just more text.
It's simply a text parser than can connect to a remote resource to get the text.
-
- Rainmeter Sage
- Posts: 16110
- Joined: October 11th, 2010, 6:27 pm
- Location: Gheorgheni, Romania
Re: Question
Yep, probably usually it's a good idea. In this particulare case maybe it doesn't...fonpaolo wrote:You're right balala, however the section starts with "script" and everything is nested inside...
I was thinking of adding a "disclaimer" just to be sure:
Are you planning to use WebParser and using an RSS Feed?
Well, ok, do it.
Are you thinking to use WebParser with a web page?
Think about it:
Be aware that if you need to be registered on the site, forget it;
If you want to download an image or some informations, they must be easily accessible, no script, java or redirection will work;
The page can change frequently, you'll have to follow the changes and update your code.
...but of course it's just a suggestion.