[BTW, thanks to all of you for the advice on using template systems.
Very interesting discussion and lots of useful info.]
> What are other specific features that would make TT attractive to an
> H::T user?
I haven't actually used TT or H::T much, but I've used a lot of custom
templating systems
NAME
Config::DBI - database connection support via Config::ApacheFormat files
SYNOPSIS
In .cshrc:
setenv DBI_CONF dbi.conf
In dbi.conf:
# Pass may be a password, or in which case, the password is
# is prompted for:
Pass
# Connect attribute
# dbi_connect_method is a stand
Mark Stosberg wrote:
Could you say more about this William? I usually inline my SQL. The one
time I tried to abstract out of the code, I felt like it was an extra
layer of abstraction that made the code harder to understand and debug
without benefits that exceeded that. What specific benefits do y
William McKee wrote:
After initial joy of abstracting my
SQL, I grew to hate the DBIx::Recordset API because I couldn't
understand my own code when I went back to code after several months.
1 - if your recordset calls were wrapped in a descriptive function name,
perhaps the inability to unders
As a TT user my own uses tend to be less plugin oriented, but are pretty
heavy on display logic. My application generally takes user requests
for data resources, makes sure the user is allowed to make such a
request, and hands them back the requested data resources if everything
checks out. A
Mark Stosberg wrote:
What are other specific features that would make TT attractive to an
H::T user? Someone already mentioned the ability to more easily
reference objects. What are some other favorite features that get used
frequently?
Like I have mentioned in a previous email, my main reason for
On 2004-01-28, Brett Sanger <[EMAIL PROTECTED]> wrote:
>
> With H::T I would find myself having to revise the C::A application when
> a display requirement changed, which broke the whole concept for me.
> (Granted, our display requirements changed fairly often, but that's a
> buisness reality where
> What are other specific features that would make TT attractive to an
> H::T user? Someone already mentioned the ability to more easily
> reference objects. What are some other favorite features that get used
> frequently?
For me, referencing objects is useful. The biggest draw, however, is
plug
On 2004-01-23, petersm <[EMAIL PROTECTED]> wrote:
>
> Not to keep harping on the subject, but this is also possible with
> CheesePizaa::TemplateLoader.
Would it possible to abstract this module so it's useful with DBI and
H::T, without using the rest of the CheesePizza framework? It seems
useful a
On 2004-01-28, Brett Sanger <[EMAIL PROTECTED]> wrote:
>
> I have to agree with the other poster that C::A/TT is far more like
> C::A/H::T than a "server-page" paradigm.
>
> TT does have a lot more processing features, and some people do put the
> application into the page, but a good many of us (a
> >> However, I think some people here will agree that CGI::App/H::T is a
> >> popular alternative to the server-page paradigm that TT is built on.
> >
> > That caught my attention as I'm missing the distinction. Isn't
> > server-page more Mason/PHP/JSP? TT and H::T are in the same camp, seems
On 2004-01-23, Bill Moseley <[EMAIL PROTECTED]> wrote:
> Yesterday Mark Stosberg wrote:
>
>> However, I think some people here will agree that CGI::App/H::T is a
>> popular alternative to the server-page paradigm that TT is built on.
>
> That caught my attention as I'm missing the distinction. Isn
thank you for your detailed answer:
> I missed that part of the documentation. It is a bit confusing because
> in one sentance you say "this module pass all the tests of
> CGI::Application 3.1", but then later on you say, "This module implements
> on purpose a little but useful difference that s
Ugh. I am the idiot here. I was testing CGI vs. CGI::Simple and then got
sidetracked for a month or so. I had even forgot I subclassed it!
Serves me right!
Thank you for helping.
> -Original Message-
> From: Cees Hek [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 27, 2004 5:19 PM
>
Bob Hicks wrote:
I have 5.8.2.808 and I am only using CGI-Application and HTML-Template.
I am going to do a reinstall of Apache to see if that is a problem as
well.
I should have reread the Subject and I would have realized you were
using 5.8.2...
Ah! From the log:
[Mon Jan 26 14:12:29 2004] [e
On Tue, 27 Jan 2004, Terrence Brannon wrote:
> Brett Sanger wrote:
> >
> > (I believe that H::T
> >currently beats all comers in speed, for example, but intentionally
> >leaves out some features I want in larger projects).
>
> HTML::Embperl 2.0 is written in C so it is probably the fastest.
Have
I have 5.8.2.808 and I am only using CGI-Application and HTML-Template.
I am going to do a reinstall of Apache to see if that is a problem as
well.
Ah! From the log:
[Mon Jan 26 14:12:29 2004] [error] [client 127.0.0.1] Premature end of
script headers: c:/apache/users/webapp/index.cgi
[Mon Jan
Terrence Brannon wrote:
Brett Sanger wrote:
(I believe that H::T
currently beats all comers in speed, for example, but intentionally
leaves out some features I want in larger projects).
HTML::Embperl 2.0 is written in C so it is probably the fastest.
If anyone is interested in some actual benc
Bob Hicks wrote:
Is there a problem with CGI-Application and the latest download from
ActiveState? I can run a regular CGI script from the same
folder/directory that my CGI-App index.cgi is in. The CGI-App doesn't
work. The only change (it was working before) was updating to the latest
AS distro.
C
Brett Sanger wrote:
(I believe that H::T
currently beats all comers in speed, for example, but intentionally
leaves out some features I want in larger projects).
HTML::Embperl 2.0 is written in C so it is probably the fastest.
--
Is there a problem with CGI-Application and the latest download from
ActiveState? I can run a regular CGI script from the same
folder/directory that my CGI-App index.cgi is in. The CGI-App doesn't
work. The only change (it was working before) was updating to the latest
AS distro.
Robert
---
Domizio Demichelis wrote:
I think Domizio's case is similar, even though it's not a sub-class,
because it passes all the current CGI::App tests.
I would be careful about stating that it passes all the tests, because I
don't believe it does. The failures seem to be minimal but they are
there.
it'
>> I think Domizio's case is similar, even though it's not a sub-class,
>> because it passes all the current CGI::App tests.
>>
> I would be careful about stating that it passes all the tests, because I
> don't believe it does. The failures seem to be minimal but they are
> there.
it's not a matt
> I think Domizio's case is similar, even though it's not a sub-class,
> because it passes all the current CGI::App tests. Even sub-classes can
> break when the original module changes. (This happened to WWW::Mechanize
> recently). In Domizio's case, his app wouldn't break if CGI::App changed
> in
On 2004-01-27, Cees Hek <[EMAIL PROTECTED]> wrote:
> Mark Stosberg wrote:
>> I highly agree that something like ::Variant would be useful. For my own
>> case, I might try to break the changes in my sub-class into several
>> pieces, each of which would be separate from the others. I think that
>> wo
Mark Stosberg wrote:
I highly agree that something like ::Variant would be useful. For my own
case, I might try to break the changes in my sub-class into several
pieces, each of which would be separate from the others. I think that
would make them all easier to name, and more valuable to others who
Richard Dice wrote:
Apart from that, to use Apache::Reload, you need to put a reference to
it in *every* file that you want to have reloaded.
And I've found you have to restart Apache anyway, since it doesn't -- in
my installation at least -- seem to do very much except generate gobs of
error lo
On 2004-01-27, David A Golden <[EMAIL PROTECTED]> wrote:
> This is why I was thinking CGI::App::Variant would be a good namespace for
> things of this type as the term "variant" is directly evocative of what it
> is intended to be: a variant. Variants might be straightforward subclasses
> of C:
Before I send it to mod_perl list I put it here because the problem
mainly concerns C::A.
No, not really. To the degree that you are having problems with
Apache::Reload, this is a mod_perl/Apache::Reload problem.
But the problem that the error message you gave us pertains to a basic
Perl syntax
Perl v5.6.0 for Apache/1.3.29 (Unix)
mod_perl/1.29
CGI::Application 3.1
Apache::Reload 0.07
Before I send it to mod_perl list I put it here because the problem
mainly concerns C::A.
There is a testing environment:
tester.cgi:
==
#!/usr/local/bin/perl -w
use Tester;
my $webapp = Teste
Re-thinking about your post...
> I think the fear, rather founded or not, is that makes it more confusing
> for people looking for a solution, when there are several similar
> options. If you saw two modules that looked like a good fit, and one was
> named "Plus", then it might same like the "::Pl
31 matches
Mail list logo
