split a big program into main + (optional) advanced

[Freddie]

I have a hotel managerial software that I wrote in perl-tk that I
would split into 2

- the main part with all base functionalities
- the advanced (and optional) part with advanced functionalities
I'd like the main would import the advanced if present, in that case
the main would
offer all functionalities to the user otherwise just the base ones.

I tried to use the 'do' (and require, actually) without success. I'd
like to have the following working:

# main.pl
$mw->configure(-menu => my $menubar = $mw->Menu);
my $menuMain = $menubar->cascade(-label => '~Checkin', -tearoff
=> 0);
do 'advanced.pl';

# advanced.pl
my $menuAdv = $menubar->cascade(-label => '~Advanced Cash', -tearoff
=> 0);


Thanks and best regards,

Freddie

 

[ccc31807]

I have a hotel managerial software that I wrote in perl-tk that I
would split into 2

I'm not familiar with perl-tk, and (obviously) haven't seen your
software, so this might not track with what you are doing, but here's
my take on things.

If you're writing a front end to a database to be used as a
distributed application, I'd write it as a web app. Do everything on
the server side, and your clients need have nothing other than a
browser.

When you write a big app, break it into modules. That way, you can
modularize your SQL, your HTML, and so on. Your example shows an OO
style, and I don't do OO Perl, but something similar using a
functional interface would be like this, assuming an HTML.pm, a
BASIC.pm and an ADVANCED.pm:

#this is something that produces index.html, say, main.pl
use strict;
use warnings;
use CGI;
#print the http header
print "Content-type: text/html\n\n";
#create the page top
HTML::html_header();
#make a menu for the basic user
BASIC::make_menu();
#make a menu for the advanced user
ADVANCED::make_menu() if $user_license eq 'ADVANCED';
#create the page bottom
HTML::html_footer();
exit(0);

Since you are calling the fully qualified name including the package,
there isn't any need to use, require, or do anything.

CC

 

[Jim Gibson]

I'm not familiar with perl-tk, and (obviously) haven't seen your
software, so this might not track with what you are doing, but here's
my take on things.

If you're writing a front end to a database to be used as a
distributed application, I'd write it as a web app. Do everything on
the server side, and your clients need have nothing other than a
browser.

When you write a big app, break it into modules. That way, you can
modularize your SQL, your HTML, and so on. Your example shows an OO
style, and I don't do OO Perl, but something similar using a
functional interface would be like this, assuming an HTML.pm, a
BASIC.pm and an ADVANCED.pm:

#this is something that produces index.html, say, main.pl
use strict;
use warnings;
use CGI;
#print the http header
print "Content-type: text/html\n\n";
#create the page top
HTML::html_header();
#make a menu for the basic user
BASIC::make_menu();
#make a menu for the advanced user
ADVANCED::make_menu() if $user_license eq 'ADVANCED';
#create the page bottom
HTML::html_footer();
exit(0);

Since you are calling the fully qualified name including the package,
there isn't any need to use, require, or do anything.

How will the Perl compiler know to include the source files HTML.pm,
etc., if you do not have a use, require, or do statement referring to
those files in your program?


% perl ccc.pl
Content-type: text/html

Undefined subroutine &HTML::html_header called at ccc.pl line 7.

 

[ccc31807]

How will the Perl compiler know to include the source files HTML.pm,
etc., if you do not have a use, require, or do statement referring to
those files in your program?

You are using the full name of the package plus the subroutine.

% perl ccc.pl
Content-type: text/html

Undefined subroutine &HTML::html_header called at ccc.pl line 7.

That's because you need to have a "package HTML;" in a file named
"HTML.pm" same as any other Perl module, and have a subroutine named
html_header in that package.

CC

 

[Freddie]

------------file:hotel-main------------

#!/usr/bin/perl
package Hotel::Main;
use strict;
use warnings;
use Tk;

my $mw = MainWindow->new;
$mw->configure(-menu => our $menubar = $mw->Menu);
our $menuMain = $menubar->cascade(-label => '~Checkin', -tearoff => 0);
do 'hotel-advanced' if -x 'hotel-advanced';
MainLoop;

-----------file:hotel-advanced----------------
package Hotel::Advanced;
use strict;
use warnings;
print "Hello there\n";
our $menuAdv = $Hotel::Main::menubar->cascade(-label => '~Advanced
Cash', -tearoff => 0);

------------cut-----------------

Thanks Mumia, that's exactly what I needed.

Best regards,

Freddie

 

[Freddie]

On Sep 9, 11:49 am, Freddie <[email protected]> wrote:

When you write a big app, break it into modules. That way, you can
modularize your SQL, your HTML, and so on. Your example shows an OO
style, and I don't do OO Perl, but something similar using a
functional interface would be like this, assuming an HTML.pm, a
BASIC.pm and an ADVANCED.pm:

hello,

my software was born as an experiment end grew up to 30k+ lines in a
few time and used in production as is. I'm not a software professional
and I know it needs a lot of rework; I'd like to port it to wxperl or
(better?) wxpython, modularize etc. Thanks for your hints.

Best regards,

Freddie

 

[ccc31807]

Did you try actually running your code?

Hell, yes! Okay, maybe I omitted small details like the environment,
as CGI scripts with mod_perl, but that doesn't obscure the point that
you can access subroutines defined in modules by using the module name
followed by the double colon followed by the subroutine name.

CC

 

[ccc31807]

That is not enough. You must also require, use, or otherwise load the
file containing the definition of that sub, or arrange for it to be
autoloaded. Perl doesn't go looking for an HTML.pm just because you used
something in package HTML (unless you ask it to).

Yes, all of that is true, but I didn't address that. The only thing I
addressed was the issue of the OP (he didn't actually ask the
question) of how to modularize a program. A program running in a
mod_perl environment with Apache (like a web app) isn't going to run
the same as a stand alone Perl script.

CC

 

[ccc31807]

Is "your code" that you claim to have run the same as "your code"
that you posted in this thread?

No. What I posted was an off-the-cuff abbreviation of working code.

I tried the posted code, and it does NOT run...

Of course it doesn't, at least not as posted. Please don't make me go
to the trouble of posting actual code that works -- for one thing my
employer would probably fire me if I did.

You cannot access subroutines defined in modules by using the module
name followed by the double colon followed by the subroutine name unless
you have first arranged for that subroutine's body to be compiled (most
often done with "use").

I spend a lot of time writing webified front ends for databases. I
have a library that I use which consists primarily of HTML and SQL
code. I call the subroutines defined in these modules when I do a new
interface. I really don't know how it works, all I know is that it
just works.

I'm not trying to be difficult or hard to get along with -- and if it
didn't work I'd certainly be the first to say so.

CC

 

[ccc31807]

Okay, I have an apology to make. You are absolutely correct, and I am
in error. I just went through my code to figure out how it works, and
I see that what you said is true.

What happens is that I have a Perl script with my dispatch logic, and
it calls (using 'use') what a C coder would view as included .h files,
that is, top level modules, which in turn call other modules where I
place my frequently used functionality (e.g., printing the pretty
date) and those in turn call the HTML and SQL modules.

I never think about calling the low level modules, it just happens and
relieves me of the work. It's funny how quickly you forget after you
make tools that abstract a lot of the heavy lifting.

Please accept my apology, CC.