Price Manager issues
by Goblin Hero
Moderators: charmer, CCGHQ Admins
Price Manager issues
by 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:
Anthony.
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.
Re: Price Manager issues
by LordHelmchen » 08 Feb 2014, 09:14
I have the same problem. It seem that the progressbar lables do not display in Windows 7, but work in Windows XP...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 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.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".
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.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.
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
by 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.
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.
Re: Price Manager issues
by LordHelmchen » 09 Feb 2014, 12:03
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 himanthonybe wrote:Concerning the progress bar, is Goblin Hero aware of the problem ? Does he looking for a solution ?
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 suggestionsConcerning 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.
- LordHelmchen
- Posts: 125
- Joined: 21 Aug 2012, 16:06
- Has thanked: 21 times
- Been thanked: 32 times
Re: Price Manager issues
by anthonybe » 09 Feb 2014, 12:50
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), ...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
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.
Re: Price Manager issues
by LordHelmchen » 09 Feb 2014, 17:36
I'll try to give all information you need/want. We might be able to evolve this into a real documentation lateranthonybe 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), ...
- 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
dropping cards:Also, how you can interact with LHpi library from the sitescript. Example with dropped card.
- 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.
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 libraryI 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.
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).
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 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.
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
by Goblin Hero » 10 Feb 2014, 06:19
I'll fix it in the next update.LordHelmchen wrote: If it seems important to you, you could file a bug in the tracker to remind him
When you´re a goblin, you don´t have to step forward to be a hero -- everyone else just has to step back.
-
Goblin Hero - Site Admin
- Posts: 1992
- Joined: 23 Oct 2005, 09:37
- Location: Russia
- Has thanked: 218 times
- Been thanked: 351 times
Re: Price Manager issues
by anthonybe » 10 Feb 2014, 10:44
Thanks. A section on the wiki page would be greatLordHelmchen wrote:I'll try to give all information you need/want. We might be able to evolve this into a real documentation later
This kind of information would also be welcome on the wiki page.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.
The impact of setting a specific property in a specific method would be great.
In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.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.
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"
In my case, we are in the scenario "*CARDNAME*PRICE*FOILSTATUS". So, I'm able to set card.foil in parseHtmlDate function.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.
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
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.
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.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).
However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.
All scenarios cannot be defined in advance, especially with internetLordHelmchen 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
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.
Re: Price Manager issues
by LordHelmchen » 11 Feb 2014, 12:02
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)anthonybe wrote:Thanks. A section on the wiki page would be greatLordHelmchen wrote:I'll try to give all information you need/want. We might be able to evolve this into a real documentation later
wikified itThis kind of information would also be welcome on the wiki page.LordHelmchen wrote:dropping cards:
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?The impact of setting a specific property in a specific method would be great.
That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.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.
added to planned features.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"
Will check BuildCardDate and probably change all instances ofIn 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.
- Code: Select all
if sourcerow.FIELD then
- Code: Select all
if sourcerow.FIELD~=nil then
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 safeFor 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.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).
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.However, the card.price property must be set (but not used later) because it is used in GetSourceDate just after parseHtmlData.
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.LordHelmchen wrote:When they work again, I will release 2.6 and concentrate on including your needs
I was aiming at the scripts being easily updateable, but this is even more ambitiousA 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.
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
by LordHelmchen » 12 Feb 2014, 09:18
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:LordHelmchen wrote:That is more or less how LHpi.tcgplayerPriceGuide works right now, so I'm glad you found this to be working for you.anthonybe wrote:In my case, I just defined one fruc: "Foild_And_Regular", which is working good, except one thing but I will explain later.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.
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
by 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
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
Re: Price Manager issues
by 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
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
by 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.
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.
Re: Price Manager issues
by LordHelmchen » 23 Feb 2014, 01:28
Thanks for helping out with the documentation. Please be assured that any critique that follows is not meant to diminish your work.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.
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
by anthonybe » 24 Feb 2014, 05:52
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.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.
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).
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 wayLordHelmchen wrote:Please do point out anything that you're unsure about, so I can verify it.
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.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.
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.
The hint are welcome in the how-to, in the appropriate section.LordHelmchen wrote:Should the paragraphs from the Hints for developers section stay seperate or be moved over to the howto?
"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.
You're welcome to add these infos in the how-to.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?
-----------------------
Apart of the wiki page, I have another question about LHpi.
- 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 ? - 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
- Code: Select all
site.frucs = { "foil", "regular" }
- Code: Select all
site.sets[setid].url[frucid]
(Still a good example to add in the how-to )
Anthony.
22 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 11 guests