home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Improvement Suggestions
Suggestion to use XBMC's XML scrapers for HTTP scraping
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="fforde" data-source="post: 424760" data-attributes="member: 52082"><p>You misunderstand me. Look at this:</p><p>[CODE]<RegExp input="$$1" output="&lt;entity&gt;&lt;title&gt;\1&lt;/title&gt;&lt;url&gt;http://jadedvideo.com/yz_resultJAVA.asp?PRODUCT_ID=\2&lt;/url&gt;&lt;/entity&gt;" dest="5"[/CODE]</p><p>Instead of just storing the URL in a variable (maybe named $URL) you have to build a wrapping XML block using escaped brackets. This is sloppy unneeded and complicates the process of writing a script. I don't care about a program you are writing that hides these problems. It still makes the scripts more difficult to work with. </p><p></p><p>The standard search function is limited in that it only returns a title and url item in the returned XML. To get around this some scripts put the year in parenthesis in the title tag. As you mentioned XML should be a structured format, well defined and easily searchable by XSLT. The way XBMC handles search results though limits the amount of data that is returned, and the only work around for this detroys any benefits gained from returning XML (even though I don't agree with the returned XML approach anyway as I describe in item #1). Additional information in search results, as I mentioned above, can be valuable for automatic matching purposes. Release year would be the most common value, but this could be different for different types of data retrieved (movies, tv-shows, weather, etc).</p><p></p><p>No. Adding more features does not mean the method of writing a script is more complicated, it means the users have more tools to work with. People can easily start small with basic page retieval and regex parsing, then move on to XSLT, looping, sorting, etc as they become more experienced, improving their scripts. <em>Requiring</em> the use of additional options would be bad. <em>Offering</em> the use of additional options makes your scripting engine mroe flexible. My point though was not that the XBMC scraper didn't have enough options. It was that it is too difficult to expand upon. It does not have a framework for creating new aspects of the scripting language without modifying the core. I think this is a limitation.</p></blockquote><p></p>
[QUOTE="fforde, post: 424760, member: 52082"] You misunderstand me. Look at this: [CODE]<RegExp input="$$1" output="<entity><title>\1</title><url>http://jadedvideo.com/yz_resultJAVA.asp?PRODUCT_ID=\2</url></entity>" dest="5"[/CODE] Instead of just storing the URL in a variable (maybe named $URL) you have to build a wrapping XML block using escaped brackets. This is sloppy unneeded and complicates the process of writing a script. I don't care about a program you are writing that hides these problems. It still makes the scripts more difficult to work with. The standard search function is limited in that it only returns a title and url item in the returned XML. To get around this some scripts put the year in parenthesis in the title tag. As you mentioned XML should be a structured format, well defined and easily searchable by XSLT. The way XBMC handles search results though limits the amount of data that is returned, and the only work around for this detroys any benefits gained from returning XML (even though I don't agree with the returned XML approach anyway as I describe in item #1). Additional information in search results, as I mentioned above, can be valuable for automatic matching purposes. Release year would be the most common value, but this could be different for different types of data retrieved (movies, tv-shows, weather, etc). No. Adding more features does not mean the method of writing a script is more complicated, it means the users have more tools to work with. People can easily start small with basic page retieval and regex parsing, then move on to XSLT, looping, sorting, etc as they become more experienced, improving their scripts. [i]Requiring[/i] the use of additional options would be bad. [i]Offering[/i] the use of additional options makes your scripting engine mroe flexible. My point though was not that the XBMC scraper didn't have enough options. It was that it is too difficult to expand upon. It does not have a framework for creating new aspects of the scripting language without modifying the core. I think this is a limitation. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Suggestion to use XBMC's XML scrapers for HTTP scraping
Contact us
RSS
Top
Bottom