Re: Getting a specific page using WWW::Mechanize [SOLVED]

[SSC_perl]

I found my error.  I ended up using $mech->save_content(‘result.html’) 
at the end of my script and, lo and behold, it produced the confirm.htm page 
with an error.  I had forgotten to add the cardholder’s name field to the final 
form submission, so of course, SurfShop was returning the same page and asking 
for it to be filled in.  Talk about embarrassing. :\  Oh, well, everything is 
working fine now and I have a super little script to place test orders 
automatically.  It’s turned out to be a great tool for solving problems.  
Before this, I was manually placing test orders, filling in every field by 
hand, which gets old real fast when you have to do it repeatedly.

If anyone is looking to automate tasks like this for testing or 
whatever else, I whole heartedly recommend WWW::Mechanize.  It’s a real time 
saver.

Thanks again to Chas for the reply.

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: Getting a specific page using WWW::Mechanize

[SSC_perl]

> On Apr 25, 2017, at 10:09 AM, Chas. Owens  wrote:
> 
> Are you using JavaScript to redirect the user to the sorry page?

Nope.  All navigation is handled by perl.  Thanks for the link, though.

Frank

Re: Getting a specific page using WWW::Mechanize

[Chas. Owens]

Are you using JavaScript to redirect the user to the sorry page?  If so
then WWW::Mechanise won't redirect.  It doesn't understand JavaScript.
Happily, there are drop in replacements for it that do:

http://search.cpan.org/~oalders/WWW-Mechanize-1.84/lib/WWW/Mechanize/FAQ.pod#Which_modules_work_like_Mechanize_and_have_JavaScript_support
?

On Tue, Apr 25, 2017 at 12:06 PM SSC_perl  wrote:

> Here’s more information on this situation.  SurfShop uses two main
> HTML templates, main.htm and secure.htm.  Then there are sub-templates that
> get loaded as the content of those two main templates.
>
> During checkout, secure.htm is used.  If the order is successful,
> receipt.htm is used as the sub-template, if not, then sorry.htm is shown
> with the error message.  This, of course, works as expected when placing an
> order by hand.
>
> When placing a successful order with WWW::Mechanize, receipt.htm
> is shown correctly in $mech->content().  However, if the order was
> declined, that’s when Mech returns the same page it was on when the
> ‘processTransaction’ button was clicked, which is confirm.htm.
>
> Up until this point, Mech performs just like when I manually place
> an order, so what could be causing it to get mixed up at the end?  I don’t
> think I'm doing anything special, but you never know.  Here’s a snippet of
> the code where the process fails:
>
>
> $mech->submit_form(
> form_name => 'ccForm',
> fields=> {
>   Ecom_Payment_Card_Type  => 'VISA',
>   Ecom_Payment_Card_Number=> ‘',
>   Ecom_Payment_Card_Verification  => '123',
>   Ecom_Payment_Card_ExpDate_Month => '05',
>   Ecom_Payment_Card_ExpDate_Year  => '2024',
>  },
> button=> 'processTransaction',
> );
>
> As you can see, it’s pretty standard stuff.
>
> Is there another method I can use besides $mech->content() to see
> what’s being returned?  The more tests I can do on this, the more it will
> help me find where I went wrong.
>
> Frank
> --
> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
> For additional commands, e-mail: beginners-h...@perl.org
> http://learn.perl.org/
>
>
>

Re: Getting a specific page using WWW::Mechanize

[SSC_perl]

Here’s more information on this situation.  SurfShop uses two main HTML 
templates, main.htm and secure.htm.  Then there are sub-templates that get 
loaded as the content of those two main templates.

During checkout, secure.htm is used.  If the order is successful, 
receipt.htm is used as the sub-template, if not, then sorry.htm is shown with 
the error message.  This, of course, works as expected when placing an order by 
hand.

When placing a successful order with WWW::Mechanize, receipt.htm is 
shown correctly in $mech->content().  However, if the order was declined, 
that’s when Mech returns the same page it was on when the ‘processTransaction’ 
button was clicked, which is confirm.htm.

Up until this point, Mech performs just like when I manually place an 
order, so what could be causing it to get mixed up at the end?  I don’t think 
I'm doing anything special, but you never know.  Here’s a snippet of the code 
where the process fails:


$mech->submit_form(
form_name => 'ccForm',
fields=> {
  Ecom_Payment_Card_Type  => 'VISA',
  Ecom_Payment_Card_Number=> ‘',
  Ecom_Payment_Card_Verification  => '123',
  Ecom_Payment_Card_ExpDate_Month => '05',
  Ecom_Payment_Card_ExpDate_Year  => '2024',
 },
button=> 'processTransaction',
);

As you can see, it’s pretty standard stuff.

Is there another method I can use besides $mech->content() to see 
what’s being returned?  The more tests I can do on this, the more it will help 
me find where I went wrong.

Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Re: are state objects ok?

[lee]

"Chas. Owens"  writes:

> State variables are just like my variables but with a different lifetime,
> so it is safe (assuming it would be safe to use my variables that life for
> the lifetime of the program).

Thanks!

What's a safe alternative?  If you need to have values remembered across
multiple calls of functions, you got to somehow store these values,
either in state variables, or otherwise in such a way that they are
inaccessible to other parts of the program.  The difference lies in the
ease, reliability and thus safety of retrieving the values, not in the
safety of the variables holding them.

The variables don't change their names across multiple calls of the
functions, and I would ask where the safety lies: In the names of the
variables, in the values you need them to remember or in the
accessability of their values?

> In this case, what happens if you lose database access and then
> reconnect?

When the connection goes away, the program is terminated, yielding an
error message?

I've had that happen in rare cases which weren't easy to fix because the
cause was hard to find.  It would just say that the mysql server has
gone away, for no apparent reason.

So the program does not reconnect --- or does it, without my knowledge
and without being terminated?

If it reconnects, is there a difference between creating statement
handles outside of functions using them and passing them as arguments
and creating statement handles within the functions using them, storing
them in state variables?

> What happens if you have two database handles?

That is awkward ;)

> Your statement handles are going to be bad or refer to the wrong
> DB.

not when I pass the right database handle to the function creating a
statement handle

> What you really want here is the $dbh->prepare_cached method call. It
> will correctly handle both scenarios and avoid reparsing the SQL.

Hmm.  That might work, and it would be better.


I haven't considered re-connecting at all.  That just hasn't come up yet
with what I've been doing with DBI so far.

How do you make a program re-connect, and in such a way that it is safe
to try that?  Like I wouldn't want it to try re-connecting indefinitely.

How do you even detect a disconnection and its reason?  Like I would
want to re-connect when the mysql server has disconnected the program
due to inactivity but not when it's disconnected due to an error in the
program.

And I need to figure that out for SNMP sessions, too.  Can they even get
disconnected?


> On Mon, Apr 24, 2017, 20:02 lee  wrote:
>
>> Hi,
>>
>> is it ok to assign an object to a state variable?  Or does doing so
>> involve a chance of causing problems because objects are not supposed or
>> designed to be used with the state-feature?
>>
>> Example:
>>
>>
>> use feature qw(state);
>> use DBI;
>>
>>
>> sub foo {
>>   my ($dbh, $q, $finish) = @_;
>>
>>   state $sth = $dbh->prepare("SELECT foo FROM bar WHERE baz = ? LIMIT 1");
>>   if($finish) {
>> $sth->finish();
>> return 0;
>>   }
>>
>>   $sth->execute($q);
>>   my ($ret) = $dbh->selectrow_array($sth);
>>
>>   return $ret;
>> }
>>
>>
>> #
>> # do some stuff like connecting to database etc.
>> #
>>
>> foreach (1..10) {
>>   my $z = foo($dbh, $_, 0);
>>   #
>>   # do more stuff with $z
>>   #
>>   my $x = foo($dbh, $z, 0);
>>   #
>>   # ...
>>   #
>> }
>>
>> foo($dbh, 1);
>> exit 0;
>>
>>
>> I think it would be nicer to keep statement handles ($sth) contained within
>> the functions that use them instead of defining them in the main part and
>> handing them over to the functions.  Their very purpose is that you define
>> a handle once and use it multiple times, thus saving the overhead of
>> interpreting the statement every time it is used.
>>
>> But can I safely use a state-variable like this?  If not, then what?
>>
>>
>> --
>> "Didn't work" is an error.
>>
>> --
>> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
>> For additional commands, e-mail: beginners-h...@perl.org
>> http://learn.perl.org/
>>
>>
>>

-- 
"Didn't work" is an error.

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/

Getting a specific page using WWW::Mechanize

[SSC_perl]

I’ve written a script using WWW::Mechanize to place test orders in 
SurfShop.  I wish I had know it could do this before. :\  For some reason, I 
was under the impression that it was only good for scraping.  

The script works great, but I need to find a way to get the contents of 
the receipt page in the cart to test if a credit card order was accepted or 
denied.  Using $mech->content at the end of the script gives me the penultimate 
page - not the last one.

How can I get the contents of the final page of the checkout process?

Thanks,
Frank
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/