It is currently 12 Apr 2021, 04:06
   
Text Size

Price Manager issues

Moderators: charmer, CCGHQ Admins

Price Manager issues

Postby anthonybe » 07 Feb 2014, 22:09

Hi Goblin Hero,

I started writing a LUA script in order to retrieve price from a Belgian website.
During development, I noticed some issues related to Price Manager and LUA api:

  • ma.SetProgress(text, position): Where is the text displayed in the progress bar ? I see nothing on the progress bar in the Price Manager window.
  • Update button uses SELECTED price source instead of CHECKED source(s): with the new script added to the Prices folder, the Price Manager offers me two sources: "MTG Mint Card" and "My source". I checks the check box next "My source" and uncheck the one next "MTG Mint Card". The "MTG Mint Card" source is selected (on row table level). When I click on Update button and check the log file of MA, I see that the source executed is "MTG Mint Card" instead of "My Source".
  • CSV file of new script must be created: When I added the new LUA file in the Prices folder, at MA starting, I noticed an error saying that "My Source.csv" could not be opened or does not exist (I can't remember the exact message). This "requirement" is not described on the MA LUA API page. I just copied the csv of MTG Mint Card and replaced all prices with 0 value.


Anthony.
anthonybe
 
Posts: 19
Joined: 07 Nov 2013, 21:51
Has thanked: 0 time
Been thanked: 2 times

Re: Price Manager issues

Postby LordHelmchen » 08 Feb 2014, 09:14

anthonybe wrote:Hi Goblin Hero,

I started writing a LUA script in order to retrieve price from a Belgian website.
During development, I noticed some issues related to Price Manager and LUA api:

  • ma.SetProgress(text, position): Where is the text displayed in the progress bar ? I see nothing on the progress bar in the Price Manager window.
I have the same problem. It seem that the progressbar lables do not display in Windows 7, but work in Windows XP...
  • Update button uses SELECTED price source instead of CHECKED source(s): with the new script added to the Prices folder, the Price Manager offers me two sources: "MTG Mint Card" and "My source". I checks the check box next "My source" and uncheck the one next "MTG Mint Card". The "MTG Mint Card" source is selected (on row table level). When I click on Update button and check the log file of MA, I see that the source executed is "MTG Mint Card" instead of "My Source".
  • I had the same problem. It is none: The checkboxes tell MA which scripts to use for min/max/average, selection tells it which scripts to run.
  • CSV file of new script must be created: When I added the new LUA file in the Prices folder, at MA starting, I noticed an error saying that "My Source.csv" could not be opened or does not exist (I can't remember the exact message). This "requirement" is not described on the MA LUA API page. I just copied the csv of MTG Mint Card and replaced all prices with 0 value.
  • Though the MA log logs the missing csvs, this doesn't stop it from working. When the script is run for the first time, the csv is created if it does not exist already.

    You may want to look at my library and test if using the sitescript template works a a shortcurt for your scripting needs. I'd be interested to hear if/how it works for someone other than me, but feel free to ignore it if you prefer to work from scratch :-)
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby anthonybe » 08 Feb 2014, 19:30

    Concerning the progress bar, is Goblin Hero aware of the problem ? Does he looking for a solution ?

    Concerning the Selection and checkbox, Ok. It was not clear the distinction between. Now I know :-)

    Concerning your script template and the LHPi lib, it's amazing. I will have a look and try to create one for the Belgian website.
    Is there another wiki page with a How-To configure the script template ? I will look at your script for MagicUniverse as an example.

    Anthony.
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Re: Price Manager issues

    Postby LordHelmchen » 09 Feb 2014, 12:03

    anthonybe wrote:Concerning the progress bar, is Goblin Hero aware of the problem ? Does he looking for a solution ?
    As he has replied and posted a screenshot of how it should look, I'd wager he is aware of it. If it seems important to you, you could file a bug in the tracker to remind him ;-)

    Concerning your script template and the LHPi lib, it's amazing. I will have a look and try to create one for the Belgian website.
    Is there another wiki page with a How-To configure the script template ? I will look at your script for MagicUniverse as an example.
    I tried to comment the template to make it self-explaining, but I'm open for any suggestions on how and what to document, either as additional comments in the code or in a seperate wiki page. You're practically my guinea pig for seeing if the template and library are useful to others, so I'm hoping for lots of feedback and improvement suggestions :-)
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby anthonybe » 09 Feb 2014, 12:50

    LordHelmchen wrote:I tried to comment the template to make it self-explaining, but I'm open for any suggestions on how and what to document, either as additional comments in the code or in a seperate wiki page. You're practically my guinea pig for seeing if the template and library are useful to others, so I'm hoping for lots of feedback and improvement suggestions :-)
    As a first remark, the missing part I found is the method chain. It would be great to have a sort of overview diagram showing the flow of your script: processUserParam, BuildUrl, ParseHtmlData, BuildCardData (with Pre & Post methods), ...

    Also, how you can interact with LHpi library from the sitescript. Example with dropped card.

    I don't know for now the complete process of the library but I found a case with the Belgian site where I must see how the library works.
    Because the page containing card price of an edition contains both foil and regular price of a card, each one with the same regex.It would be great to have the possibility to get different regex depending foil or regular fruc.

    In the HTMLParseData, I need to indicate to LHpi that the card must be ignored if foil and importFoil is not set. Same case for regular card.
    I'm thinking of using something like 'drop' or something similar but as I don't know exactly the library process flow, I must check inside code.
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Re: Price Manager issues

    Postby LordHelmchen » 09 Feb 2014, 17:36

    anthonybe wrote:As a first remark, the missing part I found is the method chain. It would be great to have a sort of overview diagram showing the flow of your script: processUserParam, BuildUrl, ParseHtmlData, BuildCardData (with Pre & Post methods), ...
    I'll try to give all information you need/want. We might be able to evolve this into a real documentation later :)
    Code: Select all
    MA calls sitescript.ImportPrice
    sitescript.Importprice loads the library, then calls LHpi.DoImport
    LHpi.DoImport calls LHpi.ProcessUserParams and initializes
    LHpi.DoImport calls LHpi.ListSources
     LHpi.ListSources loops through sets,langs,frucs and calls site.BuildUrl
    LHpi.DoImport calls LHpi.MainImportCycle
    LHpi.MainImportCycle loops through sets,urls and calls LHpi.GetSourceData
     LHpi.GetSourceData loops through matches with site.regex and calls site.ParseHtmlData, then returns sourceTable
    LHpi.MainImportCycle loops through sourceTable and calls LHpi.BuildCardData
     LHpi.BuildCardData calls site.BCDpluginPre and site.BCDpluginPost and returns newcard
     LHpi.MainImportCycle calls LHpi.FillCardsetTable with newcard
      LHpi.FillCardsetTable might call LHpi.MergeCardrows and adds a row to cardsetTable
    (optionally, LHpi.MainImportCycle calls LHpi.SaveCSV once cardsetTable is complete)
    LHpi.MainImportCycle loops through cardsetTable and calls LHpi.SetPrice
    Also, how you can interact with LHpi library from the sitescript. Example with dropped card.
    dropping cards:
    • if LHpi.BuildCardData sets card.drop=true, LHpi.FillCardsetTable is skipped.
    • site.ParseHtmlData can set card.drop, which will be preserved by LHpi.BuildCardData.
    • if not card.name then card.drop = true
    • if string.find( card.name , "%(DROP[ %a]*%)" ) then card.drop = true
      An example is in LHpi.magicuniverseDE.lua's site.BCDpluginPre. The advantage of changing the name above setting card.drop directly is that you can also add a reason for dropping to the name, which will be loggged if LOGDROPS=true.

    I don't know for now the complete process of the library but I found a case with the Belgian site where I must see how the library works.
    Because the page containing card price of an edition contains both foil and regular price of a card, each one with the same regex.It would be great to have the possibility to get different regex depending foil or regular fruc.
    Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop. For now, let's try to make the sitescript do some work instead of the library :-)
    site.regex matches shall include all info about a single card that one
    html-file has, it will be chopped into its parts by site.ParseHtmlData. If you can grab something like "*CARDNAME*PRICE*FOILSTATUS" and we're good to go, as far as this step is concerned. Then you can have site.ParseHtmlData return card.foil=true|false, which will be honoured by LHpi.BuildCardData.
    If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).

    In the HTMLParseData, I need to indicate to LHpi that the card must be ignored if foil and importFoil is not set. Same case for regular card.
    I'm thinking of using something like 'drop' or something similar but as I don't know exactly the library process flow, I must check inside code.
    Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.

    Its fascinating how much my choice of sites influenced what I considered generalization. Foil/Nonfoil on the same page is definitely something that a generally useful library needs to be able to cope with. Currently, I'm repairing breakage induced by adding more special sets to the existing sitescripts. When they work again, I will release 2.6 and concentrate on including your needs :)
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby Goblin Hero » 10 Feb 2014, 06:19

    LordHelmchen wrote: If it seems important to you, you could file a bug in the tracker to remind him
    I'll fix it in the next update.
    When you´re a goblin, you don´t have to step forward to be a hero -- everyone else just has to step back.
    User avatar
    Goblin Hero
    Site Admin
    Site Admin
     
    Posts: 1971
    Joined: 23 Oct 2005, 09:37
    Location: Russia
    Has thanked: 160 times
    Been thanked: 322 times

    Re: Price Manager issues

    Postby anthonybe » 10 Feb 2014, 10:44

    LordHelmchen wrote:I'll try to give all information you need/want. We might be able to evolve this into a real documentation later :)
    Thanks. A section on the wiki page would be great ;-)

    LordHelmchen wrote:dropping cards:
    • if LHpi.BuildCardData sets card.drop=true, LHpi.FillCardsetTable is skipped.
    • site.ParseHtmlData can set card.drop, which will be preserved by LHpi.BuildCardData.
    • if not card.name then card.drop = true
    • if string.find( card.name , "%(DROP[ %a]*%)" ) then card.drop = true
      An example is in LHpi.magicuniverseDE.lua's site.BCDpluginPre. The advantage of changing the name above setting card.drop directly is that you can also add a reason for dropping to the name, which will be loggged if LOGDROPS=true.
    This kind of information would also be welcome on the wiki page.
    The impact of setting a specific property in a specific method would be great.

    LordHelmchen wrote:Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
    [...]
    Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.
    In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.
    You're right, BuildCardData should be aware of the MA importfoil. The sitescript just needs to return all info it has, and the library does "the rest" :-)

    LordHelmchen wrote:site.regex matches shall include all info about a single card that one
    html-file has, it will be chopped into its parts by site.ParseHtmlData. If you can grab something like "*CARDNAME*PRICE*FOILSTATUS" and we're good to go, as far as this step is concerned. Then you can have site.ParseHtmlData return card.foil=true|false, which will be honoured by LHpi.BuildCardData.
    In my case, we are in the scenario "*CARDNAME*PRICE*FOILSTATUS". So, I'm able to set card.foil in parseHtmlDate function.
    This works good except with non foil card. The card.foil is set to false, but BuildCardData consider the card as foil due to the fruc ("Foil_And_Regular") in the URL.

    In BuildCardData, you have a conditional block:

    Code: Select all
    if sourcerow.foil then -- keep site.ParseHtmlData preset foil
          card.foil = sourcerow.foil
       else
          if urlfoil then
             card.foil = true -- believe urldata
          elseif string.find ( card.name, "%( ?[fF][oO][iI][lL]%)" ) then
             card.foil = true -- check cardname
          else
             card.foil = false
          end -- if urlfoil
       end -- if sourcerow.foil
    When card.foil is set to false, you enter in the else block and check the url. As my url has fruc "Foil_And_Regular", you set the card.foil on true, doing the average between foil and non foil price, to set foil price.
    I think the first test "if sourcerow.foil then" should be "if sourcerow.foil ~= nil then". If the property is set, use it and don't care about its value.
    For now, I fixed the issue by removing the fruc from the url.

    LordHelmchen wrote:If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).
    For that scenario, don't need to change anything critical. The parseHtmlDate can set card.regprice and card.foilprice properties as they are used in the BuildCardData with sourcerow.regprice and sourcerow.foilprice.
    However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.

    LordHelmchen wrote:Its fascinating how much my choice of sites influenced what I considered generalization. Foil/Nonfoil on the same page is definitely something that a generally useful library needs to be able to cope with. Currently, I'm repairing breakage induced by adding more special sets to the existing sitescripts. When they work again, I will release 2.6 and concentrate on including your needs :)
    All scenarios cannot be defined in advance, especially with internet ;-)

    A feature I would like to have is the possibility to fill in site.sets at runtime. Why ?
    When sets are hard-coded, any new set will require an update of the lua script. If the script is able to create sets at runtime, it is possible to automatically add new set when website is updated.
    Let's say the name of set in MA is identical to the one on the website, I can map easily the MA setid with the website setid and add the entry is the table site.sets.
    When a new set is release and available on the website, if set name matches, the set is automatically available in the lua script.

    In the case a map between MA abd Website is not easy, we can still define it by hand in LUA script.

    Anthony.
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Re: Price Manager issues

    Postby LordHelmchen » 11 Feb 2014, 12:02

    anthonybe wrote:
    LordHelmchen wrote:I'll try to give all information you need/want. We might be able to evolve this into a real documentation later :)
    Thanks. A section on the wiki page would be great ;-)
    Feel free to edit the wiki page with questions and by improving the documentation. Maybe developer information should be moved into a seperate page? I could post a copy of the template into the wiki there for easier reading... Also, please tell me of any improvements that could be made to the template comments (which I originally planed to be the main developer documentation)
    LordHelmchen wrote:dropping cards:
    This kind of information would also be welcome on the wiki page.
    wikified it :)
    The impact of setting a specific property in a specific method would be great.
    Could you elaborate what you mean? In particular, are there questions that are not answered by the luadoc comments? In answering those questions, what should go to the wiki and what is better/already done with code comments?

    LordHelmchen wrote:Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
    [...]
    Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.
    In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.
    That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.
    You're right, BuildCardData should be aware of the MA importfoil. The sitescript just needs to return all info it has, and the library does "the rest" :-)
    added to planned features.
    In my case, we are in the scenario "*CARDNAME*PRICE*FOILSTATUS". So, I'm able to set card.foil in parseHtmlDate function.
    This works good except with non foil card. The card.foil is set to false, but BuildCardData consider the card as foil due to the fruc ("Foil_And_Regular") in the URL.

    In BuildCardData, you have a conditional block:
    ...
    When card.foil is set to false, you enter in the else block and check the url. As my url has fruc "Foil_And_Regular", you set the card.foil on true, doing the average between foil and non foil price, to set foil price.
    I think the first test "if sourcerow.foil then" should be "if sourcerow.foil ~= nil then". If the property is set, use it and don't care about its value.
    For now, I fixed the issue by removing the fruc from the url.
    Will check BuildCardDate and probably change all instances of
    Code: Select all
    if sourcerow.FIELD then
    to
    Code: Select all
    if sourcerow.FIELD~=nil then
    LordHelmchen wrote:If you instead need to grab "*CARDNAME*REGPRICE*FOILPRICE*" ... I have not thought of that... I will have to adapt LHpi.BuildCardData to cope with a card that already has both foil and regular price. Alternatively, site.ParseHtmlData and its call by LHpi.GetSourceData could be rewritten to return not a single card, but a list of cards (similar to how site.BuildUrl returns not a single url, but a container with one or more urls).
    For that scenario, don't need to change anything critical. The parseHtmlDate can set card.regprice and card.foilprice properties as they are used in the BuildCardData with sourcerow.regprice and sourcerow.foilprice.
    How should cards with variants be handled in this case? Should the library just apply sourcerow.*price to card.*price (as it does now), should the library go through the versions and apply sourcerow.*price to card.price[variant] fields, or (probably the safest) make sure that version information matches and the do witchever of the previous two solutions fit best? I'm not sure if trusting the sitescript to get variants right is safe :-)
    However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.
    Right...although that is just to divide the price by 100 again (see comments in code. I could add a check for card.price~=nil to prevent errors and forcing the sitescript to set unneeded properties. Should I add a check for ~=nil and division by 100 for card.regprice and card.foilprice there as well, to keep the way prices are handed over consistent? Would potentially need to loop through variants there, then.

    LordHelmchen wrote:When they work again, I will release 2.6 and concentrate on including your needs :)
    2.6 is released with all that previously worked working again. All changes for your needs shall be 2.7, of which the first version will appear shortly.

    A feature I would like to have is the possibility to fill in site.sets at runtime. Why ?
    When sets are hard-coded, any new set will require an update of the lua script. If the script is able to create sets at runtime, it is possible to automatically add new set when website is updated.
    Let's say the name of set in MA is identical to the one on the website, I can map easily the MA setid with the website setid and add the entry is the table site.sets.
    When a new set is release and available on the website, if set name matches, the set is automatically available in the lua script.

    In the case a map between MA abd Website is not easy, we can still define it by hand in LUA script.
    I was aiming at the scripts being easily updateable, but this is even more ambitious ;-)
    For a new set, As long as I cannot ask MA for the information, I need to add the set's cardcounts and variant tables (usually, for sets with basic lands) anyway. The first for LHpi's ungodly amount of sanity checks, the second because I want to minimize the need to repeat the table in each sitescript and prefer to have namereplacement to full variant tables therein.
    The sitescript needs to have the set's url (which is not trivially guessable for some sites), langs, frucs and (for mtgmintcard) pagecount set correctly to prevent unneccessary calls for empty/nonexisting pages. Also, I have rarely seen a set that does not need any namereplacing done across all sites. Lastly, Due to different foil/nonfoil and available languages, guessing the number of applied namereplacements from the length of the namereplace table alone seems almost impossible, so the expected count for the sanity checks need to be adjusted by hand anyway.
    All that said, if you like, feel free to submit patches to (start to) implement site.sets at runtime. As long as nothing breakes, more features in the library are a good thing, and minimizing the need for manual updates on new sets is even better than making those updates easy :-)
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby LordHelmchen » 12 Feb 2014, 09:18

    LordHelmchen wrote:
    anthonybe wrote:
    LordHelmchen wrote:Interestingly, I have not encountered a site with regular and foil prices in the same html file. Generalizing this would probably include rethinking the whole fruc-loop.
    [...]
    Up until now, importfoil parameter passed from MA was used to set all unapplicable frucs to false before building the list of urls... foil/nonfoil prices in the same page means I (we?) need to rethink how to handle the case of the user not wanting to import both. For a start, we could pass importfoil to BuildCardData, and indeed set card.drop accordingly.
    In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.
    That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.
    Actually, now that I have thought about it for a while, the way LHpi.ProcessUserParams currently configures the script, what you need to do is:
    define two frucs, {"foil","nonfoil"}, but don't append fruc[frucid] in site.BuildUrl, but instead return the same url for both frucids. Now ProcessUserParams can configure what to import with the assumption that fruc[1] is foil and other frucs are nonfoil. LHpi.ListSources will then try to add the same url twice, overwrite the first copy with the identical second copy, so LHpi.MainImportCycle will see no difference to a single fruc. Starting with 2.7, LHpi.BuildCardData will then drop unwanted foil/nonfoil according to importfoil, to be compatible with a foil-and-nonfoil-in-one-page site. I will update the template comments to make this more obvious.

    Btw, in case you haven't seen it yet, a prerelease of 2.7 is available on the wiki for you to try.
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby anthonybe » 12 Feb 2014, 11:44

    I will have a look at 2.7-pre-release.
    Your proposition with two fruc but same url looks good to me. I will have a try.

    Concerning documentation, I will think about what to put in comment in sitescript and what to put in the wiki to help new sitescript creators. Let sometime to do it and I will return to you ;-)
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Re: Price Manager issues

    Postby LordHelmchen » 13 Feb 2014, 15:25

    2.7 is done, with a hopefully better documented template :)
    Here's another wiki link so you don't have to scroll back up to find it ;-)
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby anthonybe » 21 Feb 2014, 17:02

    Hi Lord,

    I added a wiki page explaining how to write LHpi sitescript file.
    The formating must still be done but I don't have the time for now (I quickly added the page during a travel with internet access ;-)).

    Could you please read it and given me your feedbacks ?
    Some point must be developped in order to get full information. I described some property/function how I think it should work, but as I actually don't use all of them, I cannot verify it.

    Anthony.
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Re: Price Manager issues

    Postby LordHelmchen » 23 Feb 2014, 01:28

    anthonybe wrote:Hi Lord,

    I added a wiki page explaining how to write LHpi sitescript file.
    The formating must still be done but I don't have the time for now (I quickly added the page during a travel with internet access ;-)).

    Could you please read it and given me your feedbacks ?
    Some point must be developped in order to get full information. I described some property/function how I think it should work, but as I actually don't use all of them, I cannot verify it.

    Anthony.
    Thanks for helping out with the documentation. Please be assured that any critique that follows is not meant to diminish your work.
    On first sight, I feel like there's a lot of information that is duplicated between the howto and the template, and I wonder if that is necessary. I think it's safe to assume that a sitescript developer would look at the template for examples and function definitions.

    But then, I can't know how it looks to someone who did not write the library, so it is probably better if I don't interfere much with deciding what should be in the howto, and restrict myself to make sure the template comments are correct. Those can then be copied over to the howto and expanded according to actual user's needs.
    My role in writing the howto should therefore probably be to fill in blanks, correct mistakes and answer questions. Please do point out anything that you're unsure about, so I can verify it.

    As for the howto's structure, I will wait a few revisions before changing anything major. Like with the content, it's probably better to see a user's perspective instead of me copying the template's stucture into the howto.
    I would propose to seperate general information and hints, properties (like site.regex), functions (like site.BuildUrl) and options (like VERBOSE). Within theese categories, the entries could be ordered by appearance in the script or in some order that seems useful to follow when starting to write your own script.

    Should the paragraphs from the Hints for developers section stay seperate or be moved over to the howto?

    Shall I add information about the return values that LHpi expects from the sitescript functions, or are the template comments enough for this?
    LordHelmchen
     
    Posts: 125
    Joined: 21 Aug 2012, 16:06
    Has thanked: 21 times
    Been thanked: 32 times

    Re: Price Manager issues

    Postby anthonybe » 24 Feb 2014, 05:52

    LordHelmchen wrote:On first sight, I feel like there's a lot of information that is duplicated between the howto and the template, and I wonder if that is necessary. I think it's safe to assume that a sitescript developer would look at the template for examples and function definitions.

    But then, I can't know how it looks to someone who did not write the library, so it is probably better if I don't interfere much with deciding what should be in the howto, and restrict myself to make sure the template comments are correct. Those can then be copied over to the howto and expanded according to actual user's needs.
    My role in writing the howto should therefore probably be to fill in blanks, correct mistakes and answer questions.
    You're right about template/how-to duplicate. I started the How-to based on what I found in the template and completed with some information from my experience.
    From my opinion, the template file should contain the minimal information about properties/functions and their usages (e.g. examples), and the How-to should be a reference where developers can find/share more completed examples (e.g. different scenarios like the foil/regular prices on same page).

    LordHelmchen wrote:Please do point out anything that you're unsure about, so I can verify it.
    You can find some "TODO" in the how-to for points that i'm not sure about it or I didn't know how to describe in the good way :-)

    LordHelmchen wrote:As for the howto's structure, I will wait a few revisions before changing anything major. Like with the content, it's probably better to see a user's perspective instead of me copying the template's stucture into the howto.
    I would propose to seperate general information and hints, properties (like site.regex), functions (like site.BuildUrl) and options (like VERBOSE). Within theese categories, the entries could be ordered by appearance in the script or in some order that seems useful to follow when starting to write your own script.
    For the structure, I tried to make it like a wizard where each required properties are coming first and afterwards optional properties and LHpi properties. At the end, the functions to define.
    In my case, I "reformatted" your sitescript template in that order.

    If the how-tov and template file have the same structure, developpers can read the how-to and complete their sitescript at the same time. They know what the property/function does and how-to fill it.

    LordHelmchen wrote:Should the paragraphs from the Hints for developers section stay seperate or be moved over to the howto?
    The hint are welcome in the how-to, in the appropriate section.
    "multiple copies of the same script" could be added in the "(semi-optional) Name of sitescript".
    "procedure of funtions call" could be added in separate section (e.g. annexes ?).
    "Dropping card" could be added to the appropriate function definition (ParseHtmlDate, BuildCardData, ...) depending the usage developpers do.
    "non trivial tables" could be added as a general tips in the properties introduction.


    LordHelmchen wrote:Shall I add information about the return values that LHpi expects from the sitescript functions, or are the template comments enough for this?
    You're welcome to add these infos in the how-to.

    -----------------------
    Apart of the wiki page, I have another question about LHpi.

    1. Library updade

      I started my sitescript with version 2.6.1 of the template and libver 2.6. Afterwards, you proposed libver 2.7 with sitescript 2.7.1.
      How developers should do in order to "upgrade" their sitescript to the latest version of the library and template ?
      Do they need to edit the new sitescript template version and copy/paste their properties/function in there ?
      Or is it another way to "merge" their existing sitescript with new properties/functions of the latest template ? For example, the latest version of the template could give a list of new properties/functions added or dropped ?

    2. Different url infix for same set

      In the last days, the Belgian website did an important update, causing the failure of the my sitescipt.
      Now, the foil and regular prices are not on the same page anymore :-) but splitted in two distinct pages.
      The difference between both is the ID of the collection in the url. So, 1 set --> 2 ids (foil, regular).

      I'm thinking to solve the situation by defining 'url' property of 'site.sets' as a table where the index is the FRUC_ID and value the website's ID.
      Something like:

      Code: Select all
      [800]={id = 800, lang = { true, [4]=true}, fruc = {true, true }, url = { "<foil collection id>", "regular collection id"}, -- Theros
      if site.frucs is defined like this:

      Code: Select all
      site.frucs = { "foil", "regular" }
      Afterward, in the site.buildUrl function, I would retrieve the id infix with:

      Code: Select all
      site.sets[setid].url[frucid]
      Do you think it's the correct way ? Or you see another one ?
      (Still a good example to add in the how-to ;-))

    Anthony.
    anthonybe
     
    Posts: 19
    Joined: 07 Nov 2013, 21:51
    Has thanked: 0 time
    Been thanked: 2 times

    Next

    Return to Magic Album

    Who is online

    Users browsing this forum: No registered users and 3 guests


    Who is online

    In total there are 3 users online :: 0 registered, 0 hidden and 3 guests (based on users active over the past 10 minutes)
    Most users ever online was 1371 on 09 Feb 2020, 16:22

    Users browsing this forum: No registered users and 3 guests

    Login Form