Normal
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. Requiring the use of additional options would be bad. Offering 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.
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. Requiring the use of additional options would be bad. Offering 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.
