headers
Stevan Little | 27 Dec 22:04
Favicon

RFC: IOC Configuration syntax/mini-language

So I have been using my module IOC a lot lately, so far so good, but I 
have found that writing the code to create all the containers and 
services and such gets quite tedious. For instance to do a basic DBI 
container, I do something like this:

my $r = IOC::Registry->new('MyApp');
my $c = IOC::Container->new('DBI');
$c->register(IOC::Service::Literal->new('dsn'      => 
'dbi:mysql:test'));
$c->register(IOC::Service::Literal->new('username' => 'test'));
$c->register(IOC::Service::Literal->new('password' => '****'));
$c->register(IOC::Service::ConstructorInjection->new('connection' => (
	'DBI', 'connect' [
		IOC::Service::ConstructorInjection->ComponentParameter('dsn'),
		IOC::Service::ConstructorInjection->ComponentParameter('username'),
		IOC::Service::ConstructorInjection->ComponentParameter('password')
	]
)));
$r->registerContainer($c);

# ... then in my app all I have to do is

my $reg = IOC::Registry->instance();
my $db_conn = $reg->locateService('/MyApp/DBI/connection');

Writing the code to configure the services, containers and registry 
though, can get quite tiring. Fortunately, I really only need to do 
this once and then just use it, but ideally I would like it to be a 
little less taxing on the carpal tunnel.
(Continue reading)

Permalink | Reply |
headers
Matthew Simon Cavalletto | 30 Dec 23:53
Gravatar

Re: RFC: IOC Configuration syntax/mini-language

On Monday, December 27, 2004, at 04:04  PM, Stevan Little wrote:

> So I have been using my module IOC a lot lately, so far so good, but I 
> have found that writing the code to create all the containers and 
> services and such gets quite tedious. For instance to do a basic DBI 
> container, I do something like this:
>
> my $r = IOC::Registry->new('MyApp');
> my $c = IOC::Container->new('DBI');
> $c->register(IOC::Service::Literal->new('dsn'      => 
> 'dbi:mysql:test'));
> $c->register(IOC::Service::Literal->new('username' => 'test'));
> $c->register(IOC::Service::Literal->new('password' => '****'));
> $c->register(IOC::Service::ConstructorInjection->new('connection' => (
> 	'DBI', 'connect' [
> 		IOC::Service::ConstructorInjection->ComponentParameter('dsn'),
> 		IOC::Service::ConstructorInjection->ComponentParameter('username'),
> 		IOC::Service::ConstructorInjection->ComponentParameter('password')
> 	]
> )));
> $r->registerContainer($c);

In addition to the Config::ApacheFormat mechanism that has been 
discussed, I think there's also an argument for adding a simpler Perl 
calling API.

For example, I think that the following can be unambiguously converted 
to the above:

IOC::Registry->add_registration( 'MyApp' => 'DBI' => {
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 31 Dec 05:22
Favicon

Re: RFC: IOC Configuration syntax/mini-language


On Dec 30, 2004, at 5:53 PM, Matthew Simon Cavalletto wrote:
> In addition to the Config::ApacheFormat mechanism that has been 
> discussed, I think there's also an argument for adding a simpler Perl 
> calling API.
>
> For example, I think that the following can be unambiguously converted 
> to the above:
>
> IOC::Registry->add_registration( 'MyApp' => 'DBI' => {
>   'dsn'      => 'dbi:mysql:test',
>   'username' => 'test',
>   'password' => '****',
>   'connection' => [ 'DBI', 'connect', '@dsn', '@username', '@password' 
> ],
> } );

> That's a lot easier to read, and one could always switch back to the 
> other syntax where needed... Perhaps this convenience interface 
> belongs in a separate "IOC::Easy" facade package, which could provide 
> class methods (or even exportable functions) that obscured the whole 
> underlying network of various kinds of IOC objects.

I like this idea, and is something I have given some consideration to 
in the past, but never gotten around too. My only worry though is that 
the perl syntax may eventually get really messy with too many {}[]()s 
everywhere if the configuration is very large and complex (which some 
of my IOC configs are).

Hmmmm, this is some serious food for thought though.
(Continue reading)

Permalink | Reply |
headers
Rob Kinyon | 28 Dec 15:20
Picon
Gravatar

Re: RFC: IOC Configuration syntax/mini-language

What's wrong with Config::ApacheFormat? You have the ability to have
arbitrarily-deep nested structures that you can call whatever you want
...

Rob

On Mon, 27 Dec 2004 16:04:40 -0500, Stevan Little
<stevan <at> iinteractive.com> wrote:
> So I have been using my module IOC a lot lately, so far so good, but I
> have found that writing the code to create all the containers and
> services and such gets quite tedious. For instance to do a basic DBI
> container, I do something like this:
> 
> my $r = IOC::Registry->new('MyApp');
> my $c = IOC::Container->new('DBI');
> $c->register(IOC::Service::Literal->new('dsn'      =>
> 'dbi:mysql:test'));
> $c->register(IOC::Service::Literal->new('username' => 'test'));
> $c->register(IOC::Service::Literal->new('password' => '****'));
> $c->register(IOC::Service::ConstructorInjection->new('connection' => (
>        'DBI', 'connect' [
>                IOC::Service::ConstructorInjection->ComponentParameter('dsn'),
>                IOC::Service::ConstructorInjection->ComponentParameter('username'),
>                IOC::Service::ConstructorInjection->ComponentParameter('password')
>        ]
> )));
> $r->registerContainer($c);
> 
> # ... then in my app all I have to do is
>
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 28 Dec 16:59
Favicon

Re: RFC: IOC Configuration syntax/mini-language

Rob,

My problem is that I am not sure Config::ApacheFormat can handle some 
of the more complex IOC::Service configurations.

<Registry MyApp>
	<Container DBI>
		dsn      dbi:mysql:test
		username test
		password ****
		connect ??? << how to do this one
	</Container>
</Registry>

I want to avoid doing things like this (which can start to get very 
verbose):

<Service connect>
	class DBI
	constructor connect
	args @dsn @username @password
</Service>

or this (which I don't actually think would work since the tag name 
would be so arbitrary):

<connect>
	class DBI
	constructor connect
	args @dsn @username @password
(Continue reading)

Permalink | Reply |
headers
Rob Kinyon | 28 Dec 18:22
Picon
Gravatar

Re: RFC: IOC Configuration syntax/mini-language

> <Registry MyApp>
>        <Container DBI>
>                dsn      dbi:mysql:test
>                username test
>                password ****
>                connect  [ DBI connect [ @dsn @username @password ]]
>        </Container>
> </Registry>

<Registry MyApp>
       <Container DBI>
               Literal dsn dbi:mysql:test
               Literal username test
               Literal password ****
               <ConstructorInjection connect>
                       Class DBI
                       Constructor connect
                       Parameter dsn
                       Parameter username
                       Parameter password
               </ConstructorInjection>
       </Container>
</Registry>

Or, you can have the Literal items be containers. It's up to you.

The important things to note:
1) You can have multiple items on the same line
2) You can aggregate multiple lines into the same option
3) You can have hash options, so that the first item is the key to the
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 28 Dec 18:29
Favicon

Re: RFC: IOC Configuration syntax/mini-language

Very Nice Rob!

I knew it was a good idea to ask the list before I started writing any 
code.

The only thing still is multi-line code entries, I would like to be 
able to do this:

<Registry MyApp>
        <Container DBI>
                Literal dsn dbi:mysql:test
                Literal username test
                Literal password ****
                <Service connect>
                      my $c = shift;
				  return DBI->connect($c->get('dsn'), $c->get('username'), 
$c->get('password'));
                </Service>
        </Container>
</Registry>

On Dec 28, 2004, at 12:22 PM, Rob Kinyon wrote:
>
> <Registry MyApp>
>        <Container DBI>
>                Literal dsn dbi:mysql:test
>                Literal username test
>                Literal password ****
>                <ConstructorInjection connect>
>                        Class DBI
(Continue reading)

Permalink | Reply |
headers
Rob Kinyon | 28 Dec 18:39
Picon
Gravatar

Re: RFC: IOC Configuration syntax/mini-language

Uhh ... like this?

<Service connect>
    Code my $c = shift;
    Code return DBI->connect( ... );
</Service>

By marking Code as a "combine", you will end up with all the code
within that block in the same scalar that you can eval later.

But, I personally wouldn't have code in your config files. Instead, I
would do what I suggested earlier and build the code from basic
concepts. *shrugs* If you have code in the config file, that ends up
providing a security hole - you have to secure not just your code from
prying hands, but your config files as well. While config parameters
are sensitive, someone could change the code and you'd execute it
without knowing. That code could do something like email your database
to someone else. Changing parameter values could never do that.

Rob

On Tue, 28 Dec 2004 12:29:25 -0500, Stevan Little
<stevan <at> iinteractive.com> wrote:
> Very Nice Rob!
> 
> I knew it was a good idea to ask the list before I started writing any
> code.
> 
> The only thing still is multi-line code entries, I would like to be
> able to do this:
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 28 Dec 18:50
Favicon

Re: RFC: IOC Configuration syntax/mini-language


On Dec 28, 2004, at 12:39 PM, Rob Kinyon wrote:
> Uhh ... like this?
>
> <Service connect>
>     Code my $c = shift;
>     Code return DBI->connect( ... );
> </Service>

Yuk

> But, I personally wouldn't have code in your config files. Instead, I
> would do what I suggested earlier and build the code from basic
> concepts.

Well part of the problem is that IOC::Service requires a code-ref. The 
ConstructorInjection and SetterInjection ones do not, but you can't 
always fit something into one of those. IOC::Service provides a nice 
bridge to do both ConstructorInjection and SetterInjection at the same 
time, plus any other weirdness your object might want/need in order to 
be fully configured when you get it from the IOC::Container.

> *shrugs* If you have code in the config file, that ends up
> providing a security hole - you have to secure not just your code from
> prying hands, but your config files as well.

I would argue that you _should_ secure your config file as much as 
possible, if not more than you secure your code. Your config file will 
usually have the database connection parameters as well as username and 
password. That type of data should be protected  more than just
(Continue reading)

Permalink | Reply |
headers
Terrence Brannon | 29 Dec 02:50

Re: RFC: IOC Configuration syntax/mini-language

Stevan Little <stevan <at> iinteractive.com> writes:

> One thought, would a Safe compartment be any help with this? 

I contacted Tim Bunce about some problems I was having with Safe while
trying to get Resources (a CPAN module) updated. He said that Safe was
a failed experiment and showed no interest in fixing the problem with
Safe. 

--

-- 
	Carter's Compass: I know I'm on the right track when,
	   by deleting something, I'm adding functionality.
Permalink | Reply |
headers
Rob Kinyon | 29 Dec 14:36
Picon
Gravatar

Re: Re: RFC: IOC Configuration syntax/mini-language

On Wed, 29 Dec 2004 01:50:39 +0000, Terrence Brannon
<bauhaus <at> metaperl.com> wrote:
> Stevan Little <stevan <at> iinteractive.com> writes:
> 
> > One thought, would a Safe compartment be any help with this?
> 
> I contacted Tim Bunce about some problems I was having with Safe while
> trying to get Resources (a CPAN module) updated. He said that Safe was
> a failed experiment and showed no interest in fixing the problem with
> Safe.

If you have documentation of this, I think it would be good to post to
Perlmonks. Safe is still being recommended on a somewhat regular basis
and, if Tim Bunce feels it's a failed experiment, that's a problem.

Rob
Permalink | Reply |
headers
Matthew Simon Cavalletto | 29 Dec 17:05
Gravatar

Re: Re: RFC: IOC Configuration syntax/mini-language

On Wednesday, December 29, 2004, at 08:36  AM, Rob Kinyon wrote:

> On Wed, 29 Dec 2004, Terrence Brannon <bauhaus <at> metaperl.com> wrote:
>> Tim Bunce [...] said that Safe was a failed experiment and showed no 
>> interest in fixing the problem with Safe.
>
> If you have documentation of this, I think it would be good to post to
> Perlmonks. Safe is still being recommended on a somewhat regular basis
> and, if Tim Bunce feels it's a failed experiment, that's a problem.

Seconded -- I've been using Safe in production for a while, although in 
a relatively minor role, and was under the impression that it was 
generally working and reasonably secure... If that's not the case, it 
would be good to further advise the community of how and why.

-Simon
Permalink | Reply |
headers
Rob Kinyon | 28 Dec 19:05
Picon
Gravatar

Re: RFC: IOC Configuration syntax/mini-language

On Tue, 28 Dec 2004 12:50:03 -0500, Stevan Little
<stevan <at> iinteractive.com> wrote:
> 
> On Dec 28, 2004, at 12:39 PM, Rob Kinyon wrote:
> > Uhh ... like this?
> >
> > <Service connect>
> >     Code my $c = shift;
> >     Code return DBI->connect( ... );
> > </Service>
> 
> Yuk

Ok ... How about:
<Service connect>
    Code \
        my $c = shift; \
        return DBI->connect( ... );
</Service>

It looks somewhat C macro-ish, but it'll work. :-)

> > But, I personally wouldn't have code in your config files. Instead, I
> > would do what I suggested earlier and build the code from basic
> > concepts.
> 
> Well part of the problem is that IOC::Service requires a code-ref. The
> ConstructorInjection and SetterInjection ones do not, but you can't
> always fit something into one of those. IOC::Service provides a nice
> bridge to do both ConstructorInjection and SetterInjection at the same
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 28 Dec 19:18
Favicon

Re: RFC: IOC Configuration syntax/mini-language


On Dec 28, 2004, at 1:05 PM, Rob Kinyon wrote:
> On Tue, 28 Dec 2004 12:50:03 -0500, Stevan Little
> <stevan <at> iinteractive.com> wrote:
>>
>> On Dec 28, 2004, at 12:39 PM, Rob Kinyon wrote:
>>> Uhh ... like this?
>>>
>>> <Service connect>
>>>     Code my $c = shift;
>>>     Code return DBI->connect( ... );
>>> </Service>
>>
>> Yuk
>
> Ok ... How about:
> <Service connect>
>     Code \
>         my $c = shift; \
>         return DBI->connect( ... );
> </Service>
>
> It looks somewhat C macro-ish, but it'll work. :-)

Okay, not quite as YUK, but not as nice as:

<Service connect>
	... free form code here
</Service>
(Continue reading)

Permalink | Reply |
headers
Terrence Brannon | 28 Dec 17:50

Re: RFC: IOC Configuration syntax/mini-language

Stevan Little <stevan <at> iinteractive.com> writes:

> Rob,
>
> My problem is that I am not sure Config::ApacheFormat can handle some
> of the more complex IOC::Service configurations.
>
> <Registry MyApp>
> 	<Container DBI>
> 		dsn      dbi:mysql:test
> 		username test
> 		password ****
> 		connect ??? << how to do this one

If you want evaluable code there, that is easy. My CPAN module
Config::DBI uses Config::ApacheFormat for just that reason. DBI takes
a HandleError attribute which is a routine which can be called when it
wants to throw an exception.

Here is how I built the HandleError attribute in the DBI handler to
pass to DBI->connect()

  if (my $handler = $block->HandleError)
    {
      my $hardref = eval "\\&$handler" ;
      $A{HandleError} = $hardref;
    }

In fact, that Container block above looks just like the one in
Config::DBI.
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 28 Dec 18:16
Favicon

Re: RFC: IOC Configuration syntax/mini-language

Terrance,

On Dec 28, 2004, at 11:50 AM, Terrence Brannon wrote:
> and so I developed Config::DBI based on Config::ApacheFormat
>
>     http://search.cpan.org/~tbone/Config-DBI-1.8/lib/Config/DBI.pm

I see where you are passing the code ref in the example, but it seems 
to be all on one line, which is not good for me as sometimes 
IOC::Service sub-refs can get quite large.

Is the single line a restriction? Or do you end up having to use \ 
characters to span multiple lines (which is just nasty).

> More recently, I realized that it was wrong of me to expect database
> connection information to be structured in a certain
> way. Organizations think about their database connection info in
> different ways and they have their own preferenecs for which concfig
> tool to use... your Registry and Container syntax is living proof of
> that. A flexible database connection module should allow you to pass
> your data to it but not put restrictions on how your data was
> cataloged in your personal tech stack.

IOC actually aims to be not provide any more structure than the 
Registry->Container->Service hierarchy, and allow you to structure your 
database info in any way you like from there. My example is just how we 
do it here (actually it's simplified from how we actually do it, but 
why bother you all with the details), but it is by no means how I would 
expect others to do it, nor is it the only way you can do it with IOC.
(Continue reading)

Permalink | Reply |
headers
Terrence Brannon | 29 Dec 02:47

Re: RFC: IOC Configuration syntax/mini-language

Stevan Little <stevan <at> iinteractive.com> writes:

> Terrance,
>
> On Dec 28, 2004, at 11:50 AM, Terrence Brannon wrote:
>> and so I developed Config::DBI based on Config::ApacheFormat
>>
>>     http://search.cpan.org/~tbone/Config-DBI-1.8/lib/Config/DBI.pm
>
> I see where you are passing the code ref in the example, but it seems
> to be all on one line, which is not good for me as sometimes
> IOC::Service sub-refs can get quite large.
>
> Is the single line a restriction? Or do you end up having to use \
> characters to span multiple lines (which is just nasty).

I think so. But why not name your subrefs and put them in a module and
refer to them in a single clean line of config code?

--

-- 
	Carter's Compass: I know I'm on the right track when,
	   by deleting something, I'm adding functionality.
Permalink | Reply |
headers
Stevan Little | 29 Dec 16:36
Favicon

Re: Re: RFC: IOC Configuration syntax/mini-language


On Dec 28, 2004, at 8:47 PM, Terrence Brannon wrote:
> I think so. But why not name your subrefs and put them in a module and
> refer to them in a single clean line of config code?

Hmmmm, Thats a good thought.

Steve
Permalink | Reply |
headers
Rob Kinyon | 29 Dec 17:18
Picon
Gravatar

Re: Re: RFC: IOC Configuration syntax/mini-language

I initially thought of this as well, but thinking through it further
leads to some questions:
1) Are you really going to have such re-usable components?
2) If you do, why aren't they in some sort of child class that you can specify?
3) If you cannot put them in some child class, then all you have is a
junk drawer of items that are used in one place in some config file
that need unique names. That's a real smell to me ...

Rob

On Wed, 29 Dec 2004 10:36:08 -0500, Stevan Little
<stevan <at> iinteractive.com> wrote:
> 
> On Dec 28, 2004, at 8:47 PM, Terrence Brannon wrote:
> > I think so. But why not name your subrefs and put them in a module and
> > refer to them in a single clean line of config code?
> 
> Hmmmm, Thats a good thought.
> 
> Steve
> 
> 
> _______________________________________________
> sw-design mailing list
> sw-design <at> metaperl.com
> http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
>
Permalink | Reply |
headers
Stevan Little | 29 Dec 17:27
Favicon

Re: Re: RFC: IOC Configuration syntax/mini-language


On Dec 29, 2004, at 11:18 AM, Rob Kinyon wrote:
> I initially thought of this as well, but thinking through it further
> leads to some questions:
> 1) Are you really going to have such re-usable components?

sometimes.

> 2) If you do, why aren't they in some sort of child class that you can 
> specify?

True, and a better solution. This of course means that I need to be 
able to allow for subclasses in the config file then as well (which is 
a good thing).

> 3) If you cannot put them in some child class, then all you have is a
> junk drawer of items that are used in one place in some config file
> that need unique names. That's a real smell to me ...

*sniff*,... *sniff*,... yeah I think smell something too.

I agree, Junk drawer modules are bad.

Hmmmm.

I think I am going to look at Config::ApacheFormat and see if I can't 
hack in multi-line support. That will answer my questions in the end 
anyway.

Steve
(Continue reading)

Permalink | Reply |
headers
Rob Kinyon | 29 Dec 19:07
Picon
Gravatar

Re: Re: RFC: IOC Configuration syntax/mini-language

On Wed, 29 Dec 2004 11:27:06 -0500, Stevan Little
<stevan <at> iinteractive.com> wrote:
> 
> On Dec 29, 2004, at 11:18 AM, Rob Kinyon wrote:
> > I initially thought of this as well, but thinking through it further
> > leads to some questions:
> > 1) Are you really going to have such re-usable components?
> 
> sometimes.
> 
> > 2) If you do, why aren't they in some sort of child class that you can
> > specify?
> 
> True, and a better solution. This of course means that I need to be
> able to allow for subclasses in the config file then as well (which is
> a good thing).
> 
> > 3) If you cannot put them in some child class, then all you have is a
> > junk drawer of items that are used in one place in some config file
> > that need unique names. That's a real smell to me ...
> 
> *sniff*,... *sniff*,... yeah I think smell something too.
> 
> I agree, Junk drawer modules are bad.
> 
> Hmmmm.
> 
> I think I am going to look at Config::ApacheFormat and see if I can't
> hack in multi-line support. That will answer my questions in the end
> anyway.
(Continue reading)

Permalink | Reply |
headers
Stevan Little | 29 Dec 19:31
Favicon

Re: Re: RFC: IOC Configuration syntax/mini-language

Rob,

On Dec 29, 2004, at 1:07 PM, Rob Kinyon wrote:
>> I think I am going to look at Config::ApacheFormat and see if I can't
>> hack in multi-line support. That will answer my questions in the end
>> anyway.
>
> You're going to want to look at doing something like heredocs. Maybe,
> it would look something like:
>
> <Foo foo1>
>     Directive
> multiline
> text
> here
> EndDirective
>
>     SomeOtherDirective With Some Values
> </Foo>

Actually I was thinking they would work best as <blocks> and not 
directives. This would allow for more free-form text inside the block 
and not force the introduction of an 'End<directive name>' token.

> This means you'll want to look at the while-loop labelled LINE:,
> especially the do-while loop with the comment "# accumulate a full
> line, dealing with line-continuation". Adding a new directive called
> "multi_line" would probably be best, along the same lines as
> hash_directives or duplicate_directives, where you specify which
> directives have this multi_line property set for them. That way,
(Continue reading)

Permalink | Reply |

Gmane