in reply to Re^24: global var
in thread global var

Exactly

module_1 initializes $A to 100. script_1 changes #A to 300 and prints it. script_2 loads module_1 and prints $A as 100, the value initialized in module_1.

This is my exact problem.

Replies are listed 'Best First'.
Re^26: global var
by hippo (Archbishop) on Apr 24, 2017 at 11:24 UTC

      Yes

      User logs on and id is stored to be used later in program/other modules to perform specific actions based on users id.

        @EXPORT = qw( $LoggedOn_user_id $VERSION = '0.0.1'; }
        why u troll?
Re^26: global var
by poj (Abbot) on Apr 24, 2017 at 17:40 UTC
    This is my exact problem.

    Going back to your post Re^15: global var I think I now understand. You are accessing $manageusers::LoggedOn_user_id from a different script (update_table.cgi ?) from the one that set the value which was presumably manage_users.cgi. As you found that doesn't work.

    One solution would be retrieve it directly from the CGI::Session object.

    my $dbh = manageusers::OpenConnection(); warn("update_tables.cgi after open connection"); # Dispatch to proper action based on user selection my $count = 0; my $query = new CGI; my $cgiURL = CGI::url(); my $action = lc ($query->param('action')); ## changes ## # my $userid_1 = 0; my $session = CGI::Session->load( "driver:MySQL", $query, { Handle => $dbh } ); my $userid_1 = $session->param("user_id");
    poj

      That would be going in a circle.

      User with 7 day cookie set goes to log on. Cookie recovered, session checked against session database to verify user. User_id recovered from session and stored in LoggedOn_uder_id to be accessed in update_tables.cgi to access other data from database which uses the id as key

      Recovering the id from session in the other modules would just be redundant

      I have never had such a problem in other languages

      I will check out using "storable" as soon as localhosting resolved issue. Error says it is not installed on their system but list of installed modules says it is.

        I have never had such a problem in other languages

        For some reason i doubt that. If you call a c program that starts another program via a system call do you expect the second program to have access to the variables of the first program. when you say

        MyIFrame.src = "https://www.jala-mi.org/httpsdocs/cgi-bin/update_table +s.cgi?action=" + MySource;
        you are starting a whole new perl instance, with the script called update_tables.cgi. All the data associated with the perl instance that sent http://www.jala-mi.org/httpsdocs/jala_AdminCore.htm to the browser has been lost if not stored somewhere else like a sessions table because that instance ended when it sent that page to your browser. This is true in c or python as well as you would know if you were a c or python programmer. This is simple cgi programming protocol.

        So like any other cgi program update_tables.cgi needs to check its cookies and load its session object to find out data associated with the users session.

        User with 7 day cookie set goes to log on. Cookie recovered, session checked against session database to verify user. User_id recovered from session and stored in LoggedOn_uder_id , then forgotten when jala_AdminCore.htm is sent to the browser and that perl program terminates so it can no longer to be accessed in update_tables.cgi to access other data from database which uses the id as key unless update_tables.cgi checks its cookies and loads the proper session object to get the user id from it

        Recovering the id from session in the other modules would just be redundant

        No it isnt redundant, since that is the only place the new perl instance can access the stored user level data.

        Have you considered calling manageusers::ProcessLogonRequest($query) in update_tables.cgi? That would then process the cookie, lookup the session and set the userid. all you have shown us is that you call manageusers::OpenConnection() and that doesnt do anything with cookies or sessions

        Recovering the id from session in the other modules would just be redundant

        If you add a subroutine into manageusers.pm like this

        sub getLoggedOn_user_id { my ($dbh,$query) = @_; my $session = CGI::Session->load( "driver:MySQL", $query, { Handle => $dbh } ); return $session->param("user_id"); }

        then only change in your script is from

        $userid_1 = $manageusers::LoggedOn_user_id;

        to

        $userid_1 = manageusers::getLoggedOn_user_id($dbh,$q);

        One less 'global' to worry about


        poj