[Catalyst] Odd Formbuilder behavior - parsing twice?
Hello,
I'm writing a Catalyst app based on the examples in the Catalyst book
(basic CRUD) and am experiencing odd behavior with FormBuilder.
I currently have a simple model with projects and clients.
I am forwarding /project/add to /project/edit.
When I directly edit a project I see formbuilder load the edit.fb once.
When I try to add a new project, I see formbuilder load the edit.fb file
twice. In 'edit' I seem to be able to dynamically set the form
properties (label for name) and create a select element from database
values. 'project/add' seems to build the form right the first time, but
seems to use defaults (edit.frb and no database values in select) the
second time. I've deduced this from the very verbose FormBuilder debug
output - it shows the same 'generated tag' three time for add, only once
(and with correct values) for edit.
thanks,
fahd
_ project/add:
[debug] "GET" request for "project/add" from "127.0.1.1"
[debug] Path is "project/add"
[debug] Form (project/edit): Looking for config file project/edit.fb
[debug] Form (project/edit): Found form config
/home/sultan/Workspace/TnTr/root/forms/project/edit.fb
[debug] Form (project/edit): Looking for config file project/edit.fb
[debug] Form (project/edit): Found form config
/home/sultan/Workspace/TnTr/root/forms/project/edit.fb
[debug] Rendering template "project/edit.tt2"
_ project/edit:
[debug] "GET" request for "project/edit/1" from "127.0.1.1"
[debug] Path is "project/edit"
[debug] Arguments are "1"
[debug] Form (project/edit): Looking for config file project/edit.fb
[debug] Form (project/edit): Found form config
/home/sultan/Workspace/TnTr/root/forms/project/edit.fb
[debug] Rendering template "project/edit.tt2"
_ root/forms/project/edit.fb :
name: project_edit
method: post
fields:
name:
label: Project Name
type: text
size: 30
required: 1
description:
label: Project Description
type: text
size: 30
required: 1
client:
label: Client
type: select
required: 1
_ TnTr::Controller::Project:
sub add : Local Form('/project/edit') {
my ($self, $c) = @_;
$c->stash->{template} = 'project/edit.tt2';
$c->forward('edit', []);
}
sub edit : Local Form {
my ($self, $c, $id) = @_;
my $form = $self->formbuilder;
my $project = $c->model('TnTrDB::Projects')->
find_or_new({id => $id});
$form->field(name => 'client',
options => [ map { [$_->id,$_->name] }
$c->model('TnTrDB::Clients')->all ],
);
$form->field(name => 'name',
label => 'Bobo',
);
if ($form->submitted && $form->validate) {
$project->name($form->field('name'));
$project->client($form->field('client'));
$project->update_or_insert;
$c->stash->{message} =
($id > 0 ? 'Updated ' : 'Added ') . $project->name;
$c->forward('list');
}
else {
if(!$id){
$c->stash->{message} = 'Adding a new Project';
$form->field(name => 'client',
options => [ map { [$_->id,$_->name] }
$c->model('TnTrDB::Clients')->all ],
);
}
else {
# only set values if exists in database
# if I don't do this catalyst blows up on add
$form->field(name => 'name',
value => $project->name);
$form->field(name => 'client',
value => $project->client->id);
}
}
}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
Louis Erickson wrote on 5/5/09 5:08 PM: > On Tue, 5 May 2009, Peter Karman wrote: > >> downgrade to Catalyst::Runtime 5.7 to start with. those errors look like 5.8 >> incompat issues. > > Yes, they do. I have the complete set of modules running on 5.8 on > another machine. There's two main differences that I can think of. > > 1> It was an upgrade from 5.7. Some dependency is installed that wasn't on > the new machine that isn't properly included in the dependency list. > > 2> My working 5.8 machine is on Linux. I have to wonder what Apple has > done to Perl. > I just tried installing C::C::FB under mac 10.5 with both stock perl (5.8.8) and a locally compiled version (5.8.8) and got those same errors both times with C::R 5.8. Then I tried it with a SUSE Linux install with C::R 5.8, and got the same errors. methinks this is a Cat 5.8 + C::C::FB issue, and that you need to re-check your working copy on Linux, which might either (a) be 'force install'ed or (b) be from an rpm and not straight from cpan or (c) be running C::R 5.7 after all. >> after you've done that, give some thought to whether you want to stick with >> C::C::FormBuilder. I see that the latest release is nearly 2 years old, and >> there are several RT tickets opened against it since then, which indicates a >> lack of ongoing maintenance. > > I noticed that. Mr. Rockway's book used FormBuilder, and it seemed to > work fine. Since it had been working, I assumed there simply wasn't a lot > of updates because they weren't needed. > it's the number of unanswered RT tickets that would disturb me. No updates can definitely indicate stability; open tickets suggests neglect. > I did see the Catalyst Wiki suggesting FormFu instead, but only > found that after I had already used FormBuilder. > > At the moment, I can't look that up because the Catalyst Wiki appears to > be down, while my book is still working. Outdated and filled with things > that will lead a newcomer down the wrong path, but readable. What a > terrible trade-off. > and they say the age of the book is over... :) -- Peter Karman . http://peknet.com/ . pe...@peknet.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
On 5 May 2009, at 22:05, Chisel Wright wrote: On Tue, May 05, 2009 at 11:46:49AM -0700, Louis Erickson wrote: t/01-basic.TestApp::Component::TT is trying to use NEXT, which is deprecated. Please see the Class::C3::Adopt::NEXT documentation for details at /Users/davebowers/.cpan/build/Catalyst-Controller-FormBuilder-0.04/ t/lib/Tes tApp/Component/TT.pm line 19 I cleverly based some of my own test libraries in the TestApp::Component::* modules from FormBuilder. My fixed TestApp::Component::TT ended up looking like this: You have fixes. Please commit them somewhere and we can get a development release out (at least). As so eloquently pointed out by the next poster in this thread, this is broken, and need fixing. As you demonstrate here, this is not hard - lets get it sorted out. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forward to view question
On 5 May 2009, at 20:19, Dennis Daupert wrote:
I just got your post, plugged it in, got an error. I'll need to
play with this a bit,
Sorry for pointing out the obvious, but this is just perl:
my $output = delete $c->res->{body};
opem(FH, ">file") or die;
print FH $output;
close(FH);
will do what you want...
You obviously need to do something to fill the body before and after
the snippet shown, but ;_)
Cheers
t0m
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
On Tue, 5 May 2009, Peter Karman wrote: > downgrade to Catalyst::Runtime 5.7 to start with. those errors look like 5.8 > incompat issues. Yes, they do. I have the complete set of modules running on 5.8 on another machine. There's two main differences that I can think of. 1> It was an upgrade from 5.7. Some dependency is installed that wasn't on the new machine that isn't properly included in the dependency list. 2> My working 5.8 machine is on Linux. I have to wonder what Apple has done to Perl. > after you've done that, give some thought to whether you want to stick with > C::C::FormBuilder. I see that the latest release is nearly 2 years old, and > there are several RT tickets opened against it since then, which indicates a > lack of ongoing maintenance. I noticed that. Mr. Rockway's book used FormBuilder, and it seemed to work fine. Since it had been working, I assumed there simply wasn't a lot of updates because they weren't needed. I did see the Catalyst Wiki suggesting FormFu instead, but only found that after I had already used FormBuilder. At the moment, I can't look that up because the Catalyst Wiki appears to be down, while my book is still working. Outdated and filled with things that will lead a newcomer down the wrong path, but readable. What a terrible trade-off. -- Louis Erickson - lerick...@rdwarf.net - http://www.rdwarf.com/~wwonko/ No problem is so formidable that you can't just walk away from it. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
On Tue, May 05, 2009 at 11:46:49AM -0700, Louis Erickson wrote:
> t/01-basic.TestApp::Component::TT is trying to use NEXT, which is
> deprecated. Please see the Class::C3::Adopt::NEXT documentation for details
> at
> /Users/davebowers/.cpan/build/Catalyst-Controller-FormBuilder-0.04/t/lib/Tes
> tApp/Component/TT.pm line 19
I cleverly based some of my own test libraries in the
TestApp::Component::* modules from FormBuilder.
My fixed TestApp::Component::TT ended up looking like this:
cut here
package # hide from PAUSE
TestApp::Component::TT;
# vim: ts=8 sts=4 et sw=4 sr sta
use strict;
use warnings;
use base 'Catalyst::View::TT';
use Class::C3;
sub new {
my $self = shift;
$self->config(
{
INCLUDE_PATH => [
TestApp->path_to( 'root', 'src', 'tt2' ),
TestApp->path_to( 'root', 'lib', 'tt2' ),
],
TEMPLATE_EXTENSION => '.tt',
CATALYST_VAR => 'Catalyst',
TIMER => 0,
}
);
return $self = $self->next::method(@_) if $self->next::can;
return $self;
}
cut here
I'm sure I've screwed up somewhere, but all my tests pass (again) after
this change (which you may need in the other Component::* classes under
t/lib
--
Chisel Wright
e: chi...@herlpacker.co.uk
w: http://www.herlpacker.co.uk/
It's just a motivational meeting. I don't care if I miss it.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
Louis Erickson wrote on 5/5/09 1:46 PM: > While trying to install Catalyst::Controller::FormBuilder, we got some > fairly annoying and significant looking errors. > > We're installing on OS X 10.5. This was working on a 10.4 machine, and > we got catalyst-devel to install cleanly on 10.5. > > The tests give a big chunk of errors... I'm not sure even which lines go > with which test. Does anyone have any idea why or what we might have to > do to get this to work? downgrade to Catalyst::Runtime 5.7 to start with. those errors look like 5.8 incompat issues. after you've done that, give some thought to whether you want to stick with C::C::FormBuilder. I see that the latest release is nearly 2 years old, and there are several RT tickets opened against it since then, which indicates a lack of ongoing maintenance. -- Peter Karman . http://peknet.com/ . pe...@peknet.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forward to view question
On Tue, May 5, 2009 at 1:59 PM, Andrew Rodland wrote: > > some code > > Andrew > Hi Andrew, I just got your post, plugged it in, got an error. I'll need to play with this a bit, but have an appointment, so will try later. I really appreciate the info. /dennis ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Tests fail installing Catalyst::Controller::FormBuilder
While trying to install Catalyst::Controller::FormBuilder, we got some fairly annoying and significant looking errors. We're installing on OS X 10.5. This was working on a 10.4 machine, and we got catalyst-devel to install cleanly on 10.5. The tests give a big chunk of errors... I'm not sure even which lines go with which test. Does anyone have any idea why or what we might have to do to get this to work? We're running current versions of everything as of when we ran the install, as we've installed these modules on a new machine. (We ran the install last Tuesday, and it's slipped my mind to post this until now. Will simply updating things address this?) Rather than try and guess and guess wrong what will help diagnose this, the whole output follows... sorry for the noise. (Ugh, it looks like my mail client word-wrapped it all, too.) Any suggestions on how to fix this will be very much appreciated. I have no idea where to begin even trying to sort this one out. cpan> install Catalyst::Controller::FormBuilder Running install for module Catalyst::Controller::FormBuilder Running make for J/JC/JCAMACHO/Catalyst-Controller-FormBuilder-0.04.tar.gz Is already unwrapped into directory /Users/davebowers/.cpan/build/Catalyst-Controller-FormBuilder-0.04 Has already been processed within this session Running make test Unsatisfied dependencies detected during [J/JC/JCAMACHO/Catalyst-Controller-FormBuilder-0.04.tar.gz] - Scalar::Util Running make install make test had returned bad status, won't install without force Delayed until after prerequisites Running install for module Scalar::Util Running make for G/GB/GBARR/Scalar-List-Utils-1.19.tar.gz Is already unwrapped into directory /Users/davebowers/.cpan/build/Scalar-List-Utils-1.19 Has already been processed within this session Running make test Prepending /Users/davebowers/.cpan/build/Scalar-List-Utils-1.19/blib/arch /Users/davebowers/.cpan/build/Scalar-List-Utils-1.19/blib/lib /Users/davebowers/.cpan/build/Test-Deep-0.104/blib/arch /Users/davebowers/.cpan/build/Test-Deep-0.104/blib/lib /Users/davebowers/.cpan/build/Test-Tester-0.107/blib/arch /Users/davebowers/.cpan/build/Test-Tester-0.107/blib/lib /Users/davebowers/.cpan/build/ExtUtils-MakeMaker-6.50/blib/arch /Users/davebowers/.cpan/build/ExtUtils-MakeMaker-6.50/blib/lib /Users/davebowers/.cpan/build/Test-Simple-0.86/blib/arch /Users/davebowers/.cpan/build/Test-Simple-0.86/blib/lib to PERL5LIB. PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'inc', 'blib/lib', 'blib/arch')" t/*.t t/00version.ok t/blessed...ok t/dualvar...ok t/first.ok 2/17 skipped: Poor man's MULTICALL can't cope t/isvstring.ok t/lln...ok t/max...ok t/maxstrok t/min...ok t/minstrok t/openhan...ok t/p_blessed.ok t/p_first...ok t/p_lln.ok t/p_max.ok t/p_maxstr..ok t/p_min.ok t/p_minstr..ok t/p_openhan.ok t/p_readonlyok t/p_reduce..ok t/p_refaddr.ok t/p_reftype.ok t/p_shuffle.ok t/p_sum.ok t/p_tainted.ok t/proto.ok t/readonly..ok t/reduceok 2/23 skipped: Poor man's MULTICALL can't cope t/refaddr...ok
Re: [Catalyst] Forward to view question
On Tuesday 05 May 2009 09:54:17 am Dennis Daupert wrote:
> I've created a view that's intended to write a couple of files to the file
> system.
>
> The output filename needs to be dynamically set. I'm having a bit of a go
> figuring out how to do that.
>
> The TT configuration documentation speaks of an output subroutine:
>
> OUTPUT => \&output,
>
> Later on in the view base class...
>
> sub output {
> my $filename = shift;
> # do stuff
> }
>
> Here's my question:
> How do I get the $filename into sub output when I forward to the view?
>
>
This is kind of lazy lousy code because I hate trying to squeeze real code
into an email. Hopefully it demonstrates the technique. :)
package MyApp::View::TTtoFile;
use strict;
use base 'Catalyst::View::TT';
my $outfile;
sub output {
# do stuff to $outfile
}
sub process {
my $self = shift;
(undef, $outfile) = @_; # Ignoring $c
return $self->next::method(@_);
}
__PACKAGE__->config( ... etc. etc. ...);
And then in your app you can just
$c->forward('View::TTtoFile', '/var/ham/sandwich.txt');
Andrew
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Forward to view question
I've created a view that's intended to write a couple of files to the file
system.
The output filename needs to be dynamically set. I'm having a bit of a go
figuring out how to do that.
The TT configuration documentation speaks of an output subroutine:
OUTPUT => \&output,
Later on in the view base class...
sub output {
my $filename = shift;
# do stuff
}
Here's my question:
How do I get the $filename into sub output when I forward to the view?
Here is my view class configuration:
package hde::View::TTprint;
use strict;
use base 'Catalyst::View::TT';
__PACKAGE__->config({
TEMPLATE_EXTENSION => '.tt2',
INCLUDE_PATH => [
hde->path_to( 'root', 'src' ),
hde->path_to( 'root', 'lib' ),
hde->path_to( 'root', 'tt2' )
],
PRE_PROCESS => 'config/main',
WRAPPER => 'site/wrapper',
OUTPUT => \&output,
OUTPUT_PATH => [
hde->path_to( 'root', 'static', 'published' ),
],
ERROR=> 'error.tt2',
TIMER=> 0
});
/dennis
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow fastcgi: A debugging aid
On Tue, May 05, 2009 at 01:06:52PM +0930, Jon Schutz wrote: > On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: > > > Catalyst::Plugin::AutoRestart > > > > Would I be correct in my reading of the code, that since the exit() > happens in handle_request, the request that triggers the restart does > not get served? No. The first thing this code does is call next::method to do the full normal handle_request processing. I worked with John and John on this plugin; it's rock solid and Shadowcat have used it for almost every client since. -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] unknown resource
On Sat, May 02, 2009 at 06:17:19PM +0300, Octavian Râşniţă wrote: > From: "Ash Berlin" > >I'm guessing you've got your cat app rooted/deployed on '/' and are using > >FastGCI (from your other thread)? > >If so then I think you need something like this in the config: > >Alias /server-status /server-status > > Yes, this was the problem. I made some tests and I came to the conclusion > that Catalyst responds to all those URIs which don't have a distinct Alias > when it is used with fastcgi, no matter if they are handled by other > modules. I don't understand why you mention Catalyst here. That's just how Alias works in apache; if you don't understand it you should be reading the http://httpd.apache.org/ manual and talking to apache lists; there's exactly zero Catalyst specific ness here :) -- Matt S Trout Catalyst and DBIx::Class consultancy with a clue Technical Director and a commit bit: http://shadowcat.co.uk/catalyst/ Shadowcat Systems Limited mst (@) shadowcat.co.ukhttp://shadowcat.co.uk/blog/matt-s-trout/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow fastcgi: A debugging aid
On 5 May 2009, at 04:36, Jon Schutz wrote: Octavian Râsnita wrote on 5/4/09 5:43 PM: It would be nice to be able to limit the number of requests per fastcgi child process... On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: Catalyst::Plugin::AutoRestart Would I be correct in my reading of the code, that since the exit() happens in handle_request, the request that triggers the restart does not get served? No, Since the second line is my $ret = $c->next::method(@args); This does the normal request handling first (including writing any data) then it checks the process. -ash ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow fastcgi: A debugging aid
Octavian Râsnita wrote: My development and test server is under Windows and the production server under Linux, so because perl is not a really fully portable language, I also need to do tests under the production server, which is not very nice. If your development environment doesn't look as close to production as possible, then you're going to want/need to do tests on something which *does* look like your production environment. This isn't a perl specific thing _in any way_, you'll find inter-platform differences no matter what language and runtime stack you use. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
