Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Learning what CLASSPATH is about
Message
 
À
02/12/2003 10:25:07
Information générale
Forum:
Java
Catégorie:
Bases de données
Divers
Thread ID:
00853953
Message ID:
00855291
Vues:
43
Yes - perl is very portable. Since that particular app was written for Windows, you
would need to make some modifications. If I remember, windows version uses a .dll to
send email, while Linux and Unix would use the traditional sendmail methods.

I may have both email methods included, but the Linux/unix way commented out, so you
would need to reverse this for Free BSD/Linux/Unix.

You would need to determine what perl DBI driver would be best for your database server.
In many instances perl provides more that one DBI driver like ODBC Win32ODBC and dbase,
etc. You would need to have the DBI module you want to use installed and make
corresponding adjustment to the perl connection string syntax.

Perl is very popular and has been ported to about every OS. There is almost no
difference in perl regardless of the OS.

Perl in this respect is like other languages such as c, c#, java, python, etc. You can
move between OS/s using any of these, but what you will miss is the foundation classes.

For example, once you start using the .NET foundation classes your locked into windows.
You can take your C# skills to another platform, but your code would likely still be
locked into windows, because of its dependency on the classes from which all your
objects are derived. Imagine VFP without its classes and you will begin to get the
idea.



In perl you develop your own classes or you can use any of the many modules available
from CPAN. I'm in the process of developing a class library for my shopping cart app.
I can create an object in a script like:


Find the class and create a name space in memory where all the Smglobal class
properties, events, and methods exist.
use Smglobal;
Get the memory reference to the namespace and store it in $globalobj.
$globalobj->Smglobal->new();
Create a SQL to grab some records:
$theselect="SELECT * FROM mytable WHERE clientno=123";
Call the dbconn() method in Smglobal that connects to the smvfp database and return reference to the connection handle to $dbh
$dbh = $globalobj->dbconn();

Find the class and create a name space in memory where all the Smglobal class 
properties, events, and methods exist. 

<pre>
use Smglobal;
Get the memory reference to the namespace and store it in $globalobj.
$globalobj->Smglobal->new();
Create a SQL to grab some records:
$theselect="SELECT * FROM mytable WHERE clientno=123";
Call the dbconn() method in Smglobal that connects to the smvfp database and return
reference to the connection handle to $dbh
$dbh = $globalobj->dbconn();
Call the sql_exec() method in Smglobal class and pass it the SQL to execute.
$sth = $globalobj->sql_exec($theselect);
In perl you might have a base class names Person that inherits code from a sub-class
named Fullname, so I could grab Jim's nickname like:
$the_nickname = $obj->Person->Fullname->nickname(jim)
print $the_nickname
JimBo
In VFP this might look like:
the_nickname = myObj.Person.Fullname.nickname.value
print the_nickname
JimBo
When I'm done creating my library class all connections, SQL executes, error messages,
window colors, etc will be handled by calling methods in the library class.

Are we having fun yet? <bg>

Regards,

LelandJ
Leland F. Jackson, CPA
Software - Master (TM)
smvfp@mail.smvfp.com
Software Master TM
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform