in reply to Re^2: OO, Library Configuration and Class Variables
in thread OO, Library Configuration and Class Variables

package LookupFactory;

use base qw( UserSource );

sub init_lookup {
  # run config based upon type of source requested
}

package UserSource;

sub get {
  # get the type of user source (lookup, database, whatever)
}

package User

sub new {
  # get a source based upon whatever the User config says to get
}

package App

$user = User->new();

$user->info() # look ma!  no config!

[download]
I don't think it would break your model to have the user request the type of source from a config file. It's actually still not even necessary to do that, as it could select from a pre-created list of Lookup Sources.

Code is (hopefully obviously) not tested and not intended to work

Replies are listed 'Best First'.
Re^4: OO, Library Configuration and Class Variables
by moot (Chaplain) on Jun 23, 2005 at 22:37 UTC
    Hmm.. I grok this apart from this bit: 
    sub init_lookup {
  # run config based upon type of source requested
}

    [download]
    In case I wasn't clear, my original query was how to do this config - it seems you're saying that Loopup::Remote (or LookupFactory, here) can run its own AppConfig->file(), but this raises the issue of passing in the filename from which Lookup::Remote can configure (as you can probably tell I'm against hard-coding values!).

    Also, unless I have a separate configuration file for 'library values' from the one for 'application values', I'd need to define both sets of variables that AppConfig will use, in all instances of AppConfig, or deal with the warnings it spits out about undefined variables. And something about separating out those config files strikes me as wrong.

    I guess I could just modify User to accept an AppConfig instance and pretend that there is a broader use for this than just a single remote_uri parameter, or deal with app-code knowing something about User's internals.

    Thanks for the assistance.

    --
    Now hiring in Atlanta. /msg moot for details.

[reply]
[d/l]
      You can make your application reads the configuration and store it in some place your User class knows.

      I wrote an application that has a %config all my modules can access (using Config::IniFile). I created sections for all modules and grab configuration from there.

      Config example: 

      [User]
lookup_uri = something

      [download]
      Then your code could be like this: 
      package App;
our %config = ();
&init;
sub init {
    # loads your configuration file/parameters here and
    # assigns to %App::config
}

package User;

sub new {
    my $self = {};
    bless $self;
    $self->{lookup_uri} = $App::config{lookup_uri};
}

      [download]
      You can also specify which class you want to use for Lookup in config file, and instantiate in User::new.

      Still hope it helps :)

[reply]
[d/l]
[select]
      Unfortunately, I'm not familiar with AppConfig... I'm dealing with generic initialization/configuration modules here.

      LookupFactory is a factory for Lookup::* objects. It has an initialization parameter file (i.e. a config file) that has the parameters of how to instatiate different types of Lookup:: objects.

      Your initialization class runs at the start of your service, preparing for the first request. It starts up LookupFactory which receives the parameters that are appropriate to individual Lookup::* modules (e.g. RemoteURI).

      When the user->source() method is called, it requests (from UserSource) a source that is applicable to user. Based upon a separate config file (or a separate section of the same config file, if you so choose), it reads the appropriate user source for this app is "Lookup::Remote" (or more abstractly, just "Remote" or some such moniker).

      UserSource can request the item from LookupFactory which will instantiate a Lookup::Remote object (or whatever Lookup object is requested) if one is not already available in the "pool" of Lookup Objects. When the LookupFactory instantiates the Lookup::Remote object, it already has knowledge of the aforementioned RemoteURI from it's config file.

      This is my experience in a (granted, Java-based) production-environment application. It provided great separation of knowledge and sub-classes of generic objects from the business logic. Some see this as overkill, but I found it to be highly maintainable and separable. Please let me know if you have any more questions or if this is not clear. It is based upon the Avalon framework.
[reply]
        Many thanks for all the responses. I think I'm just going to deal with the app-level code knowing about Lookup::Remote, and have it configure $RemoteURI, especially since Users are not instantiated in one place and not always at the top level (so I can't easily pass around top-level config variables). Even though I'm not following your or the other respondents' advice directly I appreciate the assistance - it helped me clarify what ideas I already had.

        --
        Now hiring in Atlanta. /msg moot for details.

[reply]

In Section Seekers of Perl Wisdom