On Dec 28, 2004, at 1:05 PM, Rob Kinyon wrote:
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. :-)
Okay, not quite as YUK, but not as nice as:
<Service connect>
... free form code here
</Service>I suppose I could try to subclass Config::ApacheFormat into supporting free form multi-line text inside tags somehow, or maybe patch it (if Sam would accept it that is).
Hmmmmm.....
Steve
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
_______________________________________________ sw-design mailing list [email protected] http://metaperl.com/cgi-bin/mailman/listinfo/sw-design
