Re: [cgiapp] :StartRunmode
On 7/14/05, Thilo Planz [EMAIL PROTECTED] wrote: I have another question for you about the plugin. I noticed in the current version, if I put the use CGI::Application::Plugin::AutoRunmode in my base class, I don't automatically have the ability to use the Runmode attributes in my subclasses, and I have to add the 'use' statement again. That is weird, it is supposed to work and I have cases like that in the test suite that do work. Are you using use base or some @ISA magic that probably gets executed too late (outside of a BEGIN block) ? It looks like you need to use the AutoRunmode plugin after the use base qw(CGI::Application) statement. I guess that makes sense, since AutoRunmode tries to register a callback during the import, so CGI::Application will need to be loaded at that time for it to work. So it was a silly mistake on my part. Thanks for that. 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]
Re: [cgiapp] RFD: Developer mailing list?
On 7/14/05 at 10:30 AM, [EMAIL PROTECTED] (Mark Fuller) wrote: It seems like there's been a significant increase in development-related topics over the past month. I'm not complaining. But, is there a risk that newbies might find it harder to locate information in the archives? Or, feel less inclined to subscribe if they're less interested in development topics? (To prospective users of C::A, is this noise? It's not to me! I'm just asking if it could impede non-developer acceptance of C::A.). I think having both a 'users' and 'dev' list would be a good idea. Andrew - 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] Catalyst movies!
Hi, Maybe you are interested in seeing some more about Catalyst too, just in case you're not on the Catalyst list or PerlMonks. Here are some movies showing it in action. http://dev.catalyst.perl.org/wiki/Movies http://breen.irt.drexel.edu/mirrors/catalyst/vid/ catalyst_auto_complete_take1.mov http://www.dunkelheit.at/catalyst/catalyst_auto_complete_take1.mov http://users.ox.ac.uk/~oliver/data/files/ catalyst_scaffolding_with_cruds_take1.mov http://www.dunkelheit.at/catalyst/ catalyst_scaffolding_with_cruds_take1.mov Have fun! -- sebastian - 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] Re: RFC: CAP::Plugin::PathInfo
On Date: Thu, 14 Jul 2005 00:08:53 -0400, Timothy Appnel [EMAIL PROTECTED]
wrote:
On 7/12/05, David Emery [EMAIL PROTECTED] wrote:
Q: I had the impression from your REST post that DELETE and PUT were
unusable from a practical POV. Are you actually able to use those in
real life?
It's still useful in non-browser systems like a web service API gateway.
I see.
...
My instinct is all that is needed for now is a
handler to register run modes based on some path_info prefix and HTTP
request method and an associate to evaluate which method to execute. I
don't think breaking the pathinfo up into pieces is that helpful
because it will vary on the implementation. It's also not that hard to
do -- probably a second split call should do it.
I've read a bit more about REST, and looked at the code of Catalyst
and REST::Application. I think what you suggest can be implemented by
overriding CAP's run mode setup and instead setting the run mode based
on user-defined regexes matched against the path_info.
I threw together a rough plugin as a proof of concept. I'm not really
sure that this is the ideal way to do it, but I've tried it out and it
seems to work as I'd hoped. Here's an example of how I use it in my
POC app. The sample URL's may not be entirely RESTful, but I think it
shows the general idea.
use CGI::Application::Plugin::REST; # no exported methods
...
sub setup {
my $self = shift;
# note: no regular run mode setup
# Set path_info regexp to runmode map
$self-param(
'path_to_runmode' = {
# The simplest scenario
# If path_info starts with /list set runmode to rm_list
# pointing to sub of same name
#
# i.e. http://xx.com/stuff.pl/list
# (the .pl isn't RESTful, but mod_rewrite can fix that)
qr{^/list} = rm_list,
# Runmode set to rm_view
# Matching parens content will be assigned to query params
# called item_id and output format
#
# i.e. http://xx.com/stuff.pl/view/123.html
# or http://xx.com/stuff.pl/view/123.pdf
qr!^/view/(\d+)\.([a-zA-Z]{3,4})! =
[rm_view, item_id, output_format],
# Different runmode depending on request method
#
# i.e. http://xx.com/stuff.pl/edit/123
qr{^/edit/(\d+)} ={
GET = [rm_edit, item_id],
POST = [rm_edit_in, item_id],
},
# Since we've eliminated the normal runmode set-up, set a default
default_runmode = rm_list,
}
);
}
The above works pretty similarly to REST::Application's resourceHooks
(run modes) set-up. One difference is that RA passes the data in the
matching parens of the regex directly as arguments to the run
mode. That isn't possible with CAP, so I add them as query params with
the option of setting their names in the set-up.
I've implemented it as a plugin, which sets a callback at the prerun
stage to set prerun_mode(). Is there any other way to override CAP's
runmode setup?
The code inside the plugin is largely taken from REST::Application.
If anyone is interested, I can clean it up a bit and put it online
somewhere or email it next week. It's a long weekend here in Japan
(Monday is Ocean Day) so I'll be away from the computer for a few
days.
Dave
-
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] Re: ANNOUNCE: ::Plugin::ValidateRM 2.00_01 with new dfv() method
Mark Stosberg wrote:
Thanks for the feedback Michael. Comments below.
On 2005-07-12, Michael Peters [EMAIL PROTECTED] wrote:
Mark Stosberg wrote:
Hello,
I've just uploaded a new developer release of ValidateRM to CPAN, which
you can also get here:
http://mark.stosberg.com/dfv/CGI-Application-Plugin-ValidateRM-2.00_01.tar.gz
I added a dfv() method as an alternate way to access the results object
that's generated. I think this will be of primary interest to other
plugin authors rather than users.
Nice! Since there is now a better way to access the results how about
making the return from check_rm cleaner too? Would you consider allowing
my $error_page = $self-check_rm(...);
It would just have to check wantarray() to DTRT in scalar context. This
would simplify things a lot IMHO. And it would still be backwards
compatible.
I'm not included to do this. Here's why.
# What's going on here? These statements don't seem related
# ... unless I go read some documentation.
my $error_page = $self-check_rm(...);
$self-dfv-valid('email');
# Oh, now I see the connection.
my ($results,$error_page) = $self-check_rm(...);
$results-valid('email');
Well, I don't expect most people would do the first option. It would
probably look more like:
my $error_page = $self-check_rm(...);
if( $error_page ) {
return $error_page;
} else {
my $email = $self-dfv-valid('email');
}
Which seems very readable to me.
Passing data around in through the object is one step away from the
evilness of global variables.
That's a little overstated imo. Object data is a great place to put
information that should persist for the duration of that object (for the
entire request cycle in the case of C::A).
Why is the above an abuse of dfv()? What wouldn't be a bad use?
Explicit parameter passing is easier to debug and less error prone in my
opinion.
I agree. I'm not talking about trying to avoid passing the results
object to other subs that might need it. I'm talking about having a
method return multiple items when there's a perfectly good object to get
them from later should you want them.
--
Michael Peters
Developer
Plus Three, LP
-
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] Re: ANNOUNCE: ::Plugin::ValidateRM 2.00_01 with new dfv() method
On 7/15/05, Michael Peters [EMAIL PROTECTED] wrote:
my $error_page = $self-check_rm(...);
if( $error_page ) {
return $error_page;
} else {
my $email = $self-dfv-valid('email');
}
Which seems very readable to me.
I don't want to join the debate on whether this is a good idea or not,
but I would rather see the above structure in reverse:
my $valid = $self-check_rm(...) or return $self-dfv-error_page;
You could probably come up with some better names than what is written
above (error_page seems to indicate a hard error, instead of a
validation problem), but that structure seems clearer to me.
What I am interested in when I call check_rm is the validated results
of the operation. The error page is a secondary convenience, so it
should be treated that way.
This structure also closely resembles what is sometimes used to pass
error messages back after a failed function call (look at DBI for an
example). If the function call returns a false value, call 'this'
method to see what the error message contains.
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]
Re: [cgiapp] RFD: Developer mailing list?
On Fri, 15 Jul 2005 11:27:05 -0400, Andrew Brosnan wrote: Hi Andrew I think having both a 'users' and 'dev' list would be a good idea. My vote is against. The negatives, as I see them, are: o Complexity. It's not just a list, it's /another/ list. For what gain? o Confusion. Which do I, experts, beginners, subscript to? Post to? Where do I look (ie the archives are now split, for what gain)? o Volume: How much traffic will there be on the lists? o Similarity. Why should traffic be split when all, or most of, the topics are the same? -- Cheers Ron Savage, [EMAIL PROTECTED] on 16/07/2005 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company - 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] RFD: Developer mailing list?
From: Ron Savage [EMAIL PROTECTED] The negatives, as I see them, are: - Complexity. It's not just a list, it's /another/ list. For what gain? Hi Ron. Why are general user and developer lists complex? Developers should be able to cope with this. Your average newbie wouldn't have to. - Confusion. Which do I, experts, beginners, subscript to? Post to? Where do I look (ie the archives are now split, for what gain)? I agree that there may be a lot of crossover between topics on both lists. But, there are clearly development discussions occuring which are beyond the pervue of the average C::A user. I was just thinking about how a less-technical person might be overwhelmed by the topics occuring here. If I've heard C::A is fantastic, and I just want to skim the mailing list to gain some understanding about what's been discussed (regarding usage), I might run into these plug-in development discussions and think that the whole thing is beyond me. And then there's the issue of using the archive's search capability for user self-help. Mark S. said that's going to be remedied by using the wiki to hold the best postings. If that's true, will the search button have a big fat Don't expect meaningful results here, see the wiki instead banner? :) - Volume: How much traffic will there be on the lists? - Similarity. Why should traffic be split when all, or most of, the topics are the same? These seem like the same issue. And, you may have a point. There's not a lot of newbie postings here. I don't know if that bodes well or not. Is C::A so easy to use that nobody needs to ask anything? Or, is it not gaining momentum? I hope it's the former! I'm just trying to view this from a less sophisticated user's standpoint (which probably described me when I stumbled onto C::A). I'm wondering if the more sophisticated discussions would have helped or hurt me back then. And, yes, I realize the irony of me questioning the possibility of noise after my recent discussion about the param method and the shared self object. :) Mark - 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] RFD: Developer mailing list?
On Fri, 15 Jul 2005 18:25:15 -0700, Mark Fuller wrote: Hi Mark These seem like the same issue. And, you may have a point. There's not a lot of newbie postings here. I don't know if that bodes well Exactly my point. This list /is/ a developers list, and newbies are welcome. So why do we need 2 lists? -- Cheers Ron Savage, [EMAIL PROTECTED] on 16/07/2005 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company - 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] RFD: Developer mailing list?
On 7/16/05 at 11:29 AM, [EMAIL PROTECTED] (Ron Savage) wrote: On Fri, 15 Jul 2005 18:25:15 -0700, Mark Fuller wrote: Hi Mark These seem like the same issue. And, you may have a point. There's not a lot of newbie postings here. I don't know if that bodes well 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? Or not...whatever. :-) Andrew - 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] RFD: Developer mailing list?
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 fragment the user community to the point where the forum becomes deserted? I think it is perfectly acceptable (and probably most productive) for newbies to post on Perlmonks. Just my two yen, Thilo - 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] RFD: Developer mailing list?
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 fragment the user community to the point where the forum becomes deserted? I joined as a newbie. I have learnt, and continue to learn, a lot from this list. I ignore topics which have been or which are over my head, and in fact, it helps to stretch your skills by following the threads. Dan - 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]
