On Fri, May 08, 2009 at 04:08:29PM +0400, Oleg Pronin wrote:
> Catalyst and controllers are the same. Catalyst imho is _not only web_
> framework.
You can beat a nail in with a screwdriver too.
More seriously, I'd really like to split out the bits of Catalyst that are
"application framework" rath
Tomas Doran wrote:
>> I'd recommend making a TestApp, pulling the relevant bits of
>> controller code out (the bodies can be mostly blank, you only care
>> about the paths), setting up trivial auth (no DB or anything needed,
>> just use Auth::Store::Minimal), and see if you can replicate the issu
OK. I'll pull out some clear code examples.
Thanks
Tomas Doran wrote:
Ascii King wrote:
the authorization component of my application no longer works
properly. Did something change with Catalyst::Plugin::Authorization?
I searched the lists, but I didn't see anything.
The tests still all p
Ascii King wrote:
the authorization component of my application no longer works properly.
Did something change with Catalyst::Plugin::Authorization? I searched
the lists, but I didn't see anything.
The tests still all pass, and they do test this sort of thing.
When testing the above stateme
Oleg Pronin wrote:
But in TCP stream we send for example "/chess/action/make_move {JSON_DATA}"
I do not see any differences between HTTP requests and request to the
daemon. Just protocols are differ.
If you're doing something like this, then the correct solution _is_ to
be subclassing Catalys
Oleg Pronin wrote:
How do i should in this case read my config in script context?
use Config::General manually..
MyApp
initializes everything - memcached, dbic, uuid, json, etc.
Erm, yes, your config is gonna have memcached and dbic connection info
in it..
I wasn't aware that generating
P.S.
Tomas, you explain things from position of most web sites. But imagine for
example multiplayer gaming portal written in flash.
Flash sends request through HTTP as well as through TCP stream connection
(for gaming purposes).
TCP connections served by daemon (not by Catalyst::Engine::* of course
2009/5/8 Tomas Doran
> Oleg Pronin wrote:
>
>> Not really :-) While in request, browser header is ok, but the task is to
>> be able to authenticate in offline scripts as well - because the controllers
>> and etc read logged in user from $c->user.
>> Currently we use workaround - fake $c object +
Oleg Pronin wrote:
Not really :-) While in request, browser header is ok, but the task is
to be able to authenticate in offline scripts as well - because the
controllers and etc read logged in user from $c->user.
Currently we use workaround - fake $c object + setup $c->request->header
for base
2009/5/8 Tomas Doran
> Oleg Pronin wrote:
>
>> I've got problem with new Authentication too. It is said that one can pass
>> login & password to authenticate call. But it somewhy no longer
>> authenticates that way (in case of Credential::HTTP)
>>
>
> Credential::HTTP doesn't work like that.
>
>
Oleg Pronin wrote:
I've got problem with new Authentication too. It is said that one can
pass login & password to authenticate call. But it somewhy no longer
authenticates that way (in case of Credential::HTTP)
Credential::HTTP doesn't work like that.
The credentials for HTTP auth come from t
I've got problem with new Authentication too. It is said that one can pass
login & password to authenticate call. But it somewhy no longer
authenticates that way (in case of Credential::HTTP)
2009/5/7 Ascii King
> the authorization component of my application no longer works properly. Did
> some
the authorization component of my application no longer works properly.
Did something change with Catalyst::Plugin::Authorization? I searched
the lists, but I didn't see anything.
My authorization code came from the Catalyst tutorial and I'm pretty
sure it used to work. However, I started doin
13 matches
Mail list logo
