[cgiapp] problem using CA::Dispatch with CAP::AutoRunmode (latest versions)
I think I have finally tracked down the problem I have been seeing
when using CGI::Application::Dispatch with
CGI::Application::Plugin::AutoRunmode. CAP::AutoRunmode was failing
to register my runmodes whenever I used CA::Dispatch.
There is a very simple solution for this. Just load
CGI::Application::Plugin::AutoRunmode inside of the dispatch script.
That seems to solve the problem for me.
Following is a test case that shows the problem:
sample.cgi
-
#!/usr/bin/perl
use strict;
use warnings;
use lib qw(.);
use CGI::Carp qw(fatalsToBrowser);
##use CGI::Application::Plugin::AutoRunmode;
use CGI::Application::Dispatch;
CGI::Application::Dispatch-dispatch(
TABLE = {
'sample' = 'Sample',
},
DEFAULT = '/sample',
);
-
Sample.pm
-
package Sample;
use base qw(CGI::Application);
use CGI::Application::Plugin::AutoRunmode;
use CGI::Carp qw(fatalsToBrowser);
sub one : StartRunmode {
my $self = shift;
return CGI::start_html( )
. CGI::h2('Sample page one')
. CGI::a( { -href = $self-query-url().'/sample/two' },
'goto page two' )
. CGI::end_html();
}
sub two : Runmode {
my $self = shift;
return CGI::start_html( )
. CGI::h2('Sample page two')
. CGI::a( { -href = $self-query-url().'/sample/one' },
'goto page one' )
. CGI::end_html();
}
1;
-
If you call sample.cgi you will end up seeing the default 'start' page
that CGI::Application provides instead of the StartRunmode that we
marked. If you first load AutoRunmode in the sample.cgi script, then
you will see the correct page.
Cheers,
Cees
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: AJAXifying of C::A::Search
On 2005-11-09, Michael Peters [EMAIL PROTECTED] wrote: + No page reload for results. After pressing the 'submit' button (or one of the page links) a page will not be reloaded, but the new results will simply be shown below. This should actually speed things up, especially on sites that have some dynamic stuff happening in navs and sidebars. I'd like this worked, and fell back to the current way if the browser is detected not to be able to handle the AJAX. + Auto-Complete/Suggest search field. As the user types they will see suggestions of what to search for (similar to Google suggest and other apps). Now, how do people want the Auto-Complete field to work? Should it suggest words that are known to be in the documents indexed? Should it just show phrases that this user has previously searched for (most browsers do this anyway)? Should it suggest phrases that other people have previously searched for? Or should it not care, but rather be pointed to a datasource of words/phrases to use and not care where it came from. I find Google suggest annoying and don't use it. On small and/or local site, revealing what other people searched for could be a privacy issue in some cases. I think Auto complete works best against a fixed list of names. For example, looking up a business name from a list of 500 possibilities, which would be too big for a drop down menu. I wouldn't want to use this feature. Also, more architectural, should the AJAX niceness be configurable within C::A::Search, or should a separate C::A::Search::AJAX module exist (probably within the same distro) so that developers aren't confused? If it's fairly simple and optional, leave it in the core module. If it adds significant complexity or requirements, go with a seperate module. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] callback ordering (was: Re: RFC: Merging CGI::App Callbacks with Class::Trigger)
On 2005-11-04, Cees Hek [EMAIL PROTECTED] wrote: ps One more thing that we haven't revisited yet (and is also not supported in Class::Trigger either) is callback ordering. We use a FIFO (first in first out) approach, since we could not agree on (or come up with) a good ordering mechanism. I still think it might be nice to have the ability to control the execution order of all the callbacks registered at one hook location (even though I haven't absolutely needed it yet). I just want to agree that I thinmk this is still a desirable feature. I'm not feeling smart enough at the moment to propose a specific solution, though. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: ANNOUNCE: CGI::Application::Demo V 1.01
On 2005-11-10, Ron Savage [EMAIL PROTECTED] wrote: CGI::Application::Demo is a vehicle for the delivery of a sample CGI::Application application, with these components: Hello Ron, I read through the main docs and reviewed the source of a few modules. It's not clear to me what exactly this delivery vehicle does. Is it actually a sample application, or is it really just the delivery vehicle? When I think of a demo, I think of things that a really easy to try. For a web application, I think of a link to a URL or screenshots, and some source code links. Clearly the source is here, but at the moment this doesn't seem one-click-demo easy to try. It's also not really clear what to expect. It has something to do with Faculty, but what? I do like the idea of having more demos of C::A out there, and appreciate your thinking along these lines. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Help with CGI::Application::Plugin::HTMLPrototype
On 2005-11-09, Prakash Inuganti -X (pinugant - Ahura Inc. at Cisco) [EMAIL
PROTECTED] wrote:
Can you help me with a small example to use
CGI::Application::Plugin::HTMLPrototype in HTML::Template. I am trying
to add a row of data dynamically retrieved by an sql query when a user
enters a date into text field.
Prakash,
You might consider using the HTDot plugin, which adds a dot notation for
method calls to HTML::Template, like Template Toolkit has. You can
access all methods in the CGI::App object by adding this:
$t-param( c = $self );
I have submitted a patch so the next version will do this by default.
Then it's all very simple. Just put code like this in your template:
!-- tmpl_var c.prototype.define_javascript_functions --
a href=# onclick=javascript:tmpl_var
c.prototype.visual_effect('Appear','extra_info') return false;Extra Info/a
div style=display: none id=extra_infoHere is some more extra info/div
Mark
--
http://mark.stosberg.com/
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
