Re: [Catalyst] Re: How to print/display some data in an end action

[Emmanuel Quevillon]

Aristotle Pagaltzis wrote:

Hi Emmanuel,

* Emmanuel Quevillon <[EMAIL PROTECTED]> [2008-04-30 16:30]:

Maybe I can clarify the situation.


OK; but all of that was already reasonably obvious. The issue is,
you are doing something to forward to ::View::TT automatically at
the end of a request. Catalyst does not do that by itself. So the
problem would have to be fixed there. First question: what does
the `end` action in your Root controller do? Do you have any other 
`end`s? If so, what do those do?


Regards,

Hi Aristotle,

My Root::end action is simply :

sub end : ActionClass(RenderView) { }

And I don't have any other end action in other controllers.

Regards

Emmanuel

--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-

___
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

[Patrick Donelan]

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

Re: [Catalyst] Anybody who fancies some LWP poking ...

[Ashley]

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/

[Catalyst] Catalyst, utf8 in form element type text

[Marius Kjeldahl]

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 ...

[Daniel McBrearty]

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/

Re: [Catalyst] So, what do we want in the -next- book?

[Marcus Ramberg]

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 ...

[Daniel McBrearty]

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] RFC: Catalyst::Controller::REST::DBIC

[Christopher Laco]

Steve Atkins wrote:


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/
/products/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. 


Not really. SKU is unique yes, but it can change (renamed, reconfigured 
when companies merge, etc) for the same physical product. It's a poor PK 
for the purposes of joining records to it, but a great key for the 
purposes of lookup and selling the item.


One could argue that UPC is a better key than sku, but that's not very 
friendly.


-=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

[Zbigniew Lukasiak]

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] RFC: Catalyst::Controller::REST::DBIC

[Steve Atkins]

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

[luke saunders]

On Sun, May 4, 2008 at 2:12 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> On Sun, May 4, 2008 at 1:28 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>  >  >
>  >  >  I think we can still make it compatible, if we agree on some kind of
>  >  >  internal API.
>  >  >
>  >
>  >  As in make this module compatible with your new module? Perhaps as a
>  >  base class without form generation?
>
>  Yes - I am thinking about something where you have a separate methods
>  for validating the parameters and updating/creating the object in the
>  database - so that I could override them in my sub-class.
>

Yeah, sure. I think the module will provide validation for column
types and FK validation, but you can override that if you wish.

>  >  >
>  >  >  It is I think quite common convention to use '.' dot for that:
>  >  >
>  >  >  param1.some_relation.field_value
>  >  >
>  >  >  or
>  >  >
>  >  >  some_param.some_multi_relation.1.field_value
>  >  >
>  >
>  >  Makes sense. I prefer that to the add_to_rel action, especially if
>  >  this is to remain a REST module rather than an RPC module.
>  >
>
>  It does not bother me if you leave those actions.

I might leave them as private actions but if I leave them as public in
the REST version I'm going to get shot.

>  >  The piece of functionality I always wanted but didn't see a clean
>  >  solution to was specifying complex conditions to the 'list' action,
>  >  for example only CDs which have a track called 'Badgers', which
>  >  requires specifying a join and a related condition. I wonder if it
>  >  makes sense to represent that this way too.
>  >
>
>  Well - this is in my plans as well - as search in InstantCRUD :)  I am
>  thinking to base it on the technique I described in my Advent article:
>  http://catalyst.perl.org/calendar/2007/16

I read your article and it looks ideal, though as you say some method
for ordering would be required, probably via some special case query
param.

Ideally I'd wait for you to implement something along these lines then
if you wouldn't mind, pull the general parts upstream.

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

___
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

[J. Shirley]

On Sun, May 4, 2008 at 9:02 AM, Christopher Laco <[EMAIL PROTECTED]> wrote:
>
> 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/
>  /products/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
>
>
>

To be honest, I'd rather see something like /products/-{id} and
/products/{sku}.  Simple checks like that make things easy, and the
'-' is inconvenient for a human but then they don't have to type a
(seemingly redundant) /sku at each time.

But also, with an index, a sku lookup should be equal to an id lookup,
so in this particular hypothetical case I would always go with the
sku.  If you use DBIC or any other sufficiently sane ORM, you don't
need to ever bother directly with the primary key field, and just do
$obj->relation and be done.

___
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

[J. Shirley]

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

[Christopher Laco]

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

[Catalyst] Anybody who fancies some LWP poking ...

[Matt S Trout]

http://use.perl.org/~acme/journal/36321

-- 
  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: [Catalyst] Tutorial

[Alejandro Imass]

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

[Zbigniew Lukasiak]

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.

>
>
>
>  ___
>  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: 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)

[Alejandro Imass]

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] Re: RFC: Catalyst::Controller::REST::DBIC

[J. Shirley]

On Sun, May 4, 2008 at 7:15 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> 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.
>

Naming things REST when they aren't confuses the namespace and further
propagates the confusion about what REST actually is.  Call it
something else and do everybody who actually tries to build RESTful
apps a favor.  Trying to argue in favor of naming something that isn't
REST in any way REST does a disservice to the world.  And kills
puppies, deprives worthy little girls of ponies, elects
neoconservatives to office and, quite possibly, lights a bag of
excrement on your porch then ringing your doorbell and running.

And, on a more topical note, my method for having actual REST and then
a dumbed down browser version is similar to jrockway's suggestion
about dispatch methods.  My approach is a set of very thin actions
that exist outside of the main API space (or, what I've been playing
around with is a more adaptive interface based on what Dave Rolsky is
working on: 
http://search.cpan.org/~drolsky/Catalyst-Request-REST-ForBrowsers-0.01/lib/Catalyst/Request/REST/ForBrowsers.pm).
 They really end up just being a sort of internal API to the base web
service.  This also addresses the id == primary key issue, because in
your front-end browser-facing scheme, you have /book/id/{primary key},
which maps to /book/{unique identifier}.

___
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

[Matt S Trout]

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: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

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//
>   /foo/
>   /foo//foo//
>   /foo//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/ 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] RFC: Catalyst::Controller::REST::DBIC

[J. Shirley]

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] So, what do we want in the -next- book?

[Matt S Trout]

On Sat, May 03, 2008 at 03:15:38PM -0700, Chris Weyl wrote:
> On Tue, Apr 29, 2008 at 10:02 AM, Peter Corlett <[EMAIL PROTECTED]> wrote:
> > On Tue, Apr 29, 2008 at 11:34:57AM -0500, Jonathan Rockway wrote:
> >  > * On Tue, Apr 29 2008, Peter Corlett wrote:
> >  [...]
> >
> > >> Right, and I need to read the entire Linux and libc source code to be
> >  >> able to write a Unix application.
> >  > It will help, yes.
> >
> >  It may well help, but it is not necessarily the best approach. The source
> >  code to a library is too low-level for a user of the library to really get 
> > a
> >  grip on how all the pieces fit together and are intended to be used.
> 
> Perhaps oddly, with Perl I've often found reading the _tests_ to be
> more helpful than wading through the source of a library, particularly
> if it builds on top of other code.  (Of course, this presupposes a
> good test suite, but...)

What forced DBIx::Class to go from a resarch project to a production
project was users replacing Class::DBI with it on the basis of almost no
docs and a good read of the test suite.

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 :)

-- 
  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: [Catalyst] modperl 1.3 wierdness

[Toby Corkindale]

On Sat, May 03, 2008 at 11:22:49PM +0100, Matt S Trout wrote:
> On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
> > Unfortunately due to somewhat unusual app deployment tactics here, apps get
> > "installed" manually, into their own little area, along with their required
> > perl dependencies, thus losing the Makefile.PL, but also requiring that the
> > config file lived in the same non-standard location.
> 
> How about using
> 
> __PACKAGE__->config(
>   'Plugin::ConfigLoader' => {
> file => __PACKAGE__->path_to(...)
>   }
> );
> 
> or setting an environment variable?

The location varies depending on build version and status, but could have been
solved with the env variable part combined with the loader options..
But at the time it was 8pm at night and I wanted to go home, and hacking up a
little DIY loader was quicker than trying to figure out what was going wrong
with the plugin.. You know how it gets sometimes?


___
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

[Jonathan Rockway]

* 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//
  /foo/
  /foo//foo//
  /foo//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/ REST endpoints do the same
thing as the RPC calls.

Anyway, making this specific to DBIx::Class sounds like a waste of time.

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/

Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

On Sun, May 4, 2008 at 1:28 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>  >
>  >  I think we can still make it compatible, if we agree on some kind of
>  >  internal API.
>  >
>
>  As in make this module compatible with your new module? Perhaps as a
>  base class without form generation?

Yes - I am thinking about something where you have a separate methods
for validating the parameters and updating/creating the object in the
database - so that I could override them in my sub-class.

>  >
>  >  It is I think quite common convention to use '.' dot for that:
>  >
>  >  param1.some_relation.field_value
>  >
>  >  or
>  >
>  >  some_param.some_multi_relation.1.field_value
>  >
>
>  Makes sense. I prefer that to the add_to_rel action, especially if
>  this is to remain a REST module rather than an RPC module.
>

It does not bother me if you leave those actions.

>  The piece of functionality I always wanted but didn't see a clean
>  solution to was specifying complex conditions to the 'list' action,
>  for example only CDs which have a track called 'Badgers', which
>  requires specifying a join and a related condition. I wonder if it
>  makes sense to represent that this way too.
>

Well - this is in my plans as well - as search in InstantCRUD :)  I am
thinking to base it on the technique I described in my Advent article:
http://catalyst.perl.org/calendar/2007/16

-- 
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] RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

On Sun, May 4, 2008 at 11:58 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
>
> On Sun, May 4, 2008 at 12:23 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>  >
>  > 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.
>
>  I think we can still make it compatible, if we agree on some kind of
>  internal API.
>

As in make this module compatible with your new module? Perhaps as a
base class without form generation?

>  >  >  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?
>  >
>
>  It is I think quite common convention to use '.' dot for that:
>
>  param1.some_relation.field_value
>
>  or
>
>  some_param.some_multi_relation.1.field_value
>

Makes sense. I prefer that to the add_to_rel action, especially if
this is to remain a REST module rather than an RPC module.

The piece of functionality I always wanted but didn't see a clean
solution to was specifying complex conditions to the 'list' action,
for example only CDs which have a track called 'Badgers', which
requires specifying a join and a related condition. I wonder if it
makes sense to repr

Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

[Zbigniew Lukasiak]

On Sun, May 4, 2008 at 12:23 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>
> 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.

I think we can still make it compatible, if we agree on some kind of
internal API.

>
>
>  >  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?
>

It is I think quite common convention to use '.' dot for that:

param1.some_relation.field_value

or

some_param.some_multi_relation.1.field_value

>
>
>  >  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, DELE

Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

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

Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

[luke saunders]

On Sun, May 4, 2008 at 6:05 AM, J. Shirley <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 3, 2008 at 9:29 PM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
>  >
>  > > 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]
>  >
>  > Those URLs don't strike me as very RESTful.
>  >
>  > Patrick
>  >
>
>  That is my first impression.  My work is an enhancement from
>  Catalyst::Action::REST, which is a great module already out on CPAN
>  and used by other people (holoway++).
>
>  I'm all for collaboration, but my work is mostly tied to have exposed
>  webservices (in addition to a web-browser compatibility layer) via
>  REST.  By that I mean that I expect, and require, that I can do a PUT
>  /api/rest/cd/[cdid], DELETE /api/rest/cd/[CDID]
>

Sure, but I have previously had problems getting a browser to send PUT
requests from JS so separate endpoints were required. In fact the Dojo
author even said that PUT was a nightmare, use POST (possibly fixed in
recent Dojo version / browsers). i see no reason why you can't have
one base action which forwards to the others based on request type so
that both URL types are exposed.

>  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.
>

I find having the id in the path to be a clearer distinction between
object level operations and class level operations. It's the
difference between object and all objects.

>  You can catch me on IRC next week, as I'm actively working on this for
>  $work and it's getting real dev time (finally).  My work is
>  functionally complete, but lacking test cases; it is just a refactor
>  of existing code in production.
>

So you don't want to automate any actual operations? In which case if
anything my module could subclass yours.

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

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.

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.

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: 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]

On Sun, May 4, 2008 at 7:05 AM, J. Shirley <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 3, 2008 at 9:29 PM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
>  >
>  > > 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]
>  >
>  > Those URLs don't strike me as very RESTful.
>  >
>  > Patrick
>  >
>
>  That is my first impression.  My work is an enhancement from
>  Catalyst::Action::REST, which is a great module already out on CPAN
>  and used by other people (holoway++).
>
>  I'm all for collaboration, but my work is mostly tied to have exposed
>  webservices (in addition to a web-browser compatibility layer) via
>  REST.  By that I mean that I expect, and require, that I can do a PUT
>  /api/rest/cd/[cdid], DELETE /api/rest/cd/[CDID]
>
>  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.


>
>  I understand the limitations of /cd/id/{id} vs. /cd/name/{id}, but a
>  lookup and redirection service is a better solution that polluting
>  your absolute unique representative URL spaces.
>
>  You can catch me on IRC next week, as I'm actively working on this for
>  $work and it's getting real dev time (finally).  My work is
>  functionally complete, but lacking test cases; it is just a refactor
>  of existing code in production.
>
>  -J
>
>
>
>  ___
>  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: 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

[Aristotle Pagaltzis]

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

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