Re: [Catalyst] Catalyst::View::JSON sends a file

[Toby Corkindale]

Tomas Doran wrote:


On 11 Jan 2010, at 23:29, Christoph Friedrich wrote:
just worked a little with Catalyst::View::JSON. But when I call some 
action via Firefox that uses this View Firefox gives me a file to 
download and don't show the json directly.
Is there a way to change this behavior? I want to see what I would get 
as JSON and not download it ^^


Your browser will do whatever it normally does with the mime type you're 
sending.


By changing settings or mime types you'll probably be able to convince 
it to display the JSON.


You could also adjust the $c->response->content_type() to be 'text/plain'.
But watch out, as some javascript libraries decide what to do with the 
response based on it's content-type, and will not JSON-decode what it 
thinks is html or plain text.


However, why not write a JSON debug view that pretty prints JSON 
responses inside an HTML page?


Definitely the better option.

Or learn to get into the Firefox or Chrome javascript debuggers.. well 
worth having that skill.


Toby

___
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::View::JSON sends a file

[Alan Humphrey]

> -Original Message-
> From: Christoph Friedrich [mailto:christ...@christophfriedrich.de]
> Sent: Monday, January 11, 2010 3:29 PM
> To: The elegant MVC web framework
> Subject: [Catalyst] Catalyst::View::JSON sends a file
> 
> Hello there,
> 
> just worked a little with Catalyst::View::JSON. But when I call some
> action via Firefox that uses this View Firefox gives me a file to
> download and don't show the json directly.
> Is there a way to change this behavior? I want to see what I would get
> as JSON and not download it ^^
> 
> Greets
> Christoph
> 

Use firebug.  The Console tab will show you the GET as well as the response.

- Alan


___
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] [ANNOUNCE] Catalyst-Runtime 5.80017

[Toby Corkindale]

Has anyone else had trouble getting this installed, due to the 
dependency on Class::MOP 0.97?

I can't get class mop to install in my local lib - keeps dying with:

Not a HASH reference at /usr/share/perl/5.10/ExtUtils/Install.pm line 557.
make: *** [pure_site_install] Error 2

I'll report back on whether the "make catalyst_par" bug from 5.8.16 is 
still present once I get it installed..


ta,
Toby

Florian Ragwitz wrote:

I'm happy to announce the next release of Catalyst-Runtime (5.80017).

This release mainly cures all issues reported with upgraded scripts (or
applications generated with the latest release of Catalyst::Devel) and
makes Catalyst compatible with upcomming versions of Moose.

This release also started being more strict about the deprecated usage
of NEXT. We're not surpressing any Class::C3::Adopt::NEXT warnings
anymore. See the changelog for details.

Full changelog included below as always.

Cheers
rafl

--
5.80017 2010-01-10 02:27:29

  Documentation:
   - Fix docs for ->forward method when passed a class name - this should
 be a component name (e.g. View::HTML, not a full class name, like
 MyApp::View::HTML).

  Bug fixes:
   - --daemon and -d options to Catalyst::Script::FastCGI are fixed.
   - Fix the debug dump for applications which use Catalyst::Plugin::Session
 (RT#52898)
   - Fix regression in the case where mod_rewrite is being used to rewrite
 requests into a path below your application base introduced with the
 %2F related fixes in 5.80014_02.
   - Do not crash on SIGHUP if Catalyst::Engine::HTTP->run is not passed the
 argv key in the options hash.
   - Correctly pass the arguments to Catalyst::Script::Server through to
 Catalyst::Engine::HTTP->run so that the server can restart itself
 with the correct options on SIGHUP.
   - Require new MooseX::MethodAttributes to be compatible with Moose
 versions >= 0.93_01
   - Require new MooseX::Role::WithOverloading to be compatible with Moose
 versions >= 0.93_01

  Cleanups:
- Stop suppressing warnings from Class::C3::Adopt::NEXT now that most 
plugins
  have been updated to not use NEXT. If you get warnings then please upgrade
  your components or log a bug with the component author if an upgrade is
  not available. The Class::C3::Adopt::NEXT documentation contains 
information
  about how to suppress the warnings in your application if you need 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/



--
Strategic Data Pty Ltd
Ph: 03 9340 9000

___
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::View::JSON sends a file

[Tomas Doran]

On 11 Jan 2010, at 23:29, Christoph Friedrich wrote:
just worked a little with Catalyst::View::JSON. But when I call some  
action via Firefox that uses this View Firefox gives me a file to  
download and don't show the json directly.
Is there a way to change this behavior? I want to see what I would  
get as JSON and not download it ^^


Your browser will do whatever it normally does with the mime type  
you're sending.


By changing settings or mime types you'll probably be able to convince  
it to display the JSON.


However, why not write a JSON debug view that pretty prints JSON  
responses inside an HTML page?


Cheers
t0m


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

Re: [Catalyst] Dynamic Argument count

[Tomas Doran]

On 11 Jan 2010, at 23:00, Christoph Friedrich wrote:

following given:

URL: http://localhost:3000/guild/myrealm/myguild
=> Controller: guild
=> Action: list_guilds (chained, CaptureArgs(2))

URL: http://localhost:3000/guild/myrealm/myguild/ajax
=> Controller: guild
=> Action: list_guilds (chained, CaptureArgs(3))


^^ Erm, this doesn't make much sense - you're not showing what things  
are chained to, which makes a big difference..


My problem is following: I want to add the parameter "ajax" (for  
example) directly to the url and not as a query parameter. Is there  
a possible way or do I have to add this parameter to the query?


sub base : Chained('/') PathPart('/guild') CaptureArgs(2) {}
sub list_guilds : Chained('base') PathPart('') Args(0) {}
sub list_guilds_ajax : Chained('base') PathPart('ajax') Args(0) {}

Is that what you want?

Cheers
t0m


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

[Catalyst] Catalyst::View::JSON sends a file

[Christoph Friedrich]

Hello there,

just worked a little with Catalyst::View::JSON. But when I call some 
action via Firefox that uses this View Firefox gives me a file to 
download and don't show the json directly.
Is there a way to change this behavior? I want to see what I would get 
as JSON and not download it ^^


Greets
Christoph

___
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] Dynamic Argument count

[Christoph Friedrich]

Hello there,

following given:

URL: http://localhost:3000/guild/myrealm/myguild
=> Controller: guild
=> Action: list_guilds (chained, CaptureArgs(2))

URL: http://localhost:3000/guild/myrealm/myguild/ajax
=> Controller: guild
=> Action: list_guilds (chained, CaptureArgs(3))

My problem is following: I want to add the parameter "ajax" (for 
example) directly to the url and not as a query parameter. Is there a 
possible way or do I have to add this parameter to the query?


Greets
Christoph

___
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] Bugzilla REST API in Catalyst

[Kiffin Gish]

Yeah, that's more like it.

On Mon, 2010-01-11 at 14:34 -0500, Hans Dieter Pearcey wrote:
> Excerpts from Gervase Markham's message of Mon Jan 11 09:10:38 -0500 2010:
> > hg co http://hg.mozilla.org/webtools/bzapi bzapi
> 
> that's 
> 
>   hg clone http://hg.mozilla.org/webtools/bzapi bzapi
> 
> I suspect.
> 
> hdp.
> 
> ___
> 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/


-- 
Kiffin Gish 
Gouda, The Netherlands



___
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] Bugzilla REST API in Catalyst

[Hans Dieter Pearcey]

Excerpts from Gervase Markham's message of Mon Jan 11 09:10:38 -0500 2010:
> hg co http://hg.mozilla.org/webtools/bzapi bzapi

that's 

  hg clone http://hg.mozilla.org/webtools/bzapi bzapi

I suspect.

hdp.

___
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] Bugzilla REST API in Catalyst

[Kiffin Gish]

I'm not familiar with Mecurial and can't get hg to run correctly.

Do you think you could just create a standard dist and make the tarball
available for download?

On Mon, 2010-01-11 at 14:10 +, Gervase Markham wrote:
> On 11/01/10 12:28, Kiffin Gish wrote:
> > Although I'm less a Catalyst expert than many folks on this mailing
> > list, I do have experience designing REST APIs, so I'd be happy/curious
> > to have a look at it.
> 
> Thank you :-) I really appreciate it. Here are the details, in case
> anyone else also wants to provide much-appreciated feedback.
> 
> If someone just wants to comment on the API design, you can probably do
> that simply by reading the docs.
> 
> Code:
> 
> hg co http://hg.mozilla.org/webtools/bzapi bzapi
> 
> or browse online at
> http://hg.mozilla.org/webtools/bzapi/
> 
> Test Installation:
> 
> You can browse the API with a web browser, getting YAML-HTML back, at:
> https://api-dev.bugzilla.mozilla.org/latest/
> (e.g. https://api-dev.bugzilla.mozilla.org/latest/bug/35)
> 
> Documentation:
> 
> https://wiki.mozilla.org/Bugzilla:REST_API
> https://wiki.mozilla.org/Bugzilla:REST_API:Methods
> https://wiki.mozilla.org/Bugzilla:REST_API:Search
> https://wiki.mozilla.org/Bugzilla:REST_API:Objects
> https://wiki.mozilla.org/Bugzilla:REST_API:Objects:Configuration
> https://wiki.mozilla.org/Bugzilla:REST_API:HowTo
> 
> Thank you again!
> 
> Gerv


-- 
Kiffin Gish 
Gouda, The Netherlands



___
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] Bugzilla REST API in Catalyst

[Gervase Markham]

On 11/01/10 12:28, Kiffin Gish wrote:
> Although I'm less a Catalyst expert than many folks on this mailing
> list, I do have experience designing REST APIs, so I'd be happy/curious
> to have a look at it.

Thank you :-) I really appreciate it. Here are the details, in case
anyone else also wants to provide much-appreciated feedback.

If someone just wants to comment on the API design, you can probably do
that simply by reading the docs.

Code:

hg co http://hg.mozilla.org/webtools/bzapi bzapi

or browse online at
http://hg.mozilla.org/webtools/bzapi/

Test Installation:

You can browse the API with a web browser, getting YAML-HTML back, at:
https://api-dev.bugzilla.mozilla.org/latest/
(e.g. https://api-dev.bugzilla.mozilla.org/latest/bug/35)

Documentation:

https://wiki.mozilla.org/Bugzilla:REST_API
https://wiki.mozilla.org/Bugzilla:REST_API:Methods
https://wiki.mozilla.org/Bugzilla:REST_API:Search
https://wiki.mozilla.org/Bugzilla:REST_API:Objects
https://wiki.mozilla.org/Bugzilla:REST_API:Objects:Configuration
https://wiki.mozilla.org/Bugzilla:REST_API:HowTo

Thank you again!

Gerv

___
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] Bugzilla REST API in Catalyst

[Kiffin Gish]

Although I'm less a Catalyst expert than many folks on this mailing
list, I do have experience designing REST APIs, so I'd be happy/curious
to have a look at it.

On Mon, 2010-01-11 at 11:44 +, Gervase Markham wrote:
> Dear Catalyst community,
> 
> Summary: I'm hoping to find a kind Catalyst expert who can spend an hour
> telling me which bits of Catalyst my open source project badly misuses,
> and give me pointers on how to do things better.
> 
> Background: I've been using Catalyst for my latest open source project.
> It's an HTTP REST API for Bugzilla, but implemented as a proxy to
> decouple it from Bugzilla's update schedule so I can do rapid
> development and prototyping of various API approaches. So the idea is,
> basically, that there's this nice REST API on the front, and all the
> nasty XML and CSV parsing/screen scraping happens on the back where the
> API user doesn't have to worry about it. It uses
> Catalyst::Controller::REST. It's about 2 thousand lines of code all
> together.
> 
> This is something that lots of people in the Mozilla project have been
> screaming for, because they want to do cool innovative webby mash-up
> type things with Bugzilla data. And I can see it being useful to many of
> the other hundreds of projects who use Bugzilla too. Once the API is
> stable, it'll eventually get implemented on top of Bugzilla itself. So
> that'll be the same, but just faster.
> 
> Aaaanyway... it's my first Catalyst app, and I'm sure I've architected a
> bunch of stuff wrong.
> 
> Question: Is there anyone out there willing to do a new open source
> project, the Mozilla project, and lots of other Bugzilla-using people a
> big favour and take an hour or two to get the code from Hg, cast an
> experienced and beady eye over it, and send me a mail that says things
> like "your URL dispatching is stuffed; this is what you should do",
> "you've crammed all that data munging into the Model, whereas it should
> be in...", "you really should have a proper log for API transactions,
> like this..." and so on?
> 
> This thing may have to scale up fairly high, so knowing the foundations
> are solid would be a great comfort to me. I and the Mozilla project
> would be very grateful :-) Do let me know if you might be able to help.
> 
> Thanks,
> 
> Gerv
> 
> ___
> 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/


-- 
Kiffin Gish 
Gouda, The Netherlands


___
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] Bugzilla REST API in Catalyst

[Gervase Markham]

Dear Catalyst community,

Summary: I'm hoping to find a kind Catalyst expert who can spend an hour
telling me which bits of Catalyst my open source project badly misuses,
and give me pointers on how to do things better.

Background: I've been using Catalyst for my latest open source project.
It's an HTTP REST API for Bugzilla, but implemented as a proxy to
decouple it from Bugzilla's update schedule so I can do rapid
development and prototyping of various API approaches. So the idea is,
basically, that there's this nice REST API on the front, and all the
nasty XML and CSV parsing/screen scraping happens on the back where the
API user doesn't have to worry about it. It uses
Catalyst::Controller::REST. It's about 2 thousand lines of code all
together.

This is something that lots of people in the Mozilla project have been
screaming for, because they want to do cool innovative webby mash-up
type things with Bugzilla data. And I can see it being useful to many of
the other hundreds of projects who use Bugzilla too. Once the API is
stable, it'll eventually get implemented on top of Bugzilla itself. So
that'll be the same, but just faster.

Aaaanyway... it's my first Catalyst app, and I'm sure I've architected a
bunch of stuff wrong.

Question: Is there anyone out there willing to do a new open source
project, the Mozilla project, and lots of other Bugzilla-using people a
big favour and take an hour or two to get the code from Hg, cast an
experienced and beady eye over it, and send me a mail that says things
like "your URL dispatching is stuffed; this is what you should do",
"you've crammed all that data munging into the Model, whereas it should
be in...", "you really should have a proper log for API transactions,
like this..." and so on?

This thing may have to scale up fairly high, so knowing the foundations
are solid would be a great comfort to me. I and the Mozilla project
would be very grateful :-) Do let me know if you might be able to help.

Thanks,

Gerv

___
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

[Aristotle Pagaltzis]

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

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