Re: [Catalyst] Creating a thin Model

[Jamie Neil]

Christopher H. Laco wrote:

Personally, I almost always do:

sub COMPONENT {
   my $self = NEXT::new

 diddle config...return $self
}



Sorry...that pseudo code was too vague:


sub COMPONENT {
  my $self = shift->NEW::new(@_);
  $self->{'noncatclass'} = NonCatClass->new
  return $self
}

Then, delegate via autoload, or use real methods to forward request to
the instance of the real class...


I assume you mean:

my $self = shift->NEXT::new(@_);

in which case it fails with:

Can't call NEXT::new from MyApp::Model::Widget::COMPONENT

I noticed that a number of newer models on CPAN were using this 
construction:


use base qw/ Catalyst::Model /;

sub new {
my $self  = shift->next::method(@_);
my $class = ref($self);
my ( $c, $args ) = @_;
$self->{'.mymodel'} = ExternalModule->new(
Catalyst::Utils::merge_hashes( $args, $self->config )
);
return $self;
}

sub ACCEPT_CONTEXT {
return shift->{'.mymodel'};
}

or is this only recommended if you need to make the context available in 
the external module?


--
Jamie Neil | <[EMAIL PROTECTED]> | 0870  454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Creating a thin Model

[Matt S Trout]

On Mon, May 21, 2007 at 11:06:44AM +0100, Jamie Neil wrote:
> Christopher H. Laco wrote:
> >>Personally, I almost always do:
> >>
> >>sub COMPONENT {
> >>   my $self = NEXT::new
> >>
> >> diddle config...return $self
> >>}
> >>
> >
> >Sorry...that pseudo code was too vague:
> >
> >
> >sub COMPONENT {
> >  my $self = shift->NEW::new(@_);
> >  $self->{'noncatclass'} = NonCatClass->new
> >  return $self
> >}
> >
> >Then, delegate via autoload, or use real methods to forward request to
> >the instance of the real class...
> 
> I assume you mean:
> 
> my $self = shift->NEXT::new(@_);
> 
> in which case it fails with:

That should be in 'sub new', and next::method would be better.

Or you could just return the intance of your external class - there's no
requirement for the return of MyApp::Model::Foo->new to be a MyApp::Model::Foo
object and $c->model('Foo') will happily return your OtherClass::Blah object.

> I noticed that a number of newer models on CPAN were using this 
> construction:
> 
> use base qw/ Catalyst::Model /;
> 
> sub new {
> my $self  = shift->next::method(@_);
> my $class = ref($self);
> my ( $c, $args ) = @_;
> $self->{'.mymodel'} = ExternalModule->new(
> Catalyst::Utils::merge_hashes( $args, $self->config )
> );
> return $self;
> }
> 
> sub ACCEPT_CONTEXT {
> return shift->{'.mymodel'};
> }
> 
> or is this only recommended if you need to make the context available in 
> the external module?

No, that's just plain silly. Could I have a list of the models that do that
so I can track down the authors and slap them, please?

sub new {
  my ($class, $c, $args) = @_;
  return ExternalModule->new(
Catalyst::Utils::merge_hashes( $args, $class->config )
  );
}

would be quite sufficient.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Creating a thin Model

[Jamie Neil]

Matt S Trout wrote:

use base qw/ Catalyst::Model /;

sub new {
my $self  = shift->next::method(@_);
my $class = ref($self);
my ( $c, $args ) = @_;
$self->{'.mymodel'} = ExternalModule->new(
Catalyst::Utils::merge_hashes( $args, $self->config )
);
return $self;
}

sub ACCEPT_CONTEXT {
return shift->{'.mymodel'};
}

or is this only recommended if you need to make the context available in 
the external module?


No, that's just plain silly. Could I have a list of the models that do that
so I can track down the authors and slap them, please?


http://search.cpan.org/search?query=catalyst%3A%3Amodel+accept_context

brings up most of them, but there are a few more like Net::Amazon.


sub new {
  my ($class, $c, $args) = @_;
  return ExternalModule->new(
Catalyst::Utils::merge_hashes( $args, $class->config )
  );
}


Thanks, I'll give that a try.

--
Jamie Neil | <[EMAIL PROTECTED]> | 0870  454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Creating a thin Model

[Matt S Trout]

On Mon, May 21, 2007 at 12:31:22PM +0100, Jamie Neil wrote:
> http://search.cpan.org/search?query=catalyst%3A%3Amodel+accept_context
> 
> brings up most of them, but there are a few more like Net::Amazon.

Looks like they were all cargo-culted from J Shirley's YouTube model. o
I shall be explaining the appropriate techniques to him and then he can
chases everybody else down and get them to change theirs :)
 
> >sub new {
> >  my ($class, $c, $args) = @_;
> >  return ExternalModule->new(
> >Catalyst::Utils::merge_hashes( $args, $class->config )
> >  );
> >}
> 
> Thanks, I'll give that a try.

If you get stuck, could you start a fresh thread, please? I think this one
has officially got confused now :)

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Session unexpectedly expiring

[Jeff Chimene]

Jeff Chimene wrote:
> Hi,
>
> I'm trying to figure out why my sessions are expiring in
> script/xxx_cgi.pl but not script/xxx_server.pl
> The desired cycle is to login then redirect to another controller.
>
> When I run the standalone server, the session state is recovered, and
> control resumes with the next controller.
>
> When I run using Apache & the script/xxx_cgi.pl, the session state is
> marked expired and control returns to the login controller.
>
> I'm using the Session, Session::Store::FastMmap, Session::State::Cookie
> plugins.
>
> Thanks for your support!
>
> Cheers,
> jec
This has something to do w/ the implementation of the "auto" method in
Root.pm

There's some "extra" stuff I added to support returning to the requested
URI after
login. Nevertheless, it works from script/aic_server.pl, but not from
Apache.

Anyway, I disabled the routine and received goodness from Apache.

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

if ($c->controller eq $c->controller('Login')) {
  return 1;
}

# If a user doesn't exist, force login
$c->session->{after_login} = '';
if (!$c->user_exists) {
  $c->log->debug('***Root::auto User not found, forwarding to
/login') if $c->debug;

  # make sure we return here after a successful login
  $c->session->{after_login} = $c->request->uri() unless
($c->request->uri() eq $c->request->base());
  $c->detach('aic::Controller::Login', 'index');
}

# User found, so return 1 to continue with processing after this 'auto'
return 1;
  }


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Session unexpectedly expiring

[Wade . Stuart]

Jeff Chimene <[EMAIL PROTECTED]> wrote on 05/20/2007 10:13:33 PM:

> Thomas L. Shinnick wrote:
> > At 08:20 PM 5/20/2007, Jeff Chimene wrote:
> >> Hi,
> >> I'm trying to figure out why my sessions are expiring in
> >> script/xxx_cgi.pl but not script/xxx_server.pl
> > [snip]
> >> I'm using the Session, Session::Store::FastMmap,
> >> Session::State::Cookie plugins.
> >
> > I've not used it, I'm guessing, and I'm an idiot, but isn't this
> > likely permissions problems, between running standalone vs. running
> > under Apache?  Any chance the backing storage file is not available to
> > Apache processes?  Peeking at the docs:
> > storage
> >  Specifies the file to be used for the sharing of session
> > data. ...
> > Note that the file will be created with mode 0640, which means
> > that
> >  it will only be writeable by processes running with the same
> > uid as
> >  the process that creates the file.  
> >
> > Try deleting the backing file before re-running under Apache?
> Good catch. Apache (or script/aic_server.pl) refuses to honor a request
> if the working storage file created by the other HTTP server exists. I
> couldn't even get started w/o a preliminary "sudo rm -r /tmp/aic" So,
> although that's /a/ problem, it's not /the/ problem.

Without more info (you will post the info Matt asked for?)  this still
seems like the best candidate for the issue.  If you are running on Linux
and have selinux turned on, another common issue is that your policy does
not allow promiscuous writes from apache.  You may verify this is or is not
the issue by running audit2why < /var/log/audit/audit.log (or wherever your
se auditlog is located) and noting any blocks that are happening via your
web server process.

Also you may want to force the directory for the session stuffs to a sane
location ( don't know if you are or not -- you will post the info that Matt
asked for?).

-Wade


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Form validation in insert() and update()?

[Dave Rolsky]

On Mon, 21 May 2007, A. Pagaltzis wrote:


So if the blank form is `/order/form`, you’d stash the form data
away somewhere under ID `7z32a` (f.ex) and redirect them to
`/order/form/7z32a` (or `/order/form?populate=7z32a`). The data
could be in the session, as long as it’s keyed off of an ID that
shows up in the URI and the ID is unique across all
users/sessions. Stick the ID in a hidden field in the form so you
can garbage the data immediately if the submit goes through.
(Else you’ll have to expire the data after a while.)

This way, you don’t have a page whose content changes based on
implicit state on the server that isn’t contained in the client’s
request – the REST way.


I do like this, in theory. It's basically equivalent to puttint the 
session key in the URI, though, which means it has some security issues.


If I were to do this, I'd probably associate each mini-session (for a form 
or whatnot) with the user_id, and I'd still be checking the user_id 
against the cookie.


I think that would be sufficiently secure.

I know that user cookies are not considered RESTful, but this is one 
problem I have not been able to work around. If web browsers could be made 
to handle HTTP auth with more flexibility (use forms, allow logout, etc) 
then I think this solution could 100% RESTful.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Announcing the first Catalyst SwagReward!

[Jonathan T. Rockway]

On Sun, May 20, 2007 at 06:14:35PM +0200, A. Pagaltzis wrote:
> * Mike Whitaker <[EMAIL PROTECTED]> [2007-05-20 16:50]:
> > >If all goes well it will probably be fully programmatic but will
> > >almost certainly involve Python.
> > 
> > Ooo. Dunno about that. :)
> > 
> > Can't help feeling that it's not really within the spirit of a
> > Catalyst-related prize to use Python - after all, the obvious
> > home for such a script in the end is in the MojoMojo source
> > tree, surely.
> 

BTW, I'm working on this.

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Session unexpectedly expiring

[James R. Leu]

Not really related to your issue specifically, but I have seen
issues with using Session::Store::FastMmap and perl ithreads resulting
in unrelated sessions appearing to terminate when a thread 'joins'
back to the parent.  I think is has something to do with ithreads
interaction with shared memory.  My fix was to not use shared memory :-)

On Mon, May 21, 2007 at 08:52:16AM -0700, Jeff Chimene wrote:
> Jeff Chimene wrote:
> > Hi,
> >
> > I'm trying to figure out why my sessions are expiring in
> > script/xxx_cgi.pl but not script/xxx_server.pl
> > The desired cycle is to login then redirect to another controller.
> >
> > When I run the standalone server, the session state is recovered, and
> > control resumes with the next controller.
> >
> > When I run using Apache & the script/xxx_cgi.pl, the session state is
> > marked expired and control returns to the login controller.
> >
> > I'm using the Session, Session::Store::FastMmap, Session::State::Cookie
> > plugins.
> >
> > Thanks for your support!
> >
> > Cheers,
> > jec
> This has something to do w/ the implementation of the "auto" method in
> Root.pm
> 
> There's some "extra" stuff I added to support returning to the requested
> URI after
> login. Nevertheless, it works from script/aic_server.pl, but not from
> Apache.
> 
> Anyway, I disabled the routine and received goodness from Apache.
> 
> sub auto : Private
>   {
> my ($self, $c) = @_;
> 
> if ($c->controller eq $c->controller('Login')) {
>   return 1;
> }
> 
> # If a user doesn't exist, force login
> $c->session->{after_login} = '';
> if (!$c->user_exists) {
>   $c->log->debug('***Root::auto User not found, forwarding to
> /login') if $c->debug;
> 
>   # make sure we return here after a successful login
>   $c->session->{after_login} = $c->request->uri() unless
> ($c->request->uri() eq $c->request->base());
>   $c->detach('aic::Controller::Login', 'index');
> }
> 
> # User found, so return 1 to continue with processing after this 'auto'
> return 1;
>   }
> 
> 
> ___
> List: Catalyst@lists.rawmode.org
> Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/

-- 
James R. Leu
[EMAIL PROTECTED]


pgptV89UZLfiG.pgp
Description: PGP signature
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Session unexpectedly expiring

[Jeff Chimene]

[EMAIL PROTECTED] wrote:
>
>
> Jeff Chimene <[EMAIL PROTECTED]> wrote on 05/20/2007 10:13:33 PM:
>
>   
>> Thomas L. Shinnick wrote:
>> 
>>> At 08:20 PM 5/20/2007, Jeff Chimene wrote:
>>>   
 Hi,
 I'm trying to figure out why my sessions are expiring in
 script/xxx_cgi.pl but not script/xxx_server.pl
 
>>> [snip]
>>>   
 I'm using the Session, Session::Store::FastMmap,
 Session::State::Cookie plugins.
 
>>> I've not used it, I'm guessing, and I'm an idiot, but isn't this
>>> likely permissions problems, between running standalone vs. running
>>> under Apache?  Any chance the backing storage file is not available to
>>> Apache processes?  Peeking at the docs:
>>> storage
>>>  Specifies the file to be used for the sharing of session
>>> data. ...
>>> Note that the file will be created with mode 0640, which means
>>> that
>>>  it will only be writeable by processes running with the same
>>> uid as
>>>  the process that creates the file.  
>>>
>>> Try deleting the backing file before re-running under Apache?
>>>   
>> Good catch. Apache (or script/aic_server.pl) refuses to honor a request
>> if the working storage file created by the other HTTP server exists. I
>> couldn't even get started w/o a preliminary "sudo rm -r /tmp/aic" So,
>> although that's /a/ problem, it's not /the/ problem.
>> 
>
> Without more info (you will post the info Matt asked for?)  
Posted yesterday:
http://www.mail-archive.com/catalyst@lists.rawmode.org/msg05448.html
> this still seems like the best candidate for the issue.  
Ibid. This isn't the problem
> If you are running on Linux
> and have selinux turned on, another common issue is that your policy does
> not allow promiscuous writes from apache.  
Debian Etch
> You may verify this is or is not
> the issue by running audit2why < /var/log/audit/audit.log (or wherever your
> se auditlog is located) and noting any blocks that are happening via yourweb 
> server process.
>   
> Also you may want to force the directory for the session stuffs to a sane
> location ( don't know if you are or not -- you will post the info that Matt
> asked for?).
>   
Ibid.

I've posted this A.M. w/r/t disabling auto() in Root.pm:
http://www.mail-archive.com/catalyst@lists.rawmode.org/msg05457.html

Cheers,.
jec

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Session unexpectedly expiring

[Jeff Chimene]

James R. Leu wrote:
> Not really related to your issue specifically, but I have seen
> issues with using Session::Store::FastMmap and perl ithreads resulting
> in unrelated sessions appearing to terminate when a thread 'joins'
> back to the parent.  I think is has something to do with ithreads
> interaction with shared memory.  My fix was to not use shared memory :-)
>   
OK, but this is a development machine, and I'm the only user. AFAIK, I'm
not using ithreads. As I mentioned, disabling the auto() method in
Root.pm seems to have solved the issue:
http://www.mail-archive.com/catalyst@lists.rawmode.org/msg05457.html

Cheers,
jec
> On Mon, May 21, 2007 at 08:52:16AM -0700, Jeff Chimene wrote:
>   
>> Jeff Chimene wrote:
>> 
>>> Hi,
>>>
>>> I'm trying to figure out why my sessions are expiring in
>>> script/xxx_cgi.pl but not script/xxx_server.pl
>>> The desired cycle is to login then redirect to another controller.
>>>
>>> When I run the standalone server, the session state is recovered, and
>>> control resumes with the next controller.
>>>
>>> When I run using Apache & the script/xxx_cgi.pl, the session state is
>>> marked expired and control returns to the login controller.
>>>
>>> I'm using the Session, Session::Store::FastMmap, Session::State::Cookie
>>> plugins.
>>>
>>> Thanks for your support!
>>>
>>> Cheers,
>>> jec
>>>   
>> This has something to do w/ the implementation of the "auto" method in
>> Root.pm
>>
>> There's some "extra" stuff I added to support returning to the requested
>> URI after
>> login. Nevertheless, it works from script/aic_server.pl, but not from
>> Apache.
>>
>> Anyway, I disabled the routine and received goodness from Apache.
>>
>> sub auto : Private
>>   {
>> my ($self, $c) = @_;
>>
>> if ($c->controller eq $c->controller('Login')) {
>>   return 1;
>> }
>>
>> # If a user doesn't exist, force login
>> $c->session->{after_login} = '';
>> if (!$c->user_exists) {
>>   $c->log->debug('***Root::auto User not found, forwarding to
>> /login') if $c->debug;
>>
>>   # make sure we return here after a successful login
>>   $c->session->{after_login} = $c->request->uri() unless
>> ($c->request->uri() eq $c->request->base());
>>   $c->detach('aic::Controller::Login', 'index');
>> }
>>
>> # User found, so return 1 to continue with processing after this 'auto'
>> return 1;
>>   }


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Setting time zone and locale on dates.

[Bill Moseley]

This likely falls into one of the many "how do I get $c into the
model" threads.

My session has the locale and timezone fetched from the user's
preferences at login.  It's not really locale, but a language tag
which is also used by Locale::Maketext, but should work for DateTime's
locale setting.

I use timestamp with time zone on my Postgresql timestamps and the
model inflates to DataTime objects.  Most if not all dates should be
localized for the user.

I'm tempted to use model class data to pass this to the model.  So at
the start of every request do something like:

My::Model->current_timezone( $c->session->{timezone} );
My::Model->current_locale( $c->session->{locale} );

And then have the model use those (if set) when inflating.

Any better ideas for dealing with this?

I ask because (besides not having that much I18N experience) I
think this is something that really belongs in the view.

[% c.local_date( user.last_updated_time ) | html %]

But, setting the locale and time_zone in the inflator would be handy
since it's all one place instead of every time I use a date in the
view.

What do you do?


-- 
Bill Moseley
[EMAIL PROTECTED]


___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Bernhard Graf]

Matt S Trout wrote:

> On Sun, May 20, 2007 at 08:55:47PM +0200, Bernhard Graf wrote:
> > No need for redirects and all the problems they impose.
>
> I described the problems with -not- redirecting and yet you assert
> their being bad without justification.

See my other response.
You can stay with redirects. No problem for me. ;^)
I just pointed out that you don't need them.

> I call straw man. Defend your position or withdraw, sir.

Hä??
-- 
Bernhard Graf

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Bernhard Graf]

Roland Lammel wrote:

> But then again this code has to be added to every method, that is
> processing form input. In case it's not there... the nightmare of
> reposting is back in town.

What are you trying to demonstrate?
"If more code isn't there, even more nightmares are in town" - or what?

> I find it far more easy to actually perform a redirect at the end of
> an action, that is intentional for the user and the developer.
> I havn't come across any problems using redirects (not even on mobile
> devices), so what kind of problems are you referring too?

- Loosing state within one http request or maintaining additional
  overhead to keep it beyond the redirect
- imposing additional load to the server
- trouble GET after POST under mod_perl as described in
  http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests 
.
  Well, actually I suspect Catalyst already does the right thing, but I
  was bitten by this issue long ago in the pre-Google era when you could
  hardly find anything about this on the WWW.

> But as usual, it's probably a matter of taste anyway.

Indeed. Whenever I have to fix somebody else's web application (usually
PHP), the number of HTTP redirects is inversely proportional to the
quality of the code. So probably that is the main reason why I try to
avoid them personally.
-- 
Bernhard Graf

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Bernhard Graf]

A. Pagaltzis wrote:

> * Bernhard Graf <[EMAIL PROTECTED]> [2007-05-20 21:05]:
> > A. Pagaltzis wrote:
> > > That, plus the re-submit when the user hits the Back button.
> >
> >   ...
> >   unless ($c->validate_token) { # Catalyst::Plugin::RequestToken
> > $c->stash(message => 'Deja vu!'); # optional verbosity
> > $c->detach('view');
> >   }
>
> So loading an extra plugin and sprinkling guards all over your
> code is preferrable to you over simply issuing a redirect. Not

Yes.

> only that, but your choice causes the following sequence of
> events:
>
> User: *hits Back button*
> Computer: This page has POSTDATA. Resubmit it?
> User: (thinks) What the?! Hmm… err…
> User: *hits OK*
> Computer: Ack! You tried to resubmit a form! No cookie!
> User: @#$&!!
>
> Compare to the alternative, where successful submit produces a
> redirect:
>
> User: *hits Back button*
> Computer: *goes back a page*
>
> Guess which one will annoy users less.

Written very nicely. Actually both variants are designed to keep posting 
data twice, right?

> You said absolutely nothing to address the “wrong URL” problem
> Matt mentioned, btw.

What wrong URL?
My example showed that http://example.com/data/update is virtually equal 
to http://example.com/data/view if not posted from a form.

> Of course, you can spend your days writing code to fight the way
> HTTP works. It’s up to you to judge whether that is a worthwhile
> use of your time. But I do think you’d be happier and your code
> simpler and more robust if it didn’t try to cut against the web’s
> grain.

I don't fight HTTP. A link is one thing, an action is a different one.
While the first always is a static route to some other place, the latter
*acts* upon (input) data and the resulting output depends on this input 
data and potentially other data as well (like this RequestToken status, 
that tells that the transaction has already been processed when trying 
to redo the action, or the request method not being POST). 

> > No need for redirects and all the problems they impose.
>
> Can you explain one the problems, please?

See my other post.

> Redirects are one of the greatest features of HTTP, actually.

As GOTO is one of the greatest features of Basic - and of course Perl.
-- 
Bernhard Graf

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Setting time zone and locale on dates.

[Chisel Wright]

On Mon, May 21, 2007 at 01:54:54PM -0700, Bill Moseley wrote:
> What do you do?

I inflate all my dates to DateTime objects:

  foreach my $datecol (qw/created/) {
__PACKAGE__->inflate_column($datecol, {
  inflate => sub { DateTime::Format::Pg->parse_datetime(shift); },
  deflate => sub { DateTime::Format::Pg->format_datetime(shift); },
});
  }

Then to display dates, I pass them through my somewhat scruffy looking
nicedate() TT macro:

http://svn.berlios.de/svnroot/repos/parley/trunk/root/base/shared/useful_tt_stuff

There might be nicer ways, but the overall method seems to be working
really well for me so far.

I'm not sure if/how locale would tie into this though.

Chisel
-- 
Chisel Wright
e: [EMAIL PROTECTED]
w: http://www.herlpacker.co.uk/

  SELECT message FROM signatures ORDER BY RANDOM() LIMIT 1;

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

RE: [Catalyst] Apache mod_proxy, SSL and uri_for

[Dylan Vanderhoof]

> -Original Message-
> From: Andy Grundman [mailto:[EMAIL PROTECTED] 
> 
> On May 17, 2007, at 6:56 PM, Dylan Vanderhoof wrote:
> 
> > I'm having a little issue with SSL and uri_for.
> >
> > mox_proxy is sending the X-Forwarded-For: headers 
> correctly, but they
> > don't appear to have any information as to whether or not 
> the request
> > was http or https.  From what I can tell, this is normal behavior.
> > However, that means that if I'm just using http on the 
> connection from
> > the proxy to the backend server, uri_for is incorrect, 
> which causes  
> > all
> > sorts of mixed-mode warnings to pop up on any subsequent requests.
> >
> > using_frontend_proxy is set to 1 in my config, but it doesn't  
> > appear to
> > address this particular issue.
> >
> > Anybody have any suggestions for how I might fix this?  For now, I'm
> > just running SSL to the backend server, but I'd really rather not  
> > waste
> > the resources.
> 
> One way to solve this is to proxy SSL requests to a different 
> port on  
> the backend, and set the environment variable HTTPS to 'ON' for that  
> port's virtualhost on the backend.  Then Catalyst will know it's in  
> SSL mode and generate the right links.
> 

Works perfectly.  Thanks.

-Dylan

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Persistent login

[Kieren Diment]

On 17/05/07, Michael Reece <[EMAIL PROTECTED]> wrote:

there's no especially sane way to extend the session cookie on a per-
user basis that i have found.


here is a hack that i am experimenting with:

if ($c->login($username, $password)) {
 $c->session->{remember_me} = $c->req->params->{remember_me};
 # ...
}

and in package MyApp.pm (or a plugin or a subclass of the
State::Cookie plugin or ...)

sub calculate_session_cookie_expires {
 my $c = shift;
 return $c->session->{remember_me}
 ? time() + 60 * 60 * 24 * 90   # 90 days
 : $c->NEXT::calculate_session_cookie_expires(@_);
}


On May 15, 2007, at 6:47 PM, Evaldas Imbrasas wrote:

> On 5/15/07, Jonathan Rockway <[EMAIL PROTECTED]> wrote:
>> Use the session plugin and set the session expiration to ... 1
>> week.  If some
>> data needs to expire sooner than that ... expire it sooner than that.
>>
>> Here's what I would do.  Create a session and log the user in.
>> Store a "last
>> login" time in the user_class.  If the last_login (or last_activity;
>> whatever) is too long ago, delete data from the session and start
>> over.
>
> Yep, makes sense. However, even in that case, I was hoping that the
> standard session/auth plugins would support this functionality without
> doing anything additional in my Controller::Auth, i.e.:
>
> if ($c->req->params->{login_remember}) {
>  $c->login($email, $password, $expires_long);
> } else {
>  $c->login($email, $password, $expires_short);
> }
>
> Am I wrong in thinking that pretty much any decent login system has to
> support this anyway?.. (This is my first Catalyst project, so I
> wouldn't be surprised if there's a one-liner out there that would
> solve this problem without a need for the above - sorry if that's the
> case.)


In WIAB::Controller::User:

sub auto : Private {
   my ($self, $c) = @_;
   $c->stash->{template} = 'login.tt';
   if(!$c->login()) {
   $c->stash->{message} = 'Please login.';
   }
   else {
   if ($c->req->param('public') ) {
   $c->session_expire_key( __user => 600 );
   }
   $c->res->redirect($c->uri_for('/'));
   }

}



http://websiteinabox.googlecode.com/svn/trunk/WIAB/lib/WIAB/Controller/User.pm

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Matt S Trout]

On Mon, May 21, 2007 at 11:31:38PM +0200, Bernhard Graf wrote:
> Matt S Trout wrote:
> 
> > On Sun, May 20, 2007 at 08:55:47PM +0200, Bernhard Graf wrote:
> > > No need for redirects and all the problems they impose.
> >
> > I described the problems with -not- redirecting and yet you assert
> > their being bad without justification.
> 
> See my other response.
> You can stay with redirects. No problem for me. ;^)
> I just pointed out that you don't need them.

Then from now on when somebody posts a redirect solution to a design problem
you have you'll implement it rather than insulting them, right?

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Matt S Trout]

On Mon, May 21, 2007 at 11:50:00PM +0200, Bernhard Graf wrote:
> Yes.

No justification, again.

So clearly you have no argument.

Don't waste this list's time with baseless assertions again. You want those,
go join the VB team at Microsoft.

> What wrong URL?

The wrong I mentioned and you ignored. Please read the thread again.

And pay attention this time.

> My example showed that http://example.com/data/update is virtually equal 
> to http://example.com/data/view if not posted from a form.

Wrong. See last paragraph for correction requirements.
 
> > Can you explain one the problems, please?
> 
> See my other post.

Which explained nothing. Try again.

At this point several people have asked you several times for reasoned
responses.

You've replied every time with un-justified assertions.

Even if I thought you were wrong I'd be willing to argue with a justification,
but you haven't even bothered trying.

Engage in the technical debate or be removed from this list just as quickly as
a $religion extremist who refused to justify -their- position would be.

This is your final warning.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Setting time zone and locale on dates.

[Matt S Trout]

On Mon, May 21, 2007 at 10:58:34PM +0100, Chisel Wright wrote:
> On Mon, May 21, 2007 at 01:54:54PM -0700, Bill Moseley wrote:
> > What do you do?
> 
> I inflate all my dates to DateTime objects:
> 
>   foreach my $datecol (qw/created/) {
> __PACKAGE__->inflate_column($datecol, {
>   inflate => sub { DateTime::Format::Pg->parse_datetime(shift); },
>   deflate => sub { DateTime::Format::Pg->format_datetime(shift); },
> });
>   }

DBIx::Class::InflateColumn::DateTime will do this part for you these days.

-- 
  Matt S Trout   Need help with your Catalyst or DBIx::Class project?
   Technical DirectorWant a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/ http://www.shadowcatsystems.co.uk/ 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Catalyst with apache, how to auto restart like run myapp_server.pl -r?

[Cookie]

I configurate my apache httpd.conf like this:

LoadModule perl_module modules/mod_perl.so
PerlSwitches -I/var/www/html/lj/catalyst/lib
PerlModule Add

   SetHandler  modperl
   PerlResponseHandler Add

And I can visit my site using:
http://localhost/catalyst

But I don't think when I modify my lib files,the modification seems not any
effect.And I must restart my apache to make it available.
My question is:
Is there any way to configurate my apache configuration files to be
available that I don't need to restart my apache server?(Like I run
myapp_server.pl -r)

My Second question is:
When I visit my web site,the link in http://loalhost/catalyst becomes
http://localhost/item,but the real link is http://localhost/catalyst/item.
How can I solve this bug?
My template like this:
[% item %]
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with apache, how to auto restart like run myapp_server.pl -r?

[Peter Karman]

Cookie scribbled on 5/21/07 8:21 PM:


Is there any way to configurate my apache configuration files to be
available that I don't need to restart my apache server?(Like I run
myapp_server.pl -r)



no.

all the -r option does for the dev server is automatically poll for file changes 
and restart the app. It's not a config option; it's a feature of the server. 
Apache has no such feature.



My Second question is:
When I visit my web site,the link in http://loalhost/catalyst becomes
http://localhost/item,but the real link is http://localhost/catalyst/item.
How can I solve this bug?
My template like this:
[% item %]


[% item %]

That second is a FAQ. Make sure you read the Catalyst advent calendars at:

http://www.catalystframework.org/calendar/2005/
http://www.catalystframework.org/calendar/2006/


--
Peter Karman  .  http://peknet.com/  .  [EMAIL PROTECTED]

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Redispatching actions

[A. Pagaltzis]

* Bernhard Graf <[EMAIL PROTECTED]> [2007-05-21 23:40]:
> Roland Lammel wrote:
> > I find it far more easy to actually perform a redirect at the
> > end of an action, that is intentional for the user and the
> > developer. I havn't come across any problems using redirects
> > (not even on mobile devices), so what kind of problems are
> > you referring too?
> 
> - Loosing state within one http request or maintaining
>   additional overhead to keep it beyond the redirect

Where’s the fundamental difference in effort between maintaining
a request token and maintaing explicitly addressable state?

> - imposing additional load to the server

Premature optimisation. If you use redirects wisely and expose
state in URIs, you can make many more things usefully cachable.
The best optimisation is not to run any code in the first place,
and if more things are cachable, more requests will be served
from caches.

> - trouble GET after POST under mod_perl as described in
>   
> http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests
>   Well, actually I suspect Catalyst already does the right
>   thing, but I was bitten by this issue long ago in the
>   pre-Google era when you could hardly find anything about this
>   on the WWW.

Right. “This is how it has always been done around here, and
we’re not going to change that now.”

> Whenever I have to fix somebody else's web application (usually
> PHP), the number of HTTP redirects is inversely proportional to
> the quality of the code. So probably that is the main reason
> why I try to avoid them personally.

Yes, redirects can be used as crutches to paper over a bad
design. Then again, request tokens can be used as crutches to
paper over a bad design.


* Bernhard Graf <[EMAIL PROTECTED]> [2007-05-22 00:00]:
> A. Pagaltzis wrote:
> > Not only that, but your choice causes the following sequence
> > of events:
> >
> > User: *hits Back button*
> > Computer: This page has POSTDATA. Resubmit it?
> > User: (thinks) What the?! Hmm… err…
> > User: *hits OK*
> > Computer: Ack! You tried to resubmit a form! No cookie!
> > User: @#$&!!
> >
> > Compare to the alternative, where successful submit produces
> > a redirect:
> >
> > User: *hits Back button*
> > Computer: *goes back a page*
> >
> > Guess which one will annoy users less.
> 
> Written very nicely. Actually both variants are designed to
> keep posting data twice, right?

Sure. And one of them requires extra code complexity and
significantly degrades usability, the other works smoothly
with no extra server-side logic.

> > You said absolutely nothing to address the “wrong URL”
> > problem Matt mentioned, btw.
> 
> What wrong URL? My example showed that
> http://example.com/data/update is virtually equal to
> http://example.com/data/view if not posted from a form.

Of course they are virtually equal – after all they are equally
terrible. If you lay out your URI space in that manner, it’s no
wonder that you can’t understand why redirects are good.

> > Of course, you can spend your days writing code to fight the
> > way HTTP works. It’s up to you to judge whether that is a
> > worthwhile use of your time. But I do think you’d be happier
> > and your code simpler and more robust if it didn’t try to cut
> > against the web’s grain.
> 
> I don't fight HTTP. A link is one thing, an action is a
> different one. While the first always is a static route to some
> other place, the latter *acts* upon (input) data and the
> resulting output depends on this input data and potentially
> other data as well (like this RequestToken status, that tells
> that the transaction has already been processed when trying to
> redo the action, or the request method not being POST). 

Right. First you say you don’t fight HTTP, then you immediately
launch into an explanation of how you put verbs in your URIs.
Something is wrong with this picture.

> > Redirects are one of the greatest features of HTTP, actually.
> 
> As GOTO is one of the greatest features of Basic - and of
> course Perl.

… come again? What do GOTOs have to do with anything?


Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Redispatching actions

[A. Pagaltzis]

* Matt S Trout <[EMAIL PROTECTED]> [2007-05-22 03:00]:
> Engage in the technical debate or be removed from this list
> just as quickly as a $religion extremist who refused to justify
> -their- position would be.
> 
> This is your final warning.

Matt, I don’t know that he’s refusing to debate; his assertions
might seem self-evident to him. But you have practically shut
down the thread now, and I’d’ve liked to see what he was going to
answer to my latest post.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst without template

[Dave Gray]

Hi Dmitri,

On 5/17/07, Dmitri Pissarenko <[EMAIL PROTECTED]> wrote:

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

my $name = $c->request->params->{name};

$c->res->write("Hello " . $name . ", welcome to the world of Dojo!\n");
}


This is basically the definition of an XSS vulnerability, I hope this
isn't production code!

Dave

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Mapping urls inside catalyst

[Dave Gray]

Hi Robert,

On 5/19/07, Robert 'phaylon' Sedlacek <[EMAIL PROTECTED]> wrote:

Mark Zealey wrote:
> I thus want the following to be equivalent:
>
> mysite.com/foo/5/fred/list
> mysite.com/bar/myname/fred/list
> othersite.com/fred/list

[snip]

This is all untested of course. But you should get the chains

  /foo/*/*/list - Foo::base, Foo::load, Fred::load_fred, Fred::list_fred
  /bar/*/*/list - Bar::base, Bar::load, Fred::load_fred, Fred::list_fred
  /*/*/list - ViaHost::base, ViaHost::load, Fred::load_fred,
  Fred::list_fred


What do you gain by doing it this way instead of using mod_rewrite or
similar? Obviously mod_rewrite isn't as flexible in that you need to
update your ruleset separately instead of only changing your
application level code, but that seems like an acceptable tradeoff to
me.

Dave

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] Re: Form validation in insert() and update()?

[A. Pagaltzis]

* Dave Rolsky <[EMAIL PROTECTED]> [2007-05-21 18:30]:
> On Mon, 21 May 2007, A. Pagaltzis wrote:
> >So if the blank form is `/order/form`, you’d stash the form
> >data away somewhere under ID `7z32a` (f.ex) and redirect them
> >to `/order/form/7z32a` (or `/order/form?populate=7z32a`). The
> >data could be in the session, as long as it’s keyed off of an
> >ID that shows up in the URI and the ID is unique across all
> >users/sessions. Stick the ID in a hidden field in the form so
> >you can garbage the data immediately if the submit goes
> >through. (Else you’ll have to expire the data after a while.)
> >
> >This way, you don’t have a page whose content changes based on
> >implicit state on the server that isn’t contained in the
> >client’s request – the REST way.
> 
> I do like this, in theory. It's basically equivalent to puttint
> the session key in the URI, though, which means it has some
> security issues.
> 
> If I were to do this, I'd probably associate each mini-session
> (for a form or whatnot) with the user_id, and I'd still be
> checking the user_id against the cookie.
> 
> I think that would be sufficiently secure.

Yeah, you would have to make sure that whoever is requesting the
prepopulated form is permitted to do so. But that’s easy – as I
said, just continue to put the data in the session as you would
have, just make sure to add a layer of indirection through a
hash. Eg.

# previously
$c->session->{foo_form} = { name => $name, email => $email };

# better:
my $form_state_id = get_appwide_unique_id();
$c->session->{foo_form}->{$form_state_id}
= { name => $name, email => $email };

Then when the user asks for `/oder/form/7z32a`, you check if
there’s a `$c->session->{foo_form}->{7z32a}` key. If not, spit
out a 404.

That’s it – it’s no harder than what you already do. All you need
is to calculate an ID and to add the routing for `.../form/{id}`
URIs.

> I know that user cookies are not considered RESTful, but this
> is one problem I have not been able to work around. If web
> browsers could be made to handle HTTP auth with more
> flexibility (use forms, allow logout, etc) then I think this
> solution could 100% RESTful.

Actually, if you use the cookie purely as an authentication
token, your app is still RESTful.

Regards,
-- 
Aristotle Pagaltzis // 

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Catalyst with apache, how to auto restart like run myapp_server.pl -r?

[Perrin Harkins]

On 5/21/07, Cookie <[EMAIL PROTECTED]> wrote:

But I don't think when I modify my lib files,the modification seems not any
effect.And I must restart my apache to make it available.
My question is:
Is there any way to configurate my apache configuration files to be
available that I don't need to restart my apache server?(Like I run
myapp_server.pl -r)


The usual way to handle this during development on mod_perl is to use
Apache::Reload.  However, there were reports that this doesn't work
with Catalyst because of the way it stores state information.  You can
try it and see.

There is no way to automatically pick up changes which is really
recommended for use in a production environment running mod_perl.  The
problem with things like Apache::Reload is that they ruin the
copy-on-write sharing of memory by modifying memory in each child
process, and this makes your application use more real memory.

It typically only takes a couple of seconds to do a stop and start of
a mod_perl server, so in practice this isn't a big deal for most
people.  A larger site will usually have a cluster of servers and a
load balancer that lets them restart their servers in sections.  You
can find more discussions of this in the mod_perl mailing list
archives.

- Perrin

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

[Catalyst] ActiveRecord for Perl

[mla]

I'm considering trying to port Ruby's ActiveRecord to Perl
as a lightweight ORM option (with some small changes
maybe, like composite PKs). If anyone's interested, toss
me a message privately and we'll coordinate.

Maurice

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Re: Redispatching actions

[Mark Zealey]

>
> > > You said absolutely nothing to address the “wrong URL”
> > > problem Matt mentioned, btw.
> >
> > What wrong URL? My example showed that
> > http://example.com/data/update is virtually equal to
> > http://example.com/data/view if not posted from a form.
>
> Of course they are virtually equal – after all they are equally
> terrible. If you lay out your URI space in that manner, it’s no
> wonder that you can’t understand why redirects are good.

Why do you say this? what do you propose for a better URI layout?


Mark

___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/