On 2003-10-20, Christopher Hicks <suppressed> wrote:
>
> The DBI::DBD model I was referring to was the fact that DBI.pm can
> discover all of the DBD's installed by the way they have things setup.
> It's painless to use - one "use DBI" line and everything else it finds for
> itself. One of the nice things about cgiapp (or your own personal
> inheritance of it) is that you don't have to "use" tons of different
> modules. Since the plugin architecture described was based on adding
> "use" lines for every plugin my gut reaction was that in some sense it was
> going backwards.
Chris,
My sense with DBD::Pg was that the module discovery was somewhat
explicit. I include "Pg" in the connect string, which causes DBI to
load DBD::Pg, correct?
To me, remembering to include "Pg" in the connect string seems to be
about the same amount difficulty as adding "use DBD::Pg" in a script.
There may also be more going on with DBI plug-in architecture that I
don't understand. (I contribute to the DBD::Pg module, but I admit to
not having a full understanding of how the "big picture" is working.)
At other points in my career, I have set things up so I had a lot of
functionality available, and I could call routines and things "just
worked". (ie: I 'used' a lot of modules that imported a lot of functions
into my name space). At the extreme, I found it confusing because I
would lose track of what was available and forget which functions were
stored where.
Now I'm more explicit about putting in "use" or "require" statements more
frequently-- and closer to where they are actually used. This
explicitness makes it easier to see how things are connected and track
down bugs.
With ValidateRM, yes you have to "use" it in the code, but it's an
alternative to adding "use" lines for HTML::FillInForm and
Data::FormValidator, so there is a little syntactic savings there.
So while I like the idea of of a simple "plug and play" architecture for
CGI::App, I also don't mind being a little explicit if needed, if that
adds clarity.
I'm also not sure I fully understand your proposal yet. Can you offer a
code sample as example, or you are still working at the conceptual,
theoretical level with the idea?
I agree that you are right that a lot of CGI::App plugins will offer the
same or similar interfaces-- such as working with templates.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
suppressed Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.