Re: [Catalyst] chained requests

[Trevor Leffler]

Hi Theo,

I hope that these resources on chained action methods will help you get started:

From the Catalyst Manual…
https://metacpan.org/pod/distribution/Catalyst-Manual/lib/Catalyst/Manual/Tutorial/04_BasicCRUD.pod#CONVERT-TO-A-CHAINED-ACTION

Examples from the Catalyst wiki…
http://wiki.catalystframework.org/wiki/gettingstarted/howtos/chainedexamples.view

A Catalyst advent calendar entry…
http://www.catalystframework.org/calendar/2006/10


Here is a code snippet that could work for your case…

# see also ChainedParent for non-Root controllers
sub base : Chained(‘/’) PathPart(‘test’) CaptureArgs(1) {
  my ($self, $c, $product_id) = @_;
  # do something with $product_id
}

sub create : Chained(‘base’) PathPart(‘create’) Args(0) {
  my ($self, $c) = @_;
}

Best,
--Trevor

From: catalyst-boun...@lists.scsys.co.uk 
[mailto:catalyst-boun...@lists.scsys.co.uk] On Behalf Of Theo Bot
Sent: Friday, November 3, 2017 7:52 AM
To: The elegant MVC web framework 
Subject: [Catalyst] chained requests

Hi
How do I create a single controller, that would be able to handle the following 
requests
/test/productA/create
and
/test/productB/create


--
Kind regards,

Theo Bot
___
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] An MVC logic separation conundrum

[Trevor Leffler]

Chris,

Related to this, I've a scheduled job that sends email that include URLs 
back to my catalyst app, so... can't really use a callback here.  URL 
details such as hostname and path are configuration info.  It would be 
nice to have a light-weight method for accessing the app's routing, but 
I'm okay with the balance and separation of concerns achieved via some 
minor "duplication."


As a second example, my app does something similar to yours...

  my $cj = $c->model('Collection::JSON');
  $cj->add_links({href => $c->uri_for(...)->as_string);

This model holds data returned via my Web API.  It's bothered me that if 
I wanted to use it outside of a web app I'd need some other way to 
supply URIs, but I've also shrugged this off because, um... *it's for a 
Web API* and the coupling seems necessary.  ;)  Regardless, the model's 
interface is clean, and it's not the model's job to figure out what the 
end-point URIs are supposed to me.


Okay, enough with my ramblings!

Cheers,
--Trevor

On 03/10/2016 04:03 PM, Aristotle Pagaltzis wrote:

* Chris Welch  [2016-03-10 15:45]:

My original question was not about passing the method call in per se,
but the return value from that method call


You could do that of course.

The question I’d ask is, does the caller have to know which values from
the match object it needs to pick out and put together to produce the
required value?

If yes, then that would leak responsibility from generate_ical_data back
into its caller – which means e.g. if you want to change exactly how the
iCal data is generated then you also have to change the caller, not just
generate_ical_data.

If not, such as if the values you pass to uri_for_action depend on the
action only, then you can just pass the return value without causing
problems, sure. And if you *can* do that, then it’s the better choice,
because the code will be more readable that way – not just the caller
but more importantly generate_ical_data itself. Callbacks will be quite
a bit more clunky than simple values there.

Like I said, it depends on the exact specifics.

Regards,



___
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] From Development to Production.

[Trevor Leffler]

+1 for Carton for managing perl application dependencies.

Also perlbrew or plenv for using your own perl / separating your app 
from the system perl.


I agree whole-heartedly with James regarding being able to stabilize 
your app's environment and being able to consistently reproduce it. 
Whether I'm spinning up a new prod server or getting a new developer up 
and running, I want a [near] push-button method for getting the app 
running as quickly as possible, and I don't want any "different versions 
of dependencies" bugs wasting my time.


--Trevor


On 03/02/2016 12:23 PM, James Leu wrote:

It all comes down to the apps 'environment`.

Do you remember when you started developing your catalyst app you had to
install a bunch of perl modules?

Those same modules (preferabbly the EXACT same versions as you installed
on your development machine) need to be installed on your
production machine.  Once you have the same 'environment'
between dev and prod, then yeah, you can just 'copy' your
app's source tree to prod, and it will "just work".

The problem we run into is that CPAN is a moving target.
Install Catalyst today might result in different versions
of modules, then when you install catalyst to start you development.
Those differences in versions of modules can result in complete
failure of the app or small subtle changes in the way it runs, or even
worse, exposes a new exploitable bug in your app.

So consistency of you apps 'environment' between dev, production,
and production a year from now, it one of the biggest challenges
to your approach.

You can look into things like Carton, PAR, FatPacker which will
bundle up the perl environment for an App so you can
deploy it.

If you like to be 'ahead of the curve', start looking at using docker
or atomic for each of you web apps.

Best of luck

On Wed, Mar 02, 2016 at 07:04:53PM -, Andrew wrote:

---> Really looking to keep it simple stupid, to be fair.

---> Looks like a lot to learn atm, so am likely to just copy and paste
folders for the time being.

---> I got a bit confused here:

As a baby-step prior to doing builds and auto deployment, you can
checkout your code from your production server(s).  While this is still
a manual step, it's probably better than copying folders and files.

---> If you're not doing an auto deployment, and you're not copying folders
and files, how are you checking out your code from the production server?

Grateful for all the insights,

Yours,
Andrew.



- Original Message -
From: "Trevor Leffler" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
Sent: Wednesday, March 02, 2016 6:54 PM
Subject: Re: [Catalyst] From Development to Production.


Yes, that.  But to be a tad verbose about it...

Use version control and branches (or whatever your VCS prefers).  Cut a
new branch whenever you want to create a new "release" for production.
This will let you switch from one branch to the next (upgrade) or back
again if things blow up.

As a baby-step prior to doing builds and auto deployment, you can
checkout your code from your production server(s).  While this is still
a manual step, it's probably better than copying folders and files.

Once you're there, start looking into "builds."  Generally folks use
some kind of Continuous Integration (CI) software that polls your VCS
for recent commits and then "kicks off a build."  The simplest thing it
might do is checkout the latest code revision and tar it up.  This
tarfile is a "build artifact" ready for you to deploy (i.e. copy into
production and untar).  Your work after this point is to figure out what
else you'd like to happen during a build -- run tests? create
documentation? do code inspections? -- and research how your build
artifacts could be automatically deployed.

I'll echo Toomas in that there's a lot to learn here and keep you busy
depending on how far you want/can take it.

Cheers,
--Trevor


On 03/02/2016 10:32 AM, Toomas Pelberg wrote:

Go learn about version control and deployment automation, you can google
these keywords and will likely be busy for the next few weeks ;-) it's a
pretty wide and interesting reading

From: Andrew <mailto:catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework <mailto:catalyst@lists.scsys.co.uk>
Subject: [Catalyst] From Development to Production.

So, I'm trying to learn Modern Perl workflows,
and I heard it's best to do all your development on a development server,
rather than mess around with code live, on the production server.
So let's say I've coded my Catalyst app on a dev server, and it's in a
folder called MyApp
Do I just copy the MyApp folder to the Production Server?
[Am likely to copy and paste the folder using Cyberduck].
I mean, assuming the producti

Re: [Catalyst] From Development to Production.

[Trevor Leffler]

On 03/02/2016 11:04 AM, Andrew wrote:

---> Really looking to keep it simple stupid, to be fair.

---> Looks like a lot to learn atm, so am likely to just copy and paste
folders for the time being.

---> I got a bit confused here:

As a baby-step prior to doing builds and auto deployment, you can
checkout your code from your production server(s).  While this is still
a manual step, it's probably better than copying folders and files.

---> If you're not doing an auto deployment, and you're not copying folders
and files, how are you checking out your code from the production server?


Maybe a typo there: "check out code *to* your prod server".  The code 
would live in a repository somewhere else.


Once you have your code safely in version control (e.g. git, 
subversion), you can check out that code to wherever you want.  So while 
yes, technically, files are being copied from *somewhere* into your 
production environment, you're using a tool to fetch them from your code 
repository and telling it exactly which branch/revision of those files 
you want.  To me, this is a safer, more repeatable way of 
up-/down-grading my production application.


You could also tar/zip up your app folder, copy that over, untar it. 
You'd manage the tars/zips yourself, maybe naming them myapp-0.01, 
myapp-0.02, or whatever.


Really, look into version control for your software projects.  You'll 
thank yourself and never look back.


Best,
--Trevor


Grateful for all the insights,

Yours,
Andrew.



- Original Message -
From: "Trevor Leffler" <tleff...@uw.edu>
To: "The elegant MVC web framework" <catalyst@lists.scsys.co.uk>
Sent: Wednesday, March 02, 2016 6:54 PM
Subject: Re: [Catalyst] From Development to Production.


Yes, that.  But to be a tad verbose about it...

Use version control and branches (or whatever your VCS prefers).  Cut a
new branch whenever you want to create a new "release" for production.
This will let you switch from one branch to the next (upgrade) or back
again if things blow up.

As a baby-step prior to doing builds and auto deployment, you can
checkout your code from your production server(s).  While this is still
a manual step, it's probably better than copying folders and files.

Once you're there, start looking into "builds."  Generally folks use
some kind of Continuous Integration (CI) software that polls your VCS
for recent commits and then "kicks off a build."  The simplest thing it
might do is checkout the latest code revision and tar it up.  This
tarfile is a "build artifact" ready for you to deploy (i.e. copy into
production and untar).  Your work after this point is to figure out what
else you'd like to happen during a build -- run tests? create
documentation? do code inspections? -- and research how your build
artifacts could be automatically deployed.

I'll echo Toomas in that there's a lot to learn here and keep you busy
depending on how far you want/can take it.

Cheers,
--Trevor


On 03/02/2016 10:32 AM, Toomas Pelberg wrote:

Go learn about version control and deployment automation, you can google
these keywords and will likely be busy for the next few weeks ;-) it's a
pretty wide and interesting reading

From: Andrew <mailto:catalystgr...@unitedgames.co.uk>
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework <mailto:catalyst@lists.scsys.co.uk>
Subject: [Catalyst] From Development to Production.

So, I'm trying to learn Modern Perl workflows,
and I heard it's best to do all your development on a development server,
rather than mess around with code live, on the production server.
So let's say I've coded my Catalyst app on a dev server, and it's in a
folder called MyApp
Do I just copy the MyApp folder to the Production Server?
[Am likely to copy and paste the folder using Cyberduck].
I mean, assuming the production server is setup to run it, and so forth...
Let's for example say, I'd already published Version 1.0 of my website
on the production server.
And it's running from a MyApp directory on the production server.
Then I code a version 2.0 on my development server, in a folder called
MyApp, and I want to publish that
...do I just again, copy MyApp from my development server, over to my
production server?
Obviously, new files would overwrite old ones.
What about if version 2.0 saw me delete some old unused stuff, do I have
to make a note of what they were,
and go through the folder on the production server and delete them?
Or is there some graceful way to sync the development and production
versions of my code?
What are other people doing?
Grateful for any insights.
Yours,
Andrew.


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable

Re: [Catalyst] From Development to Production.

[Trevor Leffler]

Yes, that.  But to be a tad verbose about it...

Use version control and branches (or whatever your VCS prefers).  Cut a 
new branch whenever you want to create a new "release" for production. 
This will let you switch from one branch to the next (upgrade) or back 
again if things blow up.


As a baby-step prior to doing builds and auto deployment, you can 
checkout your code from your production server(s).  While this is still 
a manual step, it's probably better than copying folders and files.


Once you're there, start looking into "builds."  Generally folks use 
some kind of Continuous Integration (CI) software that polls your VCS 
for recent commits and then "kicks off a build."  The simplest thing it 
might do is checkout the latest code revision and tar it up.  This 
tarfile is a "build artifact" ready for you to deploy (i.e. copy into 
production and untar).  Your work after this point is to figure out what 
else you'd like to happen during a build -- run tests? create 
documentation? do code inspections? -- and research how your build 
artifacts could be automatically deployed.


I'll echo Toomas in that there's a lot to learn here and keep you busy 
depending on how far you want/can take it.


Cheers,
--Trevor


On 03/02/2016 10:32 AM, Toomas Pelberg wrote:

Go learn about version control and deployment automation, you can google
these keywords and will likely be busy for the next few weeks ;-) it's a
pretty wide and interesting reading

From: Andrew 
Sent: ‎3/‎2/‎2016 20:17
To: The elegant MVC web framework 
Subject: [Catalyst] From Development to Production.

So, I'm trying to learn Modern Perl workflows,
and I heard it's best to do all your development on a development server,
rather than mess around with code live, on the production server.
So let's say I've coded my Catalyst app on a dev server, and it's in a
folder called MyApp
Do I just copy the MyApp folder to the Production Server?
[Am likely to copy and paste the folder using Cyberduck].
I mean, assuming the production server is setup to run it, and so forth...
Let's for example say, I'd already published Version 1.0 of my website
on the production server.
And it's running from a MyApp directory on the production server.
Then I code a version 2.0 on my development server, in a folder called
MyApp, and I want to publish that
...do I just again, copy MyApp from my development server, over to my
production server?
Obviously, new files would overwrite old ones.
What about if version 2.0 saw me delete some old unused stuff, do I have
to make a note of what they were,
and go through the folder on the production server and delete them?
Or is there some graceful way to sync the development and production
versions of my code?
What are other people doing?
Grateful for any insights.
Yours,
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/



___
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] Keep Plack -r working when commandline closed...?

[Trevor Leffler]

What about wrapping your shell session with screen?

$ man screen

--Trevor

On 10/23/2015 08:21 AM, Andrew wrote:


I've ended up using Plackup to start the catalyst app's psgi script (still
via fast cgi),
and I'm using -r to indicate it should watch for changes, and reload the
server when changes are detected.

It does this fine, as long as my commandline terminal is still open.
The moment I close it, the server continues to run, yet any watching for
changes, killing, and restarting no longer happens (as far as I can tell).

Is there any way to get Plack's scripts that watch and reload (i.e.
Restarter.pm, etc), to continue to run after I close OSX's terminal window /
end the SSH session?


Many thanks for any insights offered,

Yours,
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/



___
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] How to get default()-like behavior outside of the Root controller

[Trevor Leffler]

Hi Aristotle,

On 02/10/2015 02:39 AM, Aristotle Pagaltzis wrote:

Hi Trevor,

* Trevor Leffler tleff...@uw.edu [2015-02-07 00:00]:

Requests for non-extant paths fall through to Root-default(), which
gives the (undesired) default root view. I tried giving my top-level
controllers their own default() methods, but as others have found [1],
'default() : Path' has precedence over 'index : Chained'.


 package MyApp::Admin;
 sub default : Chained('base') PathPart('') { ... }
 package MyApp::Survey;
 sub default : Chained('base') PathPart('') { ... }

Note how you don’t specify any particular number of arguments. So it
will match any number of trailing URL segments.

I *think* this will work. I haven’t tried it.


I had tried this earlier with poor results.  However, I spun up a quick 
Foo catalyst project for testing and found that if I defined *all* the 
defaults()'s as :Chained in Root/Admin/Survey/etc. then they played well 
with my other methods, all of which are :Chained.  Once you go 
:Chained...  ;)



However, contrary to what you claimed, splitting the app into multiple
Cat apps joined together at the PSGI level *will* also work just fine.
That will lead to requests for /admin/* always being dispatched to
MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
with a `default` action that applies only to it. Likewise requests for
/survey/* will always be dispatched to MyApp::Survey which equally has
its own root controller with a `default` action that applies only to it.
If the parts of your app are not closely related, this will be a more
natural structure.


I don't think I spoke against splitting my app up, rather I just ignored 
that line of thought.  ;)  There may be too many 
relationships/dependencies across the major areas to split it up in the 
immediate future, but I can see some architectural advantages to doing 
so.  Simply the fact that I've got variations in template wrappers may 
be an indicator.


Thanks,
--Trevor


Regards,



___
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] How to get default()-like behavior outside of the Root controller

[Trevor Leffler]

It turns out the length of the chaining is a variable in this equation.

In my Test Controller...

This gives good behavior:
sub base : Chained('/') PathPart('test') CaptureArgs(0) {}
sub another : Chained('base') PathPart('') CaptureArgs(0) {}
sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('another') PathPart('') Args() { ... }

But this gives too much weight to default, allowing it to win over 
index():

sub index : Chained('another') PathPart('') Args(0) {...}
sub default : Chained('base') PathPart('') Args() { ... }

So, the shorter chain wins, eh?  This latter scenario is more common for 
me.  I'll look into having my index() $c-forward to the bits I need.


--Trevor

On 02/10/2015 02:19 PM, Trevor Leffler wrote:

Hi Aristotle,

On 02/10/2015 02:39 AM, Aristotle Pagaltzis wrote:

Hi Trevor,

* Trevor Leffler tleff...@uw.edu [2015-02-07 00:00]:

Requests for non-extant paths fall through to Root-default(), which
gives the (undesired) default root view. I tried giving my top-level
controllers their own default() methods, but as others have found [1],
'default() : Path' has precedence over 'index : Chained'.


 package MyApp::Admin;
 sub default : Chained('base') PathPart('') { ... }
 package MyApp::Survey;
 sub default : Chained('base') PathPart('') { ... }

Note how you don’t specify any particular number of arguments. So it
will match any number of trailing URL segments.

I *think* this will work. I haven’t tried it.


I had tried this earlier with poor results.  However, I spun up a quick
Foo catalyst project for testing and found that if I defined *all* the
defaults()'s as :Chained in Root/Admin/Survey/etc. then they played well
with my other methods, all of which are :Chained.  Once you go
:Chained...  ;)


However, contrary to what you claimed, splitting the app into multiple
Cat apps joined together at the PSGI level *will* also work just fine.
That will lead to requests for /admin/* always being dispatched to
MyApp::Admin – which gets to have its own MyApp::Admin::Controller::Root
with a `default` action that applies only to it. Likewise requests for
/survey/* will always be dispatched to MyApp::Survey which equally has
its own root controller with a `default` action that applies only to it.
If the parts of your app are not closely related, this will be a more
natural structure.


I don't think I spoke against splitting my app up, rather I just ignored
that line of thought.  ;)  There may be too many
relationships/dependencies across the major areas to split it up in the
immediate future, but I can see some architectural advantages to doing
so.  Simply the fact that I've got variations in template wrappers may
be an indicator.

Thanks,
--Trevor


Regards,



___
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/


___
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] How to get default()-like behavior outside of the Root controller

[Trevor Leffler]

On 2/9/2015 1:59 AM, Dmitry L. wrote:

I'd rather split one application into several (admin app, survey app,
etc) and join its via middleware.

But you can try this:

In MyApp::Admin:
sub default : Path('admin') {
# or
# sub default : Chained(base) PathPart('') Path {
 my ( $self, $c ) = @_;
 $c-response-body( 'Page not found in /admin/...' );
 $c-response-status(404);
}


Neither of these work, as in both cases default() wins over index() 
except when index is defined as 'sub index : Path', which isn't a good 
option for me.


And... I'd imagine that having both default and index defined with  : 
Chained('base') PathPart('') Args(0) would lead to a collision and/or 
non-deterministic behavior...?


--Trevor



In MyApp::Survey;
sub default : Path('survey') {
# or
# sub default : Chained(base) PathPart('') Path {
 my ( $self, $c ) = @_;
 $c-response-body( 'Page not found in /survey/...' );
 $c-response-status(404);
}

On 7 February 2015 at 01:51, Trevor Leffler tleff...@uw.edu wrote:

Some of my top-level controllers represent different, er... major pieces
of my application.  They have, among other things, different default views,
which are mainly just for configuring different page wrappers.  These
controllers have this action pattern:

package MyApp::Admin;
sub base : Chained('/') : PathPart('admin') : CaptureArgs(0) { ... }
sub index : Chained('base') : PathPart('') : Args(0) { ... }

package MyApp::Survey;
sub base : Chained('/') : PathPart('survey') : CaptureArgs(0) { ... }
...etc...

Requests for non-extant paths fall through to Root-default(), which gives
the (undesired) default root view.  I tried giving my top-level controllers
their own default() methods, but as others have found [1], 'default() :
Path' has precedence over 'index : Chained'.  Otherwise, I get the
appropriate view with 'Page Not Found' content for bad urls, e.g.
/admin/blargh or /survey/123/nurgle

I am looking for suggestions/solutions to get the desired behavior.

Changing index() to 'index : Path' is not a viable option.


Thanks,
--Trevor

[1] http://www.gossamer-threads.com/lists/catalyst/users/24883

___
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/






--
Trevor Leffler, Sr. Software Engineer
Office of Educational Assessment
University of Washington
4311 11th Ave NE, Seattle, WA 98195
tel 206.616.1479 | fax 206.543.3961
http://www.washington.edu/oea

___
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] How to get default()-like behavior outside of the Root controller

[Trevor Leffler]

Some of my top-level controllers represent different, er... major 
pieces of my application.  They have, among other things, different 
default views, which are mainly just for configuring different page 
wrappers.  These controllers have this action pattern:


package MyApp::Admin;
sub base : Chained('/') : PathPart('admin') : CaptureArgs(0) { ... }
sub index : Chained('base') : PathPart('') : Args(0) { ... }

package MyApp::Survey;
sub base : Chained('/') : PathPart('survey') : CaptureArgs(0) { ... }
...etc...

Requests for non-extant paths fall through to Root-default(), which 
gives the (undesired) default root view.  I tried giving my top-level 
controllers their own default() methods, but as others have found [1], 
'default() : Path' has precedence over 'index : Chained'.  Otherwise, I 
get the appropriate view with 'Page Not Found' content for bad urls, 
e.g. /admin/blargh or /survey/123/nurgle


I am looking for suggestions/solutions to get the desired behavior.

Changing index() to 'index : Path' is not a viable option.


Thanks,
--Trevor

[1] http://www.gossamer-threads.com/lists/catalyst/users/24883

___
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] Please help to figure out with URL's

[Trevor Leffler]

Hi,

tl;dr - Use c.uri_for() everything, including statics.

I can't say why your links are 0.0.0.0/image.png without looking at the 
full source of your page.  I think your browser is doing this, maybe 
with some (bad) hints.


However... c.uri_for('/image.png') is the right way to do it.  It will 
make sure the correct hostname, port, and path prefix for your 
application are used, and it makes your app relocatable -- meaning you 
won't have to change all of your static urls when your app's URL or root 
path changes.


This is a typical use:

link href=[% c.uri_for('/static/css/my_style.css') | html %] 
rel=stylesheet


Cheers,
--Trevor

On 12/04/2014 11:23 AM, Александер Пономарёв wrote:

Hello to all,
I'm very beginner in Catalyst and now I've faced up with the problem: on
my dev sever (script/myapp_server.pl http://myapp_server.pl) I've got
urls to static files like, for example 0.0.0.0/image.png
http://0.0.0.0/image.png, instead of localhost:3000/image.png. (in
template it looks like img src=/image.png /
So, I can't load any static file in my dev-server. Please, help me to
figure out what's going.
And yes, uri_for('/image.png') works fine, but, may be, there is another
way to do it?

Thanks for youre help.


___
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/



___
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] Please help to figure out with URL's

[Trevor Leffler]

I think you need to figure out what the problem is before knowing 
whether (and what) you need to tweak.  You might try creating a simple, 
minimal page and template with just a link and see if it's still 
happening.  Something like...


html
  headtitleTest/title/head

  body
pa href=/static/images/catalyst_logo.pngimg 
src=/static/images/catalyst_logo.png/a/p

  /body
/html


--Trevor

On 12/04/2014 12:00 PM, Александер Пономарёв wrote:

Yes, it comes from my browser, but I don't think it's normal, because I
didn't see it before in my mojolicious application.
Anyway, I think, there is the way to tweak an environment of the dev
server. Am I right? ;-)

2014-12-05 1:41 GMT+06:00 Trevor Leffler tleff...@uw.edu
mailto:tleff...@uw.edu:

Hi,

tl;dr - Use c.uri_for() everything, including statics.

I can't say why your links are 0.0.0.0/image.png
http://0.0.0.0/image.png without looking at the full source of
your page.  I think your browser is doing this, maybe with some
(bad) hints.

However... c.uri_for('/image.png') is the right way to do it.  It
will make sure the correct hostname, port, and path prefix for your
application are used, and it makes your app relocatable -- meaning
you won't have to change all of your static urls when your app's URL
or root path changes.

This is a typical use:

link href=[% c.uri_for('/static/css/my___style.css') | html %]
rel=stylesheet

Cheers,
--Trevor

On 12/04/2014 11:23 AM, Александер Пономарёв wrote:

Hello to all,
I'm very beginner in Catalyst and now I've faced up with the
problem: on
my dev sever (script/myapp_server.pl http://myapp_server.pl
http://myapp_server.pl) I've got
urls to static files like, for example 0.0.0.0/image.png
http://0.0.0.0/image.png
http://0.0.0.0/image.png, instead of localhost:3000/image.png. (in
template it looks like img src=/image.png /
So, I can't load any static file in my dev-server. Please, help
me to
figure out what's going.
And yes, uri_for('/image.png') works fine, but, may be, there is
another
way to do it?

Thanks for youre help.


_
List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk
Listinfo:
http://lists.scsys.co.uk/cgi-__bin/mailman/listinfo/catalyst
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/__catalyst@lists.scsys.co.uk/
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


_
List: Catalyst@lists.scsys.co.uk mailto:Catalyst@lists.scsys.co.uk
Listinfo:
http://lists.scsys.co.uk/cgi-__bin/mailman/listinfo/catalyst
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/__catalyst@lists.scsys.co.uk/
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.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/



___
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] HTTP headers returned from GET vs HEAD

[Trevor Leffler]

I've been playing with a toy application and inspecting its responses to 
various HTTP methods and noticed that Content-Length is missing from the 
HEAD response.  Both Catalyst::Action::RenderView and C::A::Serialize 
(from the C::A::REST package) seem to take the easy way out and return 
1 if $c-req-method eq 'HEAD'.  Does anyone with CAR history know why 
this is?


To provide message-body-based headers (content-length, last-modified, 
content-md5, etc) I'm doing this:


sub render : ActionClass('RenderView') { }

sub end : Private {
  my $self = shift;
  my ($c) = @_;

  $c-forward('render');

  # see also Catalyst::Action::RenderView or ::Serialize
  if ($c-req-method eq 'HEAD') {
my $view = $c-view
  || die sprintf(%s could not find a view to forward to.\n, 
__PACKAGE__);

$c-forward($view);
  }

  # fun with headers, for example...
  # or enable P::M::ContentMD5
  if ($c-res-has_body) {
my $md5 = Digest::MD5::md5_hex($c-res-body);
$c-res-headers-header(Content-MD5 = $md5);
  }
}

I've noted that while $c-res-body now has my rendered view, it gets 
removed by Plack::Middleware::Head prior to returning the response, so I 
don't have to worry about that detail.


--Trevor

___
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 Actions precedence

[Trevor Leffler]

Hi Nick,

The best answer I've been able to find is Don't Do This from here:

https://metacpan.org/module/Catalyst::Manual::Intro#URL-Path-Handling

Beware! If you write two matchers, that match the same path, with the 
same specificity (that is, they match the same quantity of the path), 
there's no guarantee which will actually get called.


So you're right in your confusion with the scenario you wrote up: why do 
action0 and actionx get matched, but action1 is ignored in favor of 
(:Chained) pages?  Kieren's answer sort of side-stepped the issue by 
inferring that all this goes away when you use the same matching system, 
:Chained.  By leveling the playing field it all works as you would 
expect.  I just (re-)skimmed the dwarves example, and unfortunately it 
doesn't explicitly say *not* to mix :Chained with other dispatch types.


The Manual's summary statement above might also have been: Once you go 
:Chained, go :Chained all the way.  Or at least don't have a wildcard 
chained action like pages() along with non-chained actions and expect 
things to work predictably...  ;)


--Trevor


On 02/27/2013 01:20 PM, Nick Anderson wrote:

Hi,

please could someone explain how Catalyst determines the precedence of
actions, specifically in relation to the following simple chained
example. It doesn't behave in the way I would expect for requests
numbered 4 and 6:

1. http://127.0.0.1:3001/action0 = Matched action 0
2. http://127.0.0.1:3001/action0/abc = Matched XPages / pages
3. http://127.0.0.1:3001/action1 = Matched XPages / pages
4. http://127.0.0.1:3001/action1/abc = Matched XPages / pages
5. http://127.0.0.1:3001/actionx = Matched action x
6. http://127.0.0.1:3001/actionx/abc = Matched XPages / pages

The controllers are detailed below:

package TestApp::Controller::Root;
use Moose;
use namespace::autoclean;

BEGIN { extends 'Catalyst::Controller' }

__PACKAGE__-config(namespace = '');

sub site_base :Chained :PathPart('') :CaptureArgs(0) {
 my ($self,$c ) = @_;
}

sub action0 :Path('action0') :Args(0) {
 my ($self,$c ) = @_;
 $c-response-body( Matched action 0 );
}

sub action1 :Path('action1') :Args(1) {
 my ($self,$c ) = @_;
 $c-response-body( Matched action 1 );
}

sub actionx :Path('actionx') :Args() {
 my ($self,$c ) = @_;
 $c-response-body( Matched action x );
}

sub end : ActionClass('RenderView') {}

__PACKAGE__-meta-make_immutable;

1;

package TestApp::Controller::XPages;
use Moose;
use namespace::autoclean;

BEGIN {extends 'Catalyst::Controller'; }

sub base : Chained( '/site_base' ) : PathPart('') : CaptureArgs( 1 ) {
 my ( $self, $c ) = @_;
}

sub pages : Chained( 'base' ) : PathPart('') : Args() {
 my ( $self, $c ) = @_;
 $c-response-body('Matched XPages  / pages');
}

__PACKAGE__-meta-make_immutable;

1;


Thanks for any help you can give

Nick Anderson

___
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/


___
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] Minify JS/CSS and server as static files

[Trevor Leffler]

If you've a build process, that can also be a good time to create 
minified versions of css/js, pre-process templates, etc. so that 
everything is how you want it for your production environment.


--Trevor


Pavel Karoukin wrote:

Hello,

I am looking to develop feature in my project but want to check if
something already exists or there is existing pattern to implement it.

Bassically, I want in my TT templates add JS/CSS files into header. And
in production mode I want minify/aggregate 'em and save on disc so web
server could serve these minified and aggregated files directly.

How I plan to do it:

In TT layout template define array variable and all templates will be
adding there JS/CSS they need. Then in main template I will generate
code like:

link rel=stylesheet type=text/css
href=/minify/css?files=path/to/file1.css;path/to/file2.css /

/minify/css will be action of controller minify to join and minify these
files and save them in /static subfolder as single file. Then I need to
configure webserver somehow to look for this file (good question - how
to do it...) and serve it directly instead of firing catalyst action.

Few problems tho:
1) How to name files to keep track of: list of files in minified file,
their update date.
2) How to remove old files. (probably with cron?)

Any ideas will be really appreciated!

Regards,
Pavel

___
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/


___
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] Mock dbix search/count functionality for model testing

[Trevor Leffler]

Hi Frank,

Have you mocked $c-model so that you get your mock, $pin_attempt_mock, 
when you call $c-model('Foo') ?


You can either create a MockObject for $c, or you can locally override 
$c's model method.  I tend to do the former.


--Trevor


Franklin Kumro Jr wrote:

Hello,

I have a model (MyApp/Models/Bar.pm) which retrieves data from the db 
using the generated schema files (in MyApp/Schema/Result/*.pm).


My plan is to mock the classes which are called when retrieving data 
from the database.


BEGIN {
  my $resultset_mock = Test::MockObject-new();
  $resultset_mock-fake_module('DBIx::Class::ResultSet' = ( 'count' 
= sub { 0 } ));


  my $pin_attempt_mock = Test::MockObject-new();
  $pin_attempt_mock-fake_module('MyApp::Schema::Result::Foo' = 
('search' = sub { bless $resultset_mock, 'DBIx::Class::ResultSet' }));

}


BEGIN { use_ok 'MyApp::Model::Bar' }

is (MyApp::Model::Bar-_get_failed_challenges('test', 'test'),
0,
'get failed challenges'
);

MyApp::Model::Bar-_get_failed_challenges contains calls to search and 
count (shown below)


my $result = $c-model('Foo')-search({...});
$result-count();

If I call MyApp::Schema::Result::Foo-search()-count() the mock returns 
0 (and other values that I tested). However when I attempt to use test 
the Bar model the following error is returned.


You must pass a package name and it cannot be blessed at 
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/Class/MOP/Class.pm 
line 41


Also if I follow the stack trace down into the MyApp files, it points to 
the line in MyApp::Model::Bar-_get_failed_challenges which calls search.


Any help would be appreciated!

Thanks,

-- Frank



___
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] General API question: REST + SOAP

[Trevor Leffler]

Peter Edwards wrote:


On 6 April 2011 14:59, Bill Moseley mose...@hank.org 
mailto:mose...@hank.org wrote:


Also, does anyone have a suggestion how to version an API?  That is,
say I have an API method POST /foo to create a new Foo object.
 Would it be better to use something like POST /api/rest/version_2/foo?


Yes I've used the /api/v1/foo  /api/v2/foo approach before and it works 
well and makes it easy to separate out old APIs for regression testing 
when you add new stuff.


 Regards, Peter

Hi, I've also seen the use of HTTP request headers for specifying 
service API minor versions (and other bits).  In particular, EBay comes 
to mind; they use v1, v2 in the end-point plus an 
X-EBAY-SOA-SERVICE-VERSION header.


http://developer.ebay.com/DevZone/finding/Concepts/MakingACall.html#callstruct

--Trevor


___
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] Configuration Management in Continuous Integration environments

[Trevor Leffler]

Not exactly a Catalyst-specific query, however...

Right, certainly loading all the deps onto your CI at the system/global 
level doesn't work when you've multiple projects, branches building that 
have conflicting dependency requirements.


I've seen this problem solved by the toolchain method of committing 
deps along with each project so that the deps move along with the 
software they support.  You could include both the source tarballs and 
the install dir(s) in your commits.  Some purists condemn this, pointing 
to, e.g. DRY, but it can get the job done, which I think is what counts 
at the end of the day.


I've also seen CI systems address this by creating their own entire 
build environments *at build time* -- see the Fedora Project's Koji. 
Again, this allows for multiple projects to build without trampling on 
one another's deps/envs.  One downside is that your builds can take long 
while to complete.


For faster build times, you may find the toolchain approach or even 
having multiple build systems works better for you.


--Trevor

Nicholas Wehr wrote:

Hello everyone,

First off, beware, I'm a bit nutty when it comes to configuration 
management. I've recently deployed a Hudson instance and wanted to move 
some Catalyst projects into it. What I'd like to solicit feedback on 
here is: /how are you managing your Perl dependencies in these build 
systems? /Here's some goals I have:


* do not assume any non-core modules are installed on the build platform
* use specific version of modules in the built product - product is
  a Catalyst website for example (@inc or use lib)
* need to archive specific version of CPAN dependencies offline;
  this means we can recreate a product without an internet connection
* allow for the rebuild of dependencies when the build platform has
  changed; this is meant to address a platform change from 32bit to
  64bit

What I'm looking at is either using local::lib or PREFIX  LIB w/ cpan. 
What do you think?


Thanks in advance,
-nicholas




___
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/


___
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] Remote authN not getting username from remote_user()

[Trevor Leffler]

Hi Tomas,

I've had this new version installed and authN is now working again. 
Looks good to me!  Many thanks for the new build.


Cheers,
--Trevor

Tomas Doran wrote:


On 27 Sep 2010, at 23:33, Trevor Leffler wrote:
So, I've opened bugs under C::E::Apache with patch files that fix this 
issue as well as fix broken tests and minimally bring the code up to 
date with more current C::Runtime standards.


I've just shipped Catalyst-Engine-Apache-1.13_01.tar.gz to CPAN

Thanks a lot for all the patches.

Can you (and anyone else using it - I'm not) please give the new release 
a go to confirm it works? I'll push a non-dev release as soon as you can 
confirm it looks good :)


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] Remote authN not getting username from remote_user()

[Trevor Leffler]

Update:

The issue I'm seeing lies with Catalyst-Engine-Apache, which has not 
seen updates since Feb 2008.  Since that time, Catalyst::Request has 
added remote_user() to its API with the expectation that the various 
engines would use that over the deprecated user() method.  This leads to 
a code path where $c-req-can('remote_user') will eval true, but always 
return 'undef' under the Apache engine, which is exactly what's going on 
with the Remote authN credential module.


So, I've opened bugs under C::E::Apache with patch files that fix this 
issue as well as fix broken tests and minimally bring the code up to 
date with more current C::Runtime standards.


https://rt.cpan.org/Public/Dist/Display.html?Name=Catalyst-Engine-Apache

Cheers,
--Trevor

Trevor Leffler wrote:

Stuart Watt wrote:

  On 9/22/2010 7:40 PM, Trevor Leffler wrote:

Hi, I'm using:

Catalyst::Runtime -- 5.80022
Catalyst::Plugin::Authentication -- 0.10016

I'm finding that C::Request-remote_user is not returning my username 
when I have authenticated under apache, whereas the deprecated 
C::R-user does.


Are you using SSL? Looking at the code, this can affect the 
environment variables used to transmit the remote name.


All the best
Stuart


The behavior is the same for both http and https requests.  That is, 
after a successful [AuthType Basic] authN to a non-SSL page, 
C::R-remote_user returns 'undef' while C::R-user returns 'tleffler'.


Thanks for the response though, I hadn't checked for that variable.

It's a good point about how env vars are accessed... Is Catalyst using 
(in my case, via mod_perl2) Apache2::RequestRec-user to get the 
logged-in username?


--Trevor

___
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/


___
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] Remote authN not getting username from remote_user()

[Trevor Leffler]

Stuart Watt wrote:

  On 9/22/2010 7:40 PM, Trevor Leffler wrote:

Hi, I'm using:

Catalyst::Runtime -- 5.80022
Catalyst::Plugin::Authentication -- 0.10016

I'm finding that C::Request-remote_user is not returning my username 
when I have authenticated under apache, whereas the deprecated 
C::R-user does.


Are you using SSL? Looking at the code, this can affect the environment 
variables used to transmit the remote name.


All the best
Stuart


The behavior is the same for both http and https requests.  That is, 
after a successful [AuthType Basic] authN to a non-SSL page, 
C::R-remote_user returns 'undef' while C::R-user returns 'tleffler'.


Thanks for the response though, I hadn't checked for that variable.

It's a good point about how env vars are accessed... Is Catalyst using 
(in my case, via mod_perl2) Apache2::RequestRec-user to get the 
logged-in username?


--Trevor

___
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] Remote authN not getting username from remote_user()

[Trevor Leffler]

Hi, I'm using:

Catalyst::Runtime -- 5.80022
Catalyst::Plugin::Authentication -- 0.10016

I'm finding that C::Request-remote_user is not returning my username 
when I have authenticated under apache, whereas the deprecated 
C::R-user does.


This means that C::AuthN::Cred::Remote-authenticate fails under option 
2 -- elsif ($c-req-can('remote_user')) {...} -- since yes, it can(), 
but alas 'undef' is the return value.


I'm unclear on how C::Request-remote_user is populated, or maybe I'd 
have figured out what's [not] going on here.


Any pointers, hints, perl packages that may need an upgrade, etc?

Thanks,
--Trevor


FWIW, here are relevant snippets from my App.pm and App::C::Root:

__PACKAGE__-config(
  name = 'App',

  'Plugin::Authentication' = {
default_realm = 'remoterealm',

realms = {
  remoterealm = {
credential = {
  class= 'Remote',
},
store = {class = 'Null',},
  },
},
  },
);


sub begin : Private {
  my ($self, $c) = @_;

  my $r = $c-req;

  # returns yes, 'undef'
  warn *** can remote_user? , ($r-can('remote_user') ? 'yes' : 
'no'), \n;

  my $ru = $r-remote_user;
  warn *** remote_user: [, (defined $ru ? $ru : 'undef'), ]\n;

  # returns yes, 'tleffler'
  warn *** can user? , ($r-can('user') ? 'yes' : 'no'), \n;
  my $u = $r-user;
  warn *** user: [, (defined $u ? $u : 'undef'), ]\n;

  # returns $VAR1 = undef;
  use Data::Dumper;
  warn *** env..., Dumper $c-engine-env;

  unless ($c-user_exists) {
unless ($c-authenticate({})) {
  warn *** failed authN ***\n;   # I get here
  $c-response-status(HTTP::Status::RC_FORBIDDEN());
}
  }
}


___
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] Chained actions with can't terminate with :PathPart('') ?

[Trevor Leffler]

Evan,

Here's an example of chaining that breaks out a lot of your path parts 
into discreet methods.  Watch the server debug output while hitting 
these in your browser to see how each piece is executed.


Notice how middle man methods use :CaptureArgs while endpoints use 
:Args.  Also, each piece of the chain uses :PathPart, rather than :Path, 
and it cannot be omitted.


Your application may not need or want all the controllers, methods, and 
endpoints I set up here, so play around with it.  Read also about how 
auto() and begin() might play a role in your controller hierarchy.


[root controller]
sub auth : Chained('/') : PathPart('auth') : CaptureArgs(0) { }

[company controller]
sub base : Chained('/auth') : PathPart('company') : CaptureArgs(0) { }
sub list : Chained('base') : PathPart('') : Args(0) { }
sub base_view : Chained('base') : PathPart('') : CaptureArgs(1) { }
sub view : Chained('base_view') : PathPart('') : Args(0) { }

[lot controller]
sub base : Chained('/company/base_view') : PathPart('lot') : 
CaptureArgs(0) { }

sub list : Chained('base') : PathPart('') : Args(0) { }
sub view : Chained('base') : PathPart('') : Args(1) { }

This setup generates these chained actions:
/auth/company
/auth/company/123
/auth/company/123/lot
/auth/company/123/lot/987

--Trevor

Evan Carroll wrote:

I have two destinations in my Catalyst app

/auth/company/5/lot
/auth/company/5/lot/5

This works and is often seen in Catalyst apps to achive this effect.
sub lot :Chained('/auth/company') :CaptureArgs(1) {
sub view_lot :Chained('/auth/company') :PathPart('') :Args(1) {

However, I would also expect the below to work; but, it seems it doesn't. I
can only formulate the effect I want the above way. This is
unfortunate because if all chained descendants of `lot` utilize a
check provided here in the chain, then shouldn't `view_lot` also get
to utilize that code? It would certainly be nice to eliminate
redundant code here.
sub lot :Chained('/auth/company') :CaptureArgs(1) {
sub view_lot :Chained('/auth/company/lot') :PathPart('') :Args(0) {

I think it is also confusing to those that first encounter it.

I always know that I could just call it /view, and be done with it, but still.
/auth/company/5/lot/5/view rather than, /auth/company/5/lot/5

But, I just wanted to know what others thought of this.



___
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] Chained actions with can't terminate with :PathPart('') ?

[Trevor Leffler]

Oh, and to be clear about the example controllers, they'd be named:

::Root, ::Company, and ::Company::Lot.

--Trevor

Trevor Leffler wrote:

Evan,

Here's an example of chaining that breaks out a lot of your path parts 
into discreet methods.  Watch the server debug output while hitting 
these in your browser to see how each piece is executed.


Notice how middle man methods use :CaptureArgs while endpoints use 
:Args.  Also, each piece of the chain uses :PathPart, rather than :Path, 
and it cannot be omitted.


Your application may not need or want all the controllers, methods, and 
endpoints I set up here, so play around with it.  Read also about how 
auto() and begin() might play a role in your controller hierarchy.


[root controller]
sub auth : Chained('/') : PathPart('auth') : CaptureArgs(0) { }

[company controller]
sub base : Chained('/auth') : PathPart('company') : CaptureArgs(0) { }
sub list : Chained('base') : PathPart('') : Args(0) { }
sub base_view : Chained('base') : PathPart('') : CaptureArgs(1) { }
sub view : Chained('base_view') : PathPart('') : Args(0) { }

[lot controller]
sub base : Chained('/company/base_view') : PathPart('lot') : 
CaptureArgs(0) { }

sub list : Chained('base') : PathPart('') : Args(0) { }
sub view : Chained('base') : PathPart('') : Args(1) { }

This setup generates these chained actions:
/auth/company
/auth/company/123
/auth/company/123/lot
/auth/company/123/lot/987

--Trevor

Evan Carroll wrote:

I have two destinations in my Catalyst app

/auth/company/5/lot
/auth/company/5/lot/5

This works and is often seen in Catalyst apps to achive this effect.
sub lot :Chained('/auth/company') :CaptureArgs(1) {
sub view_lot :Chained('/auth/company') :PathPart('') :Args(1) {

However, I would also expect the below to work; but, it seems it 
doesn't. I

can only formulate the effect I want the above way. This is
unfortunate because if all chained descendants of `lot` utilize a
check provided here in the chain, then shouldn't `view_lot` also get
to utilize that code? It would certainly be nice to eliminate
redundant code here.
sub lot :Chained('/auth/company') :CaptureArgs(1) {
sub view_lot :Chained('/auth/company/lot') :PathPart('') :Args(0) {

I think it is also confusing to those that first encounter it.

I always know that I could just call it /view, and be done with it, 
but still.

/auth/company/5/lot/5/view rather than, /auth/company/5/lot/5

But, I just wanted to know what others thought of this.



___
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/


___
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/