in reply to Re: DBIx::Simple
in thread DBIx::Simple

1) Configurataion file based connect parameters. These are be predefined before a connect is called or they can be loaded if absent at the time a connection is requested. 2) The user should rarely have to explictly interact with the connect statement, individual methods should make the connection when they are called.

I disagree completely. Configuration files should not be handled by a module. If the database has to be configurable, the user must provide for a function like that. Another reason I didn't create a dsn myself is that DBI's dsn is already useable, and I'm planning on writing a DSN-generator that uses the PEAR DSN scheme (mysql://user:pass@host/database and like that), so that you can use connect(pear('foo://bar...')).

OO Modules should NOT require external configuration files, but should get their configuration in the constructor method.

3) The names of the methods should state exactly what is being returned, this may increase the length of the name, but it will go a long way in making the script more mantainable.

You're right on that, but "hash" and "array" are acceptable, as a sub CANNOT return a real hash or real array. A sub can return a hash _reference_, or array _reference_. Besides, documentation removes all ambiguity, as the pod is very clear on what is returned.

That's another thing DBI does wrong: fetchrow_array returns a list, so it should be called fetchrow_list. 

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

Replies are listed 'Best First'.
Re: Re: Re: DBIx::Simple
by trs80 (Priest) on Mar 28, 2002 at 21:31 UTC
    I know you disagree, that is why you did yours differently.
    I am curious, why an OO module should not have an external configuration file. By having a separate configuration file you can access the configuration file from utilities outside of the modules when you are doing something small and other languages can read them if they are in a digestable format. I use the same connect handling mechanism and dynamicly determine which conf to use based on directory location, this avoids be from having to hard code anything inside of the modules themsevles, which I thought was the real point in OO, not to disallow any external information, but to promote external information for configuration and settings. The code I have allows for BOTH from a configuration file and setting the parameters inside of the application. Here is a trimed down constructor I am using in a current project.

    sub new {
    my ($class) = @_;
    my $self = {};
    bless $self , $class;
    my $config =  {
        dbd_user     => 'user',
        dbd_driver   => 'mysql',
        title_text   => 'TITLE HERE',
        database     => 'my_database',
        dbd_port     => '3306',
        style_sheet  => 'default.css',
        dbd_password => 'my_pass',
        smtp_server  => 'mytrusted.mailserver.com',
        dbd_hostname => '127.0.0.1'
    };
    $self->_debug(1);
    $self->assign_to_object('conf',$config);
    # $self->error_to_log(Dumper($self));
    return $self;
}

sub assign_to_object {
    my ($self,$prefix,$hash) = @_;
    foreach my $column (keys %{$hash}) {
    my $method = "$prefix" . "___" . "$column";
    $self->$method($hash->{$column});
    }
}

    [download]
    This is all part of a much larger framework that I am still refining. I some of this makes no sense unless you know more about the rest of the framework, I will have to save that for another post.
[reply]
[d/l]

In Section Meditations