On Tue, 28 Dec 2004 12:50:03 -0500, Stevan Little
<[EMAIL PROTECTED]> 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
> 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
> DBI->connect($config{dsn}....) stuff IMO.
>
> > 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.
>
> True, it could open up some funky exploits, but on some level you need
> to put that responsibilty on the user of the code, and not on the code.
> If the concern is there that sub-refs are dangerous, then you just need
> to be sure that your objects can all be configured with Setter and
> Constructor injection, but I don't want to force that restriction on
> others.
>
> One thought, would a Safe compartment be any help with this? I could
> create an IOC::Service::Safe which would initialize the component (i.e.
> - execute the sub-ref from the config) within a Safe compartment. I
> have never used Safe, so I am not very familair.
>
> Any thoughts on that?
>
> Steve
>
> >
> > Rob
> >
> > On Tue, 28 Dec 2004 12:29:25 -0500, Stevan Little
> > <[EMAIL PROTECTED]> 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:
> >>
> >> <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
> >>> 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
> >>> rest of the line
> >>> 4) Structure your config file the way you structure your code - it'll
> >>> make more sense to you.
> >>>
> >>> Rob
> >>>
> >>> _______________________________________________
> >>> sw-design mailing list
> >>> [email protected]
> >>> http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
> >>>
> >>
> >> _______________________________________________
> >> sw-design mailing list
> >> [email protected]
> >> http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
> >>
> >
> > _______________________________________________
> > sw-design mailing list
> > [email protected]
> > http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
> >
>
> _______________________________________________
> sw-design mailing list
> [email protected]
> http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
>
_______________________________________________
sw-design mailing list
[email protected]
http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
