Clarification on a few parts of the scripting engine.

edited August 2012 in New Engines/Platforms
Ok, well i think i was one of the first people to nag for a scripting guide, then it appears and i got bogged down in ironing out niggles with existing platforms, so its about time i started to contribute some platforms!

1st though i have a few questions i would like to ask to help me better understand the scripting engine.

1. What variables must go in certain sections.
Looking through varies ini files, some have these variables in the [setup] section:

submit success
submit failed
verify submission
verify by
Etc etc

Whereas others have them 1st appear in the register step. Is this important, or can they be defined any point up to and including the actual [step*] they are needed in? This goes for other variables as well.

To further illustrate my question, lets look at the new moodle.ini, because i have it open (and not because i am being in any way critical of it)
[REGISTER_STEP1]

This contains 'find link' (and its other methods to do the same)
Then 'just download' is set.

This means to find the url and download the page, then move to next step (according to the pdf).
Then however there are submit success/fail settings and a bunch of form filling variables in the same step - why are they here and not in the step that actually uses them? Is it just personal preference?

[REGISTER_STEP2]

This finds a form that doesnt take user input, and submits it.
It does however have a 'page must have' variable in this step as well - what is its purpose? Does it check the page before or after the submit? If after, it is actually checking the next page correct?

Also, there are no submit success/failed variables set here, so i guess a form can be submitted without checking for submit/failure?

[REGISTER_STEP3]

This finds a form on the next page (which suggests that GSA automatically loads the next page after a submit).
This appears to fill the form using the form filling variables from register step 1.
There are also no success/failed variables set here either, but it looks like it is using those ones set in register step one.

This particularly confused me - if it reads the last set variables, how come register step 2 didnt use those, and then get stuck waiting for an email that never came???
Maybe because this was the only time  [your email] variable was used?

I hope that all makes sense. I have been maping out some platforms in sudo code, but i still need to understand the scripting order/logic a little better before diving in.

Thanks for any help

Comments

  • SvenSven www.GSA-Online.de

    >1. What variables must go in certain sections.

    You can put all into the SETUP section when you have an engine without any registration, else you should place it in the 1st section (e.g. STEP1, REGISTER_STEP1, LOGIN_STEP1...).


    >[REGISTER_STEP1] - Moodle

    Normally you would put the form filling variables in the correct sectio. In this case you would put them into REGISTER_STEP2 as thats the first form that should be filled. However you can put all of them also in the first section for every *STEP? as the program will look at the first step if it can not find it there. Why did I put it there now you might ask? Well because some engines have a Confirmation form first and than the one filling the registration data. So I would have to define the same thing in STEP1 and STEP2 to cover both variants. This skips it if you put all in STEP1.

    >[REGISTER_STEP2]

    This "page must have" checks if this appears on the page. On this engine you have a lot sites that don't allow a sign up. So the string would not be present than. If it is not we skip the whole site.

    >[REGISTER_STEP3]

    Correct. It is filling the form, submits it and is always checking for success or failed submission from the variables defined in STEP1 and stops if success or failed is detected. So you just define the "submission success/failed" variables in SETUP or better in the *STEP1 section.

  • OzzOzz
    edited August 2012
    > Whereas others have them 1st appear in the register step. Is this important, or can they be defined any point up to and including the actual [step*] they are needed in? This goes for other variables as well.

    This is something I've problems to understand, too. AFAIK if these variable "verify by=" appear in a [Register Step] than they are mostly used for extracting passwords from emails or to confirm registration by email ("verify by=email") .

    The variable "verify by=url" for instance is used often times in the [Log In Step] of a script to verify if your url has been posted to the engine or not (submission success= / submission failed=).

    Then however there are submit success/fail settings and a bunch of form filling variables in the same step - why are they here and not in the step that actually uses them?

    I don't know exactly but I think that this moodle engines uses different registration types.
    [Register Step 1] is the most common one and if it finds the registration form it will begin to fill it out accordingly. This page has both a login-form and a registration-form as well.
    [Register Step 2] has to be used if the registration form can't be found at Step1. Once it find this link/form it will be used with the variables of RegisterStep1.
    [Register Step 2] is the same as Step2. 

    Edit: As you can see by Sven's answer I'm a total noob too :D
  • edited August 2012
    Great, thanks a lot for both your answers, that helps quite a bit.

    I am still a little off though, perhaps i am thinking this sequence is more linear than it really is.

    For example,  referencing moodle again for clarity, in 
    [register_step2]
    the 'page must have' variable is defined after the form submit instructions, yet it is performed before the form is submitted, so the actual order of variables within a step does not matter?

    It is filling the form, submits it and is always checking for success or failed submission from the variables defined in STEP1 and stops if success or failed is detected. So you just define the "submission success/failed" variables in SETUP or better in the *STEP1 section.

    Ok, so if i have got this correct, if this engine encounters a site WITH a confirmation form 1st, this is filled in at [register_step 2], (At this point, it still checks for the submit success and failed strings defined in step one, but finds neither so moves on?) then the register form is filled at 
    [register_step 3].  

    The other possibility im less sure of - If it encounters a site WITHOUT a confirmation form, either:

    A) 
    [register_step 2]  is skipped and 
    [register_step 3]  fills out the registration form]

    In which case how does in know that its ok to skip a step, rather than skip the whole site? i thought 'optional form=1' needed to be present for jt to skip?

    OR (the more likely option)

    B) 
    [register_step 2]  is able to submit the registration form, and 
    [register_step 3]  is then not required.

    I think this is how it is doing it, and can see how this could work, (although the form name and id defined in 
    [register_step 2]  will not match, the form url will.)

    However, how does it then know to skip [register_step 3] ? I presume its because the submit success/fail strings will be found. 
    What about the 'variable must be used' part of [register_step 3], if this step is skipped, does that still get read, and applied to step 2?

    Lastly, how does it know at what point to check for emails? I presume it only checks at the end of the registration steps?

    Its just a bit hard for me to comprehend, as i am used to scripts that have if/else parts to them, eg IF found 'form 1', GOTO step 2, ELSE goto step 3.

    Sorry for the numerous questions, once this all clicks into place in my head, i promise to add some decent platforms!

  • SvenSven www.GSA-Online.de

    >..so the actual order of variables within a step does not matter?

    I try to put it in the same order for better reading but it doesn'T matter. The "page must have" is checked after the "find link, find url" and "modufy url".

    And yes after each step it checks for success / failed messages and stops it one of them matches, else it goes to the next step section or if there is further it stops as well with "unknown submission status" and than taggs it as failed or success if you have "verify on unknown status=1" in the first section.

    >Lastly, how does it know at what point to check for emails?

    After a successful submission the program reads the *STEP1 section how to verify things. If it should verify it, it will put the url to a queue and check when a verification round is happening.

Sign In or Register to comment.