I was reading this article: http://www.perl.com/pub/a/2001/03/embperl.html and of course this mailing list and have seen reference to people using the $req object to have one database connection.

On my sites I did not do it that way. I use Apache::DBI to handle the DBI connection issue and do a separate connects in my base.html and in all other referenced Embperl files/code. Apache::DBI of course makes sure we really only have one connection per httpd, as you all know.

I was wondering if there is any benefit or reason to use the request object method in my scenario? I'm looking at ways to optimize my code as it has grown dramatically and this has been in the back of my mind for awhile. I remember reading something that in order to give db access to an include embperl file with only subroutines you'd have to use that method. But I can't recall now. I was also thinking that there are cases when I call .epl files directly and do not want them wrapped in base.html. If I were to use the request object method then I would either be out of luck or would have to code around it somehow.

I think I've made a lot of mistakes in the techniques I've used to develop my core site software and I'd like to correct them.

Does anyone have any thoughts on this?

What's more, is this the appropriate place for these sorts of questions? I have an interest in discussing Embperl with other developers who are actually making websites and learning about how they did things, etc. All I usually see on the list are tech support related discussions. If this is the wrong place for that, is there another list or site that might be better? If not would it be at all interesting if someone started one? I'd be open minded to that as a side project. I already have a complete content management system and community (with forums, user profiles, etc) all written in Embperl. So I could do it in short order.

Cheers,
John


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to