Re: [Catalyst] modperl 1.3 wierdness

[Toby Corkindale]

On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote:
> Hi guys,
> I have an application that runs well on modperl 2.0, fcgi and the standalone
> server.. but due to some stubborn/paranoid sysadmins[1] we are going to have
> to run it under modperl 1.3.

Footnotes:
1) This is their job, to be paranoid and stubborn.

2) We're actually running mod perl 1.29. Ick.


___
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] Unit Testing

[Yao Wang]

Hi Everyone,

After some research and tries. The testing code looks like following:

BEGIN { use_ok 'MyApp::Controller::abc' };

my $c = MyApp->prepare();

$c = Test::MockObject::Extends->new($c);

$c->set_always('forward',{});

MyApp::Controller::abc->get_info( $c);

ok($c->stash->{template} eq "get_info.tt2", "comparing template returned for 
get_ info page");

What i tried  is to check stash is correct and allow forward.

What do you think about this ?

Thanks,
61966

___
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] modperl 1.3 wierdness

[Toby Corkindale]

On Mon, Apr 21, 2008 at 04:54:00PM +1000, Toby Corkindale wrote:
> Hi guys,
> I have an application that runs well on modperl 2.0, fcgi and the standalone
> server.. but due to some stubborn/paranoid sysadmins[1] we are going to have
> to run it under modperl 1.3.
> 
> This has resulted in some wierdness I haven't seen before, and I wondered if
> anyone else had hit it?
[snip]
> During Apache start-up I see:
> -
> Subroutine My::App::Model::DB::OneTable::ACCEPT_CONTEXT redefined at
> lib/My/App/Model/DB.pm
> Subroutine My::App::Model::DB::TableTwo::ACCEPT_CONTEXT redefined at
> lib/My/App/Model/DB.pm
> Syntax error on line 7 of apache.conf:
> Can't locate My/App/Model/DB/OneTable.pm in @INC ([snip]).
> Compilation failed in require.
> -

The above problem was solved by changing the apache config.
Before:

   use lib qw(/my/home/dir);

PerlModule My::App

After:

   use lib qw(/my/home/dir);
   use My::App;



I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, well,
loading anything, though. Odd.

___
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] Catalyst and PayPal

[Angel Kolev]

Hi fellas.
I plan to include PayPal payment possibility in my cat website. Is there 
any plugin/tool that works with the paypal developers toolkit 
https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside 


Can anyone give me a direction.

Thanks.

___
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] Catalyst and PayPal

[Kieren Diment]

On 21 Apr 2008, at 21:22, Angel Kolev wrote:

Hi fellas.
I plan to include PayPal payment possibility in my cat website. Is  
there any plugin/tool that works with the paypal developers toolkit  
https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/ 
software_dev_kit_php-outside

Can anyone give me a direction



http://search.cpan.org/~mock/Business-PayPal/  # simplest
http://search.cpan.org/~scottw/Business-PayPal-API # newest and  
probably most complete
http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed  
on cpanratings.


Whichever one you go with a base controller (e.g.  
Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.


___
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] Catalyst and PayPal

[Angel Kolev]

Zbigniew Lukasiak wrote:

On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
  

 On 21 Apr 2008, at 21:22, Angel Kolev wrote:



Hi fellas.
I plan to include PayPal payment possibility in my cat website. Is there
  

any plugin/tool that works with the paypal developers toolkit
https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside


Can anyone give me a direction

  

 http://search.cpan.org/~mock/Business-PayPal/  # simplest
 http://search.cpan.org/~scottw/Business-PayPal-API # newest and probably
most complete
 http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed on
cpanratings.

 Whichever one you go with a base controller (e.g.
Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.



I am not so sure if the, often repeated here, advice to build
everything as a base controller is a good one.  Let's say you would
like to use the PayPal thing and FormFu - and bang you are dealing
with the tricky area of Multiple Inheritance.  'Composition over
Inheritance' is popular in other circles.

  
I dont need FormFu, because i will use Template toolkit only. May be 
Catalyst::Controller::Business::Paypal is good enough solution. Im not 
familiar with paypal, but can i test some payments without "real" money 
transactions?


___
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] Catalyst and PayPal

[Martin Ellison]

The hardest bit is encrypting your buttons. I don't think you need a
Catalyst::...::PayPal module though, you just need to be able to generate
the necessary HTML for a form with all the PayPal hidden variables. PayPal
gives you several options, so the approach you take will depend on that
decision.

On 21/04/2008, Angel Kolev <[EMAIL PROTECTED]> wrote:
>
> Zbigniew Lukasiak wrote:
>
> > On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
> >
> >
> > >  On 21 Apr 2008, at 21:22, Angel Kolev wrote:
> > >
> > >
> > >
> > > > Hi fellas.
> > > > I plan to include PayPal payment possibility in my cat website. Is
> > > > there
> > > >
> > > >
> > > any plugin/tool that works with the paypal developers toolkit
> > >
> > > https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside
> > >
> > >
> > > > Can anyone give me a direction
> > > >
> > > >
> > > >
> > >  
> > > http://search.cpan.org/~mock/Business-PayPal/
> > >  # simplest
> > >  
> > > http://search.cpan.org/~scottw/Business-PayPal-API#
> > >  newest and probably
> > > most complete
> > >  
> > > http://search.cpan.org/~sherzodr/Business-PayPal-IPN#
> > >  most reviewed on
> > > cpanratings.
> > >
> > >  Whichever one you go with a base controller (e.g.
> > > Catalyst::Controller::Business::Paypal) onto cpan would be
> > > appreciated.
> > >
> > >
> >
> > I am not so sure if the, often repeated here, advice to build
> > everything as a base controller is a good one.  Let's say you would
> > like to use the PayPal thing and FormFu - and bang you are dealing
> > with the tricky area of Multiple Inheritance.  'Composition over
> > Inheritance' is popular in other circles.
> >
> >
> >
> I dont need FormFu, because i will use Template toolkit only. May be
> Catalyst::Controller::Business::Paypal is good enough solution. Im not
> familiar with paypal, but can i test some payments without "real" money
> transactions?
>
> ___
> 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/
>



-- 
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.org
___
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] Catalyst and PayPal

[Zbigniew Lukasiak]

On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
>
>  On 21 Apr 2008, at 21:22, Angel Kolev wrote:
>
> > Hi fellas.
> > I plan to include PayPal payment possibility in my cat website. Is there
> any plugin/tool that works with the paypal developers toolkit
> https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside
> > Can anyone give me a direction
> >
>
>
>  http://search.cpan.org/~mock/Business-PayPal/  # simplest
>  http://search.cpan.org/~scottw/Business-PayPal-API # newest and probably
> most complete
>  http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed on
> cpanratings.
>
>  Whichever one you go with a base controller (e.g.
> Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.

I am not so sure if the, often repeated here, advice to build
everything as a base controller is a good one.  Let's say you would
like to use the PayPal thing and FormFu - and bang you are dealing
with the tricky area of Multiple Inheritance.  'Composition over
Inheritance' is popular in other circles.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Catalyst and PayPal

[Gavin Henry]

> Zbigniew Lukasiak wrote:
>> On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
>>
>>>  On 21 Apr 2008, at 21:22, Angel Kolev wrote:
>>>
>>>
 Hi fellas.
 I plan to include PayPal payment possibility in my cat website. Is
 there

>>> any plugin/tool that works with the paypal developers toolkit
>>> https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside
>>>
 Can anyone give me a direction


>>>  http://search.cpan.org/~mock/Business-PayPal/  # simplest
>>>  http://search.cpan.org/~scottw/Business-PayPal-API # newest and
>>> probably
>>> most complete
>>>  http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed
>>> on
>>> cpanratings.
>>>
>>>  Whichever one you go with a base controller (e.g.
>>> Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.
>>>
>>
>> I am not so sure if the, often repeated here, advice to build
>> everything as a base controller is a good one.  Let's say you would
>> like to use the PayPal thing and FormFu - and bang you are dealing
>> with the tricky area of Multiple Inheritance.  'Composition over
>> Inheritance' is popular in other circles.
>>
>>
> I dont need FormFu, because i will use Template toolkit only. May be
> Catalyst::Controller::Business::Paypal is good enough solution. Im not
> familiar with paypal, but can i test some payments without "real" money
> transactions?
>

There's already one in Catalyst SVN. We use it and have added to it for
https://www.flexitimemanager.net

See:

http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Model-PayPal-IPN/

It does the form data and encryption too. See the docs for it I did.

Gavin.

___
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] Catalyst and PayPal

[Matt S Trout]

On Mon, Apr 21, 2008 at 09:43:18PM +1000, Kieren Diment wrote:
> 
> On 21 Apr 2008, at 21:22, Angel Kolev wrote:
> >Hi fellas.
> >I plan to include PayPal payment possibility in my cat website. Is  
> >there any plugin/tool that works with the paypal developers toolkit  
> >https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/ 
> >software_dev_kit_php-outside
> >Can anyone give me a direction
> 
> 
> http://search.cpan.org/~mock/Business-PayPal/  # simplest
> http://search.cpan.org/~scottw/Business-PayPal-API # newest and  
> probably most complete
> http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed  
> on cpanratings.
> 
> Whichever one you go with a base controller (e.g.  
> Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.

Catalyst::Model::PayPal::IPN is sat in svn -

http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Model-PayPal-IPN/

I wrote this for a project a while back but haven't had time to add docs
and tests so it can be released.

Volunteers would be much appreciated; commit bit on request.

-- 
  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] Catalyst and PayPal

[Matt S Trout]

On Mon, Apr 21, 2008 at 02:22:55PM +0200, Zbigniew Lukasiak wrote:
> On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
> >
> >  On 21 Apr 2008, at 21:22, Angel Kolev wrote:
> >
> > > Hi fellas.
> > > I plan to include PayPal payment possibility in my cat website. Is there
> > any plugin/tool that works with the paypal developers toolkit
> > https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside
> > > Can anyone give me a direction
> > >
> >
> >
> >  http://search.cpan.org/~mock/Business-PayPal/  # simplest
> >  http://search.cpan.org/~scottw/Business-PayPal-API # newest and probably
> > most complete
> >  http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed on
> > cpanratings.
> >
> >  Whichever one you go with a base controller (e.g.
> > Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.
> 
> I am not so sure if the, often repeated here, advice to build
> everything as a base controller is a good one.  Let's say you would
> like to use the PayPal thing and FormFu - and bang you are dealing
> with the tricky area of Multiple Inheritance.  'Composition over
> Inheritance' is popular in other circles.

This is why this sort of controller extension should probably be a role
using Moose rather than a base class.

However, role application and multiple inheritance -are- basically
isomorphic for a lot of purposes; the difference is it's much easier to
shoot yourself in the head with multiple inheritance.

Which is probably why it's not popular - people are scared of powerful tools
that can bite :)

-- 
  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] Why does $c->stats require -Debug flag?

[Matt S Trout]

On Mon, Apr 21, 2008 at 11:49:56AM +0930, Jon Schutz wrote:
> On Sun, 2008-04-20 at 15:15 +0100, Matt S Trout wrote:
> 
> > So far as I can see, all we really need to do is supply a proxy of the
> > common Tree::Simple method from the C::Stats object through to $self->{tree}
> > and we're done. That'll provide compatibility with obvious usages without
> > adding any significant compatibility overhead.
> > 
> > I was hoping Jon would do this because he was the original author of 
> > C::Stats
> > and could see any subtleties that needed paying attention to that I've
> > missed.
> > 
> 
> I would have to review the pre-5.7012 code but from memory there were
> some differences in when internal fields in the tree were set, so
> returning $self->{tree} will stop crashes but there may be some side
> effects, such as inaccuracies in the resulting reports.

Well, if there is you can make the warning mention that.
 
> Trouble with explicitly proxying the methods is that Tree::Simple has
> many methods and who knows how many people have used what out there (I
> suspect, very few and very little, but who knows?).

So? That's just a for() loop setting up *{$name} = sub { ... } entries.
 
> You've heard my objections on principle and resistance due to minimal
> residual impact in practice, but if one were to fix it, I suppose a
> simple compromise would be something like this (untested):

That's not a compromise, that's an AUTOLOAD, which is poor coding practice
when you know what methods the object on the other side exists.

I'm aware you object on principle; however I've stated very clearly why I
believe your objections are incorrect and since you're contributing to
Catalyst I'd ask that you follow the current Catalyst standards for
backwards compatibility even if you disagree, just the same as you'd do
for coding style and other matters of opinion. If I ever contribute to one
of your projects I'll happily return the favour :)

Please can you do a specific setup, with tests; I'd suggest using
Class::Inspector to pull the list of methods and to proxy all those that
don't currently exist in your class.

Then we can have a warning included and happily throw these methods out in
5.80; the point is that people's code shouldn't go from "fully working" to
"completely broken" without a stage of "still works but warns them they're
doing it wrong" first (and note that if we'd called the method $c->_stats
I'd agree with you that it was private and we can deprecate it at will. but
we didn't. such is life)

-- 
  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] Why does $c->stats require -Debug flag?

[Matt S Trout]

On Mon, Apr 21, 2008 at 11:29:56AM +0930, Jon Schutz wrote:
> I'm making a stand here for the rights of all developers!  Backward
> compatibility is a must for defined interfaces, but to carry that
> through to say that all design decisions turn into interfaces that must
> be preserved, even though not meant for external consumption,
> discourages innovation.  Many factors separate good projects from bad,
> and one is well defined interfaces!

And the tradition in perl is that if it doesn't start with an _, it's a
public interface.

DBIx::Class originally used an "if it's not documented it's not a public
interface" approach and I got massive negative feedback over that from
people who'd followed the perl convention and got bitten later.

If I had a choice, I'd follow "documentation means public, no docs means
use at your own risk". But there's an established standard, and that isn't
it, so we live with the world we have.

You're not making a stand for anything except your right to buck standard
perl practice and get away with it; I tried, failed, had unhappy users, and
learned. Welcome to the real world sucking. If it was perfect, we'd need a
lot less developers :)

-- 
  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] modperl 1.3 wierdness

[Matt S Trout]

On Mon, Apr 21, 2008 at 07:09:26PM +1000, Toby Corkindale wrote:
> The above problem was solved by changing the apache config.
> Before:
> 
>use lib qw(/my/home/dir);
> 
> PerlModule My::App
> 
> After:
> 
>use lib qw(/my/home/dir);
>use My::App;
> 

Yep. PerlModule will do double-loading, as documented, which Catalyst can't
handle  (and shouldn't need to).

I suspect you'd've found changing PerlModule to PerlRequire would have done
the trick as well, though my MP1's rusty.
 
> I'm still seeing some problems indicating the Plugin::ConfigLoader isn't, 
> well,
> loading anything, though. Odd.

If you didn't make install it and deleted the Makefile.PL, it's not going to.

Catalyst uses the presence of Makefile.PL to check if it's running in an
unpacked dist versus running installed; since obviously an unpacked dist
-must- have a Makefile.PL otherwise it's not a valid dist[0]

Choose one option :)

[0] Yes, we do check for Build.PL as well. Hush.

-- 
  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] Catalyst and PayPal

[Ashley]

On Apr 21, 2008, at 10:44 AM, Matt S Trout wrote:

Catalyst::Model::PayPal::IPN is sat in svn -

http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Model- 
PayPal-IPN/


I wrote this for a project a while back but haven't had time to add  
docs

and tests so it can be released.

Volunteers would be much appreciated; commit bit on request.


I'm very interested in this. I've wanted to do a micro-payment based  
ad server for small/medium sites/blogs for a long time and this fits  
a big piece that was holding me back. I think J Shirley already set  
me up in SVN. If I get any tuits, I'll try to add some POD at least  
and tests if I can.


-Ashley


___
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] Unit Testing

[Matt S Trout]

On Mon, Apr 21, 2008 at 06:01:17PM +1000, Yao Wang wrote:
> Hi Everyone,
> 
> After some research and tries. The testing code looks like following:
> 
> BEGIN { use_ok 'MyApp::Controller::abc' };
> 
> my $c = MyApp->prepare();

No.

Still not safe. Still not right. Don't. Stoppit.

-- 
  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] Catalyst and PayPal

[Matt Rosin]

Hello,

I used the IPN service and it worked well in Catalyst. I used a
product database to generate a catalog with PayPal buttons set to 1
year subscriptions. Unfortunately I did the no-no and built it into a
controller so I don't suppose I should share it. So here anyway.

Maybe it is bad form to do this for a Controller based module
(encourages use) but I release this under GPL2 or higher, or Perl
Artistic License.

In my setup I allowed unregistered users to sign up, and PayPal IPN
contacted an url to activate the account in a second. Then their click
in PayPal would redirect them back to the newly activated customer
portal where they logged in.

It doesn't use those fancy modules but it _does_ do verification which
you should do too. Caveat this is an old archive and might not be
final. At least it shows what kind of thinking I distilled from all
their PDF guides. I stored all transactions and return values in a
Transaction table but have the client use PayPal's portal. Note that
PayPal sends double notifications (at least did for me).


Regards,

Matt Rosin

package CatMgr::Controller::Notify;

use strict;
use warnings;
use base 'Catalyst::Controller';


=head1 NAME

CatMgr::Controller::Notify - Catalyst Controller

=head1 DESCRIPTION

Catalyst Controller to receive notifications from payment gateways and
other services

Copyright (c) 2007-2008 Matt Rosin
I hereby make this module is available for use under GPL v2 or later,
or the Perl Artistic License.

=head1 METHODS

=cut


=head2 index

Unused. Paypal etc have their own subroutines.

=cut

sub default : Local {
  my ( $self, $c, @args ) = @_;

  my $msg = "Access Denied.";


  $c->response->body("Notify: $msg");
}


=head2 paypal

Processes an Instant Payment Notification. PayPal sends a POST to this
url (/notify/paypal) and then we validate it.

It sends the notification back to PayPal to make sure it is not being
spoofed. PayPal responds with "VERIFIED" or "INVALID" and we post back
a 200 OK response to prevent additional attempts by PayPal to post the
transaction data. If PayPal does not receive the 200 OK response from
your server, PayPal will resend the notification for up to four days.

INVALID should be treated as suspicious and be investigated.
If you receive a VERIFIED response, following checks should be done:

 Confirm payment_status is Completed (not Pending or Failed)

 Check that the txn_id is unique, to prevent a fraudster from reusing
an old, completed transaction
  They only send a txn_id with a payment_status update it seems. My
own txn id is the same if you click on a button twice, so while it is
good to keep lots of dupe notifications together, it is not useful for
checking fraud. So make sure I only fulfill once per their txn_id.

 Check item number and price using the custom field. (custom: 255 chars max)

 Skipping check of my own txn id, since no longer recording ordinary
dupe notifications.

After doing a post-back and getting VERIFIED, we record it, if it has
a payment_status field.
If we recorded everything we would get a lot of duplicates that are
just notifications that a payment was initiated but not yet cleared,
and those notifications are also a pain because they use different
fields or have missing fields anyway.

When success is determined (payment_status = Completed and unique
txn_id in the database), a purchased product is instantiated (a
Package) and the user account is changed from provisional to enabled.

When a new listing is made, the category is set to 25.
This is an unused category intentionally left empty, so the
listing.category relation works.
Otherwise Catalyst seems to want to autovivify a category no. 0 but
that insert fails for some reason and a crash.
With this change it still won't display (because it is a disabled
category) but the customer portal will let me edit it without
crashing. (If we didn't set it it would be 0, but there is no category
#0 and I think I used that fact in the past.)

Note: listings were changed 2007-0624 to be live when created by
Notify, so that people will not complain if they forget to change it
from Preparing to Live. It still won't be displayed until they set the
category from 25 to a different one, and the listing editor will not
let them get away without setting the category.

=cut

sub paypal : Local {

  my ( $self, $c, @args ) = @_;
  my $msg = "";
use Data::Dumper;
  use FreezeThaw qw(freeze thaw cmpStr safeFreeze cmpStrHard);

  my $failed = 0;
  my $money = 0;
  my $paystatus = "";

  ## VALIDATION ##

  # Check which url to use, test or live
  my $pi = $c->config->{paymentinfo}->{paypal};
  my $ppmode = $pi->{mode}; # test or live
  my $verifyurl = $pi->{$ppmode}->{verifyurl}; # sandbox or not webscr url
  # my $verifyurl = 'https://www.paypal.com/cgi-bin/webscr';
  # $verifyurl = 'https://www.sandbox.paypal.com/cgi-bin/webscr' if
$ppmode eq 'test';

  # Have user agent $ua send a validation request to paypal, and get
back a response ($ures)
  use L

Re: [Catalyst] Catalyst and PayPal

[Zbigniew Lukasiak]

On Mon, Apr 21, 2008 at 7:46 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
>
> On Mon, Apr 21, 2008 at 02:22:55PM +0200, Zbigniew Lukasiak wrote:
>  > On Mon, Apr 21, 2008 at 1:43 PM, Kieren Diment <[EMAIL PROTECTED]> wrote:
>  > >
>  > >  On 21 Apr 2008, at 21:22, Angel Kolev wrote:
>  > >
>  > > > Hi fellas.
>  > > > I plan to include PayPal payment possibility in my cat website. Is 
> there
>  > > any plugin/tool that works with the paypal developers toolkit
>  > > 
> https://www.paypal.com/cgi-bin/webscr?cmd=p/pdn/software_dev_kit_php-outside
>  > > > Can anyone give me a direction
>  > > >
>  > >
>  > >
>  > >  http://search.cpan.org/~mock/Business-PayPal/  # simplest
>  > >  http://search.cpan.org/~scottw/Business-PayPal-API # newest and probably
>  > > most complete
>  > >  http://search.cpan.org/~sherzodr/Business-PayPal-IPN # most reviewed on
>  > > cpanratings.
>  > >
>  > >  Whichever one you go with a base controller (e.g.
>  > > Catalyst::Controller::Business::Paypal) onto cpan would be appreciated.
>  >
>  > I am not so sure if the, often repeated here, advice to build
>  > everything as a base controller is a good one.  Let's say you would
>  > like to use the PayPal thing and FormFu - and bang you are dealing
>  > with the tricky area of Multiple Inheritance.  'Composition over
>  > Inheritance' is popular in other circles.
>
>  This is why this sort of controller extension should probably be a role
>  using Moose rather than a base class.
>
>  However, role application and multiple inheritance -are- basically
>  isomorphic for a lot of purposes; the difference is it's much easier to
>  shoot yourself in the head with multiple inheritance.
>
>  Which is probably why it's not popular - people are scared of powerful tools
>  that can bite :)

Yeah - I was also thinking about Moose roles here.  But I think that
subject is actually a bit broader and I think that some of the modules
in the Catalyst namespace would be better as examples, perhaps with
tests ensuring that they work with the current Catalyst release and
other libraries, than as modules.  There is some point on the diagram
of the ratio between the complexity of the API and the code where it
starts to not make sense to release the code as a module.  When the
controls of the blackbox become more complicated as the gears inside
it then I would rather use the gears directly.

I don't want to discuss any particular module here - but I would like
to get consensus that there is such a point.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Catalyst and PayPal

[Jonathan Rockway]

* On Mon, Apr 21 2008, Zbigniew Lukasiak wrote:
> There is some point on the diagram of the ratio between the complexity
> of the API and the code where it starts to not make sense to release
> the code as a module.  When the controls of the blackbox become more
> complicated as the gears inside it then I would rather use the gears
> directly.
>
> I don't want to discuss any particular module here - but I would like
> to get consensus that there is such a point.

I would like to see some examples.

I think that anything that will be used more than once should be easy to
reuse.  I never want to see the gears.  Seeing the gears means it's way
too easy to get your hair caught in them, and this is a problem that
obviously worries me :)

Regards,
Jonathan Rockway

-- 
print just => another => perl => hacker => if $,=$"

___
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] Dispatching based on path and host/domain

[Curtis Fletcher]

Hi again guys.

I've got a moderate sized Catalyst App in production now which I'm
almost happy with :)
It responds to one domain at the moment, and I'm pondering how to break
out into two or more doing mostly the same thing on the same codebase
and hopefully the same app instance.

The app has a few "usual" controllers that handle specifics like the
e-commerce, admin and soon, some database product access stuff. Any URI
that fails to match a action defaults to the root controller and is then
stripped and handled with a few calls to my model which builds the
closest page from CMS style content.

E.G.

http://mydomain.com/cart/view
Ends up calling the Local "view" method of myapp::Controller::Cart as
you might expect but
http://mydomain.com/businessunit1/product1/specialofferpage

Ends up in the root controller and queries tables that holds dynamic
URI-to-page content object mappings which then uses common code to
render the page

So for the CMS style data, if I add another domain "mydomain2" to the
apache config for my myapp and another field to the UriPage table for
"domain" and I'm almost there.
But I'm at a bit of a loss at to what to do about:
http://mydomain2.com/cart/view
Ending up at myapp::Controller::Cart->view because that domain isn't
supposed to have the e-commerce bit.

I've been pondering how to make this distinction, maybe there is
something I could get the dispatcher to do like:

package myapp::Controller::Cart;

sub view : Local Domain('mydomain.com')
{
}

Or something with the namespaces so that 
http://mydomain.com/cart/view got mapped to
myapp::mydomain::Controller::Cart->view and
http://mydomain2.com/search got mapped to
myapp::mydomain2::Controller::Search

still making sure that anything that didn't match still ended up in the
root controller unmangled.

What I think I'd like if to be able to do is opt a namespace out of a
particular domain's dispatcher
Something like:
__PACKAGE__->config->{'opt_out'}->
{
'mydomain2.com' => ['/cart',],
'mydomain.com' => ['/search',],
}

That way common actions still work on both domains. Worst comes to the
worst I'll set config options that disable methods based on ENV
variables then run two app instances on the same codebase but I'd prefer
to avoid that.

Is this approach even sane? any suggestions/pointers/thoughts are
welcomed.

___
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] Dispatching based on path and host/domain

[Matt Pitts]

> -Original Message-
> From: Curtis Fletcher [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 21, 2008 7:08 PM
> To: catalyst@lists.scsys.co.uk
> Subject: [Catalyst] Dispatching based on path and host/domain
> 
> Hi again guys.
> 
> I've got a moderate sized Catalyst App in production now which I'm
> almost happy with :)
> It responds to one domain at the moment, and I'm pondering how to
break
> out into two or more doing mostly the same thing on the same codebase
> and hopefully the same app instance.
> 
> The app has a few "usual" controllers that handle specifics like the
> e-commerce, admin and soon, some database product access stuff. Any
URI
> that fails to match a action defaults to the root controller and is
> then
> stripped and handled with a few calls to my model which builds the
> closest page from CMS style content.
> 
> E.G.
> 
> http://mydomain.com/cart/view
> Ends up calling the Local "view" method of myapp::Controller::Cart as
> you might expect but
> http://mydomain.com/businessunit1/product1/specialofferpage
> 
> Ends up in the root controller and queries tables that holds dynamic
> URI-to-page content object mappings which then uses common code to
> render the page
> 
> So for the CMS style data, if I add another domain "mydomain2" to the
> apache config for my myapp and another field to the UriPage table for
> "domain" and I'm almost there.
> But I'm at a bit of a loss at to what to do about:
> http://mydomain2.com/cart/view
> Ending up at myapp::Controller::Cart->view because that domain isn't
> supposed to have the e-commerce bit.
> 
> I've been pondering how to make this distinction, maybe there is
> something I could get the dispatcher to do like:
> 
> package myapp::Controller::Cart;
> 
> sub view : Local Domain('mydomain.com')
> {
> }
> 
> Or something with the namespaces so that
> http://mydomain.com/cart/view got mapped to
> myapp::mydomain::Controller::Cart->view and
> http://mydomain2.com/search got mapped to
> myapp::mydomain2::Controller::Search
> 
> still making sure that anything that didn't match still ended up in
the
> root controller unmangled.
> 
> What I think I'd like if to be able to do is opt a namespace out of a
> particular domain's dispatcher
> Something like:
> __PACKAGE__->config->{'opt_out'}->
> {
>   'mydomain2.com' => ['/cart',],
>   'mydomain.com' => ['/search',],
> }
> 
> That way common actions still work on both domains. Worst comes to the
> worst I'll set config options that disable methods based on ENV
> variables then run two app instances on the same codebase but I'd
> prefer
> to avoid that.
> 
> Is this approach even sane? any suggestions/pointers/thoughts are
> welcomed.
> 

You've probably heard this before on the list, but...

Ideally, you shouldn't have enough code in your Controllers to justify
"sharing" the app across domains that need different functionality. The
meat of the app should be in the Models, then you can just run multiple
Cat apps - one with Cart controllers and one without - that use the same
"shared" Models.

If you're thinking that you're "stuck with what you've got" think about
the time it will take you to implement per-domain dispatching vs. the
time to extract out functionality to a set of Models. Usually for me,
"fancy" things like dispatching based on domain take much more time to
implement than they appear, are more buggy and are harder to maintain.
Ultimately, you'll end up with more maintainable applications if you
keep the "sharable" functionality in the Models.

If you're looking to share the app for other reasons (i.e. hosting
costs) then I would look at it from a "white-labeling" perspective.
Rather than have domain information in my Controllers, I would create
the concept of "sites" inside the app and create a Plugin to interface
the current site's config interface via something like $c->site. Then in
my Cart controllers I might do something like

MyApp::Controller::Cart;

...

sub auto : Private {
my ( $self, $c ) = @_;
  
if ( ! $c->site->has_function('cart') ) {
// something here to drop the request back to your "best guess"
logic
}
}

...

1;

You could even implement $c->site to use a Model to pull in site config
info, which means changes on-the-fly.

v/r
-matt pitts

___
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] Dispatching based on path and host/domain

[Matt Pitts]

> -Original Message-
> From: Matt Pitts [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 21, 2008 9:29 PM
> To: The elegant MVC web framework
> Subject: RE: [Catalyst] Dispatching based on path and host/domain
> 
> > -Original Message-
> > From: Curtis Fletcher [mailto:[EMAIL PROTECTED]
> > Sent: Monday, April 21, 2008 7:08 PM
> > To: catalyst@lists.scsys.co.uk
> > Subject: [Catalyst] Dispatching based on path and host/domain
> >
> > Hi again guys.
> >
> > I've got a moderate sized Catalyst App in production now which I'm
> > almost happy with :)
> > It responds to one domain at the moment, and I'm pondering how to
> break
> > out into two or more doing mostly the same thing on the same
codebase
> > and hopefully the same app instance.
> >
> > The app has a few "usual" controllers that handle specifics like the
> > e-commerce, admin and soon, some database product access stuff. Any
> URI
> > that fails to match a action defaults to the root controller and is
> > then
> > stripped and handled with a few calls to my model which builds the
> > closest page from CMS style content.
> >
> > E.G.
> >
> > http://mydomain.com/cart/view
> > Ends up calling the Local "view" method of myapp::Controller::Cart
as
> > you might expect but
> > http://mydomain.com/businessunit1/product1/specialofferpage
> >
> > Ends up in the root controller and queries tables that holds dynamic
> > URI-to-page content object mappings which then uses common code to
> > render the page
> >
> > So for the CMS style data, if I add another domain "mydomain2" to
the
> > apache config for my myapp and another field to the UriPage table
for
> > "domain" and I'm almost there.
> > But I'm at a bit of a loss at to what to do about:
> > http://mydomain2.com/cart/view
> > Ending up at myapp::Controller::Cart->view because that domain isn't
> > supposed to have the e-commerce bit.
> >
> > I've been pondering how to make this distinction, maybe there is
> > something I could get the dispatcher to do like:
> >
> > package myapp::Controller::Cart;
> >
> > sub view : Local Domain('mydomain.com')
> > {
> > }
> >
> > Or something with the namespaces so that
> > http://mydomain.com/cart/view got mapped to
> > myapp::mydomain::Controller::Cart->view and
> > http://mydomain2.com/search got mapped to
> > myapp::mydomain2::Controller::Search
> >
> > still making sure that anything that didn't match still ended up in
> the
> > root controller unmangled.
> >
> > What I think I'd like if to be able to do is opt a namespace out of
a
> > particular domain's dispatcher
> > Something like:
> > __PACKAGE__->config->{'opt_out'}->
> > {
> > 'mydomain2.com' => ['/cart',],
> > 'mydomain.com' => ['/search',],
> > }
> >
> > That way common actions still work on both domains. Worst comes to
> the
> > worst I'll set config options that disable methods based on ENV
> > variables then run two app instances on the same codebase but I'd
> > prefer
> > to avoid that.
> >
> > Is this approach even sane? any suggestions/pointers/thoughts are
> > welcomed.
> >
> 
> You've probably heard this before on the list, but...
> 
> Ideally, you shouldn't have enough code in your Controllers to justify
> "sharing" the app across domains that need different functionality.
The
> meat of the app should be in the Models, then you can just run
multiple
> Cat apps - one with Cart controllers and one without - that use the
> same
> "shared" Models.
> 
> If you're thinking that you're "stuck with what you've got" think
about
> the time it will take you to implement per-domain dispatching vs. the
> time to extract out functionality to a set of Models. Usually for me,
> "fancy" things like dispatching based on domain take much more time to
> implement than they appear, are more buggy and are harder to maintain.
> Ultimately, you'll end up with more maintainable applications if you
> keep the "sharable" functionality in the Models.
> 
> If you're looking to share the app for other reasons (i.e. hosting
> costs) then I would look at it from a "white-labeling" perspective.
> Rather than have domain information in my Controllers, I would create
> the concept of "sites" inside the app and create a Plugin to interface
> the current site's config interface via something like $c->site. Then
> in
> my Cart controllers I might do something like
> 
> MyApp::Controller::Cart;
> 
> ...
> 
> sub auto : Private {
> my ( $self, $c ) = @_;
> 
> if ( ! $c->site->has_function('cart') ) {
> // something here to drop the request back to your "best
guess"
> logic
> }
> }
> 
> ...
> 
> 1;
> 
> You could even implement $c->site to use a Model to pull in site
config
> info, which means changes on-the-fly.
> 
> v/r
> -matt pitts

Some improvements to my own idea...

1) Abstract the ideas of "controller functions" and "separate sites" as
separate plugins.

2) Build a ControllerRoles plugin and implement
$c->site->has_function('cart') as
$c->can_access_controller_roles('cart')

3) Build the 

[Catalyst] DBIC error when starting dev server

[Andrew]

I'm just starting with Catalyst (but experienced in MVC frameworks) and I got J. Rockway's book.  I'm working through the 1st DB example (pages 27-30), where we use DBIC to connect to a simple database.  When I start the development server, I get the following error -"Couldn't instantiate component "MyApp::Model::TestDatabase", "Can't call method "require" without a package or object reference at /usr/local/share/perl/5.8.8/Catalyst/Model/DBIC/Schema.pm line 271." at script/myapp_server.pl line 53Compilation failed in require at script/myapp_server.pl line 53."I've checked that the test database exists and that it has the right path (/tmp/database), I've also made sure that the database controller does not have any syntax errors.  Also I cut and pasted the html and I'm sure that's formatted correctly after checking in a
 browser.  I am newbie at Catalyst (and haven't programmed in Perl in about 2 years) so I'm sure I'm missing something.  Suggestions?

  Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.

___
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] DBIC error when starting dev server

[Andrew Rodland]

On Monday 21 April 2008 09:08:37 pm Andrew wrote:
> I'm just starting with Catalyst (but experienced in MVC frameworks) and I
> got J. Rockway's book.  I'm working through the 1st DB example (pages
> 27-30), where we use DBIC to connect to a simple database. 

http://catwiki.toeat.com/thebookerrata

Specifically: "On page 28, the "\" characters are meant to be continuations of 
the command-line across newlines. The newlines were omitted, so you should 
also omit the "\" characters."

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/