I've been discussing the possibility of using an HTML parser instead of regular expressions to parse through the HTML source from the web site. My main concern is primary any extra overhead that would be added. Chances are, there would be some additional overhead if an HTML parser was used. Ease of use is also a concern, though, because if the extra overhead is minimal, I'd still consider switching over to using an HTML parser just for the sake of simplicity. Regular expressions certainly provide capability, but they themselves (i.e. not the Java API for them) are not easy to use. Any thoughts?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've found the same problem....for example, I wish to add a method to KolItem -> setImageURL which sets the url address of the gif image of the item...using the HTMLParser would be made in just 1 line....!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
jaadams5 has sent me a new module for interacting with the Clan Stash that uses an HTML parser. It looks promising, although we'll have to see how well it benchmarks. I'll put updates in this thread, so keep an eye out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was getting a little frustrated with the broken closet in KwiKoL (I had not realized how much my playing style depended on being able to quickly identify which items were "surplus". This is not a complaint to Matt ;-) because I still think KwiKoL is right up there with sliced bread (or should that be toast?)) so I bit the bullet and implemented a getItemsInCloset that used a parser. It turned out to be a 5 minute exercise because the code was identical to the ClanStash code once I made the HTML page to be fetched a parameter. I'll clean things up and release them to Matt eventually.
Two things I realized: 1) Parser will probably continue to work fine for "reading" the game but I doubt that it brings anything useful to bear on opeartions that actually change the game state. Not a great insight but does point towards a separation of "Read" and "Write" functionality. 2) Autosell prices remain a problem. While there are several ways to generate item lists, most of them do not support fetching autosell prices without another hit to the server. Given that the prices are static, perhaps this suggests obtaining them from another site, such as KoLHelper?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had considered that option. In cooperation with PoolAce (creator of KoL Helper), I actually created an XML API for his MySQL database of items before I started work on KwiKoL. It's plausible that we could tie KwiKoL into it for fetching autosell prices, although I'm not sure I want to go that road yet. I'm considered implementing a separate method, likely in the KoLInventory class, for fetching the autosell price of an individual item from its description window. That way, the player can do it on a per-item basis and (hopefully) more than likely won't need to do it for every item in a returned set of items.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been discussing the possibility of using an HTML parser instead of regular expressions to parse through the HTML source from the web site. My main concern is primary any extra overhead that would be added. Chances are, there would be some additional overhead if an HTML parser was used. Ease of use is also a concern, though, because if the extra overhead is minimal, I'd still consider switching over to using an HTML parser just for the sake of simplicity. Regular expressions certainly provide capability, but they themselves (i.e. not the Java API for them) are not easy to use. Any thoughts?
I've found the same problem....for example, I wish to add a method to KolItem -> setImageURL which sets the url address of the gif image of the item...using the HTMLParser would be made in just 1 line....!
jaadams5 has sent me a new module for interacting with the Clan Stash that uses an HTML parser. It looks promising, although we'll have to see how well it benchmarks. I'll put updates in this thread, so keep an eye out.
I was getting a little frustrated with the broken closet in KwiKoL (I had not realized how much my playing style depended on being able to quickly identify which items were "surplus". This is not a complaint to Matt ;-) because I still think KwiKoL is right up there with sliced bread (or should that be toast?)) so I bit the bullet and implemented a getItemsInCloset that used a parser. It turned out to be a 5 minute exercise because the code was identical to the ClanStash code once I made the HTML page to be fetched a parameter. I'll clean things up and release them to Matt eventually.
Two things I realized: 1) Parser will probably continue to work fine for "reading" the game but I doubt that it brings anything useful to bear on opeartions that actually change the game state. Not a great insight but does point towards a separation of "Read" and "Write" functionality. 2) Autosell prices remain a problem. While there are several ways to generate item lists, most of them do not support fetching autosell prices without another hit to the server. Given that the prices are static, perhaps this suggests obtaining them from another site, such as KoLHelper?
I had considered that option. In cooperation with PoolAce (creator of KoL Helper), I actually created an XML API for his MySQL database of items before I started work on KwiKoL. It's plausible that we could tie KwiKoL into it for fetching autosell prices, although I'm not sure I want to go that road yet. I'm considered implementing a separate method, likely in the KoLInventory class, for fetching the autosell price of an individual item from its description window. That way, the player can do it on a per-item basis and (hopefully) more than likely won't need to do it for every item in a returned set of items.