Re: [Catalyst] UTF8 and content length
* Kroshka Yenot [2016-07-15 13:12]:
> Hi!
>
> if content type is 'application/json' or 'application/json;
> charset=utf-8' Catalyst sets content length in chars, NOT IN BYTES and
> I'm getting
>
> {"id":1, "msg":"В Питере
>
> if content type is 'text/html' Catalyst sets content length in bytes
> (properly) and everything works fine
I am guessing you have an encoding configured in Catalyst? If yes, then
it encodes text/html bodies etc automatically for you, so the body comes
out in bytes, and its length is then correct, so everything works.
> Is there any workaround to configure this behaviour, except setting
> content length manually everytime ?
>
>
> my $json_text = '{"id":1, "msg":"В Питере пить"}';
>
> $c->response->content_type('application/json');
> $c->response->content_length(bytes::length $json_text);
> $c->response->body($json_text);
>
> Thanks in advance
(Side note: if that code works, you must have `use utf8` in effect.
Next time you ask about such a problem, please mention this and any
other relevant parts of your configuration/setup. They are crucial.)
Here you are using bytes::length, which is broken by design and is
always the wrong thing to use (unless you are debugging perl itself or
writing XS code maybe), after putting a character string in the body,
and then relying on the fact that perl falls back to converting char
strings to UTF-8 on output because it can’t do anything else.
This ends up working, but it’s a terrible way to achieve what you need.
It relies on multiple broken things and workarounds cancelling each
other in just the right way to get the correct answer. The clean way to
do this is to simply encode the data before you put it in the body:
use utf8;
my $json_text = '{"id":1, "msg":"В Питере пить"}';
$c->response->content_type('application/json; charset=utf-8');
$c->response->body(Encode::encode_utf8 $json_text);
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] An MVC logic separation conundrum
* 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, -- Aristotle Pagaltzis // <http://plasmasturm.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] An MVC logic separation conundrum
* Chris Welch [2016-03-10 14:05]:
> Thinking about it: any way you would pass in an anonymous sub rather
> than the return value from the actual methods - i.e.:
>
> $match->generate_ical_data(
> get_uri => $c->uri_for_action( ... ) ,
> get_description => $c->maketext( ... ) ,
> # ...
> );
I’m not sure what you’re asking. Do you mean you want to get rid of the
`sub { ... }` noise and just pass in “a method call”? If so, no, there
is no way of doing that in Perl.
Also, that would tie you to the signature of the Catalyst method. Which
may be OK, or may not be.
Using a closure allows you to write generate_ical_data generically and
keep the knowledge of how to translate that to Catalyst within the part
of your code that knows about Catalyst. Consider e.g.
get_uri => sub {
my ( $date, $event_id ) = @_;
$c->uri_for_action( '/day/event', [ $date, $event_id ] );
},
Now generate_ical_data doesn’t have to hard-code the '/day/event' action
path. It doesn’t need to know anything about how URIs are made, it just
tells the closure which date and ID it needs a URI for, and the closure
produces one. That makes generate_ical_data easier to test too. Likewise
the closure might close over variables besides $c – maybe $self, or some
other lexical from the action method.
That’s what I meant when I used `...` in the example instead of just
writing `@_` to pass through the arguments. Using a closure gives you
control over what parameters are passed in what order, which doesn’t
have to be identical to the signature of the Catalyst method you wind
up calling.
This the same principle as the reason for having the controller, model
and view be separate from each other: isolating responsibilities.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] An MVC logic separation conundrum
* Chris Welch [2016-03-09 20:10]:
> All of this brings up a quandary: there are only two ways around this
> that I can see:
There’s plenty more. E.g. you could have generate_ical_data expect one
or several callbacks to generate those values for it, something like
$match->generate_ical_data(
get_uri => sub { $c->uri_for_action( ... ) },
get_description => sub { $c->maketext( ... ) },
# ...
);
Possibly you want to set these as instance data somewhere and then not
pass them explicitly in every call of that method, but that can easily
hurt testability and understandability of the code, so it depends on the
exact specifics of the case.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] catalyst psgi behind 2 apache reverse proxies
* Bernhard Bauch [2015-07-08 16:50]:
> suroundings: catalyst, psgi, starman, apache2.
> but in our setup there are *two* apache2s doing reverse proxies before
> the requests reaches the starman server.
>
> so what happend:
>
> the http headers look like this (for catalyst)
> X-FORWARDED-FOR: ,
> REQUEST_IP_ADDRESS:
>
> what Plack::Middleware::ReverseProxy does it puts the LAST ip in the
> forwarded-for header into
> $env->{REMOTE_ADDR}
> which is actually not the IP of the client.
> why is that happening ?
Because any other IPs could be untrustworthy. The client could include
an X-Forwarded-For header with bogus content, or there could be a proxy
legimitately sitting between you and the ultimate client (e.g. a caching
proxy run by the user’s ISP)… there are many scenarios.
> shouldn't it take the first IP, so catalyst has access to the original
> requests IP ?
Absolutely not. It cannot know whether that IP is trustworthy.
> my apache proxy configs look like this...
> is there something wrong with the proxies config ?
IMO, yes.
I think the correct solution here is to encode into your deployment
infrastructure the knowledge that a) there are two proxies and b) that
they are both trusted.
Using the ReverseProxy means you have already told the app that the
app-facing proxy exists and is trusted.
But also telling it that the world-facing proxy exists and is trusted
would IMO put too much knowledge about your specific infrastructure
layout in the app.
Instead you should tell the app-facing proxy that the world-facing
proxy is trusted. That way the different parts of your infrastructure
are more self-contained and independent.
Unfortunately I don’t speak Apache very well any more but I *think* what
you want is to load mod_remoteip on proxy 2 and then add something like
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 10.0.200.0/24
to its config.
Or maybe you have to configure the proxy 2 to just leave X-Forwarded-For
alone (which implicitly means it trusts whatever proxy 1 has put there).
(No idea if that’s possible or how.)
I can’t say what exactly will work but something along these lines would
be my approach.
> thanks for hints!
> cheers, bernhard
Hope this helps.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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
Hi Trevor,
* Trevor Leffler [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.
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.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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
* Larry Leszczynski [2014-12-04 21:35]: > On Thu, Dec 4, 2014, at 12:41 PM, Trevor Leffler wrote: > > This is a typical use: > > > > > rel="stylesheet"> > > Assuming you're using Template Toolkit, you should use the "url" > filter, not the "html" filter: > >rel="stylesheet"> No. First, if $c->uri_for gives you a URI which isn’t already correctly URI-encoded, then it has a bug which should be reported. And if it does give you correctly encoded URIs, as it should and probably does, then re-encoding them will break any already-encoded parts. Second, you are outputting URIs into HTML content, and URIs can contain verbatim things that are metacharacters in HTML, such as ampersands. Those need to be entity-escaped for HTML. If you aren’t doing that, then you are producing broken HTML. So what you are directing Trevor to do is broken – and not just once but twice. In practice, URIs that require escaping are uncommon and browsers go to enormous lengths to understand broken HTML (and unescaped ampersands in URIs are a very common problem), so you can go for a long time without running these problems. But that code is still broken, and broken twice, nonetheless. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Log4Perl and Catalyst startup routing table
Hi Adam, * Adam Witney [2014-11-13 12:45]: > I saw this post, but I 'm not sure I can use it to get the Catalyst > normal startup output in my logs. Is this possible? I guess you could make half a work-around with this module, by writing a plugin that uses the module to log this data manually during startup. How satisfactory that is I cannot say, since that depends on whether you also want the normal debug output to not to go to screen and whether you need debug mode in general. The problem with redirecting this stuff is that Catalyst produces the debug output very early during its startup, before it has loaded any extensions or plugins, so the logging facilities are the built-in stuff. (Hm, maybe it is possible to load the logging-related modules yourself and then hack them in with BEGIN or some such.) The code to produce this output is part of the startup code and not well accessible separately (which is the whole reason for CatalystX::Info after all). I.e. Catalyst basically doesn’t support what you want, and any solution done without built-in support will be ugly in some way or other. However maybe it can be modularised to support this. The tricky part of that is that you do want to output this info early, so that it will be useful for debugging e.g. when components break during loading – but OTOH it should optionally be subject to the user’s configured logging system. How do you resolve that contradiction? The rest of a new design should fall out of the answer to that question automatically. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Log4Perl and Catalyst startup routing table
* Adam Witney [2014-11-12 13:55]: > I have Log4Perl controlling the logging in my Catalyst app, but > I can't seem to get the debug information from the normal Catalyst > startup (routing table, Loaded plugins etc) included into the Log4Perl > output. > > Is it possible to log this output through Log4Perl? Synchronicity: http://techblog.babyl.ca/entry/catalystx-info ___ 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 Unicode
* Will Crawford [2014-01-31 13:05]: > If the string has been decoded *from* UTF-8 to Perl's internal > representation, it's *not* going to be marked as UTF8 internally; it > *shouldn't* be. It's no longer a "UTF8" string but a "Unicode" string, > complete with wide characters. If anything, the internal "UTF8" flag > means "this string needs decoding" rather than "has been decoded". Sorry, this is nonsense. The UTF8 flag means the string is internally stored as a variable-width integer sequence using the same encoding scheme as UTF-8, which means it can store characters > 0xFF. If the UTF8 flag is off, the string is stored as a byte array. You are correct only insofar as that decoding a string could in theory yield a string with the UTF8 flag *off*. Because the UTF8 flag doesn’t mean anything. It only means that the string can store characters > 0xFF, which only matters to perl internally, since UTF8=0 strings will be transparently promoted to UTF8=1 whenever necessary. But Perl can’t tell whether a string is a Unicode string or byte string. The UTF8 flag is irrelevant. *You* can tell, because `length` returns 2 for a byte string with a “ü” represented in UTF-8, and 1 for a Unicode string with the character “ü”. (But `length` can return 1 for a UTF8=0 string, because the codepoint is 0xFC which can be stored as a single byte just fine; and it can return 2 even for a UTF8=1 string, because the UTF-8 encoded representation of “ü” is 0xC3 0xBC and it doesn’t matter whether you store that in a UTF8=0 or UTF8=1 string, it’s still the sequence 0xC3 0xBC.) Christian: This also affects you: you should not be looking at `is_utf8`. Instead you should be looking at whether `length` returns the correct value. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Can't detach from root / create action object
* Hartmaier Alexander [2013-11-27 13:30]:
> Exactly like I just told you on IRC:
> $c->detach($c->controller('ComplianceUpdate')->action_for('index'));
Or using an action path:
$c->detach( $c->dispatcher->get_action_by_path('/complianceupdate/index') );
It’s a mouthful so if you need it lots, stick a method in your
application class à la
sub path_action {
my $c = shift;
$c->dispatcher->get_action_by_path( @_ );
}
so you can then say
$c->detach( $c->path_action('/complianceupdate/index') );
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Setting file handle as the response body generates warnings.
* Craig Chant [2013-11-26 10:20]:
> # create an IO::File for Catalyst
> use IO::File;
> my $iof = IO::File->new;
>
> # open XLS
> $iof->open(\$xls, "r");
open my $iof, '<', \$xls;
--
*AUTOLOAD=*_;sub _{s/..([^:]*)$/()[print$1,(",$\/"," ")[defined
wantarray]]/e;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Response traits.
* Bill Moseley [2013-10-31 00:40]: > What is the recommended way to apply a Response trait? Uhm, how about applying it to your response class? CatalystX::RoleApplicator I guess? Not sure I get the question though. -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: New design
* Mark Keating [2013-07-23 10:50]: > The nice chaps at Evozon have recently been making design mocks for > a bunch of Perl sites and they have come up with a fresh look for > Catalyst. Take a look and let me know what you guys think. > > http://www.mdk.me.uk/community/mocks/Catalyst.jpg Well it looks cool. But the entire first page is nothing but a starry sky with 2 sentences worth of information on it. In general, information density in this design is really low, and most of it gives me a headache if I try to read rather than just take in the prettiness. Test that yourself: try to really read a few paragraphs of the prose on that mockup. Then switch to the http://catalystframework.org/ and do the same there. Which one hurts your eyes and which one soothes them? Then what is this design trying to accomplish? The goal that Tobias’ design was created to meet was to sell people on Catalyst at a glance, by providing answers to the questions a) what is Catalyst, b) why would anyone want it, and c) how to get started, all in as little space and as few words as possible. Was there any similar goal formulated for this new design? Was it met? Furthermore – is this is supposed to be developed into a site-wide design implemented beyond the front page? Or is this just swapping out another look for the landing page shared with absolutely no other part of the site that is even just one click away, like all the previous “redesigns”? Changing the looks on the landing page is the easy part, making something that works for the entire site and is implemented on the entire site is what’s necessary and what has yet to happen, I think ever since Catalyst has existed. Design isn’t just putting a coat of paint on it… Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: New Catalyst Release on CPAN!
* Evan Carroll [2013-06-14 03:40]: > > But the quick summary includes UTF8 support out of the box, support ^ > > for event loops and async code (including goodies like Websockets, > > and all that stuff) as well as the usual assortment of documentation > > fixes and related dependency fixes. > > I wish people would stop saying that in such a vague fashion. It seems > as if there is no such thing as "UTF-8" out of the box. Every time it > comes up and someone requests it, I see a very complex and detailed > message by a UTF-8 wizzard about why it's not possible and why such > a request is a stupid one. Then a few months later, I see people > claiming it's been done in some niche area. > > There is Catalyst::Plugin::Unicode::Encoding > And, Catalyst::Plugin::Unicode > > What's wrong with those two, and what does the core magically do now? There is nothing wrong with CP:Unicode::Encoding; the CP:Unicode POD has long said what is wrong with it; John’s link explains what the core does now. Spoiler: no magic. I wish people would take the time to read what they are responding to before they respond to it. (And the antidote to the seeming back-and-forth about Unicode is to go and figure out enough of how text is modelled in computers that you gain gain the independent ability to judge what they say about it rather than being beholden to being told what will or won’t work. You will find that some things can be done and some things can’t be done, and that there is no contradiction in that. There are no gurus.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: New Catalyst Release on CPAN!
* John Napiorkowski [2013-06-13 02:05]: > Today we released 'SicilianButtercup' the most recent version of > Catalyst to CPAN! I get to drop a couple more non-core extensions, hooray! Thanks. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Chained and exceptions
* Dimitar Petrov [2013-05-14 14:05]: > It was a reply to the whole thread. Ah. > Yeah, we could probably add a warning. I dunno. I lean toward it but maybe the devs disagree. > I left it dispatch_on_die because it's concise with the action role, > but I guess abort_dispatch_in_chains_on_exception is more meaningful. I figured… well the action role is an action role, you don’t want to have to type too much, plus it’s clear when it applies by the fact that you apply it directly to an action. So a short name is good. But an app- global setting has to meet higher standards for specificity IMO. > Any other thoughts? Nothing else, I did the exact same thing. I dug through the execution flow of the dispatcher first and found that yes, Bill’s patch is exactly the right way to add this. (Well, short of the complete, chained-based refactoring of the dispatcher, in which case I’d do it a different way.) > If you already have your fork ready or differs from mine either > discard mine or fork it and add the warning? :) You have tests, I hadn’t gotten that far yet. I did fork and tweak Catalyst::Devel to add the config option to the new app boilerplate though. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Chained and exceptions
* Tomas Doran [2013-05-10 19:55]: > We should make it a config variable that defaults to the old behaviour > but adjust -Devel to default it to true in new apps. > > This keeps back compat, but makes new apps behave 'correctly'. > > +1 from me. Should there be a warning in old apps when an exception gets swallowed? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Chained and exceptions
* Bill Moseley [2013-05-10 17:15]: > What would the developers think of deprecating this behavior (for the > few that might actually be relying on this) and issue a warning if > a config option is not set that fixes the issue? I’ll second that, I’d love to drop some more unbreak-me boilerplate. ___ 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] Re: Chained and exceptions
* Bill Moseley [2013-05-09 22:50]: > Tricks for applying it globally? package MyApp::Controller; use parent 'Catalyst::Controller'; __PACKAGE__->config( action_roles => ['DetachOnDie'] ); 1; Then inherit that instead of Catalyst::Controller in your controllers. Pre-5.90013 you need `use parent 'Catalyst::Controller::ActionRole';` (got merged into Catalyst::Controller in that release). ___ 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] Re: Chained and exceptions
* Bill Moseley [2013-05-09 15:30]: > What's the reasoning that chained actions continue to run after an > earlier exception? Seems like an accident of the design to me, borderline bug. If like me you don’t like it, Catalyst::ActionRole::DetachOnDie ___ 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] Thanks! (was: [ANNOUNCE] Catalyst-Runtime 5.90030)
* Dimitar Petrov [2013-04-12 19:25]:
> The Catalyst team is proud to announce that the latest version of
> Catalyst (5.90030) is released on CPAN.
Oh frabjous day!
> - make $app->uri_for and related methods return something sane, when
> called as an application method, instead of a context method. Now
> if you call MyApp::Web->uri_for(...) you will get a generic URI
> object that you need to resolve manually.
Calloo!
Just to give you and idea of what this did for me, let me show here some
sample code.
Background: I recently split my MyApp into MyApp and MyPublicApp, both
loaded within the same app.psgi, with different requests dispatched to
each using Plack::App::URLMap. This cleaned up a previously very hairy
and precarious dispatch situation wherein I had a few custom attributes
to make sure that requests would dispatch only along certain chains in
the app depending on the hostname they were for and whether or not they
used SSL. It was a massive win. But I needed a way to generate URIs for
MyApp from within MyPublicApp’s templates.
At first I somewhat punted on the question, and just started with this:
sub uri_for_fileticket {
my $c = shift;
my ( $file_id, $ticket_id, $filename ) = @_;
sprintf 'https://%s/file/%d/ticket/%d/%s', (
$c->config->{'vhosts'}{'application'},
$file_id,
$ticket_id,
URI::Escape::uri_escape( $filename ),
);
}
And in some places I didn’t use uri_for at all, just reluctantly hard-coded
the URIs.
But soon I ran into needing to link to other actions with variable arguments,
and I sure wasn’t going to write more of the above.
Cue the first, appalling hack:
package MyPublicApp;
use MyApp ();
use HTTP::Request ();
use HTTP::Response ();
use HTTP::Message::PSGI ();
sub uri_for_app_action { # XXX terrible hack magick:
# make a mock request to the backend app
# for a special action which captures the context into the PSGI env
# where we can then pick it up and use it to generate URIs
my $c = shift;
state $app = MyApp->psgi_app;
my $env = HTTP::Request->new( GET => 'http://localhost/ctx' )->to_psgi;
my $res = HTTP::Response->from_psgi( $app->psgi_app->( $env ) );
my $hostname = $c->config->{'vhosts'}{'application'};
my $c = delete $env->{'myapp.ctx'}; # break the ref cycle to avoid
leaking memory
$c->uri_for_action( @_ )->rel->abs( "https://$hostname/"; );
}
package MyApp::Controller::Root;
sub ctx : Chained {
my $self = shift;
my ( $c ) = @_;
$c->engine->env->{'myapp.ctx'} = $c;
$c->res->status( 404 );
$c->res->body( '' );
}
Yeughw… eughw. Yick. Yew. But it worked.
Note that omitted here are various other bits elsewhere that make sure
to skip auth, logging, etc. when dispatch goes to this `/ctx` action.
At some point this action and its assorted supporting bits mutated into
an `if` block within `around dispatch` within MyApp.pm, which at least
removed some litter from the code.
The terrible ugliness of this hack kept bugging me though. Finally I had
enough and decided see whether Catalyst exposed enough enough public
methods to reimplement the relevant-to-me bits of `uri_for` to do its
job without depending on a context and without too much hassle. Well…
see for yourself.
sub uri_for_app_action {
my $c = shift;
my ( $path, $captures ) = @_;
state $dispatcher = MyApp->dispatcher;
my $action = $dispatcher->get_action_by_path( $path );
my @args = splice @$captures, $dispatcher->expand_action( $action
)->number_of_captures;
unshift @args, '' if @args; # ensure leading "/" if any args, omit if
none
return 'https://'
. $c->config->{'vhosts'}{'application'}
. $dispatcher->uri_for_action( $action, $captures )
. join '/', map { s/\?/%3F/g; $_ } my @copy = grep { defined } @args;
}
OK, could’ve been worse I suppose. And at least this did get me rid of
the `/ctx` thing. Good thing I only use Chained dispatch, which meant
there was lots of crud in `uri_for` that my emulation of it didn’t need
to bother duplicating, otherwise this could not have been a win.
And now? I just upgraded to 5.90030 and immediately took advantage:
sub uri_for_app_action {
my $c = shift;
MyApp->uri_for_action( @_ )
->abs( 'https://' . $c->config->{'vhosts'}{'application'} );
}
Much better!! So, so, so much, much, much better! Just as it should have
been (able to be) from the start, that is how it is now.
> - Adde
[Catalyst] Re: Progress bar
* Bill Moseley [2012-10-22 00:50]: > So, when running under Starman the uploads are buffered before chunked > to Catalyst, which means the progress bar data isn't updated until the > upload has completed. This renders the upload progress bar pretty > useless with Starman. > > The progress bar works fine running the app under mod_perl. > > I suppose using something like Nginx or Perlbal in front of the app > would work (because those do cache uploads but also provide a hook for > reading upload progress). But, we already have hardware load balancers > in front of the app, so don't really need an extra proxy in front of > every web server. Note that Perlbal::Plugin::PSGI allows you to run a PSGI app directly inside Perlbal. So if you are using Perlbal, you can skip Starman and avoid the separate set of processes entirely, if you wish to. ___ 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] Re: Advent 2012 is launched!
* John Napiorkowski [2012-12-06 15:25]: > http://www.catalystframework.org/calendar Weird newsfeed. Today (11th) it lists the entries from 16th thru 20th. ___ 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] Re: Does uri_for() URL-escape arguments correctly ?
I have (lots of stuff like) the following in MyApp::View::TT:
sub uri_for_action {
my $self = shift;
my $c = shift;
return $c->uri_for_action( @_ );
}
__PACKAGE__->config( expose_methods => [ qw(
uri_for_action
...
) ] );
This lets me write just
Note the absence of `c`. That absence was the rationale for this – it
makes it much easier to rig up a test environment for the templates if
they do not refer to the context directly.
But in your case, it would also give you a central place where you could
stick the pre-escaping of %.
Something along the lines of
sub uri_for_action {
my $self = shift;
my $c = shift;
my $action = shift;
for ( @_ ) {
my $r = ref $_;
s/%/%25/g for
'ARRAY' eq $r ? @$_ :
'HASH' eq $r ? values %$_ :
( not $r )? $_ :
();
}
return $c->uri_for_action( $action, @_ );
}
(Note the code is entirely untested and may be buggy not just
in implementation but also conceptually – it is meant only for
illustration.)
See `expose_methods` in the Catalyst::View::TT docs.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: prepare_body_chunk in Catalyst 5.9
* Peter Flanigan [2012-07-14 19:00]: > On 12/07/12 21:42, Eric Wright wrote: > > Looking into this further - in the the source for Catalyst I see > > that the prepare_body statement has been moved to the Request object > > removing the ability to hook into this event via the Plugin > > architecture > > Does CatalystX::RoleApplicator help? Or else moving the responsibility to a PSGI middleware may be an option. ___ 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] Re: Catalyst::ActionRole::RequireSSL under development server
* Rippl, Steve [2012-04-19 00:45]: > Anyone know what I should be testing for now? When I query > $c->engine_class I get Catalyst::Engine whether I'm running > under the development server or fastcgi. Why not simply `$c->debug`? ___ 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] Re: New catalystframework.org
* Tobias Kremer [2012-03-21 10:25]: > Let's hope that the MetaCPAN team makes a good choice. By the way: > This one is totally awesome: > http://entries.contest.metacpan.org/2012/01/raul-matei-books-left.html Unlike almost all of them, yes… listed at <https://vote.metacpan.org/>. It certainly is the only one that contains any cultural reference… except for the recoloured CPAN logo, but let’s be real. There are some other decent attempts but they are all just cool-looking generic logo-like thingies, they could stand for almost anything just as well as for MetaCPAN. And none of them translate to readily recognisable iconography (e.g. for the favicon), not like that one. If only I had made my wishlist MetaCPAN patch soon enough to be eligible to vote now… :-( Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: RESTful response codes.
* Bill Moseley [2012-02-24 03:00]:
> I was going to disagree with you, but I think we are talking about two
> differnt things.
>
> For a 400 response I completely agree with you. In that case I do
> return a very detailed and standard-formatted response that explains
> why the client request could not be processed.
Right. A 4xx response says you couldn’t give the client the thing it
asked for, which means the response body bears no relation to the
content of the thing anyway and could be anything you deem useful in
that scenario. A machine-readable structured error message is the
obvious option.
> This consumer of he API is arguing that the 2xx HTTP response are not
> enough of a "status" -- that *every* request needs a status (and that
> should not mix HTTP "transport" codes with business logic). But,
> I cannot think of an example where this would be the case.
It is the wrong way to think of HTTP. HTTP is an application protocol,
not a transport protocol. Rather than a network layer for carrying the
arbitrary semantics specific to your application, it is a standardised
vocabulary for expressing application semantics in a general way.
That means sometimes one has to constrain an application design in order
to fit it into HTTP. But that is not an arbitrary capricious lack of
freedom, rather HTTP is derived from a set of principles designed to
guarantee a particular set of characteristics. Those are what one gets
those in exchange for abiding by HTTP’s restrictions.
This API consumer’s request is mistaken in two ways:
1. They are essentially arguing that your application needs arbitrary
application-specific semantics beyond the vocabulary. That is a…
rather contestable premise. Far from everything fits into HTTP but
few who claim special snowflake status have grounds for it.
2. The mechanism they suggest is broken. In a 200 response the body is
supposed to represent the state of the *resource*, expressed in some
concrete format. What they are asking you to put in the response body
is information about the *request*. That does not belong there. This
is another indicator that they are thinking about HTTP as a transport
protocol.
In short, I suggest you don’t listen.
> So you do GET /user/1234 and it returns a 200 with a status saying
> { status => "here's the user you asked for, but I was not able to look
> up their LDAP id because the server was down. Hope you don't mind the
> omission." }. That's a scary road to head down, no?
That’s even worse than the suggestion above, it’s plain broken.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Fix for content-length issue introduced with Catalyst 5.8.x
* Dominic Germain [2012-02-16 04:00]: > All our apps code and our DBs are in ISO-8859-1 encoding. View::TT is > configured to output stuff as UTF-8 and everything is working fine > until the update. It means that there is some re-encoding occurring > somewhere in Catalyst View processing. > > The problem is quite simple: Catalyst is unable to figure out the > right content-length as soon we have characters that requires two > bytes in UTF-8. French accent characters like "é", "ê", 'è", "à", > etc. are good examples. Previously, "bytes::length" was used and it > works fine but the code was changed to just "length". > > Because of that, if I have 100 accentuated characters in the body, the > last 100 characters will be chopped by all browsers that are taking > care of content-length (Chrome and Safari for example). It seems that > FF doesn't care about content-length, it displays everything. Don't > know about IE. > > reverting back to the old way does the trick... Your code is broken and Catalyst used to be broken in such a way that it hid your own breakage. Any occurrence of the bytes pragma or one of its functions is *always* a bug: the bytes pragma violates encapsulation and is broken as designed. (Except when it’s not, but understanding when it isn’t comes when you understand why it is. It’s certainly never the best way to do what you want to do.) Your mistake is passing a character string to Catalyst as the response body. Old versions of Catalyst would then break the encapsulation of the character representation in Perl which conveniently happens to be UTF-8 in some cases (but can be Latin-1 in others), effectively giving you an implicit encoding of characters to UTF-8; if your output was UTF-8 also, then the whole misery would add up to something that happened to work. Instead of this implicit encoding from characters to UTF-8 that falls out of the implementation details of an abstraction you cracked open, what you want to do is simply do the encoding explicitly, manually. The proper fix is Catalyst::Plugin::Unicode::Encoding, as already mentioned, but that is probably a big job for your codebase because you will have to fix all other instances of character/byte confusion that you have (and you have them, per your description above) in order to make it work. The surgical change to make your code work with Cat 5.9 with no deeper changes and without hacking Catalyst itself is to encode the body in your root controller’s `end` action (*after* forwarding to View::TT). This is not a workaround – it is one of the things that the plugin will do for you, and is the minimum you need to get your code going again. But it is only one of the things the plugin does, and you should fix all of your issues. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Running Catalyst apps with start_server
* Tomas Doran [2012-01-25 16:05]: > (As perl is interpreted, your perl code lives in 'data' pages, rather > than executable pages - so you don't and can't get the same memory > sharing you can in C - where the code pages are always shared with > your child processes - as you're executing the same program... > > Or, rather - you do get exactly the same semantics - the perl binary > itself, and any shared objects (.so files) you have loaded in the > parent will be shared with children forever - but this is generally > a small proportion of your memory use, compared to your perl code and > data structures, which all live in 'data' pages - meaning that your > program running causes static perl code in data pages to become > unshared.. There is an accessible explanation of this here: http://virtualthreads.blogspot.com/2006/02/understanding-memory-usage-on-linux.html In other notes, I have seen weblog posts (maybe from Reini Urban, but I do not recall for certain) discuss the possibility of restructuring the Perl op tree such that the op data that needs to be mutable is stored separately in memory from that which never changes. That would allow forked Perl programs to not inevitably slowly grow unshared over time, just as C programs don’t. But I understood it to be a non-trivial undertaking (much though a feasible one). Maybe someday perl will be implemented that way. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Running a Cat app with HTTP::Prefork
* Octavian Rasnita [2012-01-14 17:40]: > Should it be used diffrently with Catalyst 5.9 For 5.9 I suggest switching horses completely and using the built-in PSGI support together with Starman as a stand-alone preforking dæmon. Works beautifully for me. You get to use PSGI middlewares for many of the things you would’ve used Cat plugins for before, which are both simpler and more flexible. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Double encoded UTF in config and string constants
* Alex Povolotsky [2011-11-05 11:05]: > What's more strange for me, manually upgrading string to UTF-8 with > utf8::upgrade does not help. utf8::upgrade only changes the internal storage format of the string but not its meaning. If it contained encoded text before, it will still contain encoded text afterwards. If you want the decoded text, you have to decode the string, not upgrade it. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Session duplicate key constraints on concurrent requests
* Tobias Kremer [2011-10-07 15:00]: > I've written about this issue a couple of times in the past and it > seems that this still hasn't been fixed. Maybe the answer is mu. Why use a session at all? ___ 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] Re: FormFu missing Moose::Role
* Carl Franks [2011-09-12 15:15]:
> Something must have gone wrong during the installation of
> Moose, as we depend on Moose and Moose::Role is part of that
> package.
You’re Doing It Wrong then.
You should always declare a dependency on every single module you
`use`, not just on the “main” module of the distributions that
you ended up installing, because dependency resolution follows
modules, not distros.
If you have done it right, then if any upstream distros get split
or combined (cf. LWP for a recent case), you won’t have to fix a
thing: the CPAN client will figure out the set of distros it has
to install, for you, automatically, by itself.
Don’t try to manually do the dependency solver’s work for it. You
can only do a worse job of it.
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Multiple applications (some cat based) on the same server
* Peter Edwards [2011-08-27 09:40]:
> On 27 August 2011 08:07, Aristotle Pagaltzis wrote:
> > If they all have Plack integration it’s trivially easy,
^
That should read PSGI, sorry.
> > something like
> >
> >use Plack::Builder;
> >builder {
> >mount '/cat' => $cat_app;
> >mount '/mouse' => $other_cat_app;
> >mount '/foo' => $ledgersmb_app;
> >mount '/' => $shinycms_app;
> >}
> >
> >
> Can you integrate PHP apps with Plack?
Not as of this writing. But a Plack::Middleware::PHP should be
a Small Matter Of Programming given PHP::Interpreter…
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Multiple applications (some cat based) on the same server
* Roderick A. Anderson [2011-08-26 01:40]:
> I'm wondering how difficult (or if even possible) it is to have
> several applications, with two or more being cat based, running
> on the same httpd (Apache) server?
If they all have Plack integration it’s trivially easy, something
like
use Plack::Builder;
builder {
mount '/cat' => $cat_app;
mount '/mouse' => $other_cat_app;
mount '/foo' => $ledgersmb_app;
mount '/' => $shinycms_app;
}
will do the trick.
___
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] Re: TT2 multiple subtemplates
* Stefan [2011-08-10 21:05]:
> What is the best practice to load a template like the following:
>
>
>
>
> [% content %]
>
>
> [% right_content %]
>
>
>
>
> ,content' should be replaced with left_content.tt2
> ,right_content' with right_content.tt2
>
>
> If I use a Wrapper, only content is automatically replaced. How
> can I also replace right_content?
If you want to make `right_content` dependent on the page, i.e.
you want to define both a main content and some sidebar content
*per page*, then you can keep them both in the same template
using the following structure:
First off you need two infrastructure templates in your TT
configuration:
PREPROCESS => [ 'includes.tt' ],
WARPPER=> [ 'layout.tt' ],
Then in `includes.tt`:
[% BLOCK sidebar ; END %]
(Yes, an empty block. It’s there to establish a fallback so you
can leave it out later.)
Then you use it in `layout.tt`:
[% content %]
[% INCLUDE sidebar %]
And now in your `somepage.tt` you can write:
blah blah blah blah
[% BLOCK sidebar %]hello world[% END %]
The `sidebar` block in this template will override the one
defined in `includes.tt`, and the resulting output will be:
blah blah blah blah
hello world
This way you can keep all the per-page content in one template
file, but you can break it down into smaller pieces of content
that the wrapper template can layout freely.
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Actions for asserting relationships
* Bill Moseley [2011-05-31 06:55]:
> I'm looking for more guidance wrt URLs.
Sorry for the late reply. I haven’t caught up with all my mail
in a very long time. But I thought an answer to this would be
of interest even if it comes after the fact.
> Say in the music database example that tracks have
> a many-to-many relationship to albums. A track can be
> associated with zero or more albums.
>
> In the API for this we can POST, GET, PUT, and DELETE /track
> and /album. But, what about asserting relationships between the
> two?
>
> POST /album/$album_id/add_track { track => $track_id };
> POST /album_track { album => $album_id, track => $track_id );
> POST /album/$album_id/track/$track_id (or
> /track/$track_id/album/$album_id).
>
> The last one seems best as it allows associating other data
> with the relationship, and make DELETE make sense.
If you look at it as one aspect of an album being a collection
of tracks, then you want albums to have a collection sub-resource
for their list of tracks. Naturally you instantiate new members
in a collection by POSTing to the collection.
So something close to your option #1 falls out naturally – just
call the action `track` (a resource, here a collection) rather
than `add_track` (an action). (I’m not religious about not using
verbs when they’re more concise. But here it makes sense to me.)
And POSTing would result in a new /album/$album_id/track/$track_id
resource which can be DELETEd (and maybe PUTting, eg. changing its
position).
GETting /album/$album_id/track should of course return a list of
links to all the connection resources, as any collection would.
> And what HTTP status code should be returned if a) the
> relationship is created? b) the relationship already exists?
> I'm not sure it's important that there's a distinction if only
> need to assert that the relationship exists. But, a 201 really
> implies that the resource was created.
If you follow the above model this answers itself. You send 201
if the relationship is new and 303 if it’s not.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: error while starting my dev enviroment
* Charlie Gonzalez [2011-07-10 09:10]: > I guess my question now is how do I Identify any missing > dependencies without the use of moose-outdated? or should > I simply upgrade to moose 2.0 ? After you upgrade Moose, the program will be available. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: REST-like url question
* Bill Moseley [2011-05-18 18:30]: > And these seem wrong because the query parameter is about the > user not the session. Why do you care? > That is, seems like any query parameters should be limiting on > the session (e.g. session_type). > > GET /user/1234/sessions?user_type=attendee > GET /user/1234/sessions?user_type=presenter > > Other options would be: > > GET /user/1234/sessions_attending > GET /user/1234/sessions_presenting > > What would you use? You are presenting a collection in all cases, and the list is the same in all cases. You are just filtering it differently. Use a query parameter. * John Beppu [2011-05-22 20:55]: > Could you pull this off? > > GET /user/1234/sessions > GET /user/1234/sessions/attending > GET /user/1234/sessions/presenting > GET /user/1234/sessions/attending+presenting > > This is similar to how del.icio.us handles tags. Attending + presenting = all. The first and last of these URIs mean the same thing. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: General API question: REST + SOAP
* Dave Rolsky [2011-04-07 05:25]: > On Thu, 7 Apr 2011, Aristotle Pagaltzis wrote: > >This is a very bad idea. No matter what problem you have, > >a custom HTTP header is very nearly certainly the wrong > >solution. For API versioning it definitely is. > > My understanding of REST, at least, is that versioning should > be done by specifying different Accept and Content-Type > headers, like x-application/x-myapp-auction-item-v1. > > This makes sense with REST, since the URI for a thing should > always stay the same, but it's representation can vary. The API > version is part of that representation. There isn’t any requirement in REST that a resource have only one URI. There is much less so any requirement that a resource be the equivalent of a platonic idea. In fact, if you try to treat them that way, you cause yourself problems that REST is meant to eliminate – it increases the coupling of client and server that REST aims to loosen. Switching media types is not a bad idea, much better than using a header anyway. But you want to be very careful about just when you make a change as disruptive as that, as well you don’t want to use too application-specific media types, because doing so very nearly eliminates the opportunity to bind services together in unforeplanned ways (“serendipity”, in Roy’s words, “mash-ups” if you are Web 2.0 hipster, “synergy” if you are the CTO, or just plain “integration” if you’re the one getting work done :-) ). Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: General API question: REST + SOAP
* Trevor Leffler [2011-04-06 18:50]: > 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 This is a very bad idea. No matter what problem you have, a custom HTTP header is very nearly certainly the wrong solution. For API versioning it definitely is. Putting the version in the URI is the right approach – if in fact you even need an explicit version. (You can always switch to a different URI space no matter whether you made a provision for it using a version number in the URI or not.) Of course eBay didn’t have a lot of options, being that their API is SOAP-centric (even though they now support non-SOAP options). So don’t make their mistake: don’t use SOAP. If you inescapably have to support it as an option, then at least don’t design your API from its point of view. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: HTML::FormHandler IDs not playing with JQuery
* Dmitry L. [2011-03-29 18:20]:
> > http://api.jquery.com/category/selectors/
> >
> > If you wish to use any of the meta-characters ( such as
> > !"#$%&'()*+,./:;<=>?@[\]^`{|}~ ) as a literal part of a name, you must
> > escape the character with two backslashes: \\. For example, if you
> > have an an element with id="foo.bar", you can use the selector
> > $("#foo\\.bar").
> >
> or do something like this:
>
> $('[id="foo.bar"]')
But note that this is much, much slower than an actual ID search,
which compiles down to a single `getElementById` call.
And note also that the quotes around the value are not actually
allowed per CSS spec, and recent jQuery versions have been
updated to follow the spec on this point.
So in this case it’s really preferable to use something like
$( '#' + elt_id.replace( /\./, '\\.' ) )
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Action for index not 'index'?
* Marius Olsthoorn [2011-03-24 10:25]: > We use the same technique. We have some breadcrumbs that extend > the path of the previous breadcrumb. Eg. Home > User > Rating > corresponds with paths '/', '/user//, '/user//rating'. > > Our version has support for this if you pass it an 'append_url' > option instead of just 'url' in the relevant parts of your > chain. This encodes your URI structure into your `add_breadcrumb` call *sequence* as well as the chain structure, though. If you leave the job all to `uri_for_action` you can shuffle things around and the breadcrumb links will continue to be correct with no extra work. I doesn’t happen a lot, but I was glad for the magic each time it did. It doesn’t cause much redundancy either, you just have to pass a few ID values a few times extra. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Action for index not 'index'?
* will trillich [2011-03-23 15:30]:
> What we do instead is, we call a function to add another link
> in our breadcrumb chain, so it's deliberate and we're
> completely in control:
That’s what I did too.
> sub add_breadcrumb {
> my ( $c, $path, $label ) = @_;
> my $bc = $c->stash->{breadcrumbs} ||= [];
> push @$bc, +{
> path => $path,
> label=> $label,
> };
> }
Mine looks like this:
sub breadcrumb {
my $c = shift;
my $label = shift;
my $uri;
$uri = $c->uri_for_action( @_ )
if @_;
push @$_, {
label => $label,
href => $uri.
} for $c->stash->{ breadcrumbs };
return $c;
}
Note that it takes the label as first argument.
This yields a few nice properties. You can set breadcrumbs as
pure labels without a link simply by passing just the label.
I use that option mainly on the final action of a chain. (The
code in the template also omits the `` on the last breadcrumb
even if there is a link.)
And aside from the first argument it’ll work just like Catalyst’s
own `uri_for_action`.
So in a typical mid-chain action I get something like this:
sub base : PathPart('workspace') CaptureArgs(0) {
# ...
$c->breadcrumb( 'Workspace', '/workspace/list' );
}
sub item : PathPart('') CaptureArgs(1) {
# ...
$c->breadcrumb( $ws->name, '/workspace/view', [$ws->id] );
}
So the chain structure automatically yields the right choice and
sequence of breadcrumbs.
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Escaping of "argument" of private path
* John M. Dlugosz [2011-03-15 08:10]: > alt="photo" /> > > That works (using Smart_URI settings to leave off the host). > But it did not escape out the '&' in the filename! Is that > a bug? No. It’s exactly the right answer: ` ` → `%20` is URI escaping (which `uri_for` does, as it should), `&` → `&` is HTML escaping (which `uri_for` has nothing to do with). You want Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Opinions on static::simple - with caching
* Toby Corkindale [2011-02-02 07:50]: > My suggestion being to continue to use Static::Simple, but with > cache-related headers added so that the reverse-proxy in front > of Starman will cache-and-serve them itself. Exactly. HTTP has great scaling features. There is no need to invent special-purpose mechanisms to achieve the same things. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Opinions on static::simple - with caching
* Toby Corkindale [2011-02-01 03:25]:
> The case that I find having the headers enabled is as follows:
>
> Front end load-balancing proxies, talking to app servers
> running starman, running catalyst apps.
> If you use Static::Simple, this does make the pipeline
> configuration nice and simple.
> I like simplicity.
> If you enable caching on your static content, then your
> reverse-proxies at the front will cache things, and take the
> load of static content off Catalyst at the back.
>
> I'd like to see it as an option on Static::Simple; I could mod
> that and send a patch over if you liked?
You may be interested in my setup:
http://blogs.perl.org/users/aristotle/2011/01/some-nifty-things-you-can-do-with-catalyst-on-plack.html
--
*AUTOLOAD=*_;sub _{s/::([^:]*)$/print$1,(",$\/"," ")[defined
wantarray]/e;chop;$_}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: Static MultiViews?
* Tomas Doran [2010-12-10 17:05]: > MultiViews is an apache feature for language customisation, and > has nothing to do with not having extensions on files. No it isn’t (just), and yes it does. MultiViews allows you to put directory.png directory.gif directory.ico in `/icon/`, then use the URI `/icon/directory` (notice the lack of extension) to let Apache decide which of these files to serve to the browser, based on the `Accept` header sent by the browser and the MIME type ↔ filename extension mapping from the Apache configuration. I don’t think such a thing exists for Catalyst. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Converting a GET request to a POST request
* Ronald J Kimball [2010-11-29 18:30]: > This is for a widget that will be hosted on third party > websites. The widget will allow users of those sites to > interact with our content. The widget will be written in > JavaScript and HTML. The widget will retrieve content and > submit user interactions using Ajax and JSONP (supposedly via > a REST API :). Users will not be required to log in to interact > with the content in the widget. An obvious idea would be to serve the client-side code from your own domain so it can use XMLHttpRequest – so I have to assume you considered and rejected that approach. Is that so? If yes, it would be useful to hear the considerations behind that rejection. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Converting a GET request to a POST request
* Ronald J Kimball [2010-11-23 18:00]: > For what it's worth, the REST methods that I want to expose in > this way are for posting responses to content. There won't be > any deletes. Still, it opens you up to hostile third-party sites injecting 15,000 bogus responses on behalf of a user. > On Mon, Nov 22, 2010 at 3:12 PM, Aristotle Pagaltzis wrote: > >The same-origin policy is not there by mistake, but to keep > >your users safe from malicious 3rd party sites they may visit. > > REST principles dictate that I use POST, not GET, for these > requests. The same-origin policy forces me to use JSONP, which > can only make GET requests, not POST. What's the solution? “You can’t get there from here”: you can’t use Javascript to make unsafe requests outside the origin. Step back. What are you actually trying to do? I could imagine that eg. an OAuth-based solution could work (wherein the user hands other sites an auth token from you, and the sites use that token to make requests to your site on their users’ behalf). Or maybe it’s too complicated or overkill for you – that depends on your aim and constraints. So tell us about them. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Converting a GET request to a POST request
* Ronald J Kimball [2010-11-22 18:50]:
> I want to convert a GET request to a POST request, inside my
> Catalyst app, before dispatching happens. For example, I want
> to take a request like:
>
> GET /foo?method=POST&body={"foo":1}&content-type=text/javascript
>
> and convert it into a request like this:
>
> POST /foo
> Content-Type: text/javascript
>
> {"foo":1}
This is really, really, really bad. It’s roughly like modifying
a file system to be allow file deletion as a side effect of
opening a file. GET is supposed to be safe, that is, it should be
free of side effects that the user cannot be held responsible
for. It is very, very easy to get a browser to send GET requests
incidentally, eg. by putting the link in a `` or
a stylesheet `` and getting a user to visit. Things like
Google Web Accelerator and other automated user agents (like
search engines of course) also generally assume that GET is safe.
Much web infrastructure also assumes that GET requests are
cacheable, so if there are any proxies between the app and the
user, sending multiple pseudo-POST requests may not actually do
anything.
> Background: I'm implementing a REST API using
> Catalyst::Controller::REST. The API will be accessed via Ajax
> running on third party websites, using JSONP to get around the
> same-origin policy. Unfortunately, JSONP can only make GET
> requests. So, I want to take that GET request and turn it into
> a POST before Catalyst::Action::Deserialize does its magic.
The same-origin policy is not there by mistake, but to keep your
users safe from malicious 3rd party sites they may visit.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: $c->visit without calling end()
* Bill Crawford [2010-11-15 14:20]: > On 13 November 2010 02:54, Bill Moseley wrote: > > Any tricks to do a $c->visit type of call but w/o doing > > a full dispatch, that is, without calling the auto and end > > actions? > > Doesn't $c->forward(...) do exactly that? Or have I completely > misunderstood the docs? No, `forward` does not do a full redispatch. Most importantly, if you’re using chains in your app, then `visit` will walk the entire chain to the action you passed and call those actions (as well as all the `begin` and `auto` actions along the way), while `forward` will only call the action itself. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Organizing link generators
* Evan Carroll [2010-11-12 18:55]: > Knowing how uri_for_action works, and action dispatch: '/' is > a really stupid character to delimit controllers and actions. > This confuses a lot of people, and while I've known for years > now how it works, it confused me enough to remember being > confused then. A lot of this confusion would probably go away > if we would just revert to a different character, like the '>', > or something. I like how it makes the action path correspond to path to the template below the root, but yeah. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Organizing link generators
* Alexander Hartmaier [2010-11-12 15:35]: > To me company, lot and vin in the url look like arguments, not > PathParts. That’s not how `uri_for_action` works. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Organizing link generators
* Alexander Hartmaier [2010-11-11 09:00]:
> I strongly advise to use
> $c->controller('Auth')->action_for('edit') instead of
> '/auth/company/lot/vin/edit' to not let Catalyst guess what you
> mean. The string can fail if you have a typo in it and will be
> hard to spot.
No, that would be `$c->controller('Auth::Company::Lot::Vin')`.
I use the action paths in our app and haven’t had any serious
trouble.
You can always wrap `uri_for_action` or `uri_for` in your
application class to throw an error if it’s a real issue, anyway.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: using template plugins
Hi Stuart, * Stuart Dodds [2010-10-13 18:35]: > I use template toolkit in my catalyst application and need to > use the plugin Template::Plugin::UTF8Decode in several template > files. I can do what it says in the synopsis for this module: > [% use UTF8Decode %] at the top of every template, which works > fine but my question is, is there a way to use this plugin (or > any other template plugin) in catalyst so that it is included > in all templates rather than having to use it in each template > separately. this is not a Catalyst question, it’s a Template::Toolkit one. The answer is to put `[% USE UTF8Decode %]` in `prepare.tt` and add `PREPROCESS => 'prepare.tt'` to your TT config. Adjust the name of the include file to taste, obviously, and list multiple files by passing an array ref instead of a string. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Returning to referer - which action to take?
* Ekki Plicht (DF4OR) [2010-10-02 00:15]: > How would you identify a returning customer (returning within > a few seconds to a few minutes in one browser session)? Browser > fingerprinting in an auto action? For personalisation or analytics? For personalisation you pretty much have to use a cookie. That has nothing to do with a session though. For analytics I would not do this inside the app at all. You can use referrers to stitch a trail of requests into a click stream. If you tack a short random sequence of characters onto all your links as an ignored request parameters, and you follow the trail backward, you will get near-perfect accuracy for click streams even for visitors with cookies off, as long as they send referers. (Many more people block cookies than referers. You can use both methods of course, possibly using detection to select one.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Returning to referer - which action to take?
* Ekki Plicht (DF4OR) [2010-09-30 22:40]: > Am Dienstag 28 September 2010, 23:09:49 schrieb Aristotle Pagaltzis: > > Ultimately you should not need any session storage for > > anything. > > Yes, for session tracking. I would like to see what my visitors > do on our site :-) You definitely don’t need sessions for user tracking. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: "Wrong Content-Length value"
* Bill Moseley [2010-09-08 23:15]: > Shouldn't that just return 411, 413, or just a 400? Returning 411 is indeed exactly what the server should do. (413 is wrong. 400 is fine but not as helpful.) The server should definitely not throw an error. It shouldn’t even log a warning, because this has nothing to do with what the server did. All it is is a client being silly. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Returning to referer - which action to take?
* Ekki Plicht (DF4OR) [2010-09-26 23:50]: > Am Sonntag 26 September 2010, 23:05:51 schrieb Octavian Rasnita: > > For example, you can have urls like: > > > > www.site.com/en/dir1/dir2 www.site.com/ro/dir1/dir2 > > Hm, I don't like URLs like that very much, but your later > argument, that SEs wouldn't know which language to index when > the pages have the same URL is convincing. I didn't think of > that. Thanks. > > I will look at the links you provided. Another advantage of putting the language in the URI is that if you want to refer to a specific language version of the page, you can use that link. Another is that you do not need to keep any session data. You can implement the “select language” functionality by putting “[English] [German] [French]” etc links somewhere at the top right of the page that simply link to the other-language versions of the same page – and simply by clicking on one of them, the user has “changed” their “session”. Ultimately you should not need any session storage for anything. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: A point of confusion/frustration on chained actions
Hi Jeff, * Jeff Albert [2010-05-28 22:30]: > Can you expand on this? I followed the suggestion that Ido and > others had put forward, but I don't like the 'extra' midpoint > to extend the chain; what would a simple example of your > proposed solution look like? I’m confused. I thought you followed Ash’s suggestion. Ido’s is different. You can’t have followed both of their suggestions. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: A point of confusion/frustration on chained actions
* Ash Berlin [2010-05-20 00:40]:
> sub tutorials : Chained('/') PathPart CaptureArgs(0) {
> # stash tutorials rs
> }
> sub all_tutorials : Chained('tutorials') PathPart('') Args(0) {
> # empty, or set stash for view
> }
>
> sub a_tutorial : Chained('tutorials') PathPart('') CaptureArgs(1) {
> # stash tutorial
> }
> sub show_tutorial : Chained('a_tutorial') Args(0) PathPart('') {
> # setup view
> }
>
> sub comments : Chained('a_tutorial') CaptureArgs(0) PathPart {
> # stash comments rs from stash->{tutorial}
> }
>
> # You get the idea hopefully
> sub show_tutorial_comments : Chained('comments') Args(0) PathPart('') {}
> sub a_comment : Chained('comments') CaptureArgs(1) PathPart('') {}
>
> sub show_comment : Chained('a_comment') Args(0) PathPart('') { }
>
> sub replies : Chained('a_comment') PathPart CaptureArgs(0) {}
> sub show_replies : Chained('replies') Args(0) PathPart('') {}
> sub a_reply : Chained('replies') CaptureArgs(1) PathPart('') {}
> sub show_reply : Chained('a_reply') Args(0) PathPart('') {}
FWIW, I’d pull this out to several controllers and then use the
naming convention I’ve adopted for this sort of thing:
package MyApp::Controller::Tutorials;
sub base : Chained PathPart('tutorials') CaptureArgs(0) {
# stash tutorials rs
}
sub list : Chained('base') PathPart('') Args(0) {
# setup index view
}
sub item : Chained('base') PathPart('') CaptureArgs(1) {
# stash one tutorial
}
sub view : Chained('item') PathPart('') Args(0) {
# almost always empty
}
package MyApp::Controller::Comments;
sub base : Chained('/tutorials/item') PathPart('comments') CaptureArgs(0) {
# stash comments rs from stash->{tutorial}
}
sub list : Chained('base') PathPart('') Args(0) {}
sub item : Chained('base') PathPart('') CaptureArgs(1) {}
sub view : Chained('item') PathPart('') Args(0) {}
package MyApp::Controller::Replies;
sub base : Chained('/comments/item') PathPart('comments') CaptureArgs(0) {}
sub list : Chained('base') PathPart('') Args(0) {}
sub item : Chained('base') PathPart('') CaptureArgs(1) {}
sub view : Chained('item') PathPart('') Args(0) {}
You get the idea.
This also makes it very nice to navigate the template structure
when using RenderView, as you can always relate everything to its
purpose at a glance without referring to the controllers once.
I kept the namespace structure flat here intentionally.
I recommend doing so even if your URIs are nested – unless there
are several different kinds of comments and replies in the
system. In that case I would nest the package names in order to
make it simpler to navigate the source. Chained dispatch makes it
easy to get just about any URI structure, regardless of how the
code is laid out; this is a feature, you should use it.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: A point of confusion/frustration on chained actions
* Ido Perlmuter [2010-05-20 00:35]:
> In this case all you have to do is create the comment
> action as a mid point, and then create another action with
> a different name, but the same PathPart (e.g. comment) only
> this time as an end-point, and all this action needs to do is
> forward or detach to the original action (also passing any
> parameters it needs).
Don’t do that.
Chain a `PathPart('')` endpoint from the mid-point.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Chained actions with can't terminate with :PathPart('') ?
* Evan Carroll [2010-05-07 19:20]:
> However, I would also expect the below to work; but, it seems
> it doesn't.
I have dozens of such view actions in our $work app. It works.
> 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.
The problem is not in Chained.
> sub lot :Chained('/auth/company') :CaptureArgs(1) {
> sub view_lot :Chained('/auth/company/lot') :PathPart('') :Args(0) {
Your snippet implies that you have a `company` action in an
`Auth` controller (when you chain to `/auth/company`), and
a `lot` action in an `Auth::Company` controller (when you chain
to `/auth/company/lot`). That doesn’t make much sense.
I think you wanted
sub view_lot :Chained('lot') :PathPart('') :Args(0) {
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Alternatives to Catalyst ?
* Oleg Pronin [2010-04-29 11:10]: > Maybe it is not the bottleneck, but how many places do we have > like this that are "not a bottleneck" ? maybe the sum of all > these "mini" mistakes is the bottleneck ? Maybe, maybe, maybe. Stop guessing. Profile the code in question. Here is my experience – *experience*, not theory, and not dogma: If you look at any non-trivial piece of code, and you guess where the performance bottleneck in that code will be, you will ALWAYS be wrong. This is not a figure of speech. I am not taking poetic licence here. I very literally mean you will guess wrong EACH and EVERY single time. Furthermore my experience is that in almost any codebase, the execution time is spent almost entirely in very few spots. If you optimise any other part than those spots, even if you make it 500,000 times faster, the result will be virtually nil. You can even make *every*thing faster, *except* the hotspots, and it will still add up to almost no improvement. This is why we don’t all still write assembly today. (Which is actually a pity, and part of the reason why so much code today is so slow. Not because the code isn’t written in assembly, but because it’s not written by assembly programmers.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Alternatives to Catalyst ?
* Zbigniew Lukasiak [2010-04-27 09:20]: > Not a very concrete answer - but I remember that Miyagawa > talked about fixing that in Plack::Request (and I am not sure > but I think it also involved H::MV) - so there might be some > occasion for reuse :) Yeah, that’s exactly what he wrote H::MV for. I chimed in a bit, and the way its internal storage works now fell out of a back & forth between the two of us, designed for the typical use case in web apps – it’s optimised for initialisation speed at the expense of query speed, because you typically only ask for param values once anyway, and the initialisation cost is incurred for every request no matter how little of its effort you exploit. (So people who randomly microbenchmark querying, like the thread starter, will be unhappy about that… just goes to show the fallacy of doing that.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Alternatives to Catalyst ?
* Zbigniew Lukasiak [2010-04-26 12:25]:
> This is a fine advice - but unfortunately the ->param method
> call suffers from additional problem - which is described in
> much detail in the documentation (go to the NOTE at:
> http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).
Yeah, but the ->params hash has the converse problem: if you
write
$c->model->insert_person( name => $c->req->params->{'name'} )
then you may be surprised to find out there are people with name
like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
case of data corruption. Worse is if you legitimately expect
a parameter to have one or more values, eg. a pile of checkboxes.
Then you have to constantly check whether you’re getting a scalar
or an array reference.
So either you use the legacy method and have to protect against
getting more values than you wanted, or you use the suggested
method and have to protect against getting fewer values than you
expect in the general case.
I briefly tried to write something to stick Hash::MultiValue into
Catalyst to end the madness, but doing it properly would require
a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
approach that made deep integration of H::MV impossible (with
properly preserved k/v pair order).
Could have written a Request role… but that seemed unsatisfying.
I wonder whether it would be possible to rip out the respective
bits from Cat and use just H::MV, and leave the current stuff to
a compat plugin or something like that…
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Alternatives to Catalyst ?
* Oleg Pronin [2010-04-21 18:40]: > Guys, is Catalyst a senior system ? > > I think that creator of Moose, and some similar shit is in > cooperation with hardware manufactorers :-) > The more CPU spent - the more hardware bought. You should switch to PHP. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Outcome of the "Security issue with hashed passwords in C:P:A:Password"?
* Andrew Rodland [2010-04-10 09:00]: > the complexity of storing them separately Does not compute. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Which C::View::PDF should I use?
* Wade Stuart [2010-03-26 01:45]: > * Aristotle Pagaltzis [2010-03-25 17:05]: > >And how is Xvfb (which is an X11 server) a solution the > >problem of requiring an X11 server? > > It is a virtual frame buffer that allows x11 requiring apps to > run without a full display/head. What besides that is your > issue around the x11 requirement on servers? Either you start one per CutyCapt instance which can get quite expensive quickly, or you have a new dæmon to manage. And either way you need to install a metric ton of X11 crap on the server. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Which C::View::PDF should I use?
* Wade Stuart [2010-03-22 22:35]: > On Tue, Mar 16, 2010 at 2:53 PM, Aristotle Pagaltzis wrote: > > * Adam Sjøgren [2010-03-16 18:15]: > > > An alternative could perhaps be CutyCapt: > > > > > > * http://cutycapt.sourceforge.net/ > > > > It requires an X11 server, so it isn’t. > > > Xvfb has been the solution to this forever. And how is Xvfb (which is an X11 server) a solution the problem of requiring an X11 server? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Which C::View::PDF should I use?
* Gabriel Andrade [2010-03-16 16:50]: > http://code.google.com/p/wkhtmltopdf/ That looks interesting, thanks! * Adam Sjøgren [2010-03-16 18:15]: > An alternative could perhaps be CutyCapt: > > * http://cutycapt.sourceforge.net/ It requires an X11 server, so it isn’t. The wkhtmltopdf doesn’t make it easy either: it requires a patched Qt for that. But at least it’s possible at all. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Which C::View::PDF should I use?
* Ovid [2010-03-16 11:25]: > And trying to pass Acid2 in a PDF renderer? Wow. Yeah, it was one of the first renderers to pass the test suite, beating out several of the big browsers. A magical piece of work. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Which C::View::PDF should I use?
* Steve Kleiman [2010-03-14 17:10]: > I've been using iText (http://itextpdf.com/) after using > PDF::API2 for years. API2 hasn't grown and even once you know > it, it's tricky to use. The community is inactive. > > iText is Java and the community is vibrant. I'll have my > Catalyst app assemble a whole bunch of data and ship it to > iText as a JSON object (iText reads XML, too). Then I have > a program I wrote in Java suck in the JSON and render the PDF. > It's way faster than Perl and there's all sorts of handy > features that make doc generation easier. On our project, we dropped some cash coin to buy a licence for PrinceXML <http://princexml.com/>. That thing is totally awesome, you give it pretty much any old XHTML with CSS and it spits out a PDF that looks the way you’d expect. It also supports a bunch of custom CSS rules for even more control. It’s not cheap, but for our purposes the price was completely worth it – I spent some time integrating it, but it has completely eliminated all further work related to producing PDFs. (In contrast, our Excel exports f.ex. have consistently consumed non-trivial amounts of work.) As a rule I don’t like closed-source, binary stuff, but PrinceXML has proven to be an exception. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: JSON views and CamelCase column names
Hi Bill, * Bill Moseley [2010-02-26 01:05]: > In case the question wasn't clear: how should I implement > a View that has methods associated with specific controllers > and where should that live? you might want to look at Catalyst::View::TD for inspiration. http://search.cpan.org/dist/Catalyst-View-TD/ Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: How to read the performance information
* Andrew Rodland [2010-02-19 07:35]: > On Thursday 18 February 2010 11:14:46 pm Julien Sobrier wrote: > > The time don't add up. Form the timing under Action. it took > > less than 1 second. But the line before says 8.27s. Does it > > mean 7+ seconds were spend doing something else? Doing what? > > > There are two things that spring to mind: > > 1. Time spent reading the request from the user (after the > connection is made but before the full request is received) is > accounted to the "Request took" time but not to any action. > Normally this should be a very small amount of time for a GET, > but in case of very bad network conditions it could be longer. > This wouldn't be any indication of the performance of your app. > > 2. Your system could have had a major I/O stall between the > beginning of request handling and the beginning of action > dispatch, or between the end of action dispatch and the end of > request handling. You would probably know if this was > happening. :) Or something that qualifies as both. My immediate first suspicion in such cases: check your DNS lookup machinery. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Large requests with JSON?
* Bill Moseley [2010-02-09 16:10]: > On Tue, Feb 9, 2010 at 2:36 AM, Aristotle Pagaltzis wrote: > > That sounds like the case I was thinking about: just do a PUT > > request with X-MyApp-Filename, X-MyApp-Timestamp etc headers. > > Of course, I left out the ability to upload multiple flies at > once. Doing that with headers could get ugly. > (X-MyApp-Filename-01, X-MyApp-Filename-02, ...) Of course, > could just not provide that multiple-file upload ability to API > users and limit it to web users. That would work ok. I would seriously just not provide multiple uploads via the API. For the browser UI they’re a necessity because it’s so awkward to upload files one at a time, but the API is a completely different category. This falls under “batching”, and all the HTTP sages will tell you “don’t do that”. It makes both the server and the client more complicated without any discernible upsides. (In fact, if you do pipelining, then separate PUT requests are actually more efficient in terms of roundtrips and overhead.) > From past experience I can assume some customers will have > trouble adding request headers for the libraries they are > using. That would be a problem, yes. (Damn people treating HTTP as a transport protocol… *mutter*) > form-data is possible serialization, but it's a flat > serialization so also need to have fields like filename_01, > title_01, filename_02, title_02 to handle multiple uploads at > once. (Plus, the app already handles that form-data). Just don’t do batch uploads in the API. > XML-RPC Yuck. > JSON provides the nice nested structures but, IIUC, has to be > in-memory to parse. Not in principle, although it may well be that there isn’t any library that implements a streaming parser yet. > Not pretty at all, but maybe using form-data with > a JSON-encoded "meta" field that has a list of uploads with > associated meta-data including a field_name with each upload > that associates it with a field that contained the uploaded > file. Most client libraries have a way to send form-data, so > that would be easy for customers to implement. > > None of those are great options. Actually, that sounds like a decent option if you really need a nested data structure and can’t use headers. (I’d still not do batch uploads, though.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Large requests with JSON?
* Bill Moseley [2010-02-06 23:35]: > 1) create a new user in account #1234 with name, email, etc. This is just a normal form POST. > 2) create a user but also provide a photo when creating the user I might separate this out into two requests – whatever the POST request returns would contain a link to which the client can PUT the photo. > 3) upload a document for the user and the document must include > an associated collection of meta data (e.g. filename, > timestamp, author etc.). The uploaded document must include > this meta data before it can be accepted. That sounds like the case I was thinking about: just do a PUT request with X-MyApp-Filename, X-MyApp-Timestamp etc headers. (Another option, which is better in some ways I think, would be the two-request approach as above, though that would be more complicated. Ie. the client POSTs the metadata, the server files the data away temporarily and returns a link to which the client can PUT the file, and only once that request has succeeded does the server store both metadata and file in their proper place.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: proper flow control with $c->foward, in search of greater grok
* Dennis Daupert [2010-01-24 18:05]:
> On Mon, Jan 11, 2010 at 4:00 AM, Aristotle Pagaltzis wrote:
> > I think you are looking for
> >
> >my @caps = ( $user_id, $blog_id );
> >$c->go( '/user/blog/entry/list', \...@caps );
> >
> > or just
> >
> >$c->go( '/user/blog/entry/list', [ $user_id, $blog_id ] );
>
> Neither of these formats works for me. I'm getting exactly the
> same behavior as I got previously. I see all the correct body
> parameters being passed, but the $user_id isn't being
> recognized in the first leg of the chain. However, the
> uri_for_action format does work:
>
> $c->response->redirect($c->uri_for_action('/user/blog/entry/list',
> [$user_id, $blog_id]));
Hmm, per my reading of the documentation, the examples I gave
should work. However, I haven’t used `go` in practice yet. (I
have some places that currently do more hacky things that should
be converted to `go`, but I haven’t found the time.)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Large requests with JSON?
* Bill Moseley [2010-02-06 17:30]: > As in don't provide a way to upload meta data along with the > file (name, date, description, author, title, reference id) > like the web upload allows with multipart/form-data? Or invent > some new serialization where the meta data is embedded in the > upload? Neither, depending on your metadata. The things you did mention could quite well be sent as request headers. No need to put another envelope inside the HTTP request envelope. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: action_for with user_id removed ...
* Kiffin Gish [2010-02-06 11:25]: > I'm not so sure that I agree, though I can appreciate your > point of view. > > All I'm doing in fact is using the $user->id saved in the > session, there being nothing papered over for authorization > which is accomplished via the usual login mechanism. I’m talking about the fact that you don’t want users to know their account ID. Why would it be any problem if they do know it? * Bill Moseley [2010-02-06 17:35]: > Plus, it sure is handy in documentation to say: > > To update your personal profile go to: http://example.com/myprofile True. My first inclination would be to handle that with a redirect. * Oliver Charles [2010-02-06 18:15]: > We have to points in urls for this: > > * /user// >"Public" viewing of user stuff (public may mean only >a restricted set of users can view it, but it's not private) > > * /account/ >For doing stuff that only you can do to your own account >(change password etc) ++ I’ve found this to be a generally good idea, not only to reduce the amount of conditional checks in server code and templates, but also from the user’s point of view, as it makes it readily possible to access all the different views to a resource. Basically: URIs are cheap. Don’t be afraid to have more of them. HTTP infrastructure suffers much more where there are too few URIs than where there are too many. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: action_for with user_id removed ...
* Kiffin Gish [2010-02-01 17:20]: > I have a number of user-defined actions which are described > with the user id like this: > > settings/user_id/(view|edit) > > Where user_id is the primary key into the users resultset. > However, I do not want this to be visible to the end-user for > security reasons (if I'm admin it's alright). > > Is it possible to retain these, but for users who are logged in > the /user_id/ is removed to get this visible instead: > > settings/(view|edit) I find this highly suspect. It sounds like your authorisation checks are inadequate somewhere, and you are trying to paper over that instead of fixing it. From an HTTP point of view it is unwise to make endpoint URIs like that which can refer to many different resources at any one point in time. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: How to forward to a specific path
* Julien Sobrier [2010-01-26 06:30]: > I have pages in /page// > > I created a couple of categories: /ca1, /cat2, etc. Each of > them map to a /page// > > /page/1/some-title > /cat1/page/1/some-title > /cat2/page/1/some-title > > For cat1 and cat2, I wanted to set some variables. So > I intercept the page in /cat1 and send it back to > /page/1/some-title > > /cat1, /cat2 and /page reside in different controller. OK, but that doesn’t explain why you need to forward to a URI rather than an action. Why is that? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: modules for conditional GET ?
* Dami Laurent (PJ) [2010-01-18 08:35]: > So clients should keep asking for those pages at each request, > and depending on the If-Modified-Since header and on the > timestamp for the config file, the server can decide if it's > worth recomputing the page for that client, or rather send > a cheap 304 Not Modified. I suggest you send an ETag and check `If-None-Match` (possibly just a hash of the timestamp for the config file) instead of (or if you have HTTP/1.0 clients, in addition to) relying on the timestamp and `If-Modified-Since`. Beyond that: It’s easy to write a module that will conserve bandwidth using these headers, by hashing the body after all computation is done and checking whether to send it or just a 304. But conserving server CPU requires intimate knowledge of both the model and the structure of the controllers. It seems hard to find a generically useful abstraction beyond a utility method or two for setting the headers. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Newbie question on debugging inside a schema
* Steve Kleiman [2010-01-16 13:15]:
> I gather it's Bad to pass in $c so that within a schema I can't
> do what I'd really like which is:
> $c->log->warn('some useful debug info');
Pass in $c->log and do:
$log->warn('some useful debug info');
In your testsuite you can pass a Class::Null object.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1}
&Just->another->Perl->hack;
#Aristotle Pagaltzis // <http://plasmasturm.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] Re: modules for conditional GET ?
* Dami Laurent (PJ) [2010-01-14 16:05]: > For some actions of a Catalyst app, I would like to implement > conditional GET (using If-Modified-Since HTTP header), where > the timestamp of one config file decides whether the page > should be refreshed or not --- this is because that page is > quite expensive to compute. I agree with the others who have responded, but they didn’t explain why theirs was the right answer, so: You’re not checking whether any state has changed since the last GET to decide whether to recompute. That is the case in which conditional GET would be appropriate. That would allow you to avoid recomputing the page indefinitely as long as no state changes necessitate it, but it requires that the clients keep asking. Instead you merely want to avoid doing any recomputation for some predefined period of time, regardless of your state. This is a case for caching: since you aren’t going to recompute the page until said time has passed, you may as well tell the client that it’s superfluous for them to try asking again before that period is up. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Bugzilla REST API in Catalyst
* Kiffin Gish [2010-01-11 20:25]: > I'm not familiar with Mecurial and can't get hg to run correctly. A note for the interested: with hg-git it’s very easy to work mostly with git and only touch hg when publishing/downloading commits: http://stackoverflow.com/questions/883452/git-interoperability-with-a-mercurial-repository/1089221#1089221 Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: proper flow control with $c->foward, in search of greater grok
* Dennis Daupert [2010-01-08 17:50]: > I've tried various incarnations of go, but here's one: > > my @args = qw( $user_id $blog_id ); Uhm, you know that `qw` does not interpolate, right? So that line will assign the literal strings '$user_id' and '$blog_id' into @args, not the contents of the variables $user_id and $blog_id. That would be why your IDs are invalid… just basic Perl stuff, nothing to do with Catalyst. > my @captures = $c->req->captures; > > $c->go( 'Blog::Controller::User::Blog::Entry', 'list', [ \...@captures, > \...@args ] ); > > I also tried with my @captures = (), @captures = qw( $user_id $blog_id ); > > I don't see go yet. The square brackets in the POD (which I think they are a really bad stylistic choice there) mean that these arguments are optional, not that you should pass those parameters inside an anonymous array. I think you are looking for my @caps = ( $user_id, $blog_id ); $c->go( '/user/blog/entry/list', \...@caps ); or just $c->go( '/user/blog/entry/list', [ $user_id, $blog_id ] ); Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Various ways to use c.uri_for
* Octavian Rasnita [2010-01-09 15:20]:
> It could be helpful to have shortcuts for the second way of
> creating URLS, something like...
>
> c.url_query('controller_name', 'action_name', param1, param2)
Already exists, although it uses the internal path instead of
separately passing the controller package and the action name:
c.uri_for_action('/controller/action', param1, param2)
Note that this is *not* a hardcoded URI! The above this is not
same as the following:
c.uri_for('/controller/action', param1, param2)
When you use `uri_for_action`, you are referring to the action
paths listed in the debug info table that you see when you start
the Catalyst server in debug mode. If you use attributes to
change the URI an action matches, then the `uri_for_action`
output will also automatically reflect that change.
> We can put a url_query subroutine in MyApp.pm that looks like
> the one below (although I don't know if it works in all the
> cases - chains),
It works just fine with chains. It will follow the chain backward
and use any captures you supply to construct a URI that will
dispatch to the end point you specified. F.ex. I have the
following:
package MyApp::Controller::Staff;
sub base : Chained PathPart('app') CaptureArgs(0) { ... }
package MyApp::Controller::Person;
sub base : Chained('/staff/base') PathPart('person') CaptureArgs(0) { ... }
sub list : Chained('base') PathPart('') Args(0) { ... }
sub item : Chained('base') PathPart('') CaptureArgs(1) { ... }
sub edit : Chained('item') Args(0) { ... }
Now if I say this:
c.uri_for_action('/person/edit', [42])
that will give me a URI that looks like this:
/app/person/42/edit
Here you can clearly see that the first argument refers to action
paths, not URIs. The URI is constructed out of the PathParts of
all the actions that participate in the chain.
> but it could be helpful to have such a thing in the core:
As you see, there already is. :-)
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: How to forward to a specific path
Hi Julien, * Julien Sobrier [2010-01-01 23:30]: > I'm try to do a forward to a path rather than a controller. For > example, if I get the url /foo/my/path, I want to redirect it > to /my/path which belongs to a different controller. this sounds like there may be a way to achieve the goal you are trying to achieve. What is your goal here? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: catalyst request path and apache rewrites
* William Wueppelmann [2009-12-18 14:40]:
> I have the following rules configured for my virtual host in
> apache:
>
> RewriteCond %{REQUEST_URI} !^/foo/bar
> RewriteRule ^/(.*)$ /foo/bar/$1 [PT]
Btw, this is most probably not going to affect your problem, but
anyway, you likely want to lose the RewriteCond and instead have
just
RewriteRule ^/(.*)$ /foo/bar/$1 [L,PT]
Just another mod_rewrite hacker,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Partial page cache plugin
* Tomas Doran [2009-12-08 01:05]: > I'd be happy with it _defaulting_ to use CHI in fact :) ++ Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Avoiding UTF8 in Catalyst
* Jonathan Rockway [2009-12-08 06:40]: > Basically, if you are doing things right, this code will cause > no harm Yes it will, in some cases. > (as the string will be an octet stream There is no such thing as an octet stream in Perl. There are only strings, and strings are sequences of arbitrarily large integers. You can store an octet stream in a string, which will then be a string that just happens to be a sequence of integers < 256, but it’s a string like any other, not specifically an octet sequence, and any string in Perl can internally have either form of internal representation. *Usually* after encoding a string will be a packed byte array… but that’s an implementation detail. > and bytes::length will return the length of the octet stream > you are about to send). This will work only if the string is using one of the two kinds of internal representation but not in the other. The case the OP had was that he wanted to send Latin-1 and his strings contained sequences of Latin-1 characters, which happen to be interchangeable with their octet representation. His strings were getting upgraded in the course of the code, which is hardly uncommon with Latin-1 strings and in fact is necessary in some cases. It should not have mattered that they were upgraded. Their content was semantically correct. But it did matter, because Catalyst::Engine used bytes::length, so forced the user to care about the internal representation. And you know what you said about the internal representation. > HTTP is a binary protocol, but people need to send text, so > there is an impedance mismatch. HTTP is a red herring. *All* forms of I/O have this mismatch. > But for now, trying hard to Do The Right Thing (instead of > causing weird web browser errors) is what we're stuck with. Nice ideal. Unfortunately you can’t. You can merely partially paper over one set of problems – only by creating another. I’m not saying that people who have broken apps should be told to take a hike. It might be nice to provide old workaround approach as a plugin for people who depended on that behaviour. It can be agonising to fix an app after the fact, as I know very well. I only recently cleaned up $job app in that regard, which still suffered the legacy of the days of Perl 5.6 and some very old DBD::mysql versions… and therefor required cleaning a database that contained arbitrarily mixed doubly- & triply-encoded data. So I put it off for as long as it could wait; other things took priority. It’s nice to have the option to wait until an opportune moment. But Catalyst shouldn’t in the meantime punish people who haven’t done anything wrong for the mistakes of other people. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Partial page cache plugin
Hi Julien, * Julien Sobrier [2009-12-06 09:10]: > there is a plugin for caching an entire page. I am looking for > the same type of plugin to cache part of the page, but did not > find one. uhm… Catalyst::Plugin::Cache? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] 2nd person plural (was: [ANNOUNCE] Catalyst-Runtime 5.80015)
* Bernhard Graf [2009-12-03 15:50]: > I really appreciate your(*) effort. > > (*) your = all contributors You could say “y’all’s effort”. ;-) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Unicode trouble with Catalyst::Engine::FastCGI
* Tomas Doran [2009-11-23 23:20]: > This probably means (I'm guessing) that the xs part of FCGI > doesn't correctly handle buffers which are characters rather > than bytes. That was my initial guess. > We can get this fixed, but not without test cases, and I'm > struggling to reproduce the issue here. > > Help? Glad that Bernhard stepped up because I’ve never used FCGI. :-) * Bernhard Graf [2009-11-24 13:40]: > As a quick fix, we could utf8::downgrade($buffer) in > Catalyst::Engine::FastCGI right before syswrite. Doesn't hurt, > as far as I understand. It wouldn’t even necessarily be a quick fix in this case, IMO. It would be preferrable to fix it in FCGI, but if the maintainer is gone and a new version is not likely to happen, then downgrading in the FastCGI engine would be the correct and proper fix. Any fix in the XS code would effectively imply a transient downgrade anyway. If the body string represents an encoded octet sequence, then downgrading will always succeed, as well. (If it’s not downgradeable, then the engine should probably throw an exception, as mentioned in the other thread.) Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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] Re: Unicode trouble with Catalyst::Engine::FastCGI
Hi Bernhard,
* Bernhard Graf [2009-11-23 20:00]:
> Aristotle Pagaltzis schrieb:
>
>>> While this fixes the problem, it is still unclear, why the
>>> utf8 flag is set for the whole buffer.
>>
>> It shouldn’t matter.
>
> But it does.
yes, because ::FastCGI is broken. :-) Is what I’m saying.
>>> So Ladies and Gentleman, may I present you the culprit? It
>>> is YAML::XS! Everything read by YAML::XS
>>>
>>> perl -MYAML::XS -E '
>>> my $config = YAML::XS::LoadFile("myapp.yml");
>>> say((utf8::is_utf8($config->{name}) ? "is" : "is not"), " utf8");
>>> '
>>> is utf8
>>
>> No, that’s not the culprit.
>>
>> The culprit is Catalyst::Engine::FastCGI, which does not pay
>> attention to the UTF8 flag.
>
> Obviously YAML::XS doesn't do that either.
It does. It sets the flag to correctly reflect the state of the
internal byte buffer of the scalar so that its string value will
mean the right thing.
> But aside from that I agree with you, that something ist broken
> in F(ast)CGI. It seems more that F(ast)CGI pays attention to
> the utf8 flag where it shouldn't, because it seems to
> automatically utf8::encode the buffer due to the set utf8 flag.
Ah, that may be, yeah, it would produce the result you are
seeing, and would clearly be broken. C::E::FastCGI should just
output the string as it is and let perl worry about its meaning,
rather than (if that’s what it does) checking the UTF8 flag
itself and doing something broken in response.
> > No. YAML::XS is completely correct.
>
> No, it is not. Because it claims:
>
> This module exports the functions Dump and Load. These
> functions are intended to work exactly like YAML.pm's
> corresponding functions.
>
> And that's not the case. And therefore you can't use it as
> a drop-in-replacement for other YAML modules.
Hmm. I guess it depends on whether think of “drop-in” as
something that replicates behaviour down to internal
implementation details, or just functions identically on the
semantic level. When I see a module advertise itself like that
I assume only the latter.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.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] Re: Avoiding UTF8 in Catalyst
* Bill Moseley [2009-11-23 20:10]: > I'd argue that when it's time to set the length it should die > if utf8 flag is still set. I’m of two minds about this… it may well be that a string is correctly encoded but has gotten upgraded, and such a string will produce the right output anyhow. I don’t know if it’s not too stringent to demand that the UTF8 flag be off. However, the string should be *downgradeable* by that time. If there are wide characters in it at that time, then throwing an exception is absolutely the right thing to do. But if there aren’t, then you can’t decide based on the UTF8 flag whether the string is correct or not. As I wrote, you can read a binary file, upgrade the string, and output it right back, and you’ll get an identical copy of the file out of that, because a string means one and the same thing regardless of whether it’s upgraded. > When calculating the length the content should have already > been encoded. Yes. > Again, at some point decoding and encoding should be core not > just a plugin. It's an important part of the request cycle. I agree. Although it’s difficult to make it fully automatic because browsers suck so bad about telling you what encoding the data that they’re sending is in. I am working on a plugin for that, but due to its dependencies and API I don’t know if it’d be reasonable to make it core. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.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/
