Re: [Catalyst] Multi-language and REST
Haven't been looking in here for a while, just saw this thread. I have a multilingual app at http://www.engoi.com which uses Chained to do this. It works really well, and makes Do Not Repeat Yourself quite easy to achieve. In fact, for many actions, *two* languages are selected - the native and target language of the user. You can see the way this maps to URI's easily enough by looking around. Browser detection happens if you go to the domain root, and redirects you straight to the home page in your language. It's pretty simple. BTW don't let the fact that many pages are actually served static fool you. All content is developed in Catalyst, I use a script to generate html pages for stuff which is not actually dynamic in behaviour, and some shennaigans with URL's and server config to make it all work together. Cat is very powerful and flexible and lets you do things many, many ways. Daniel ___ 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: RFC: Catalyst::Controller::REST::DBIC
* luke saunders [EMAIL PROTECTED] [2008-05-04 02:50]: Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP requests favouring instead entirely separate endpoints, but that's up for discussion. Putting the verb in the URI is RPC, not REST. This is not a matter of discussion. 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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 10:20 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 2:38 AM, luke saunders [EMAIL PROTECTED] wrote:
I have started to write a Catalyst base controller for REST style CRUD
via DBIC. I have noticed that a number of other people have been
working on or are thinking about working on something similar, most
notabley J. Shirley who seems to be creating
Catalyst::Controller::REST::DBIC::Item
(http://dev.catalystframework.org/svnweb/Catalyst/browse/Catalyst-Controller-REST-DBIC-Item/)
and some chaps from a recent thread on this list (entitled
Dispatching with Chained vs HTTP method).
Ideally I would like to merge J. Shirley's effort into mine (or visa
versa) along with anything that anyone else has. Basically I want to
avoid ending up with a load of modules that all do the same thing.
My effort is heavily based on something mst wrote a while ago, and
since then I've ended up writing something very similar for every
project I've worked on which indicates it's worth OSing. Essentially
it is used like so:
package MyApp::Controller::API::REST::CD;
use base qw/Catalyst::Controller::REST::DBIC/;
...
__PACKAGE__-config
( action = { setup = { PathPart = 'cd', Chained =
'/api/rest/rest_base' } },
class = 'RestTestDB::CD',
create_requires = ['artist', 'title', 'year' ],
update_allows = ['title', 'year']
);
And this gets you the following endpoints to fire requests at:
/api/rest/cd/create
/api/rest/cd/id/[cdid]/update
/api/rest/cd/id/[cdid]/delete
/api/rest/cd/id/[cdid]/add_to_rel/[relation]
/api/rest/cd/id/[cdid]/remove_from_rel/[relation]
The full source is here:
http://lukesaunders.me.uk/dists/Catalyst-Controller-REST-DBIC-1.00.tar.gz
If you have a few moments please have a look, especially if you are
working on something similar. Today I even wrote a test suite which
has a test app and is probably the best place to look to see what it
does.
I've been planning for a more REST-like update to InstantCRUD for a
long time. My approach is a bit different because for validation and
for generating form's HTML I use HTML::Widget. I believe validation
is important and separate enough to have a separate package (and I
don't want to reinvent the wheel - so I use what is available at
CPAN). I also choose to generate the HTML - because I believe there
is too much logic (classes for errors, options from the database,
subforms from the database - see below) in it for the simplistic
Template::Toolkit language - an elegant solution for that could be
also a TT plugin.
Now I am working on porting Instant to use Rose::HTML::Form instead of
HTML::Wiget - it will give it much more solid base.
I thinking generating the form is a step too far for this sort of
thing, normally I just want the API. In some cases I'll be generating
the form HTML with Jemplate for example.
One more difference in my approach is that the 'update' action will be
able to edit not just one row from the DB - but all the interrelated
records that together make a full object. This means also adding and
removing the related records - so I'll not have the add_to_rel
remove_from_rel actions.
Interesting. How are you representing the related objects in the request?
There is also an effort by Peter Carman:
http://search.cpan.org/~karman/CatalystX-CRUD-0.25/lib/CatalystX/CRUD/REST.pm
- and I more or less agreed with Peter on some basics - so that
hopefully our code will be compatible and maybe even will form
together just one solution.
Finally I am waiting for the Moose port of Catalyst - so that all the
CRUD functionality could be just a Role instead of forcing the user to
'use base'.
Note that it lacks:
- list and view type methods which dump objects to JSON (or whatever)
- clever validation - it should validate based on the DBIC column
definitions but it doesn't
- any auth - not sure if it should or not, but it's possible
Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP
requests favouring instead entirely separate endpoints, but that's up
for discussion.
So, J. Shirley, do you have any interest in a merge? And others, do
you have ideas and would you like to contribute?
Thanks,
Luke.
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo:
Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 1:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 7:05 AM, J. Shirley [EMAIL PROTECTED] wrote:
On a side note about REST - REST doesn't mean human readable URLs. It
means representative URLs. The bit about cd/id/{CDID}/ smells like
named parameters going into positional parameters. What is the real
difference between cd?id={CDID}action=delete, aside from different
characters? Where as with REST, /cd/{id} is a unique identifier for
that object and hence a full representation.
The problem I see with /cd/{id} is that when you have a primary key
that is 'create' - this would clash with the 'create' action.
/cd/id/{id} let's you separate the reserved words from the user data.
A pet peeve of mine is that people seem to have this weird idea that
primary key == id. An id can just be some human readable mechanism to
looking up the item, where as the primary key is what is actually used
by the database to determine the relations.
They do not have to be the same field but often times they are out of
convenience. In cases like this, they simply shouldn't be though.
___
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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 2:18 PM, Jonathan Rockway [EMAIL PROTECTED] wrote:
* On Sat, May 03 2008, luke saunders wrote:
__PACKAGE__-config
( action = { setup = { PathPart = 'cd', Chained =
'/api/rest/rest_base' } },
class = 'RestTestDB::CD',
create_requires = ['artist', 'title', 'year' ],
update_allows = ['title', 'year']
);
And this gets you the following endpoints to fire requests at:
/api/rest/cd/create
/api/rest/cd/id/[cdid]/update
/api/rest/cd/id/[cdid]/delete
/api/rest/cd/id/[cdid]/add_to_rel/[relation]
/api/rest/cd/id/[cdid]/remove_from_rel/[relation]
This is RPC, not REST. Not that there's anything wrong with that.
It sounds like what you want to write is a Controller that proxies class
methods to a URI. For example, you write a class like this:
package Foo;
sub create { my ($class, $username, $password) = @_; ... }
sub delete { my $self = shift; $self-delete }
sub foo{ my ($self, $quux, $value_for_42) = @_; ... }
sub fetch_existing { my ($class, $id) = @_ }
...
1;
Then you write a controller like this:
package MyApp::Controller::Foo;
use base 'The::Thing::You're::Writing';
__PACKAGE__-config(
class = 'Foo',
fetch_existing = 'fetch_existing',
new_instance= 'create',
methods = {
create = ['username', 'password'],
delete = [],
foo= ['quux', '42'],
},
);
1;
Then you have actions like:
/foo//create/username/password
/foo/id
/foo/id/foo/quux/value for 42
/foo/id/delete
In your configuration, an option would be available to REST-ify certain
parts of the RPC interface:
rest = {
create = 'create',
get= 'fetch_existing',
delete = 'delete',
update = 'update',
}
Then you would have the /foo and /foo/id REST endpoints do the same
thing as the RPC calls.
I think I'd prefer to use query parameters like I already do rather
than having them in the URI. In fact what I think I should do is leave
the module as it is but make the verb actions private and write the
base action to distribute based on request type so it can be called
REST. Then, because REST isn't always ideal, create a very slim
subclass which gives the Private methods URIs and call this the RPC
version.
Anyway, making this specific to DBIx::Class sounds like a waste of time.
Yes, ideally the general parts would be put in a non-DBIC specific
base controller which $whatever can plug into.
However, a DBIC specific module will allow the bulk of the validation
to be done automatically based on column definitions, foreign keys
etc. Also, a powerful list method can be implemented which allows for
complex search conditions via $rs-search for retrieving a subset of
objects, related rows and so forth. I think stuff like this has to be
DBIC specific.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
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/
___
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] Re: RFC: Catalyst::Controller::REST::DBIC
On Sun, May 04, 2008 at 09:10:56AM +0200, Aristotle Pagaltzis wrote: * luke saunders [EMAIL PROTECTED] [2008-05-04 02:50]: Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP requests favouring instead entirely separate endpoints, but that's up for discussion. Putting the verb in the URI is RPC, not REST. This is not a matter of discussion. No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Or at least a matter for determining an architecture that allows you to use whatever alternative you like. Please don't let your obsessive REST advocacy blind you to pragmatic software development issues; it's starting to get boring. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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: Fw: high school reunion [Catalyst] (no subject)
Too bad one cannot unsubscribe them from the Internet altogether. On Sun, May 4, 2008 at 5:25 PM, Matt S Trout [EMAIL PROTECTED] wrote: Unsubscribed and banned. Bai. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ 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/ ___ 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] Tutorial
IMHO we should all be thinking of outputting UIML or XUL from TT and push a lot more work to the client, letting your server REST a lot ;-) On Fri, May 2, 2008 at 6:09 PM, Ali M. [EMAIL PROTECTED] wrote: Considere reading the mailist thread about the possibilities for a new book here is the link http://www.gossamer-threads.com/lists/catalyst/users/18157 it will give you a better idea about the state of catalyst documentation and how to find answer Good luck On Thu, May 1, 2008 at 9:17 PM, gaurav001 [EMAIL PROTECTED] wrote: Hello gurus, I am newb for Catalyst so forgive me if I ask stupid questions. I have Rockway's book. I followed it. All went good so far (ignore FormBuilder stuff ). Now i want to customize application. Lets say FormBuilder.render gives me submit button automatically (no idea how). But what if I want One Registration button and another Cancel Button. Also Controller file (.PM) file, how can i write my business logic. I know its perl but as I include Catalyst::Controller::FormBuilder...Anychange gives me error. Where to find tutorial for extra METHODS. CGI::FormBuilder has some really nice tutorial online. But how can I do that kind of coding in Catalyst. What should I go through now? Template-Toolkit.org and Formbuilder.org ... Then what extra steps do I need to make Navigating Site with complex Business logic. -- View this message in context: http://www.nabble.com/Tutorial-tp16994039p16994039.html Sent from the Catalyst Web Framework mailing list archive at Nabble.com. ___ 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/ ___ 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/ ___ 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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
If the ID is generated, that gets a bit trickier but I usually handle
that with a POST to /user with the data and then let the application
forward me to the final URL of where the resource exists.
The other reason is that this system breaks when you no longer have
records tied to a database. As an example, if you use an md5 sum of a
file as the identifier. /file/1234 doesn't work because it isn't in a
database under that system (think of a MogileFS cluster or something
with hash keys rather than primary keys in the conventional sense) -
instead /file/{md5sum} is used.
In brief summary, over-utilization of primary keys as record lookup
identifiers ends up diminishing the human readability and
accessibility of your web service. I'm not trying to win over any
converts, because I think there is a time and a place for each (even
in the same application, it just depends upon what each action is
really doing). If I'm not building something that is REST/webservice
driven I tend to do the /user/{id or token} (with a simple regex to
check, and if someone has a login of all numbers then screw 'em) - but
it's a very different strategy when I work with webservices -- each
time I always make sure if the record lookup indicator should be the
primary key, and what cases should it not and then react accordingly.
___
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] RFC: Catalyst::Controller::REST::DBIC
Zbigniew Lukasiak wrote:
On Sun, May 4, 2008 at 3:54 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 1:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 7:05 AM, J. Shirley [EMAIL PROTECTED] wrote:
On a side note about REST - REST doesn't mean human readable URLs. It
means representative URLs. The bit about cd/id/{CDID}/ smells like
named parameters going into positional parameters. What is the real
difference between cd?id={CDID}action=delete, aside from different
characters? Where as with REST, /cd/{id} is a unique identifier for
that object and hence a full representation.
The problem I see with /cd/{id} is that when you have a primary key
that is 'create' - this would clash with the 'create' action.
/cd/id/{id} let's you separate the reserved words from the user data.
A pet peeve of mine is that people seem to have this weird idea that
primary key == id. An id can just be some human readable mechanism to
looking up the item, where as the primary key is what is actually used
by the database to determine the relations.
They do not have to be the same field but often times they are out of
convenience. In cases like this, they simply shouldn't be though.
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My pet peeve is that /foo/primary_key makes computers happy... but not
people.
/products/23
/products/ABC-1234
The first is the PK for a product record..
The second is the actual sku for a product... just a unique as the
pk...but not the PK itself...
Now what does id mean in this case?
What id your SKU is a numeric just like your PK?
Two different and equally useful ways to get at the same resource.
If you're talking about an interface where humans know the skus, and
computers know the id (restfully and/or remotely).. you need a sane uri:
/products/id/id
/products/sku/sku
In the end, I always run into a situation where humans (think marketing
SEO pushers who know not of REST) want something other than a true
restful uri.
-=Chris
___
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] RFC: Catalyst::Controller::REST::DBIC
On May 4, 2008, at 9:02 AM, Christopher Laco wrote: My pet peeve is that /foo/primary_key makes computers happy... but not people. /products/23 /products/ABC-1234 The first is the PK for a product record.. The second is the actual sku for a product... just a unique as the pk...but not the PK itself... Now what does id mean in this case? What id your SKU is a numeric just like your PK? Two different and equally useful ways to get at the same resource. If you're talking about an interface where humans know the skus, and computers know the id (restfully and/or remotely).. you need a sane uri: /products/id/id /products/sku/sku In the end, I always run into a situation where humans (think marketing SEO pushers who know not of REST) want something other than a true restful uri. Part of the problem here might be the wish to avoid a natural primary key in the database schema, preferring a synthetic primary key even when there's a perfectly good natural primary key. That's something that I expect to see from the ruby on rails crowd, not the (presumably more pragmatic) perl folks. If your SKU is unique, then it's a perfectly good primary key, and having a synthetic numeric primary key isn't necessary. (It might be the right choice in some cases, and not in others, but the primary key is an arbitrary integer is not a given). Cheers, Steve ___ 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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 6:06 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
If the ID is generated, that gets a bit trickier but I usually handle
that with a POST to /user with the data and then let the application
forward me to the final URL of where the resource exists.
The other reason is that this system breaks when you no longer have
records tied to a database. As an example, if you use an md5 sum of a
file as the identifier. /file/1234 doesn't work because it isn't in a
database under that system (think of a MogileFS cluster or something
with hash keys rather than primary keys in the conventional sense) -
instead /file/{md5sum} is used.
In brief summary, over-utilization of primary keys as record lookup
identifiers ends up diminishing the human readability and
accessibility of your web service. I'm not trying to win over any
converts, because I think there is a time and a place for each (even
in the same application, it just depends upon what each action is
really doing). If I'm not building something that is REST/webservice
driven I tend to do the /user/{id or token} (with a simple regex to
check, and if someone has a login of all numbers then screw 'em) - but
it's a very different strategy when I work with webservices -- each
time I always make sure if the record lookup indicator should be the
primary key, and what cases should it not and then react accordingly.
Then we are talking about two diffrent things. My point is that you
should not have /foo/create and foo/{id or token} - because you mix a
reserverd work 'create' with data, you can never guarantee that the
data, be it primary key or token or whatever, does not contain
'create'.
I do understand that in full REST design you would not have a
'/foo/create/' uri - but if you want to add this REST as an add-on to
a controller you'll still have other methods on the controller that
could conflict with the token/id.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
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] Anybody who fancies some LWP poking ...
yeah, I started setting up cat on a new system yesterday and hit this :-( The salient line seems to be : HTTP::Message content not bytes at lib/Test/WWW/Mechanize/Catalyst.pm line 88 I will spend an hour or two on it now, as I hate force installing, but am starting almost from scratch and don't have much intuition yet as what this is about. Any pointers welcome ... D ___ 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] So, what do we want in the -next- book?
On 4. mai. 2008, at 15.39, Matt S Trout wrote: Then again, I originally learned Catalyst by reading the source; took me about 8 hours. The only thing that confused me was the dispatcher, which is why I rewrote most of it later when I became a contrib :) And now it confuses the rest of us instead ;-) Marcus ___ 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] Anybody who fancies some LWP poking ...
OK, I walked through the code and found out roughly what is going on. Hard to say where the real source of the bug is (could be at least two modules) but I have a workaround which I am using (basically just to remove the croak in HTTP::Message, a bit dirty but probably harmless). http://rt.cpan.org/Public/Bug/Display.html?id=34802 I forwarded this to Leon also. HTH D On Sun, May 4, 2008 at 9:30 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: yeah, I started setting up cat on a new system yesterday and hit this :-( The salient line seems to be : HTTP::Message content not bytes at lib/Test/WWW/Mechanize/Catalyst.pm line 88 I will spend an hour or two on it now, as I hate force installing, but am starting almost from scratch and don't have much intuition yet as what this is about. Any pointers welcome ... D -- Daniel McBrearty email : danielmcbrearty at gmail.com http://www.engoi.com http://danmcb.vox.com http://danmcb.blogger.com find me on linkedin and facebook BTW : 0873928131 ___ 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, utf8 in form element type text
I'm having a small problem that I hope somebody has a simple solution to. I'm using Catalyst with TT for the view, PostgreSQL and everything set up using utf8 (in perl source use utf8, in postgres using enable_utf8 and in the actual templates containing utf8 encoded interational characers). I've verified that the data stored in postgres is actually stored correctly (international characters in the postgres table display correctly in psql, and data pulled from both the database and templates show international characters fine). Everything seems to work fine, with one small exception. Whenever I have a HTML form input type=text with an international character and the form validation fails, so the default value of the input field contains the international character, the rest of the html document does no longer display international characters correctly. If I remove the international character from the input field and resubmit, everything is displayed correctly again. I'm guessing the browser detects that the document contains some element that is not proper utf8, and disables utf8 altogether before displaying whenever the input field contains an international characters. The input field value is set in the template from the $c-req-parameters passed in the stash. So my question is what's the best way to handle this? Can an input value in a form handle a utf8 encoded string at all, and if so how can I convince it my string is utf8, and if I do does the browser detect it automagically? Any pointers? Thanks, Marius K. ___ 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] Anybody who fancies some LWP poking ...
There was a recent SoPW on PerlMonks about this. Seems HTTP::Message is doing the right thing. http://perlmonks.org/?node_id=683833 -Ashley On May 4, 2008, at 2:21 PM, Daniel McBrearty wrote: OK, I walked through the code and found out roughly what is going on. Hard to say where the real source of the bug is (could be at least two modules) but I have a workaround which I am using (basically just to remove the croak in HTTP::Message, a bit dirty but probably harmless). http://rt.cpan.org/Public/Bug/Display.html?id=34802 I forwarded this to Leon also. HTH D On Sun, May 4, 2008 at 9:30 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: yeah, I started setting up cat on a new system yesterday and hit this :-( The salient line seems to be : HTTP::Message content not bytes at lib/Test/WWW/Mechanize/ Catalyst.pm line 88 I will spend an hour or two on it now, as I hate force installing, but am starting almost from scratch and don't have much intuition yet as what this is about. Any pointers welcome ... D -- Daniel McBrearty email : danielmcbrearty at gmail.com http://www.engoi.com http://danmcb.vox.com http://danmcb.blogger.com find me on linkedin and facebook BTW : 0873928131 ___ 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/ ___ 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] Re: RFC: Catalyst::Controller::REST::DBIC
No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Which clients are we talking about here? I did a quick google search and could only find an off-hand remark along the lines of in 2006 safari had poor support for REST verbs. I'm interested because in my own personal experience I haven't run into any problems generating PUT/POST/GET/DELETE with IE/FF/Opera browsers. Or are you talking about the inability to specify anything other than GET or POST as a form method? Patrick ___ 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/
