> From: John Gibbons [mailto:[EMAIL PROTECTED]
> Subject: Re: Is there a point in using the request object for
> db connectionswhenusing Apache::DBI?
>
> >Most of the modules that I write for such applications inherit from a
> >common base database class (think home grown Class::DBI) and have
> >intrinsic class-based handle sharing but its all the same idea.
> >
> >None of the website code cares about database details whatsoever.
> >Abstraction and website code simplification are your friends. Well,
> >abstraction and efficient caching and code simplification. And ... :)
> >
>
> Hi Andrew,
>
> Yeah something like that does seem to make sense. However
> when you say
> you've abstracted everything from the website code, how abstracted do
> you mean? For example what I do now is do a connect in each
> file (with
> variables from a config file for username, db, etc) and then
> use the DBI
> interface to run a sql query or insert data, etc. How would
> your method
> be better? Are you removing all sql statements from your code
> and just
> making calls to the module which returns data? Is it just
> neater that way?
Something along those lines. Most of my applications share common code
between website and backend jobs / command line tools and the like. This
naturally means that most of the get/set data manipulation code is
located in those modules, wrapped in various functions. You can take
this one step further and have a completely OO approach to the data
manipulation but that is too abstracted for some and not necessary for
your requirements.
The perl module method is not necessarily better than your approach for
simpler sites but if you have common queries in many parts of your site
you can either:
1) As Luis suggested, have an embperl object or perl object for common
actions and cache this in $req. You can then use
$req->{myobj}->func()
or $req->{myobj}->{dbh}->prepare_cached(blah) or whatever is easiest.
2) Take direct advantage of mod_perl and its module compilation/caching
speedups and put common code in modules. Having a common base class
for all your modules helps with handle caching. DB connection
information can be stored in a file that is read in within a module's
BEGIN block or passed through via Apache directives or whatever.
This approach moves responsibility for DB calls out to the modules
and means you don't need to think about specifics like table names
and the like. In your embperl files you just call a function which
returns a data set.
I would probably recommend approach 1) as it means the least amount of
refactoring and restructuring.
> Anyhow there are so many database calls and things going on that are
> unique to each section of the site that I'm not sure how much
> abstraction would be possible. That is depending on what you
> mean by that.
If you have sets of similar database calls that can be turned into
functions then you are already saving yourself some maintainability
problems down the track by centralising this.
Breaking your epl up into appropriate functional pieces is just as
important as breaking out the common display or data functions. My
general approach is:
- Common data manipulation and business logic into perl modules
- Common display functionality into an embperl object using
$req->{lib} = Execute({object=>'lib.epl'}). Eg website-
centric debug(), link generation, common form section displays.
For bonus points you can override lib.epl in different parts of
the site as required if you're using embperlobject
- Overridable larger display components in .epl files.
- Main entry points as .html pages that merely perform the display
of the guts of the page. Most of the surrounding structure is
determined by the base file and friends if you're using
embperlobject.
An example basic structure this I find myself using over and over. This
may or may not be directly useful to you, I'm just procrastinating
before a deadline :)
/base.epl
- set up common library objects and variables into $req
- execute layout.epl
/lib.epl
- library of embperl subroutines. Overridable in subdirs
/layout.epl
- define basic layout for this part of the site. Eg set up
a menu via menu.epl, sidebars and whatnot. This is where
frames would be set up if using them etc.
- includes an Execute('*') at the appropriate place
/index.html
- the content on the main page
/sitesection1/layout.epl
- different layout for this part of the site
/sitesection1/menu.epl
- different menu etc
/sitesection2/menu.epl
- this part of the site uses the same basic layout but has
a different menu construction.
/sitesection3/lib.epl
- via a call to Execute({isa => '../lib.epl'}) we can add to
or override functions in lib without changing any other
part of the embperl structure. OO for $req->{lib}.
/sitesection4/base.epl
- completely different page initialisation. You can, for
example have fully constructed html pages contributed by
a 3rd party here so you may want to only include a simple
Execute('*').
.. And so on. There are a number of different ways to implement the
exact same structure overrides. There is a lot of power there.
</end waffle>
Cheers,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
