Re: [Catalyst] problem with FormBuilder + TT2
John Napiorkowski wrote:
>
> (snip)
>
> Hey, question for you; are you using Formbuilder with
> a database? If so what are you doing to manage
> getting stuff between formbuild and your datbase of
> choice? I'm using DBIx and just doing braindead stuff
> like writing a bunch of $c->form->field(name=>,
> value=>) but I figure there's a better way. I just
> can't seem to get DBIx::Class::FormTools to do what I
> think it can do for me. Maybe I just need more work
> on it.
I'm using Catalyst::Plugin::FormBuilder and in order to transfer data back
and forth between the forms and the database (accessed with DBIx::Class) I
do something like:
1. Make sure that your form-fields have the same names as your columns
accessors.
2. Give your sub-routines to which Catalyst dispatches your URL's the ":
Form" attribute.
3a. To add a record:
my ( $self, $c ) = @_;
if ($c->form->submitted && $c->form->validate) {
my $record=$c->model('Your::table')->create(scalar
$c->form->field());
}
3b. To edit a record:
my ( $self, $c, $key ) = @_;
my $record=$c->model('Your::table')->find($key);
if ($c->form->submitted && $c->form->validate) {
$record->update(scalar $c->form->field());
}
else {
map {$c->form->field('name' => $_, 'value' => $record->$_)}
$c->form->field();
}
Easy as pie!
Karl
aka CountZero at Perlmonks
~~~
This message and any attachments are confidential. If you have received
this message in error please delete it from your system. If you require any
assistance please notify the sender. Thank You.
~~~
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Trouble with Chained Actions and Redirects?
John Napiorkowski said: > I have a controller with some chained actions. One of > the actions (not an endpoint) will redirect given a > certain value for the arguments. However I find that > this doesn't stop the chain from completing. I still > get a line about the redirect in the log, but the > endpoint in that chain still activates. > > I find that this doesn't happen when I use $c->detach, > although in this circumstance detach is not the best > use for me. Of course, redirect and detach/foward are completely different. While redirect may seem like "external detach," it isn't. A redirect is an answer to the browser, telling him to look up another site. A forward or detach moves the execution to another action. If you call redirect, it will just set the appropriate headers. It can't just stop there, because you might want to change those headers or do something else before the redirect (E.g. Setting a message in the flash). > Has anyone run into this before and found a way around > it? See Ash's answer, if you want to detach, detach :) (Note that detach can also be called without arguments at all, just ending the execution). hth, Robert ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] problem with FormBuilder + TT2
On Sep 19, 2006, at 1:37 AM, Moritz Sisenop wrote:When I try$c->path_to(qw/root customers signup.tt2/)there is no Catalyst error message anymore. Just a TT one: "Not a GLOB reference at /usr/local/lib/perl/5.8.7/Template/Provider.pm line 647." Template Toolkit doesn't know what to do with the Path::Class::File object that path_to is going to return,use $c->path_to(qw/root customer signup.tt2/)->stringify instead.-- Jason Kohles[EMAIL PROTECTED]http://www.jasonkohles.com/"A witty saying proves nothing." -- Voltaire ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst::Model minor doc patch
Attatched a small patch to make Catalyst::Model POD consistent with Catalyst::View POD. Kiki Index: lib/Catalyst/Model.pm === --- lib/Catalyst/Model.pm (revision 4965) +++ lib/Catalyst/Model.pm (working copy) @@ -15,6 +15,11 @@ Catalyst Model base class. +=head1 METHODS + +Implements the same methods as other Catalyst components, see +L + =head1 AUTHOR Sebastian Riedel, C<[EMAIL PROTECTED]> ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Arrrrrgggggg.
http://today.icantfocus.com/blog/archives/entries/ahoy_me_land_lovin_dogs.icf signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Trouble with Chained Actions and Redirects?
--- Robert 'phaylon' Sedlacek <[EMAIL PROTECTED]> wrote: > John Napiorkowski said: > > I have a controller with some chained actions. > One of > > the actions (not an endpoint) will redirect given > a > > certain value for the arguments. However I find > that > > this doesn't stop the chain from completing. I > still > > get a line about the redirect in the log, but the > > endpoint in that chain still activates. > > > > I find that this doesn't happen when I use > $c->detach, > > although in this circumstance detach is not the > best > > use for me. > > Of course, redirect and detach/foward are completely > different. While > redirect may seem like "external detach," it isn't. > A redirect is an > answer to the browser, telling him to look up > another site. A forward or > detach moves the execution to another action. If you > call redirect, it > will just set the appropriate headers. It can't just > stop there, because > you might want to change those headers or do > something else before the > redirect (E.g. Setting a message in the flash). > > > Has anyone run into this before and found a way > around > > it? > > See Ash's answer, if you want to detach, detach :) > (Note that detach can > also be called without arguments at all, just ending > the execution). > > hth, > Robert I guess I am still used to how in mod_perl I'd just return a status code when I wanted to break execution and hadn't figured out the best way to do that in Catalyst. I didn't know you could detach without an arg. That sounds like want I want. I have to think I'm not the only one with this confusion. Maybe we could alias $c->end to $c->detach or something to make it clear in the docs how to stop the execution right away? Or even a $c->response->redirect_and_end() could do it. I mean most of the time when you redirect what you are looking for is catalyst to stop right there (at least for me but I can see reasons why you might want it to continue for logging and so forth). I think it's intuitive to think that dire I suppose it could be a trivial plugin as well. Thanks for the suggestions. I see there's a new Cat out, time to update! --john __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Arrrrrgggggg.
http://today.icantfocus.com/blog/archives/entries/ahoy_me_land_lovin_dogs.cf claco == The Catalyst Patch(ed) Pírate! ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Trouble with Chained Actions and Redirects?
John Napiorkowski said:
> I didn't know you could detach without an arg. That
> sounds like want I want.
That's docced in Catalyst.pm, tho I think it was only added recently.
> I have to think I'm not the only one with this
> confusion. Maybe we could alias $c->end to $c->detach
> or something to make it clear in the docs how to stop
> the execution right away?
$c->end would break if you have a sub end : Private in your MyApp.pm (not
encouraged, as we have Root controllers now, but some people might still
be using this). Personally, I find this function in ->detach more clean
than adding another keyword that just does ->detach but doesn't take
arguments.
> Or even a $c->response->redirect_and_end() could do it.
Well, but then you'd have functionality affecting the execution flow
placed in Catalyst::Response, which is also not rather clean.
> I mean most of the time when you redirect what you are
> looking for is catalyst to stop right there (at least
> for me but I can see reasons why you might want it to
> continue for logging and so forth). I think it's
> intuitive to think that dire
The API is released, can't be changed now anyway. And while I've been
bitten by this in the beginning as well one or two times, I now rather
appreciate it that ->detach (and return 0 in auto's) is the only thing
stopping the execution chain.
> I suppose it could be a trivial plugin as well.
Wouldn't even need to. It's just an (untested)
sub MyApp::redirect_and_stop {
my $c = shift;
$c->response->redirect(@_);
$c->detach;
}
and a call via $c->redirect_and_stop( $c->uri_for('/foo', $foo) );
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Trouble with Chained Actions and Redirects?
>
> Wouldn't even need to. It's just an (untested)
>
> sub MyApp::redirect_and_stop {
> my $c = shift;
> $c->response->redirect(@_);
> $c->detach;
> }
>
> and a call via $c->redirect_and_stop( $c->uri_for('/foo', $foo) );
Or maybe call it redirect_and_detach so other devs that may eventually need
to read/debug the code can guess what it does without seeing what your
definition of "stop" is =)
always good to use known verbs =)
-Wade
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] patch: C::P::Compress::Deflate
Patch below allows Compress::Deflate plugin to play nicely with Static::Simple
and to allow for skipping deflation based on browser. Specifically, we found
issues with older versions of IE that claimed to deal with the deflate encoding
but balked.
I'm not sure if the way I detect presence of Static::Simple is the Right Way or
not. Comments welcome.
--- /usr/lib/perl5/site_perl/5.8.6/Catalyst/Plugin/Compress/Deflate.pm
2006-09-05 11:29:48.0 -0500
+++ Catalyst/Plugin/Compress/Deflate.pm 2006-09-19 10:15:16.0 -0500
@@ -2,6 +2,8 @@
use strict;
+our $VERSION = '0.02';
+
use Compress::Zlib ();
sub finalize {
@@ -29,6 +31,25 @@
return $c->NEXT::finalize;
}
+# skip if using Static::Simple
+if ( $c->can('_serve_static') ) {
+$c->log->debug("skipping Compress::Deflate due to Static::Simple")
+ if $c->debug;
+return $c->NEXT::finalize;
+}
+
+# skip if we have a particular browser type
+if ($c->request->browser
+and $c->request->browser->windows
+and $c->request->browser->ie
+and $c->request->browser->major() <
+( $c->config->{compress}->{skip_ie} || 0 ) )
+{
+$c->log->debug("skipping Compress::Deflate due to skip_ie detection")
+ if $c->debug;
+return $c->NEXT::finalize;
+}
+
my ( $d, $out, $status, $deflated );
( $d, $status ) = Compress::Zlib::deflateInit(
@@ -80,6 +101,21 @@
Deflate compress response if client supports it.
+=head1 CONFIGURATION
+
+The config key B can be used. If you need to skip deflation for IE
+browsers, you can set the B key to the major version below which you
+want to skip deflation.
+
+Example:
+
+ __PACKAGE__->config( compress => { skip_ie => 6 } )
+
+will skip deflation for all IE browsers below version 6.
+
+B The B feature requires the Catalyst::Plugin::Browser module.
+
+
=head1 SEE ALSO
L.
--
Peter Karman . http://peknet.com/ . [EMAIL PROTECTED]
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Trouble with Chained Actions and Redirects?
[EMAIL PROTECTED] said: > Or maybe call it redirect_and_detach so other devs that may eventually > need to read/debug the code can guess what it does without seeing what > your definition of "stop" is =) > > always good to use known verbs =) Sure. But I found some people stay away from "detach" because they don't associate the detaching result with it. That's why I said stop in this example. Personally, I see detach and redirect as two separate mechanisms :) ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Peter Karman wrote: > Patch below allows Compress::Deflate plugin to play nicely with > Static::Simple > and to allow for skipping deflation based on browser. Specifically, we found > issues with older versions of IE that claimed to deal with the deflate > encoding > but balked. Does this mean you are using Catalyst to serve static pages in production? That's going to hurt your performance quite a bit. Static pages are better left to your web server. For that matter, compressing pages is also better left to your web server. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Perrin Harkins scribbled on 9/19/06 10:34 AM: > Peter Karman wrote: >> Patch below allows Compress::Deflate plugin to play nicely with >> Static::Simple and to allow for skipping deflation based on browser. >> Specifically, we found issues with older versions of IE that claimed >> to deal with the deflate encoding but balked. > > Does this mean you are using Catalyst to serve static pages in > production? That's going to hurt your performance quite a bit. Static > pages are better left to your web server. For that matter, compressing > pages is also better left to your web server. > Thanks, Perrin. No, we don't use Catalyst to serve static pages in production. That's actually why I added the Static::Simple check. I like to be able to move code directly dev -> testing -> production with only changing config files. My problem was that Static::Simple messes with Deflate in devel (which is the only place I use S::S) for CSS and other files, since they have text/* mime types. I actually have a conditional in my base MyApp.pm file that checks if running under mod_perl and only loads S::S if not under mod_perl. I was doing the same thing with the Compress module (only loading if running under mod_perl) but I wanted to test deflation in dev under the dev server, and still use S::S. see http://article.gmane.org/gmane.comp.web.catalyst.general/2089/match=static+simple+compress I didn't see mention of any fix in the list archives, hence this patch. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] Trouble with Chained Actions and Redirects?
--- [EMAIL PROTECTED] wrote:
> > Wouldn't even need to. It's just an (untested)
> >
> > sub MyApp::redirect_and_stop {
> > my $c = shift;
> > $c->response->redirect(@_);
> > $c->detach;
> > }
> >
> > and a call via $c->redirect_and_stop(
> $c->uri_for('/foo', $foo) );
>
> Or maybe call it redirect_and_detach so other devs
> that may eventually need
> to read/debug the code can guess what it does
> without seeing what your
> definition of "stop" is =)
>
> always good to use known verbs =)
>
> -Wade
Yes, but for me it's not about saving the keystrokes,
it's just that it's not intuitive (to me) that
->detach is used to escape processing in Catalyst.
The word "detach" is a great one for the idea of "It's
like forward but it's not going to return, it's
detached". I guess I can kind of see it as "It's
permanently detached" but I only think of that now
after all the feedback I've gotten.
I have a lot of programmers with experience writing
mod_perl apps and for them (and me) we are used to the
idea that you can end processing with a location
header and returning the redirect http status code.
There is no equally obvious method to end processing
in Catalyst, since the detach method is not documented
that way and the word itself does not give me the idea
to use it for that purpose. Now, in auto methods you
can return 0 to stop processing but that doesn't work
for normal Catalyst actions. So at first pass I can't
see how to stop processing if I want to. This is
something I've wondered about for months but until now
it didn't bite me so I was able to ignore it.
Also I think it's intuitive to think that redirect
would function as a end to processing, which is how I
got into this trouble in the first place. I'm not
saying that Catalyst should do that, because I can see
the very valid reasons why it doesn't, I'm just saying
that in the absence of direction my instincts
developed from writing CGI and mod_perl apps would
lead me to think that a redirect call would function
as a end to the processing. When it didn't it caused
confusion and misunderstanding. I am guessing I am
not the only one confused about this.
I'd be happy to offer a small POD patch to the
redirect and detach functions to document that
redirect doesn't actually redirect until you reach the
endpoint in your catalyst chain or sequence of actions
and that this is a good thing because it give you
finer control. It makes total sense to me now that
you've all spent to time to explain it to me. Also
that $c->detach is the catalyst way to end processing
a chain right away and fills the role that "return
HTTP_STATUS_CODE" does for mod_perl apps except it's
better because it also you to do some cleanup and
finalization if you need to.
I guess another way to handle this is to write your
own action to handle redirects as I have for handling
not found and other error types. I have a controller
for this: $c->detach("/errors/not_found", [$errmsg])
which I use for this purpose. I could create a
$c->detach("/http/redirect", [$url]) to handle this
instead of using the catalyst built in.
Does that all sound correct to you?
--john
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] Trouble with Chained Actions and Redirects?
John Napiorkowski said:
> I have a lot of programmers with experience writing
> mod_perl apps and for them (and me) we are used to the
> idea that you can end processing with a location
> header and returning the redirect http status code.
> There is no equally obvious method to end processing
> in Catalyst, since the detach method is not documented
> that way and the word itself does not give me the idea
> to use it for that purpose.
Well, that part of documentation has been added to Catalyst.pm recently.
> Also I think it's intuitive to think that redirect
> would function as a end to processing, which is how I
> got into this trouble in the first place. I'm not
> saying that Catalyst should do that, because I can see
> the very valid reasons why it doesn't, I'm just saying
> that in the absence of direction my instincts
> developed from writing CGI and mod_perl apps would
> lead me to think that a redirect call would function
> as a end to the processing. When it didn't it caused
> confusion and misunderstanding. I am guessing I am
> not the only one confused about this.
I think the main misunderstanding is the way Catalyst works. It is not
like a mod_perl handler or CGI script in that you just say "I'm finished."
Because Catalyst is supposed to do your finishing works (headers, outputs,
session sync, etc.). Therefore the wording in C:Response
Causes the response to redirect to the specified URL.
can be misleading if you're standing at the POV that you immediately send
a response, and not just prepare it.
> I'd be happy to offer a small POD patch to the
> redirect and detach functions to document that
> redirect doesn't actually redirect until you reach the
> endpoint in your catalyst chain or sequence of actions
> and that this is a good thing because it give you
> finer control.
++ for that.
> Also that $c->detach is the catalyst way to end
> processing a chain right away and fills the role that
> "return HTTP_STATUS_CODE" does for mod_perl apps except
> it's better because it also you to do some cleanup and
> finalization if you need to.
Well, no. detach() really just returns and lets Catalyst look for an end
action and then start the finalization. To prepare your response, you'd
act on the $c->response object, just like with redirect. In Catalyst, you
don't return a stream of headers and data yourself, but you build up your
response object during the execution of the request, and Cat will care for
returning it to the user.
I know, the difference seems minimal, but I already see people asking why
detach doesn't accept status values, if we're stating it exactly like that
:)
> I guess another way to handle this is to write your
> own action to handle redirects as I have for handling
> not found and other error types. I have a controller
> for this: $c->detach("/errors/not_found", [$errmsg])
> which I use for this purpose. I could create a
> $c->detach("/http/redirect", [$url]) to handle this
> instead of using the catalyst built in.
That would be a possibility. I myself usually just detach to the specific
actions doing the redirect then. I have most redirects behind actions that
change something, so mostly after POST requests. Then I'd have
(pseudo-perl)
if ($this_was_submitted) {
put_stuff_in_the_stash();
$c->detach('do_store_stuff_in_db');
}
To be honest, it largely depends on how you build your application and
your control flow. Catalysts big advantage is that it can fit flexibly in
many designs, so there's no true way. Do whatever makes sense, is
read-/maintainable and gives an elegant feeling to you and your
developers.
if you really need this often, a MyApp plugin, a controller base class or
any other way to write this to easily integrate it into your apps might
fit what you're looking for.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Question on Authorization
Nagarajan M wrote: > Hi, > > I have a question on catalyst Authorization. Then please start a thread rather than hitting reply to a random e-mail in an old one, thus tacking it on and ensuring nobody except me notices it. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Question on Authorization
Hi, I have a question on catalyst Authorization. I am having a table which contains both user name and role defined. (one user will have one role only) unlike the example given in the tutorial (three tables user, role, user_role). In my case what should be the yml file or what are the things I should change in the yml file of the tutorial Thanks,Nagarajan My table user_namepasswordemailfirst_namelast_namerole yml file== authorization:dbic:role_class: ?role_field: rolerole_rel: ???user_role_user_field: ??? Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
On Tue, 2006-09-19 at 10:45 -0500, Peter Karman wrote: > I actually have a conditional in my base MyApp.pm file that checks if running > under mod_perl and only loads S::S if not under mod_perl. It always sounds a little scary to me to have a different environment for dev vs. production, but I know many Catalyst users do it. Since you use apache in production, have you considered using mod_deflate for compression? It seems like a better solution than something at the perl level. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
> > Thanks, Perrin. > > No, we don't use Catalyst to serve static pages in production. > That's actually > why I added the Static::Simple check. I like to be able to move codedirectly > dev -> testing -> production with only changing config files. My problem was > that Static::Simple messes with Deflate in devel (which is the only > place I use > S::S) for CSS and other files, since they have text/* mime types. > > I actually have a conditional in my base MyApp.pm file that checks if running > under mod_perl and only loads S::S if not under mod_perl. I was > doing the same > thing with the Compress module (only loading if running under mod_perl) but I > wanted to test deflation in dev under the dev server, and still use S::S. I do understand what you are saying -- although I don't see any advantage in doing so. If you use the webserver to compress, testing compression on the dev server not only does not test the behavior of production, but also may befoul the testing you are doing on dev that would normally match production (think about unintended side effects from Cat compress plugins). My suggestion would be to strip compress from your app completely, do light dev with the dev server and then QA on a dev apache/light or whatever webserver that you are using in production -- this gives you actual parity between dev qa and production without introducing extra errors that may give false positive failures. > > see > http://article.gmane.org/gmane.comp.web.catalyst. > general/2089/match=static+simple+compress > > I didn't see mention of any fix in the list archives, hence this patch. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Invoke *complete* subrequests in Catalyst?
Is there a way to invoke a complete subrequest, with a complete request cycle, in Catalyst? I've tried the Plugin::SubRequest and it's a step in the right direction, but what I need is something that allows complete prepare()/finalize() functionality. I'm building an AJAX app with FormBuilder, and want to use it to embed multiple forms in a page (each of which would be linked to a different action and submitted using JQuery). I've found I can do this, but I've had to make changes to the FB plugin so that it only instantiates an object on a call to $c->form, and doesn't use prepare() to do so. This then requires a bit of internal magic to work both normally and in subrequest mode. Other ideas? -Nate ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Invoke *complete* subrequests in Catalyst?
Nate Wiger wrote: > Is there a way to invoke a complete subrequest, with a complete request > cycle, in Catalyst? I've tried the Plugin::SubRequest and it's a step in > the right direction, but what I need is something that allows complete > prepare()/finalize() functionality. Yep, it exists. It's called Catalyst::Plugin::SubRequest, trunk version :) I kinda rewrote it somewhat, for similar reasons, but then marcus had problems with it in MojoMojo but never sent me failing tests for it *COUGH*. If anybody fancies using the trunk version and shaking the bugs out, I'd love to see the new version released - it's just I'm not confident enough to do so until we've QA-ed the bugger a bit more. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Invoke *complete* subrequests in Catalyst?
You might want to rethink using a plugin and instead just create a custom controller that does what you want. This has the advantage of not employing any trickery, so it's easy to figure out what's going on. I prefer code that does what it says, rather than some magic that gets mysteriously called during prepare()/finalize(). As mst indirectly mentions, this can be prone to bugs, whereas your own controller (that you can call from /begin or /auto and /end anyway) won't fall victim to the unintended side effects here (i.e. calling prepare/finalize in other plugins). Your own controller is also easier to debug than the interaction between a plugin, NEXT, and the Catalyst core :) That said, how about the Larry Wall way: my $me = $c->uri_for(...); my $page = `curl $me`; Hopefully you're using myapp_server -f or the POE engine :/ :) Regards, Jonathan Rockway Nate Wiger wrote: > Is there a way to invoke a complete subrequest, with a complete request > cycle, in Catalyst? I've tried the Plugin::SubRequest and it's a step in > the right direction, but what I need is something that allows complete > prepare()/finalize() functionality. > > I'm building an AJAX app with FormBuilder, and want to use it to embed > multiple forms in a page (each of which would be linked to a different > action and submitted using JQuery). I've found I can do this, but I've > had to make changes to the FB plugin so that it only instantiates an > object on a call to $c->form, and doesn't use prepare() to do so. This > then requires a bit of internal magic to work both normally and in > subrequest mode. > > Other ideas? > > -Nate > > ___ > List: Catalyst@lists.rawmode.org > Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ > Dev site: http://dev.catalyst.perl.org/ signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Perrin Harkins scribbled on 9/19/06 11:46 AM: > Since you use apache in production, have you considered using > mod_deflate for compression? It seems like a better solution than > something at the perl level. > I started to write a long response, then realized why I was having the whole compression/caching issue in the first place. I was caching compressed pages, which meant that browser headers were ignored, etc. doh! So now I need to implement mod_deflate. Since y'all have likely done this before, I'll ask here. We have a typical proxy frontend/mod_perl backend setup. Which server should handle the compression? Seems like maybe the backend could, since we are caching pages, but don't know if there are accepted best practices on this. Thanks. -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
On Tue, 2006-09-19 at 15:00 -0500, Peter Karman wrote: > We have a typical proxy frontend/mod_perl backend setup. Which server should > handle the compression? Seems like maybe the backend could, since we are > caching > pages, but don't know if there are accepted best practices on this. If your frontend serves static files, and you want them compressed, you should put it there. It's also better to have it there because it frees up the backend server processes faster. - Perrin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Invoke *complete* subrequests in Catalyst?
Nate Wiger wrote: > I'm building an AJAX app with FormBuilder, and want to use it to embed > multiple forms in a page (each of which would be linked to a different > action and submitted using JQuery). I've found I can do this, but I've > had to make changes to the FB plugin so that it only instantiates an > object on a call to $c->form, and doesn't use prepare() to do so. This > then requires a bit of internal magic to work both normally and in > subrequest mode. > > Other ideas? Actually, yes. MAKE IT A CONTROLLER BASE CLASS LIKE I ALREADY SAID You just proved *perfectly* why this is a really stupid thing to have as a plugin ... -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Peter Karman wrote: > > > Peter Karman scribbled on 9/19/06 10:45 AM: > >> see >> http://article.gmane.org/gmane.comp.web.catalyst.general/2089/match=static+simple+compress >> >> >> >> I didn't see mention of any fix in the list archives, hence this patch. >> > > To make some amends for my earlier bone-headedness, here's patches that > actually address this particular issue. It adds a 'no_types' config > option to exclude content types from compression that match 'text/' -- > specifically CSS. It will skip text/css by default. Actually, what I'd really like is somebody to volunteer to write a new Catalyst::Plugin::Compress that handles all this crap once and allows multiple compression backends to be used. Sadly, the ::Compress::* plugins are owned by Sebastian Riedel so we have no way of getting patches fed back and as such they shoul be considered entirely unmaintained. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Peter Karman scribbled on 9/19/06 10:45 AM:
see
http://article.gmane.org/gmane.comp.web.catalyst.general/2089/match=static+simple+compress
I didn't see mention of any fix in the list archives, hence this patch.
To make some amends for my earlier bone-headedness, here's patches that actually
address this particular issue. It adds a 'no_types' config option to exclude
content types from compression that match 'text/' -- specifically CSS. It will
skip text/css by default.
I realize this doesn't address the question of best development practices, but
it does fix the bug in the email thread above.
--
Peter Karman . http://peknet.com/ . [EMAIL PROTECTED]
--- /usr/lib/perl5/site_perl/5.8.6/Catalyst/Plugin/Compress/Deflate.pm
2006-09-05 11:29:48.0 -0500
+++ Catalyst/Plugin/Compress/Deflate.pm 2006-09-19 15:03:49.0 -0500
@@ -2,8 +2,19 @@
use strict;
+our $VERSION = '0.02';
+
use Compress::Zlib ();
+sub setup
+{
+my $c = shift;
+
+$c->NEXT::setup(@_);
+
+$c->config->{config}->{no_types} ||= [qw( text/css )];
+}
+
sub finalize {
my $c = shift;
@@ -23,6 +34,17 @@
return $c->NEXT::finalize;
}
+for my $type (@{$c->config->{compress}->{no_types}||[]})
+{
+if ($c->response->content_type eq $type)
+{
+$c->log->debug("skipping Compress::Deflate due to match on type
$type")
+if $c->debug;
+
+return $c->NEXT::finalize;
+}
+}
+
my $accept = $c->request->header('Accept-Encoding') || '';
unless ( index( $accept, "deflate" ) >= 0 ) {
@@ -80,6 +102,21 @@
Deflate compress response if client supports it.
+=head1 CONFIGURATION
+
+The config key B stores all Compress Plugin options.
+
+=head2 Skip based on content type
+
+Not all B content types should be compressed. By default
Compress::Deflate
+will skip all B content types. You can configure more B
types to skip
+with the B option:
+
+ __PACKAGE__->config( compress => { no_types => [qw( text/plain text/css )]
} );
+
+B If you must include B explicitly if you set the B
option.
+Otherwise it will be compressed.
+
=head1 SEE ALSO
L.
--- /usr/lib/perl5/site_perl/5.8.6/Catalyst/Plugin/Compress/Gzip.pm
2006-09-05 11:29:48.0 -0500
+++ Catalyst/Plugin/Compress/Gzip.pm2006-09-19 15:06:10.0 -0500
@@ -4,6 +4,16 @@
use Compress::Zlib ();
+sub setup
+{
+my $c = shift;
+
+$c->NEXT::setup(@_);
+
+$c->config->{config}->{no_types} ||= [qw( text/css )];
+}
+
+
sub finalize {
my $c = shift;
@@ -23,6 +33,17 @@
return $c->NEXT::finalize;
}
+for my $type (@{$c->config->{compress}->{no_types}||[]})
+{
+if ($c->response->content_type eq $type)
+{
+$c->log->debug("skipping Compress::Deflate due to match on type
$type")
+if $c->debug;
+
+return $c->NEXT::finalize;
+}
+}
+
my $accept = $c->request->header('Accept-Encoding') || '';
unless ( index( $accept, "gzip" ) >= 0 ) {
@@ -54,6 +75,21 @@
Gzip compress response if client supports it.
+=head1 CONFIGURATION
+
+The config key B stores all Compress Plugin options.
+
+=head2 Skip based on content type
+
+Not all B content types should be compressed. By default
Compress::Deflate
+will skip all B content types. You can configure more B
types to skip
+with the B option:
+
+ __PACKAGE__->config( compress => { no_types => [qw( text/plain text/css )]
} );
+
+B If you must include B explicitly if you set the B
option.
+Otherwise it will be compressed.
+
=head1 SEE ALSO
L.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Right. Think of it like this; your backend generates content, and your frontend serves that content as if it were static. Since you wouldn't gzip your static HTML before serving it, it follows that your backend server wouldn't compress it either. Caching is a bit different. I think it's best to do it on the frontend, but if your frontend isn't smart enough to do it right (sessions), then you'll have to let the backend do it. Apache has some pretty intelligent modules these days, though, so investigate those before you do all the caching on the backend. (Then there's memcached, which is even farther back... but it serves a different purpose.) Regards, Jonathan Rockway Perrin Harkins wrote: > On Tue, 2006-09-19 at 15:00 -0500, Peter Karman wrote: >> We have a typical proxy frontend/mod_perl backend setup. Which server should >> handle the compression? Seems like maybe the backend could, since we are >> caching >> pages, but don't know if there are accepted best practices on this. > > If your frontend serves static files, and you want them compressed, you > should put it there. It's also better to have it there because it frees > up the backend server processes faster. > > - Perrin signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] [OT] compiling perl/apache from scratch
not strictly a cat question, but probably interesting to a few that pass through here ... and as I know this group ... decided to setup apache2/mod_perl on my laptop for dev purposes today. In the past I've just used apt for this, but I decided to have a go at compiling all from scratch, as I know I will need to do this. I have built apache and perl 5.8.8 from source, and installed, after a few hiccups ( I used the compile option for apache to stick everything under one directory, as it seemed easier ... but whatever ...) having built a new perl, I switch over by renaming the old /usr/bin/perl and setting up a symlink. Now I have 5.8.8 Now I try to run my old cat test suite ... it seems I need to go to cpan for each module that was previously installed. is there any way to avoid this when upgrading perl ? or at least a quick way to find back all the stuff you had installed and install it all in one hit? and any other useful stuff i could know for doing this 1st time? thanks Daniel -- Daniel McBrearty email : danielmcbrearty at gmail.com www.engoi.com : the multi - language vocab trainer BTW : 0873928131 ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] compiling perl/apache from scratch
> Now I try to run my old cat test suite ... it seems I need to go to > cpan for each module that was previously installed. > is there any way to avoid this when upgrading perl ? Is there a way to avoid it? Yes; trickery with @INC. But I wouldn't recommend it because you have no idea if your CPAN'd modules even work under 5.8.8 -- you didn't run their test suites, and their (potential) prerequisite core modules may have been changed. (Not to mention new features in the interpreter.) > or at least a > quick way to find back all the stuff you had installed and install it > all in one hit? http://search.cpan.org/~andk/CPAN-1.87/lib/CPAN.pm#autobundle Autobundle your old @INC, then install that bundle with your new perl. Should work. Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Arrrrrgggggg.
GARRR! SHIVER ME TIMBERS! Happy International Talk Like A Pirate Day! Festivities in Columbia, MO included our local Flat Branch Pub decorating the entire establishment in pirate regalia. The servers all dressed up as pirates and wenches, and the bar was decorated like a pirate ship. Walk the Plank, ye scurvy knave! Ted Carnahan Kaare Rasmussen wrote: >http://today.icantfocus.com/blog/archives/entries/ahoy_me_land_lovin_dogs.cf > >claco == The Catalyst Patch(ed) Pírate! > >___ >List: Catalyst@lists.rawmode.org >Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst >Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ >Dev site: http://dev.catalyst.perl.org/ > > ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Matt S Trout scribbled on 9/19/06 3:21 PM: > Actually, what I'd really like is somebody to volunteer to write a new > Catalyst::Plugin::Compress that handles all this crap once and allows > multiple compression backends to be used. Sadly, the ::Compress::* > plugins are owned by Sebastian Riedel so we have no way of getting > patches fed back and as such they shoul be considered entirely > unmaintained. > would it still be called C::P::Compress? Or would a new namespace be needed? -- Peter Karman . http://peknet.com/ . [EMAIL PROTECTED] ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] compiling perl/apache from scratch
thanks. I'll try that next time. Actually it wasn't *that* bad. but I get a make test error after building mod_perl, that ends with a "file bug report" message. damn ... I managed to confuse it ... -- Daniel McBrearty email : danielmcbrearty at gmail.com www.engoi.com : the multi - language vocab trainer BTW : 0873928131 ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] patch: C::P::Compress::Deflate
Peter Karman wrote: > > > Matt S Trout scribbled on 9/19/06 3:21 PM: > >> Actually, what I'd really like is somebody to volunteer to write a >> new Catalyst::Plugin::Compress that handles all this crap once and >> allows multiple compression backends to be used. Sadly, the >> ::Compress::* plugins are owned by Sebastian Riedel so we have no way >> of getting patches fed back and as such they shoul be considered >> entirely unmaintained. >> > > would it still be called C::P::Compress? Or would a new namespace be > needed? > C::P::Compress is fine since then you'd have C::P::Compress::Backend::* - c.f. how C::P::Cache works. -- Matt S Trout Offering custom development, consultancy and support Technical Directorcontracts for Catalyst, DBIx::Class and BAST. Contact Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ + ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RFC: JobQueue Job Notification
Hello, Anyone who's interested in the Catalyst::Engine::JobQueue, please provide some feedback. Here's the deal: you have a jobqueue running, jobs have been setup... each job is sent as a $request to your app (auto, begin, controller action, etc.), which deals with it and generates a response. This response is returned to the Engine. What should the engine do with it? It can email it and/or log it. Any other ideas? How much of the response should get emailed/logged? The full thing: 200 OK X-Catalyst: 5.7002 ... Or just the body, body+headers,body+status? Should the log level be computed from the response status (i.e. 100-399 - info level, 400+ - error level)? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [Problem Solved]Quesion about Chaining usage
--- John Napiorkowski <[EMAIL PROTECTED]> wrote: > Matt, > > I created a test case and a test for the issue I am > having. I tried to match the way this was done in > the > Catalyst test directory but I have to be honest and > say I am still a learner when it comes to this so I > probably need some pointers to get it to a place > where > it can be properly integrated. > [lots of stuff snipped] Just to let you know this problem was fixed in the latested Catalyst. I'm not sure if the tests I provided where useful but either they or something else did the trick. Now I can spend some time on code refactoring :) --John __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Invoke *complete* subrequests in Catalyst?
Matt S Trout wrote:
> Nate Wiger wrote:
>> I'm building an AJAX app with FormBuilder, and want to use it to embed
>> multiple forms in a page (each of which would be linked to a different
>> action and submitted using JQuery). I've found I can do this, but I've
>> had to make changes to the FB plugin so that it only instantiates an
>> object on a call to $c->form, and doesn't use prepare() to do so. This
>> then requires a bit of internal magic to work both normally and in
>> subrequest mode.
>>
>> Other ideas?
>
> Actually, yes.
>
> MAKE IT A CONTROLLER BASE CLASS LIKE I ALREADY SAID
>
> You just proved *perfectly* why this is a really stupid thing to have as a
> plugin ...
Never said I wasn't going to do that... but it doesn't really solve the
problem. I've played with the base class, AFAICT it has the issue that
you have to say something like this:
sub myform : Local Form {
my($self,$c) = @_;
my $form = $c->form;
$form->etc(...);
$c->stash->{form_output} = $form->render;
}
To get the form instantiated and rendered. In the normal case, having it
as a plugin makes sense because:
- The form config is automatically resolved per the $c->action
- The form is loaded during Catalyst preparation
- The form is rendered automatically via Catalyst View::Whatever
I'm not sure if you've actually tried to use the FormBuilder plugin or
not. If you can show/hint/link at how these items could be done via a
base class, and auto-invoked during prepare(), that would be helpful. So
far I can't find any decent documentation on controller base classes.
-Nate
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: JobQueue Job Notification
I think you should have an option for both. Use case A, you want to run something every 5 minutes (clean sessions, update stock ticker, whatever). That, you'll just want logged. Use case B, you want a nightly report (or something), and you will probably want e-mail about that. > What should the engine do with it? It can email it and/or log it. Any > other ideas? How much of the response should get emailed/logged? The > full thing: > 200 OK > X-Catalyst: 5.7002 > > > ... > > > Or just the body, body+headers,body+status? > > Should the log level be computed from the response status (i.e. 100-399 > - info level, 400+ - error level)? "Log" should just log that the event ran (to info), and the $c->error if there was an error. If you want warnings to be logged, I suggest having a plugin for that :) "E-mail" should probably log that the event ran, and then send the body if the response is 200 OK. If there was an error, log the details, and then mail or log the error message, headers, response, probably the request, and maybe the contents of the stash; depending on debug levels of course. My $0.02 Regards, Jonathan Rockway signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: JobQueue Job Notification
Jonathan Rockway wrote: > I think you should have an option for both. > > Use case A, you want to run something every 5 minutes (clean sessions, > update stock ticker, whatever). That, you'll just want logged. > > Use case B, you want a nightly report (or something), and you will > probably want e-mail about that. > > So how about the engine inspects the response ... and decides based on a header what to do with it (email, log or both)... X-Job-Response-Transport: email, log Should the other two options also be decided via headers? X-Job-Response-Content: status, headers, body X-Job-Response-LogByStatus: yes (Of course there will be fallbacks for each option) or just try to act smartly like suggested below? >> What should the engine do with it? It can email it and/or log it. Any >> other ideas? How much of the response should get emailed/logged? The >> full thing: >> 200 OK >> X-Catalyst: 5.7002 >> >> >> ... >> >> >> Or just the body, body+headers,body+status? >> >> Should the log level be computed from the response status (i.e. 100-399 >> - info level, 400+ - error level)? >> > > "Log" should just log that the event ran (to info), and the $c->error if > there was an error. If you want warnings to be logged, I suggest having > a plugin for that :) > > "E-mail" should probably log that the event ran, and then send the body > if the response is 200 OK. If there was an error, log the details, and > then mail or log the error message, headers, response, probably the > request, and maybe the contents of the stash; depending on debug levels > of course. > > My $0.02 > > Regards, > Jonathan Rockway > > Thx, Kiki ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Best Practices - an application.
I lost my first post as I was on a different computer, so I'm posting an update
of my relevant files here as I see it my relevant files are:
package DMU::Controller::Servers;
use strict;
use warnings;
use Data::Dump qw(dump);
use base 'Catalyst::Controller';
=head1 NAME
DMU::Controller::Servers - Catalyst Controller
=head1 DESCRIPTION
Catalyst Controller.
=head1 METHODS
=cut
=head2 index
=cut
sub get_db_types : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'db_type'} ],as => [ 'db_type' ],order_by=>'db_type'});
my @responses;
while(my $server=$rs->next) {
my $db_type=$server->db_type;
push(@responses,"[\"$db_type\",\"$db_type\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub get_db_names : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'db_name'} ],as => [ 'db_name' ],order_by=>'db_name'});
my @responses;
while(my $server=$rs->next) {
my $db_name=$server->db_name;
push(@responses,"[\"$db_name\",\"$db_name\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub get_user_roles : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'user_role'} ],as => [ 'user_role' ],order_by=>'user_role'});
my @responses;
while(my $server=$rs->next) {
my $user_role=$server->user_role;
push(@responses,"[\"$user_role\",\"$user_role\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub get_db_servers : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'db_server'} ],as => [ 'db_server' ],order_by=>'db_server'});
my @responses;
while(my $server=$rs->next) {
my $db_server=$server->db_server;
push(@responses,"[\"$db_server\",\"$db_server\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub get_systems : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{cols=>[qw /db_server db_name/],group_by=>[qw /db_server db_name/]});
my @responses;
while(my $server=$rs->next) {
my $db_server=$server->db_server;
my $db_name=$server->db_name;
push(@responses,"[\"$db_server\",\"$db_name\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub get_aliass : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'alias'} ],as => [ 'alias' ],order_by=>'alias'});
my @responses;
while(my $server=$rs->next) {
my $alias=$server->alias;
push(@responses,"[\"$alias\",\"$alias\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
sub add_server : Local {
my ( $self, $c ) = @_;
my $params=$c->req->params();
my $primary={db_server=>undef,db_name=>undef,db_server=>undef,db_type=>undef,user_role=>undef};
my @errors;
while(my ($k,$v)=each(%{$primary})) {
if(${$params}{$k} ne '') {
${$primary}{$k}=${$params}{$k};
}else {
push(@errors,$k);
}
}
if(@errors) {
my $response="[".join(",",@errors)." ]";
$c->response->body($response); #return missing fields
return;
}
dump($primary);
${$primary}{alias}=${$params}{alias};
dump($primary);
my @rs=$c->model('DMU::Systems')->search($primary)->all();
if(@rs){
$c->response->body(0); #record exists
return;
}
if($c->model('DMU::Systems')->create($primary)) {
$c->response->body(1);
return;
}
}
sub index : Private {
my ( $self, $c ) = @_;
$c->stash->{template}='servers.tt'
#$c->response->body('Matched DMU::Controller::Servers in Servers.');
}
=head1 AUTHOR
root
=head1 LICENSE
This library is free software, you can redistribute it and/or modify
it under the same terms as Perl itself.
=cut
1;
servers.tt
Description: root/servers.tt
dmu.js
Description: /root/servers/static/javascript/dmu.js
So questions that arise about best practice are:
I followed the thread about Modeling and keeping the business logic out of the
controller, and in the model instead. I'm not sure I completely followed it,
and would like to regurgitate it here. I think that this is not best practice
(from Servers.pm file above):
sub get_db_names : Local {
my ( $self, $c ) = @_;
my $rs=$c->model('DMU::Systems')->search({},{select=> [ {distinct=>'db_name'}
],as => [ 'db_name' ],order_by=>'db_name'});
my @responses;
while(my $server=$rs->next) {
my $db_name=$server->db_name;
push(@responses,"[\"$db_name\",\"$db_name\"]");
}
my $response="[ ".join(",",@responses)." ]";
$c->response->body($response);
}
My understanding is that the stuff in the middle could and should be
tucked away in the ./lib/dmu/Model/DMU.pm. Can anyone verify this?
I have a get_db_se
