SPUG: spug CPAN

[John Cokos]

What I've got so far is about a 80% implementation of it
but needs more hands in the pot to think of things that I've
forgotten or overlooked, and some TLC.  I started it
about 6 months ago, when I was first learning OOP, and
now with a higher skillset (and others to help out), it could
be trimmed down, and made more efficient.

John

========================================
  John Cokos, President / CEO: iWeb Inc.
  http://www.iwebsys.com
  jcokos at ccs.net
========================================

----- Original Message ----- 
From: "Christopher Cavnor" <chris at enthusiasm.com>
To: "John Cokos" <jcokos at ccs.net>
Cc: <spug-list at pm.org>
Sent: Wednesday, August 16, 2000 11:25 AM
Subject: Re: SPUG: spug CPAN


> I would tend to align with this project. I have written a small mod with an OO interface that
> allows acts as a DBI wrapper for the application that uses it. The interface is generified and
> allows overloading (so that you can call $db_wrap->select() and get all results, or call
> $db_wrap->select(\%query) - where %query is a hash of column = value so that the select statement
> becomes "select * from table where column = value").
> 
> The mod is limited, but could be used as a proof of bigger and better things.
> --
> Christopher Cavnor
> Software Design Engineer
> Enthusiasm.com
> 
> 
> John Cokos wrote:
> 
> > Apologies, my finger slipped and I sent the mail before I finished it...
> >
> > Just some thoughts on the CPAN module to be written ...
> >
> > We kicked around a few ideas last evening, but never really
> > came to a final resolution on what the actual project will
> > be.  Seems like there were a lot of application ideas presented,
> > but not many actual usable module ideas.
> >
> > So perhaps we could think of dividing our efforts into 2 parts
> > one: an appication, and two: a generic usable module.
> >
> > My personal preference is a module.  My proposal is one
> > that I mentioned to a few people at Rock Bottom after the meeting:
> >
> > a Wrapper for DBI.  I've gotten a good start on this, but it's
> > really a mess and needs TLC.  Anyone that's coded with DBD
> > can relate to it's shortcommings, and how much code it can take
> > to get simple things done.  The module I propose is a wrapper.
> >
> > Consider:
> > Current DBI Method:
> >
> >     return("Some error") if($input{somevalue} !~ /someregexp/);
> >     .... and so on for each field.
> >
> >     my $SQL = qq^
> >         UPDATE sometable SET
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >            somecolumn = '$input{somevalue}',
> >             ......
> >     ^;
> >     $sth = $dbh->prepare($SQL);
> >     $rc = $sth->execute;
> >
> >     if($DBI::errstr) { print "Failure .... \n"; }
> >     else { print "OK\n"; }
> >
> > Proposed Module Method:
> >     my ($statuscode, $message) = $sql->isql_update_table( table=>'sometable', values=>\%input );
> >     print $message if( ! $statuscode );
> >
> > Much less code, for the developer (especially considering that a typical SQL
> > aplication has many many different inserts and updates like that one throughout
> > the code), and a consistent back end that
> > would match the input to the table rows, do error checking, input validation,
> > etc.....and retun a meaningful error message.
> >
> > Routines like that could be / should be written to handle selects statements
> > that give you the data as you want it instead of only one of the 3 ways DBD
> > allows for now, insert statements that do the extensive validations that the update
> > routine does, schema management, etc.
> >
> > Thoughts?
> >
> > John
> > ========================================
> >   John Cokos, President / CEO: iWeb Inc.
> >   http://www.iwebsys.com
> >   jcokos at ccs.net
> > ========================================
> >
> >  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
> >       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
> >   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
> >  For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
> >   Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
> 
>  - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
>       Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
>   Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
>  For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
>   Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
> 
> 
> 


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For full traffic, use spug-list for LIST ; otherwise use spug-list-digest
  Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/