Hi,
I am using CGI::Application for all my CGI scripts now, and only have
one issue with it at the moment:
Exception handling.
CGI::Application handles its own exceptions with a simple die(), but that's
no reason you need to use die(). In your code you could call something
completely
Hello,
(1) That error (line #156, CGI::Application 2.4) only happens when you
map
your run modes like so:
'select_document', = 'select_document',
but will not occur if the run mode is directly mapped (this holds the
method to the current package I believe.)
'select_document', =
Hi,
In order for this to work I
need to prevent the CGI::header
from printing automatically.
What's the best way to do this?
You could overload run(), set the env variable, call SUPER::run() and
grab the output, filter it, or delay printing for stdout for later.
Note that this is the
Since most of us use HTML::Template, how about allowing runmodes to
As one of those that don't use H::T (and I'm not alone), I'd be unhappy
with tightening the bonds between them.
Well, it would just be an option.
No one is forced to use it, but it would benefit those who do use H::T.
Thilo
A little bit of an optimization and security check - if all you are
doing
is comparing if the username and password match, why not let SQL do it?
my $query = SELECT count(*) FROM user WHERE USER_ID = ? and
USER_PASSWORD = ?;
my $sth = $dbh-prepare($query);
In the recent best practices document that Mark started, he mentions
configuration information that is global, i.e. is needed by more than
one cgi script. What CPAN configuration modules are people using in
their CGI::Apps?
Hi,
I am not using any CPAN module, but wrote a small module myself.
Has anyone tried to use CGI::Application with fastcgi?
When I try, my script runs, but it does not switch between the runmodes
correctly.
You probably have problems with the CGI object not being initialized
properly (thus retaining values from a previous request).
The CGI::Fast module worked for
2. for a large project, not all of the pages have to be dynamic
obviously. How do people deal with static pages that you want to still
share the look of your dynamic pages that you are using HTML::Template
for? I was considering creating a commandline tool to generate the
static pages from the
i have a couple of html-templates, which i would like to fill in
with their appropriat backend functions. e.g. i have a search
template, where one can enter search terms and submit a query.
Then there is the major part of the page, which should be used to
display stuff, mostly the search results.
Question: are the HTTP requests (with CGI fields and values, including
session_id) encrypted when using https?
Everything you send or receive via https is encryted.
This even includes the HTTP headers, which is why name-based virtual
hosting does not work with https.
Cookies are a bit more
Depending on how paranoid you are you can also set the secure
connection flag on the cookie, so the cookie will only be send via
encrypted connections.
Does this work using http? (A given session may go back and forth
between http and https.)
In that case, you should not use this flag.
A cookie
I do not know CGI::Minimal, but CGI::Application does not use the
HTML-producing functions of CGI.pm.
Thanks. CGI::Minimal is just a way to get access to CGI vars without
accepting all the more popular things CGI.pm gives.
$q-header(%header_props)
I'm *very* weak with Perl's object programming.
Cees, Mark, and I are in a conversation regarding changes to the
functionality of header_props() in version 3.2. Before I reply to
Cees'
message, I wanted to forward it to the list to get your input.
Regarding the cookie functionality: I would rather not fix problems
in
CGI.pm. That said,
Solution 1.
We could simply remove the catch/rethrow altogether, and leave it up to
Perl to say that the method can't be dispatched if that's the case:
Solution 2.
Slightly nicer than that: Pick off those cases where the run mode
method dispatch might fail and use the catch/rethrow to give a nice
Fred,
I'd like to measure the time taken to execute each particular hit to
cgi::app and display the result.
My thoughts on how to implement this are roughly:
* get the time $T1 in cgiprerun - store in $self
* get the time $T2 in cgipostrun and compute the difference
* output the result as a
I am starting a new project today which is going to have more 200 run
modes, and I would
like to break things up.
Next. I suppose I will have one base class which will be called form
CGI script.
This class will have only one run-mode, which will load config and
determine, which module to load
Is there a way to globally set the HTML::Template options when using
CGI::Application? TMPL_PATH allows you to set the template directory,
but
there are other application-wide setting like caching etc that I would
like
to set, but don't want to do it eveytime I call load_tmpl
You can have a
However, I strongly recommend a different name. :) The current name
sounds like you are adding support for HTML::Template to CGI::App
as a plugin...which doesn't make sense.
Yeah, I am not so happy about the name myself.
But I could not come up with anything better.
TemplateDispatcher?
The best name depends on what you consider the primary function:
Is the it the ability to handle nearly static pages easily, or the
'show_tmpl' system of handle data passed to the template?
I guess the runmode that automatically dispatches to your templates is
the main thing.
The system to handle
Hi all,
here is another plugin to discuss:
http://perl-pad.sourceforge.net/cgiapp/AutoRunmode.html
http://perl-pad.sourceforge.net/cgiapp/CGI-Application-Plugin-
AutoRunmode-0.01.tar.gz
The plugin lets you flag methods as Runmode and then you can call
them without setting up the usual name
Joel,
You might also look at using Template Toolkit (see site
http://template-toolkit.org).
It has scripts to allow whole websites to be built with the
invocation of a single script.
My favourite static renderer at the moment is HTML::Webmake.
http://webmake.taint.org/
It can also build/refresh
HtmlTemplate looked easy enough, but mentions problems with select
constructions. Does TT treat these more gracefully?
Just to remind everyone of our excellent Wiki, which has a whole page
on this topic:
http://twiki.med.yale.edu/twiki2/bin/view/CGIapp/SettingDropDownValues
I prefer
it would be nice to have
a wrapper around Apache::Request that supplies the missing methods.
That wrapper would function like a normal CGI.pm object for all the
CGI::App cares.
I like this idea. It seems like there would be some edge cases, though.
If you set something with 'param' with one
It's just that I've never needed a redirect in my life. I'm curious as
to how you've worked redirects into your way of thinking of them as
being part of your solution.
I have taken up the practice of ALWAYS redirecting after successfully
processing a POST request (to a page that shows the
Once these features are moved into CGI::App, I see the documentation
appearing a little out of the way in a section on WRITING PLUGINS or
Advanced Usage. There is no need for new users to be trying to
figure
out if they need these features, in my opinion.
The whole WRITING PLUGINS sections could
Hi,
It is unfortunate that it needs to be implemented using the prerun
hook, but I can see your reasons for not rewriting the 'run' method in
CGI::Application.
This module also shows a very good example of the potential usefulness
of the callbacks patch as well.
I updated the AutoRunmode plugin to
sub setup{
my $self = shift;
$self-use_plugin('::AutoRunmode');
}
where use_plugin() would use the plugin and call some install
method to let it set itself up.
I like the idea of making it less verbose. I haven't actually looked
at the callback implementation, but is it not possible to
Agreed, though I wish CGI::App would provide a means of catching that
and displaying it to the browser rather then throwing up a 500 error
and forcing a tail through the server error log.
For errors that occur in the run_mode itself, CGI::App has much
improved recently by allowing an error_mode
What I'm looking for is a method which i cause use 1 single runmode to
display any page in my system, [and let the pages more or less draw
them selves.] then other runmodes would only be used for doing
business logic, adding things to a database etc.. I thought of using
embedded perl with this..
Hi all,
I just saw that Randal L. Schwartz published CGI::Prototype on CPAN
yesterday.
http://search.cpan.org/~merlyn/CGI-Prototype-0.90/lib/CGI/Prototype.pm
The more, the merrier I suppose...
Thilo
-
Web Archive:
This should work ok with H::T. But, the only way I can make it work
with
C::A is if I write my own load_tmpl method to distinguish between the
first
load from file and second load from scalar. If C::A used H::T's -new
method, the source of the template could be passed as a parm on
load_tmpl
Hi all,
I am just looking at the DBH plugin and how it is used:
use CGI::Application::Plugin::DBH (qw/dbh_config dbh/);
sub cgiapp_init {
my $self = shift;
# use the same args as DBI-connect();
$self-dbh_config($data_source, $username, $auth, \%attr);
}
Since you need to get
names
as keys:
$app-param('::Plugin::DBH::dbh_config' =
{ my_handle = [ $data_source, $username, $auth, \%attr
] ,
my_other_handle = [ $data_source, $username, $auth,
\%attr ]
} );
200a276,278
Autoconfig Support added by:
Thilo Planz
Hi Dan,
For some reason, one of my CGI::Application modes outputs the source in
Firefox instead of the formatted HTML itself (it works fine with MS
Internet
Explorer)
That sounds a lot like a wrong content-type header (which MSIE seems to
ignore).
Before trying to find out what is causing this,
Hi all,
here is another take on one of my favourite topics, the automatic
discovery of run modes.
Basically, I want to have CGI::App to look at my application instance
and call a method of the
same name as the requested run-mode. Because of the security problem
inherent in this approach,
Hi all,
thanks for the feedback.
this would be especially useful if you were allowed to have more than
one delegate...as it would open the way for run-mode reuse across
applications.
You can have delegates that inherit from (possibly multiple) other
(delegate) classes.
That should solve the
Wow, that's a great idea. In fact, what would be more useful for me
would be a way to mix-in runmodes from other classes (or delegates).
Also note that you can already do the following in CGI::App to access
runmodes defined in other packages:
sub setup{
my ($self) = @_;
Also note that you can already do the following in CGI::App to access
runmodes defined in other packages:
sub setup{
my ($self) = @_;
$self-run_modes( 'start' = 'MyRunModes::blah' );
}
To spare me digging into the code, what does the above actually do?
Sorry for the brevity of the
Adding an
attribute is as simple as this:
sub my_runmode : RunMode {
...
}
Well, not quite.
In order to be able to set attributes, you have to write some code.
Without it, the sample above will just produce:
Invalid CODE attribute: RunMode at /tmp/t.pl line 7
BEGIN failed--compilation aborted at
If you use the CGI::Application::Plugin::AutoRunmode it will install
handlers for an attribute Runmode
into the CGI::Application package ( I am not totally comfortable with
this, it should install these in the sub-class that you
are actually using to reduce potential clashes with other attributes,
Hi all,
If you haven't heard of XMLHTTPReqeust aka Remote Scripting aka AJAX
it's basically a way for web pages to communicate with the server and
return information through JavaScript without having to refresh the
page.
For those interested in using JavaScript to update parts of the page
Hi Peter,
About question one:
sub cgiapp_init
{
$self-tmpl_path('/Library/WebServer/CGI-Executables/kartingdata/
templates/');
}
sub logon
{
my ($self, @args) = @_;
my $page = HTML::Template-new(filename = 'logon.tmpl');
I get the error . . .Cannot open included file logon.tmpl . . .
the
Dan,
I guess the other benefit I'm looking to receive is the caching
of templates. But I don't want to go through all of my modules adding
the
cache option to load_tmpl. Can I set this somehow in my base class's
prerun
or init methods?
You can override your base class's load_tmpl method (now
I am in the process of updating the AutoRunmode plugin to use the new
hook interface.
Unfortunately, it seems that CGI::App prerun will always run after all
the hooks. I am not sure how to resolve this without requiring
additional hooks
such as 'after_prerun'.
I will probably just point
How about this:
sub my_run_mode : DefaultRunmode {
# do something here
}
That looks entirely doable, and not even too difficult, but I am not
sure if I want to implement it,
mostly because the functionality is already in CGI::App, which defines
a default run-mode named start.
So you can
Cees,
it seems my assumption earlier today, that
sub start : Runmode {
}
would work as a default run mode, was partly mistaken.
It does work, but only if you override the setup in CGI::App,
because the default setup registers a start runmode as method
dump_html.
Since start is then
I thought of the same idea as Cees independently and would also like to
see this happen.
Okay, I'll work on that.
Also, is there a particular reason to use StudlyCaps when this_style
is the convention for names in CGI::App?
If you refer to the Runmode attribute, all-lower-case attribute
Hi Rhesa,
- add_callback() accepts both a coderef and a string. Class::Trigger
only accepts coderefs. Why did you decide to accept sub names as well?
The whole system of overloadable methods in sub classes depends on that.
So an alternate implementation had better preserve it.
Cheers,
Hi Mark and Cees,
How about this:
sub my_run_mode : DefaultRunmode {
# do something here
}
If I saw this I would know what the run mode does, /and/ that is the
default:
college_application_form : StartRunMode
I started to work on this, but I am afraid it is not so easy.
The
Hi Mark,
sub first : StartRunmode {
my $self = shift;
return $self-forward('second');
}
The current AutoRunmode plugin does not support StartRunmode, but
since you really seem to like that feature, I guess I should try to
implement it ...
AnyTemplate can figures out the file name for
Ideally there would need to be a runmode evaluator in the pre_run
method that examined the requested URL and/or PATH_INFO in addition to
the HTTP method of the request. So it would not be enough to say a
PATH_INFO value of /article means I can method view_article. Chances
are you would want to
sub first : StartRunmode {
my $self = shift;
return $self-forward('second');
}
The current AutoRunmode plugin does not support StartRunmode, but
since you really seem to like that feature, I guess I should try to
implement it ...
I have put something together now.
It works by
This means that it will not be possible to mix the class-based
:StartRunmode with the traditional instance-based
$app-start_mode(new_name).
You will not be able to change the start_mode from an instance script.
I think that is acceptable. I don't think it would be advisable to
mix the styles
Exactly my point. This list /is/ a developers list, and newbies are
welcome. So why do we need 2 lists?
Because newbies are turned off by mostly dev talk. If CGI::App wants to
attract new users, why not create a forum geared for them?
How many forums do we need ?
Does not this just
Hi,
Does this cgiapp_init get called for each run mode. I put a database
query into this and the resultant strings were put into params. This
slowed down the entire application.
Every stage in CGI::App is executed for every request:
1) create the $app instance
2) run setup, init, prerun, the
I have not used Persistent Perl, but FastCGI is quite stable in my
experience.
Can it cache DB connections, or is a connection made per request?
Except for not being able to access Apache internals, PPerl and FastCGI
should not be much different than mod_perl in this respect.
You can
Hi Mark,
I'd like to discuss possibilities to make this more flexible. Right now it
considers every method in a delegate class to be a run mode.
I would like a way to mark only some of the methods for use.
Hmm.
My concept for the module was that a delegate is a class
that only contains
All runmodes including start rm into ./runmodes folder:
Error executing class callback in prerun stage: could not evaluate
runmode in file ./runmodes/start.pl: Bad file descriptor at
C:/usr/local/site/lib/CGI/Application/Plugin/AutoRunmode.pm line 220.
I have seen that error message when the
Hi Giannis,
Just moved a C::A under mod_perl 2 and CAP::AutoRunmode is not working.
Runmodes defined by CAP::AutoRunmode are not recognized.
The runmodes can not be found / seem not registered.
In plain cgi and persistentperl runmodes are ok.
I hope to have fixed this issue in the 0.14
59 matches
Mail list logo
