Re: [Catalyst] C::C::FormBuilder question

[Carl Franks]

On 29/01/07, Marc Logghe <[EMAIL PROTECTED]> wrote:



Hi all,
I am lost.
In my conf I have:
# configuration of FormBuilder
Controller::FormBuilder:
method_name: form
template_type: Mason
stash_name: form
obj_name: fb
form_suffix: fb
attr_name: Form
form_path: __path_to(forms)__

In the mason template:
<% $form->render %>
<%args>
 $form => undef


The error I get:
Couldn't render component "/moe/mol_3D_conv_form" - error was "Can't call
method "render" on an undefined value ...
I was convinced that C::C::FormBuilder automagically sets
$c->stash->{}, but it seems not to be the case (btw: calling
$c->stash->{form} gives the same error).
Do you have to assign your fb object manually in the controller ? And if so,
what is the purpose of the 'stash_name' conf setting ??
I am afraid I am missing something teriibly.


I was just looking at this last week, as I was using the code as a
basis for a new controller. I suspect that it's never been tested,
because as far as I can tell, it incorrectly reads the config from the
controller object, rather than the application object.

in sub "new",
 $self->__setup();
should be
 $self->__setup($c);

and in sub "__setup",
   my $self   = shift;
   my $config = $self->config->{'Controller::FormBuilder'} || {};
should be:
   my ( $self, $c ) = @_;
   my $config = $c->config->{'Controller::FormBuilder'} || {};

Cheers,
Carl

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

[Catalyst] Re: Tweaking REST

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2007-01-29 20:10]:
> As for RSS/Atom, I'd need a Serializer for them, which in the
> end isn't really different than writing a view.

I have a nice module for Atom. :-)

Any reason why you want to generate both RSS and Atom? (And which
version of RSS are you talking about?)

Regards,
-- 
Aristotle Pagaltzis // 

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

Re: [Catalyst] C::C::FormBuilder question

[Tobias Kremer]

> I was just looking at this last week, as I was using the code as a
> basis for a new controller. I suspect that it's never been tested,
> because as far as I can tell, it incorrectly reads the config from the
> controller object, rather than the application object.

Yeah, I stumbled across this the other day but was unsure if it was
done on purpose (for a controller-specific configuration rather than a
global config). Nevertheless I found it awkward and IMHO it should be changed.

--Tobias

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

Re: [Catalyst] Field types and Sybase

[Matt S Trout]

On 29 Jan 2007, at 17:46, Jonathan Batchelor wrote:

I have a problem with one of the field types set up in my Database  
and wondered if anyone can help me to define it within my model  
properly. The error I get is as follows:


Caught exception in ReCharge::Controller::Contracts->url_create  
"DBIx::Class::ResultSet::create():


http://lists.rawmode.org/mailman/listinfo/dbix-class/

This is nothing to do with Catalyst, really, and our various list  
archives get confusing enough as it is :)

--
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +




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

Re: [Catalyst] Hair-pulling over YAML config

[Carl Vincent]

>Message: 10
>Date: Mon, 29 Jan 2007 19:49:29 +0100
>From: "A. Pagaltzis" <[EMAIL PROTECTED]>
>Subject: [Catalyst] Re: Hair-pulling over YAML config
>To: The elegant MVC web framework 
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=utf-8
>
>* Joel Bernstein <[EMAIL PROTECTED]> [2007-01-29 18:30]:
>> I think the difficulty here is that Config::Any::_load has the
>> potential if running without use_ext=>1 to generate a lot of
>> spurious warnings caused by all the plugins to which a given
>> config file is offered, but which can't parse the file. So any
>> patch would presumably only report warnings if use_ext=>1. But
>> that still doesn't seem ideal. Suggestions?
>
>Just warn if the file fails with *all* parsers. We’ve got a
>config file; we can reasonably assume that one of the parsers
>will be able to make sense of it. If none of them can, since
>it’s still a config file, it’s obviously a broken one.

That's exactly what we need - outputting warnings at on of the ConfigLoader 
levels loses the content of the error message. Could always add a "Keep Quiet" 
option...

Cheers

Carl

-- 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Carl Vincent http://www.netskills.ac.uk/ (URL)
 Systems Manager   0191 222 5003 (voice)
 Netskills, Newcastle University   0191 222 5001  (fax)
 Training  —  Accreditation  -  Consultancy  —  Development
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/

Re: [Catalyst] Hair-pulling over YAML config

[Chisel Wright]

On Tue, Jan 30, 2007 at 09:58:00AM -, Carl Vincent wrote:
> That's exactly what we need - outputting warnings at on of the
> ConfigLoader levels loses the content of the error message. Could
> always add a "Keep Quiet" option...

To be read from the unparsable/invalild config file? ;-)

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

  This is not an automated signature.
  I type this in to the bottom of every message.

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

Re: [Catalyst] Tweaking REST

[Kieren Diment]

On 30/01/07, Adam Jacob <[EMAIL PROTECTED]> wrote:


>> On top of that, I want things to also work by
>> extension: .json, .atom,
>> .rss etc. That's where C::P::Flavour enters the picture.

I thought about that.  I have never seen Catalyst::Plugin::Flavour
(it doesn't look like it has a CPAN release, nor is it in the
Catalyst repo.)  Currently, C::A::REST supports using a content-type
argument on GET requests to over-ride the serializer.  It would be
pretty simple to just add the logic for the extension mapping to work
as well




um
http://search.cpan.org/author/TYPESTER/Catalyst-Plugin-Flavour-0.03/lib/Catalyst/Plugin/Flavour.pm

and

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

Re: [Catalyst] Tweaking REST

[Christopher H. Laco]

Adam Jacob wrote:
> On Jan 29, 2007, at 12:19 PM, Christopher H. Laco wrote:
> 
>> Christopher H. Laco wrote:
>>> I'm needing to support RSS/Atom feeds of some of my cart/wishlist data.
>>> The lazy guy in me says I can just make a view or two and be done with
>>> it (Thanks for the code LTjake!). The anal retentive programmer in me
>>> says I probably really want to use C::A::REST to get the benefit of
>>> mime-type request mapping and de/serialization for other things that
>>> might come along, like json/yaml.
> 
> Adding RSS/Atom is, as you say, just adding a proper serialization class
> for the data.
> 
>>> On top of that, I want things to also work by extension: .json, .atom,
>>> .rss etc. That's where C::P::Flavour enters the picture.
> 
> I thought about that.  I have never seen Catalyst::Plugin::Flavour (it
> doesn't look like it has a CPAN release, nor is it in the Catalyst
> repo.)  Currently, C::A::REST supports using a content-type argument on
> GET requests to over-ride the serializer.  It would be pretty simple to
> just add the logic for the extension mapping to work as well
> 
>>> As it stands now, REST JustWorks with xml/json stuff. text/html is
>>> mapped to YAML::HTML, but I want to map that to my standard TT view. As
>>> for RSS/Atom, I'd need a Serializer for them, which in the end isn't
>>> really different than writing a view.
> 
> I think you nail that problem lower down.  We should totally make a
> C::A::Serialize::View.

Yeah, I eeked this out yesterday while tinkering with the idea:

> package Catalyst::Action::Serialize::View;
> use strict;
> use warnings;
> 
> BEGIN {
> use base 'Catalyst::Action';
> };
> 
> sub execute {
> my $self = shift;
> my ($controller, $c, $view) = @_;
> my $stash_key = $controller->config->{'serialize'}->{'stash_key'} || 
> 'rest';
> 
> if (!$c->view($view)) {
> $c->log->debug("Could not load $view, refusing to serialize");
> return 0;
> };
> 
> return $c->view($view)->process($c);
> };
> 
> 1;


There are still some issues with using views, mainly that they both
fight of setting content-type...and since REST sets it already, the view
never sets it, which is good, but also the charset=utf isn't set either...

Once I get something more solid, I'll post what I have.

-=Chris



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

Re: [Catalyst] Re: Tweaking REST

[Christopher H. Laco]

A. Pagaltzis wrote:
> * Christopher H. Laco <[EMAIL PROTECTED]> [2007-01-29 20:10]:
>> As for RSS/Atom, I'd need a Serializer for them, which in the
>> end isn't really different than writing a view.
> 
> I have a nice module for Atom. :-)
> 
> Any reason why you want to generate both RSS and Atom? (And which
> version of RSS are you talking about?)

Because while I prefer Atom, other users of the software may prefer to
server RSS instead. As for version, probably 2.0, or whatever XML::Feed
spits out.

-=Chris



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

Re: [Catalyst] Tweaking REST

[Christopher H. Laco]

> There are still some issues with using views, mainly that they both
> fight of setting content-type...and since REST sets it already, the view
> never sets it, which is good, but also the charset=utf isn't set either...

Just to solidify that statement...

__load_content_plugins sets the response content type to the strict
mapping itself sans the charset= part. Things like the TT view add the
charset=utf-8 if not encoding is set, but it already is, but that gets
trashed between the two, making using REST + UTF-8 producing views a
pita at first, and setting content_encoding makes no difference in some
browsers.

Ultimately, doing this in the views template does the right thing:

> [% CALL c.response.content_type('text/html; charset=utf-8') -%]

or

> [% CALL c.response.content_type('text/plain; charset=utf-8') -%]


which imho is the better option, since each individual template
file/view may even use a different encoding...each view can tweak the
encoding, and not rely in the magic inner workings of REST when using views.

-=Chris



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

[Catalyst] DBIx virtual columns depending on database column

[Ulrich Leodolter]

Hi

I working on a database frontend using Catalyst, DBIx and all the other
goodies.

The schema is loaded from existing MySQL database using
DBIx::Class::Schema::Loader and Catalyst::Model::DBIC::Schema

The database is not DBIx::Class friendly (multi pk and other things)
but my Catalyst/DBIx setup basically works.
There are many perl scripts (CGI,DBI,print) building an active web
application, so changing the database is currently not an option.

One bad thing is a table having a column person_ids which stores one,two
or three primary keys from another table called person, the keys are
separated by space.

I could write some code to iterate over search results, but i would
like to integrate it into my database model/schema.

I think about virtual columns person1,person2,person3 and
setup relationship for these columns.

How can this be done?

Thanks
Ulrich






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

Re: [Catalyst] C::C::FormBuilder question

[Juan Camacho]

On 1/30/07, Tobias Kremer <[EMAIL PROTECTED]> wrote:

> I was just looking at this last week, as I was using the code as a
> basis for a new controller. I suspect that it's never been tested,
> because as far as I can tell, it incorrectly reads the config from the
> controller object, rather than the application object.

Yeah, I stumbled across this the other day but was unsure if it was
done on purpose (for a controller-specific configuration rather than a
global config). Nevertheless I found it awkward and IMHO it should be changed.

--Tobias


It was done somewhat on purpose since configuring it via the
controller was how I use it. I would be happy to accept a patch to
make it read from both places.  Just make sure existing tests continue
to pass and work off the version that's up on subversion at
http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Controller-FormBuilder/

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

Re: [Catalyst] DBIx virtual columns depending on database column

[Matt S Trout]

On 30 Jan 2007, at 16:38, Ulrich Leodolter wrote:


Hi

I working on a database frontend using Catalyst, DBIx and all the  
other

goodies.

The schema is loaded from existing MySQL database using
DBIx::Class::Schema::Loader and Catalyst::Model::DBIC::Schema

The database is not DBIx::Class friendly (multi pk and other things)


Erm. DBIx::Class has supported multi pks happily from 0.01, and was  
designed to not care whether your primary key was one or more than  
one column before I wrote a single line of code.


Class::DBI and ActiveRecord might not handle this but DBIx::Class is  
fine :)


It also has its own mailing list, dbix-class on the same list server  
as this one - you'll probably get a better response asking there.


--
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +




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

Re: [Catalyst] C::C::FormBuilder question

[Matt S Trout]

On 30 Jan 2007, at 09:07, Tobias Kremer wrote:


I was just looking at this last week, as I was using the code as a
basis for a new controller. I suspect that it's never been tested,
because as far as I can tell, it incorrectly reads the config from  
the

controller object, rather than the application object.


Yeah, I stumbled across this the other day but was unsure if it was
done on purpose (for a controller-specific configuration rather than a
global config). Nevertheless I found it awkward and IMHO it should  
be changed.


Why can't you just use a common base class for any controllers that  
need the same defaults?


--
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +




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

Re: [Catalyst] C::C::FormBuilder question

[Matt S Trout]

On 30 Jan 2007, at 08:48, Carl Franks wrote:

I was just looking at this last week, as I was using the code as a
basis for a new controller. I suspect that it's never been tested,
because as far as I can tell, it incorrectly reads the config from the
controller object, rather than the application object.


That's what it's supposed to do! This is a feature, not a bug - and  
the fact that all the plugin-style ones (HW, DFV etc.) use global  
config if frankly a bug in *them* since it makes code re-use much  
harder.


If you need common defaults, use a controller base class. Works  
beautifully.


--
Matt S Trout, Technical Director, Shadowcat Systems Ltd.
Offering custom development, consultancy and support contracts for  
Catalyst,
DBIx::Class and BAST. Contact mst (at) shadowcatsystems.co.uk for  
details.
+ Help us build a better perl ORM: http://dbix- 
class.shadowcatsystems.co.uk/ +




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

Re: [Catalyst] Tweaking REST

[Adam Jacob]

On Jan 30, 2007, at 7:13 AM, Christopher H. Laco wrote:


There are still some issues with using views, mainly that they both
fight of setting content-type...and since REST sets it already,  
the view
never sets it, which is good, but also the charset=utf isn't set  
either...


Just to solidify that statement...

__load_content_plugins sets the response content type to the strict
mapping itself sans the charset= part. Things like the TT view add the
charset=utf-8 if not encoding is set, but it already is, but that gets
trashed between the two, making using REST + UTF-8 producing views a
pita at first, and setting content_encoding makes no difference in  
some

browsers.

Ultimately, doing this in the views template does the right thing:


[% CALL c.response.content_type('text/html; charset=utf-8') -%]


or


[% CALL c.response.content_type('text/plain; charset=utf-8') -%]



which imho is the better option, since each individual template
file/view may even use a different encoding...each view can tweak the
encoding, and not rely in the magic inner workings of REST when  
using views.


Makes sense to me.

One thing to watch out for if you are combining the REST stuff with  
other bits; the Accept header parsing.  You're liable to need to map:


text/xml
application/xml
application/xhtml+xml
text/html

To something a browser can understand.  Firefox ranks all four of  
those content-types equally, but (if I remember correctly) we process  
them in order.. so if you can do text/xml, and we can speak it, we'll  
do it.


This may need to be a tweakable switch in C::A::REST... something like:

'accept_prefer' => [ 'text/html', 'application/xhtml+xml',  
'application/xml', 'text/xml' ];


I'll add this to the todo list; if you don't get to it, I probably will.

Adam



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

Re: [Catalyst] Tweaking REST

[Adam Jacob]

Yeah, I totally spaced it.  I was spelling "Flavor" instead of  
"Flavour".


Silly english.

Adam

On Jan 30, 2007, at 2:29 AM, Kieren Diment wrote:




On 30/01/07, Adam Jacob <[EMAIL PROTECTED]> wrote:
>> On top of that, I want things to also work by
>> extension: .json, .atom,
>> .rss etc. That's where C::P::Flavour enters the picture.

I thought about that.  I have never seen Catalyst::Plugin::Flavour
(it doesn't look like it has a CPAN release, nor is it in the
Catalyst repo.)  Currently, C::A::REST supports using a content-type
argument on GET requests to over-ride the serializer.  It would be
pretty simple to just add the logic for the extension mapping to work
as well


um http://search.cpan.org/author/TYPESTER/Catalyst-Plugin- 
Flavour-0.03/lib/Catalyst/Plugin/Flavour.pm


and

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

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

Dev site: http://dev.catalyst.perl.org/


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

Re: [Catalyst] C::C::FormBuilder question

[Juan Camacho]

On 1/29/07, Marc Logghe <[EMAIL PROTECTED]> wrote:

Actually, the docs give a TT example:
[% FormBuilder.render %]
And therefore in TT it is not clear whether it is a variable or a
package name. Anyways, I tried it with the package name in Mason as well
(FormBuilder->render, Catalyst::Controller::FormBuilder->render, ):
nope. 99% sure in the TT example 'FormBuilder' is a variable, not a
package name.
It seems to work only when I do the assignment in the controller:
$c->stash->{form} = $self->form;

In Mason template:
<% $form->render %>

No magic...


by default C-C-FormBuilder does the equivalent of this:

  $c->stash->{FormBuilder} = CGI::FormBuilder->new(\%attr)

If instead you want it to be $c->stash->{form} set obj_name config variable:

obj_name:
   Not applicable for HTML::Template view. By default, it is
FormBuilder. e.g. $c->stash->{FormBuilder} = $formbuilder.

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

Re: [Catalyst] Hair-pulling over YAML config

[Jonathan Rockway]

Chisel Wright wrote:
> On Tue, Jan 30, 2007 at 09:58:00AM -, Carl Vincent wrote:
>> That's exactly what we need - outputting warnings at on of the
>> ConfigLoader levels loses the content of the error message. Could
>> always add a "Keep Quiet" option...
> 
> To be read from the unparsable/invalild config file? ;-)

If the config file was parsed OK there's no need to report errors.
Because there weren't any.

-- 
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;

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

Re: [Catalyst] Re: Tweaking REST

[Jonathan Rockway]

> As for version, probably 2.0, or whatever XML::Feed
> spits out.

Which version of RSS 2.0?  Google for RSS 2.0 and you'll find it's a
nightmare.  Multiple versions with the same version number, inability to
embed HTML properly etc.  Nightmare, nightmare, nightmare.  Use an
"older" (RSS 2.0 isn't the newest) RSS version or use Atom.

On second thought, just use Atom.  It's an IETF standard and everything
supports it now.

-- 
package JAPH;use Catalyst qw/-Debug/;($;=JAPH)->config(name => do {
$,.=reverse qw[Jonathan tsu rehton lre rekca Rockway][$_].[split //,
";$;"]->[$_].q; ;for 1..4;$,=~s;^.;;;$,});$;->setup;

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

Re: [Catalyst] Re: Tweaking REST

[Christopher H. Laco]

Jonathan Rockway wrote:
>> As for version, probably 2.0, or whatever XML::Feed
>> spits out.
> 
> Which version of RSS 2.0?  Google for RSS 2.0 and you'll find it's a
> nightmare.  Multiple versions with the same version number, inability to
> embed HTML properly etc.  Nightmare, nightmare, nightmare.  Use an
> "older" (RSS 2.0 isn't the newest) RSS version or use Atom.
> 
> On second thought, just use Atom.  It's an IETF standard and everything
> supports it now.
> 

Again, the decisions isn't mine, but the person using my software. If
they want to server RSS, that's their issue. Whatever XML::Feed spits
out, it it's issue.

In either case, NMP. :-)



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

[Catalyst] Re: Tweaking REST

[Greg McAlpin]

I would very much appreciate feedback on my approach to using my TT view with 
REST.  I'm just playing with the AdventREST example trying to understand the 
whole REST thing.
   
  I created a class (lib/AdventREST/MyREST.pm) for my controllers to inherit 
from.  This class inherits from Catalyst::Controller::REST.
   
  In MyREST.pm, I override the 'end' method to either use the RenderView 
ActionClass or the Serialize ActionClass:
   
  sub _renderview : ActionClass('RenderView') {}
  sub _serialize : ActionClass('Serialize') {}
   
  sub end : Private {
 my ($self, $c) = @_;
  
 if ( $self->want_renderview($c) ) {
  $c->forward('_renderview');
 }
 else {
  $c->forward('_serialize');
  }

  where the want_renderview() method can be written however you want to (using 
the Content-Type or file extension or whatever).

  Thanks.
   
  Greg
  
Message: 4
Date: Mon, 29 Jan 2007 21:36:03 -0800
From: Adam Jacob 
Subject: Re: [Catalyst] Tweaking REST
To: [EMAIL PROTECTED], The elegant MVC web framework

Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On Jan 29, 2007, at 12:19 PM, Christopher H. Laco wrote:
  ...
>> As it stands now, REST JustWorks with xml/json stuff. text/html is
>> mapped to YAML::HTML, but I want to map that to my standard TT 
>> view.

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

Re: [Catalyst] Re: Tweaking REST

[Adam Jacob]

On Jan 30, 2007, at 11:01 AM, Greg McAlpin wrote:

I would very much appreciate feedback on my approach to using my TT  
view with REST.  I'm just playing with the AdventREST example  
trying to understand the whole REST thing.


I created a class (lib/AdventREST/MyREST.pm) for my controllers to  
inherit from.  This class inherits from Catalyst::Controller::REST.


In MyREST.pm, I override the 'end' method to either use the  
RenderView ActionClass or the Serialize ActionClass:


sub _renderview : ActionClass('RenderView') {}
sub _serialize : ActionClass('Serialize') {}

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

 if ( $self->want_renderview($c) ) {
  $c->forward('_renderview');
 }
 else {
  $c->forward('_serialize');
}
where the want_renderview() method can be written however you want  
to (using the Content-Type or file extension or whatever).


That looks totally reasonable to me.  What we are talking about it  
basically codifying that as a Serialization type, so that people can  
pass various content-types through to a given view.


Adam

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