[Catalyst] Two ways to create record

2008-01-13 Thread Alex Povolotsky

Hello!

In Tutorial (BTW, CRUD section of tutorial lacks U completely), I've 
seen  this way of filling in the record:


   my $book = $c-model('GalleryDB::Gallery')-new({});
   $book-populate_from_widget($result);

In InstantCRUD data is filled in with

my $item = $result-save_to_db();

Can anyone experienced tell me about drawbacks of both ways to do create?

Alex.
 


___
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] Re-enable digest mode?

2008-01-13 Thread Matt S Trout
On Fri, Jan 11, 2008 at 03:43:25PM -0500, Lampert, Hugh wrote:
 Well, I respectfully submit that the purpose of a digest is so people can 
 archive the mailing list themselves in their e-mail systems, one digest per 
 day.  An RSS feed does not easily allow this, and for a busy list like this 
 one, a subscriber might receive many messages per day, the number of which 
 could rapidly increase into the thousands in the inbox.  Filtering these many 
 messages into a folder, as you suggest, will more than likely mean that for 
 me they will never get looked at at all, as I receive many, many emails that 
 require my attention every day.
 
 I use Outlook for my corporate mail system and I know your opinion of the way 
 it works Matt.  I like to keep up with Catalyst as much as possible but not 
 enough to have to monitor an RSS feed or thousands of individual e-mails in 
 my business mailbox. I have an alternate suggestion.  Re-enable digests for 
 those who subscribe to the traditional function of a mailing list and don't 
 want to be flooded by individual e-mails, and revoke and block the 
 subscriptions of those who subscribe but don't know how to respond properly 
 and spam the list by responding improperly to the digest.

I'd note that you mailed the list instead of the list admin address
which was the wrong place to do so, and just replied top-posting with the
entire message quoted below to no aim, which is exactly the problem that we
have with digests.

Should I disable your subscription too?

 I have already unsubscribed from the Catalyst list for my personal mail box, 
 which collects on a somewhat limited portable micro drive.  If I can't get a 
 digest I guess I will have to unsubscribe from the list from my corporate 
 mail box as well, as I don't want to awkwardly manage thousands of individual 
 e-mails.  While I can make some time to scan the subjects of the digest when 
 it comes into my mailbox during my work day, I'm afraid I will not have time 
 to monitor yet another RSS feed, so it will be so long Catalyst info.  Too 
 bad for me, I guess.

You can put together an outlook mail rule trivially to move the mails into
a subfolder, and skim the subjects in there. I used to do that for lists back
when I was at a job that mandated outlook. Plus that way you can actually use
threading, which makes the skimming even quicker :)

If you really want digests back on, find me a way to detect replies to digests
and reject them at the border; we're using exim and standard mailman
integration so if you're sufficiently motivated to have a go it should be
easy enough to get an equivalent setup to test.

 Interestingly, I will continue to subscribe to the DBIx-Class list, as the 
 digest for that has NOT been turned off as of yet.  Are the subscribers to 
 that list just more intelligent?

My experience is that a lot of people seem to ignore the available evidence
and assume that Catalyst is an all-in-one project with DBIC and TT - the number
of DBIC or TT related questions on here rather than the relevant lists would
certainly fit with this.

In any case, digest replies haven't become a problem there and I have no
desire to disable them unless they do.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] Two ways to create record

2008-01-13 Thread Matt S Trout
On Sun, Jan 13, 2008 at 04:47:38PM +0300, Alex Povolotsky wrote:
 Hello!
 
 In Tutorial (BTW, CRUD section of tutorial lacks U completely), I've 
 seen  this way of filling in the record:
 
my $book = $c-model('GalleryDB::Gallery')-new({});
$book-populate_from_widget($result);

which sets a bunch of data and then calls $book-insert_or_update;

 In InstantCRUD data is filled in with
 
 my $item = $result-save_to_db();

I have no idea how this works.

 Can anyone experienced tell me about drawbacks of both ways to do create?

Neither of these are standard DBIx::Class methods; the standard approach
is to do

my $obj = $rs-new(\%data);

maybe use $obj-column_name($value) to set more data

$obj-insert;

DBIx::Class::ResultSet provides a $rs-create(\%data) shortcut that calls
$obj-insert for you before returning it, but that really is just a
shortcut - the end effect is identical.

For more info, have a look at the DBIx::Class documentation on CPAN and
note that DBIC-specific questions can be asked on the dedicated dbix-class
list.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] Two ways to create record

2008-01-13 Thread Alex Povolotsky

Matt S Trout wrote:

On Sun, Jan 13, 2008 at 04:47:38PM +0300, Alex Povolotsky wrote:
  

Hello!

In Tutorial (BTW, CRUD section of tutorial lacks U completely), I've 
seen  this way of filling in the record:


   my $book = $c-model('GalleryDB::Gallery')-new({});
   $book-populate_from_widget($result);



which sets a bunch of data and then calls $book-insert_or_update;

  

In InstantCRUD data is filled in with

my $item = $result-save_to_db();



I have no idea how this works.
  

It seems to obtain $result with

my $result = $w-action( $c-uri_for('do_add') )-process( $c-request );

And $result is a HTML::Widget::Result::DBIC instance, so save_to_db is

HTML::Widget::DBIC::Result method to save the data from widget to
the database


Neither of these are standard DBIx::Class methods; the standard approach
is to do

my $obj = $rs-new(\%data);

maybe use $obj-column_name($value) to set more data

$obj-insert;

DBIx::Class::ResultSet provides a $rs-create(\%data) shortcut that calls
$obj-insert for you before returning it, but that really is just a
shortcut - the end effect is identical.

For more info, have a look at the DBIx::Class documentation on CPAN and
note that DBIC-specific questions can be asked on the dedicated dbix-class
list.

  

Thanks a lot. I'll go read it. There is such a lot of useful Perl modues...

Alex.


___
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] component's new() call browser dependent

2008-01-13 Thread Juan Camacho
I found something quite strange. When I use Firefox the model's new
method is called for each request, but if I use IE it doesn't.  This
is under mod_perl. Is this behavior by design?  Have I missed some
documentation on this?

Thanks, Juan

___
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] component's new() call browser dependent

2008-01-13 Thread Jonathan Rockway

On Sun, 2008-01-13 at 19:11 -0500, Juan Camacho wrote:
 I found something quite strange. When I use Firefox the model's new
 method is called for each request, but if I use IE it doesn't.  This
 is under mod_perl. Is this behavior by design?  Have I missed some
 documentation on this?

Can you provide a test case (just some code I can run to try to
reproduce this)?  It would be best if this works against the dev server
instead of mod_perl.

Regards,
Jonathan Rockway



signature.asc
Description: This is a digitally signed message part
___
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] component's new() call browser dependent

2008-01-13 Thread Juan Camacho
On Jan 13, 2008 7:17 PM, Jonathan Rockway [EMAIL PROTECTED] wrote:


 On Sun, 2008-01-13 at 19:11 -0500, Juan Camacho wrote:
  I found something quite strange. When I use Firefox the model's new
  method is called for each request, but if I use IE it doesn't.  This
  is under mod_perl. Is this behavior by design?  Have I missed some
  documentation on this?

 Can you provide a test case (just some code I can run to try to
 reproduce this)?  It would be best if this works against the dev server
 instead of mod_perl.


I've been simply printing to STDERR in my model new method, e.g.

use strict;
use warnings;
use base qw|Catalyst::Component::ACCEPT_CONTEXT Catalyst::Model
Class::Accessor::Fast|;
use NEXT;

package MyApp::Model::Foo;

sub new {
my $self = shift-NEXT::new(@_);
print STDERR __PACKAGE__ . ::new called;
return $self;
}

sub something_else { print STDERR something_else called\n }

Do you still need some code? Should new be called for every request or
is there some intentional session caching going on?

Juan

___
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] process a restored request

2008-01-13 Thread Matt S Trout
On Fri, Jan 11, 2008 at 07:06:17PM +, Jonas Alves wrote:
 On Jan 11, 2008 6:27 PM, Matt S Trout [EMAIL PROTECTED] wrote:
  Don't try and serialize $c-req, just dump any POST data back out into
  hidden fields in the login form, don't change the URL, and have the login
  form processed in a forward() from auto or similar rather than doing a
  detach. This is how I handle user needs to log in to continue across the
  board and it makes life much simpler.
 
  i.e. something like
 
  sub auto :Private {
my ($self, $c) = @_;
unless ($c-user_exists) {
  unless ($c-forward('try_login')) {
$c-detach('show_login_form');
return 0;
  }
}
return 1;
  }
 
  sub try_login :Private {
my ($self, $c) = @_;
my $b = $c-req-body_parameters;
return 0 unless $b-{__username};
return $c-authenticate({
 username = $b-{__username}
 password = $b-{__password}
   });
  }
 
 
 And how do you handle file uploads? Do you save them in the session?

Just keep the file in a temp dir on disk that gets cleaned out regularly
and drop an identifier into the form. Most session stores are not a good
place to store arbitrary sized files.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical Directorhttp://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

___
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] component's new() call browser dependent

2008-01-13 Thread Jonathan Rockway

On Sun, 2008-01-13 at 19:41 -0500, Juan Camacho wrote:
 Do you still need some code? Should new be called for every request or
 is there some intentional session caching going on?

new is usually called at COMPONENT time, not ACCEPT_CONTEXT time.  I'd
like to see how you're using this code, though.  What does the $c-model
call look like?  Are you sure the exact same code is being run with IE
vs. Firefox?  I don't see how the user agent would make any difference
as to whether new would run.

I asked for a minimal test case because your problem may be something
unrelated.  Making a small test case isolates the real bug.  Mostly, I'd
like to see the code working outside of mod_perl, since the mod_perl
environment could be causing problems. 

Regards,
Jonathan Rockway



signature.asc
Description: This is a digitally signed message part
___
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/