Re: [cgiapp] ActionDispatch setup
I am jumping in with both feet in writing my first C::A app by using the
ActionDispatch plugin [1]. In my reading the docs suggest that there is
no need to setup the run modes, that is if I have in MyApp.pm
sub fiveDigitCofips : Path('cofips/(\d{5})') { . . . }
The Path attribute shouldn't really have regular expression in it
use the Regex attribute for that.
Regex('configs/(\d{5})') --should work
On another note, I saw this post yesterday and I figured I'd take a
look at this module again. I haven't really programmed in Perl in
over a year. However, since at least one person maybe using the
module ;), I figured I'd fix some outstanding problems. The version
on CPAN even had an erroneous print used for debugging that would
screw up HTTP headers. Whoops.
Hopefully by the time people read this it is uploaded. Check here.
http://search.cpan.org/~jaywhy/CGI-Application-Plugin-ActionDispatch/
--
Jason Yates
[EMAIL PROTECTED]
-
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] ANNOUNCE: CGI::Application::Plugin::ActionDispatch
Previously called CAP::Attributes, CAP::ActionDispatch takes the
PATH_INFO and dispatches requests based on the attributes you've setup
in your class.
Not much has changed functionality-wise snce the developer release.
However I've fixed a few bugs, specifically using subclasses now works
properly. Thanks to Rhesa on IRC for pointing this out. Also the
module should now work properly with other modules which use
attributes, thanks to Cees for pointing me in the direction of the
Attribute::Handlers module.
The module is avaiable on CPAN here:
http://search.cpan.org/~jaywhy/CGI-Application-Plugin-ActionDispatch-0.02/
Here is a brief example.
package WebApp;
use base 'CGI::Application';
use CGI::Application::Plugin::ActionDispatch;
sub list : Regex('^/products/(\w+)/(\d+)') {
my $self = shift;
my($category, $id) = $self-snippets();
...
}
1;
Feel to ask any questions and feedback is welcome. Thanks.
--
Jason Yates
[EMAIL PROTECTED]
-
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] CGI::Application::Plugin::Attributes developer release
I have a developer release of my Attributes plugin up. The plugin
takes the PATH_INFO and dispatches the requests based on the
attributes you've setup in your class. This is very similar to how
Catalyst works. This plugin should't break the default behavoir of
cgi-app. So you should be able to intermix both approaches.
The is a developer release so use in production at your own risk.
However I don't think the interface will change much. It's not on
CPAN yet, so you have to get it from here:
http://home.comcast.net/~jaywhy2/plugin-attributes.tar.gz
Here is a short example, check the perldoc for a more thorough example:
sub setup {
my $self = shift;
$self-mode_param('test_rm');
$self-run_modes(
basic_runmode = 'basic_runmode'
);
}
sub basic_runmode {
}
# http://example.com/myapp.cgi/products/this/is/optional/and/stored/in/snippets/
sub product : Path('products/') {
my $self = shift;
my($category, $product) = $self-snippets();
}
# http://example.com/myapp.cgi/products/music/product/
sub music : Path('products/music/') {
my $self = shift;
my $product = $self-snippets();
}
# http://example.com/myapp.cgi/products/music/beatles/
sub beatles : Regex('^/products/music/beatles\/?') {
my $self = shift;
}
I'd love feedback, patches, or whatever.
--
Jason Yates
[EMAIL PROTECTED]
-
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]
Re: [cgiapp] CGI::Application::Plugin::Attributes developer release
I haven't tried it yet, but it definitely looks useful. I'm a fan of the global dispatcher myself, but I can see the appeal of this approach as well. My only complaint is the name. I guess by global dispatcher you mean C::A::Dispatch. I wonder if they could be used together. I was personally going to create a mod_perl handler similar to yours in C::A::Dispatch. However instead of dispatching directly to runmode, I would just forward the request to the right class. Then let CAP::Attributes take over from there. Maybe have something like CGI::Application::Dispatch::Table(your method) and CGI::Application::Dispatch::Attr. Just a thought. It doesn't describe what it does but rather describes an implementation detail. Maybe CAP::AttributeDispatch CAP::SubDispatch CAP::MethodDispatch Not that those are much better :) Hah! This was the major reason I'm not putting it on CPAN yet, because of the dumb name. I just couldn't think of anything better. Those are certainly much better than the name now. I should use a name like C::A::P::ThisModuleSucks to force me to change it next time. -- Jason Yates [EMAIL PROTECTED] - 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]
Re: [cgiapp] new CGI::Application::Dispatch and URL generation
Pretty cool module, this is my first look at it. I did something
similar awhile back for a project using REST. I wish this module was
around when I did it :).
Just to give you an idea, I ended up using regular expressions instead
of literal string comparisons. You could do both just use something
else for regex table_regexp. I did something like this(trying to
use your syntax):
my($module,$rm);
my $path = $ENV{'path_info'};
foreach my $t (keys %{$table_regexp}) {
if((@args) = ($path =~ /$t-{path}/)) {
$module = $rmodes-{$t-{app}};
$rm = $r-{rm}
last;
}
}
$self-require_module($module);
$module-$rm(@args);
If you're interested maybe I'll hack up a patch.
--
Jason Yates
[EMAIL PROTECTED]
-
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]
Re: [cgiapp] XMLHTTPRequest / Remote Scripting / AJAX
On Thu, 10 Mar 2005 13:53:48 -0500, Steve Comrie [EMAIL PROTECTED] wrote:
I converted their demo app -
http://www.modernmethod.com/sajax/sajax-0.8/php/example_multiply.php to one
running on my code using C::A - http://www.unobserved.org/misc/rs/
I wish I could see the code. However
http://www.unobserved.org/misc/rs/ is done for me.
Interesting you posted about xmlhttp. I've been using xmlhttp alot
lately using cgi-app. Basically, the only thing I've done was make it
so I could pass an argument to the script and it would return XML
instead of using TT(template toolkit).
sub myrunmode {
my $self = shift;
my $params = {}
return $self-process('mytemplate.tmpl', $params);
}
sub process {
my($self, $mytemplate, $params) = @_;
if($self-query-param('xml')) {
use XML::Simple;
my $xml = new XML::Simple (noAttr=1);
$self-header_props(-type=text/xml);
return $xml-XMLout($params);
} else {
$self-tt_process($mytemplate, $params);
}
}
Whats great about this is, for me at least, no code has to get changed
to use this and you can use something like REST to access your webapp.
Also another thing, with TT you usually need a TON of more data inside
the params hash. Then you'd need with xmlhttp. Basically because
with TT you're building a whole page, and with xml http you're
building a part or section of a page. In my case I was also doing
worthless queries etc. So beware of this. In my case I created a
wrapper, using cgi-app, around modules that I would normally just
include into my application modules.
--
Jason Yates
[EMAIL PROTECTED]
-
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] CGI::Application::Plugin::Auth -- alpha release
CGI::Application::Plugin::Auth adds authentication and authorization support to CGI::App. For futher information on use check out the pod. The auth module can be found here. http://home.comcast.net/~jaywhy2/auth.tar.gz You will also need the callbacks version of CGI::App mentioned here. http://www.mail-archive.com/cgiapp@lists.erlbaum.net/msg02800.html You'll also need my very small patch to the callbacks version of CGI::App. I patched the version I got off of the darcs server. So use that, instead of the tar'd version which I believe is different. http://home.comcast.net/~jaywhy2/cgiapp-callbacks.patch Phew! Hopefully thats not too confusing. Any criticisms on design, features, etc would be greatly appreciated. -- Jason Yates [EMAIL PROTECTED] - 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]
Re: [cgiapp] CGI::Application::XML
Terrence Brannon wrote: Do you have any practical examples demonstrating the need for XML to XML transformations? There are tons of uses for XSLT. The simplest and most known is transforming XML into HTML. XSLT can seperate content and presentation simlar to HTML::Template or TT2. But unlike these template options, XSLT is standard compliant and works beyond the world of Perl. Of course, there are many other less known uses for XSLT. XML transformation into PDF, JPEG, SQL, etc. And could you show some source code for how this is done? I never could fathom Matt Sergeant's XML::(LibXML|LibXSLT|XPath) modules. The Perl interface is fairly simple. I'm guessing you're having problems with XSLT itself. The documentation on XSLT for the most part is cut and paste from the W3C standard. Which usually aren't the easiet reads. Here are some good articles on XSLT. http://www.xml.com/pub/a/2000/08/holman/index.html http://www.vbxml.com/xsl/tutorials/intro/default.asp If your still having problems. I'd be happy to help of list. I was able to find the nodes I wanted via XML::XPath, but because they were XML::XPath objects, I did not know how to manipulate them to change the XML as I desired. XML::XPath really isn't used to manipulate XML. Rather its used to extract XML data. - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] CGI::Application::XML
Attached is a module I wrote today. Hopefully you guys can put it to
good use. The module is pretty simple. Basically instead of your
runmodes returning HTML, CGI::Application::XML expects runmodes to
return XML. The module is simple to understand, but I made an example
to explain its use.
Example of use:
###WebApp.pm###
package WebApp;
use XML::LibXML::SAX::Builder;
use XML::Generator::DBI;
use DBI;
use base 'CGI::Application::XML';
sub setup {
my $self = shift;
$self-set_stylesheet_dir(/var/www/xslt/); #set the location of
the xslt stylesheets
$self-start_mode('mysql');
$self-mode_param('rm');
$self-run_modes(
'mysql' = 'do_mysql',
);
}
sub cgiapp_postrun {
my $self = shift;
$self-serialize(shift); #Most have this line in your cgiapp_postrun
}
sub do_mysql {
my $self = shift;
my $sql = 'select * from user';
my $dbh = DBI-connect(
'dbi:mysql:database=mysql;host=localhost','username','password') || die
database connection couldn't be initialized: $DBI::errstr \n;
my $builder = XML::LibXML::SAX::Builder-new();
my $gen = XML::Generator::DBI-new(Handler = $builder,
dbh = $dbh,
RootElement = 'mysql',
QueryElement = 'userlist',
RowElement = 'user');
$gen-execute($sql) || die Error Building DOM Tree\n;
return $builder-result()-toString(1);
}
1;
###webapp.cgi###
use WebApp;
my $webapp = WebApp-new();
$webapp-run();
###mysql.xslt###
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns=http://www.w3.org/TR/xhtml1/strict;
xsl:output
method=xml
indent=yes
encoding=iso-8859-1
/
xsl:template match=mysql
html
head
titlemySQL User List/title
/head
body
table border=1
tr
tdbHost/b/td
tdbUser/b/td
tdbPassword/b/td
/tr
xsl:for-each select=userlist/user
tr
td
xsl:value-of select=Host /
/td
td
xsl:value-of select=User /
/td
td
xsl:value-of select=Password /
/td
/tr
/xsl:for-each
/table
/body
/html
/xsl:template
/xsl:stylesheet
package CGI::Application::XML;
$CGI::Application::XML::VERSION = '0.1';
use strict;
use XML::LibXML;
use XML::LibXSLT;
use CGI::Application;
@CGI::Application::XML::ISA = qw(CGI::Application);
#Path to XSLT stylesheets
sub set_stylesheet_dir { $_[0]-{CGIAPPXML_STYLESHEETDIR} = $_[1] }
sub get_stylesheet_dir { $_[0]-{CGIAPPXML_STYLESHEETDIR} }
#Current stylesheet for runmode
sub get_stylesheet {
my $self = shift;
return $self-{CGIAPPXML_CURSTYLESHEET} || $self-{CGIAPPXML_STYLESHEETDIR} .
$self-get_current_runmode . .xslt;
}
sub set_stylesheet {
my $self = shift;
$self-{CGIAPPXML_CURSTYLESHEET} = $self-{CGIAPPXML_STYLESHEETDIR} ?
$self-{CGIAPPXML_STYLESHEETDIR} . shift : shift;
}
#Serializes data in body
sub serialize {
my $self = shift;
my $bodyref = shift;
my $style_doc = $self-get_stylesheet;
my $parser = XML::LibXML-new();
my $xslt = XML::LibXSLT-new();
my $source = $parser-parse_string($$bodyref);
my $stylesheet = $xslt-parse_stylesheet_file($style_doc);
my $result = $stylesheet-transform($source);
$$bodyref = $stylesheet-output_string($result);
}
1;
-
Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
