A little related commentary

Is ZXappz::Logger that uses log4perl and ZXappz::Database will load DBI

:) That is one of those weird things that don't quite make sense

log4perl and DBI both provide good APIs that they don't need generic wrappers

Now if you're talking a static "Config" module or a "Model" module, that makes sense, but not a generic logger/database, log4per/DBI are already that generic module, just configure them and you're done

Yeah, sometimes it makes sense to have a generic logger/database module as part of your API, but I'd say most of the time it doesn't :) its weird :D

Ok, stated my limited experience, i just only to say that probably you need ZXappz::Database anyway because it can contains for example store_new_user and store_action_for_user and so on. So in the main code you can just:

my $appdb = ZXappz::Database->new();

$appdb->store_new_user($previously_generated_name,time); # uses DBI to
+ insert into a table

..

$appdb->close # call the DBI's close but maybe also log somewhere the 
+succesfull operation
[download]

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

ZXappz::Database anyway because it can contains for example store_new_user and store_action_for_user and so on...

:) That is good thinking, separate the stuff, groupt the database stuff together

but the name should be different from "database" because that is kind of stuff that goes in your "model",

so you might have a ZXappz::UserGroup (or ZXappz::Model::UserGroup) with a add_user and ...

yes it goes in a database, maybe one created from ZXappz::Schema::UserGroup ...

but you call it something important to your app, symbolic not generic

Its like when you first learn programming, no subroutines, just long stretches of code, you have to start somewhere

then the next evolution, you start using subroutines, but its still one file, and they're very long and do too much, and the names are focused on the implementation details

then you start making packages, which is great, but you're organizing principle is not the intent of the code but implementation detail;

Is this terrible? No. Its common, its workable, its maintainable, esp for short programs, but could be improved; and should be improved , esp if you want to reuse the code, and for others to use your code , and enjoy it (collaboration )

There is no reason to take the long way around, jump straight to intent :) organize stuff with big picture in mind, like a house, you have to frame it, but you don't design around the frame, around stud, you design around rooms with purpose, by walking around the house in your head, wake up in the morning, get ready for work, host a party...

start with a story board, how should the user use the application, what should it do

then start with use cases, how should the code be used by the programmer, write that code, and your api will emerge

The following is not the proper way to modularize your code, but because you are just 'one yard before the finish line' you could use a script or Makefile to concatenate multiple files to a single program. That is easier and less error prone then the temporary "manually cut and paste" solution, that you are considering.

Assuming you have the following files:

-rw-r--r--  1 hadri  hadri   51 Feb 12 04:24 main_barack
-rw-r--r--  1 hadri  hadri   63 Feb 12 04:15 my-serial-library.src
-rw-r--r--  1 hadri  hadri   68 Feb 12 04:27 postlude_general.src
[download]

Your general libary routines are in my-serial-library.src and postlude_general.src. The 'main' program is the only customized part and is named after your client or location: main_barack.

With a simple Makefile you can generate your program serial_com_barak.pl:

$ make
cat my-serial-library.src main_barack postlude_general.src > serial_co
+mm_barack.pl
[download]

For another customer you create a new customized main and run 'make' again:

$ echo "This is for Bernie" > main_bernie

$ make CLIENT=bernie
cat my-serial-library.src main_bernie postlude_general.src > serial_co
+mm_bernie.pl
[download]

The Makefile:

 # -- sample Makefile
CLIENT          =       barack

NAME            =       serial_comm
PROG_NAME       =       ${NAME}_${CLIENT}.pl

PRELUDE         =       my-serial-library.src
MAIN            =       main_${CLIENT}
POSTLUDE        =       postlude_general.src

TAR_NAME        =       serial-comm_${CLIENT}.tgz
TAR_FILES       =       Makefile
TAR_FILES       +=      ${PRELUDE} ${MAIN} ${POSTLUDE}

${PROG_NAME}: ${PRELUDE} ${MAIN} ${POSTLUDE}  
        cat ${PRELUDE} ${MAIN} ${POSTLUDE} > ${PROG_NAME}

clean:
        rm -rf ${PROG_NAME}

archive:        
        tar cvzf ${TAR_NAME} ${TAR_FILES} 

# --- end of Makefile
[download]

Note: Make sure that you have a tab character (\x09, CNTRL-I or ^I) before the cat and other commands in the Makefile.Verify with 'cat -t Makefile':

${PROG_NAME}: ${PRELUDE} ${MAIN} ${POSTLUDE}  
^Icat ${PRELUDE} ${MAIN} ${POSTLUDE} > ${PROG_NAME}
[download]

Ah yes thanks. That will get me going for now. I'll spend some time studying the info and links provided in the replies. Thanks everyone for the help.

I understand that if the whole program was destined to be a 1 million line ERP system, the it would be worth re-organizing and rewriting everything to fit into modules. However I'm aiming at just splitting things into "two" files, and I'm 1 yard from the finish line. So cut/paste into 10 scripts may be the way to go.

No, copy/paste isn't the answer, thats like first week of intro to programming :)

modules are the answer, modules that are accompanied with tests, your code should live in modules :)

Maybe

Read more... (593 Bytes)

Something like that, draw a few outlines like that on a piece of paper, putting different stuff in different places, see what makes more sense

You can see all kinds of examples on cpan, see App::

https://metacpan.org/release/Module-Starter

tracker/App::TimeTracker

booklist/App::Booklist