Re: [Catalyst] What text editor to use?
At 08:13 PM 3/2/2011, gvim wrote: On 02/03/2011 11:10, John M. Dlugosz wrote: What's a good text editor to use for Catalyst/TT development? The editor I really like for C++ doesn't handle XML well. I've been using Notepad++ for windows, but the syntax highlighting doesn't understand mixing TT inside the base language, and it has tabs only instead of multiple visible windows. I would entertain both Windows and Linux solutions. TIA, --John Vim does everything you will ever need if you're dealing with text :-). Try MacVim if you're on OS X: http://code.google.com/p/macvim/ gvim I second the nomination for Vim, for another important reason. I hate switching editors. So, er... huh? Vim runs everywhere. I can wander from platform to platform and not have to worry whether something capable is available. That was really something I needed back when (15+ years) when Windows was so badly served. Still using it, even on Solaris! ;-) Now if you like learning new editors, or having 2 or 3 in your pocket, fine. But I've not yet found something I couldn't do in Vim. Hey I rarely need to edit in binary, but it can do it. And hacking Unicode isn't so revolutionary now, but was possible with Vim before some other editors. Good pedigree, barks on command, etc., etc. ___ 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] create controller 'option' -mechanize fails
I'm confused about the 'options' to script/foo_create.pl . Nothing seems to work as documented. Run without any parameters foo_create.pl says Usage: foo_create.pl [options] model|view|controller name [helper] [options] Options: --forcedon't create a .new file where a file to be created exists --mechanizeuse Test::WWW::Mechanize::Catalyst for tests if available --help display this help and exits Examples: foo_create.pl controller My::Controller foo_create.pl -mechanize controller My::Controller Note already the disagreement between --mechanize and -mechanize. When I try either of these forms before the 'controller' or after all other parameters I get an error apparently saying the options were not interpreted correctly. Such as Unknown option: m Unknown option: e Unknown option: c Unknown option: a (note absence of 'h' !) Unknown option: n Unknown option: i Unknown option: z Unknown option: e or Couldn't load helper Catalyst::Helper::Controller::--mechanize, syntax error at (eval 276) line 1, near require Catalyst::Helper::Controller::-- Why aren't options being understood as documented? For instance, --force also explodes. But -h just shows the help without exploding. -( I see comptest.tt has sample code for including mechanize - is this valid for controllers? (Note: I'm up-to-date on all Catalyst components according to CPAN, e.g. Catalyst::Devel 1.26) ___ 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/
Fwd: [Catalyst] Selecting from more tables (DBIC - bug?)
Trying again to forward to DBIC list, which rejected my previous try
at forwarding with additions...
From: Octavian Rasnita orasn...@gmail.com
To: The elegant MVC web framework catalyst@lists.scsys.co.uk
Date: Sun, 17 Jan 2010 15:22:57 +0200
Subject: [Catalyst] Selecting from more tables (DBIC - bug?)
Hi,
Sorry for not writing to the DBIC mailing list, but it rejects my messages
as SPAM.
I have tried the following select from the table user:
return $self-search_rs({},{
prefetch = {blogs = 'blog_comments'},
'+select' = ['me.id'],
'+as' = ['user_id'],
});
The table user has_many blogs and it also has_many blog_comments.
The table blog has_many blog_comments and belongs_to user.
The table blog_comment belongs_to user and belongs_to blog.
The problem is that the +select and +as options have no effect, and the
query above returns all the columns from all 3 tables, no matter what
columns I select.
It seems to work only if I use join instead of prefetch and select and
as instead of +select and +as.
I use ActivePerl 5.10.1 and the latest versions of DBIx::Class and
SQL::Abstract.
Is there a bug or I am missing something obvious, or it is just not possible
what I want?
Thank you.
Octavian
I'm having some of the same questions regarding +select and +as . It
seems that using '+select' and '+as' does not stop other columns from
being returned. I'm using DBIC 0.08115.
I've got a 3 table test setup, which might be confusing, but please just
look at the SELECT lines below.
First I use the syntax as documented, with the '+' in front of 'select'
and 'as'.
$rs1 = $schema-resultset('Users')
-search( { 'me.is_admin' = '1' },
{ join = { 'users_roots' = 'root_id' },
'+select' = [ 'me.user_id',
'me.user_name',
'root_id.rootpath',
],
'+as' = [ 'admin_id',
'admin_name',
'admin_rootpath',
],
'order_by' = ['root_id.rootpath'],
When I query a returned row using get_column() I get something for every
name queried, table column or 'as' specified name.
# ( I see '2' for user_id )
# ( I see '1admin' for password )
# ( I see '2' for admin_id )
And looking at the SELECT line you can see that what is being requested
isn't just what was asked for, and some columns are requested twice!
SELECT me.user_id, me.user_name, me.password, me.is_admin, me.info,
me.user_id, me.user_name, root_id.rootpath
FROM users me
LEFT JOIN users_roots users_roots ON users_roots.user_id = me.user_id
LEFT JOIN roots root_id ON root_id.root_id = users_roots.root_id
WHERE ( me.is_admin = ? ) ORDER BY root_id.rootpath: '1'
Here I just take the '+' out of '+select' and '+as':
'select' = [ 'me.user_id',
'me.user_name',
'root_id.rootpath',
],
'as' = [ 'admin_id',
'admin_name',
'admin_rootpath',
],
And now some of the unrequested columns are now gone or renamed as requested:
# ( I see 'undef' for user_id )
# ( I see 'undef' for password )
# ( I see '2' for admin_id )
And that is the story that the SELECT line tells also - only the 3 columns
I've asked for are requested:
SELECT me.user_id, me.user_name, root_id.rootpath
FROM users me
LEFT JOIN users_roots users_roots ON users_roots.user_id = me.user_id
LEFT JOIN roots root_id ON root_id.root_id = users_roots.root_id
WHERE ( me.is_admin = ? ) ORDER BY root_id.rootpath: '1'
So while I'm not seeing a difference with 'join' and 'prefetch' with
Octavian (and that is probably because my debug tests aren't good enough),
I am seeing a concrete difference about retrieved columns. What is
supposed to be true?
___
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] New Apress book shipping now from Amazon.com
At 05:28 PM 7/8/2009, Kieren Diment wrote: On 09/07/2009, at 7:40 AM, Ari Constancio wrote: Hello, For those interested, Amazon.com is shipping now pre-orders for The Definitive Guide to Catalyst. Not sure about new orders, though. Regards, Ari Constancio Thanks for this. Indeed they are, officially the book is being released on Friday. Anybody going to have one of those link to Amazon from here and we'll get a donation links on their web page. (hint hint) Hmm, http://books.perl.org/ should, but doesn't...? (I'll wait until tomorrow before ordering) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] ANNOUNCE: SimpleDB - Auth configuration made easy
At 07:13 PM 10/27/2008, Jason Kuri wrote: I made the default 'clear', as the tutorial uses 'clear' and it is the least likely to cause failure of auth for those just coming to catalyst / going through the tutorials. The password_type config option allows changing it to something more reasonable for production use. Matt and I discussed and he made the point that this module will probably get a lot of production use and it's default should probably at least attempt to prevent newbies from making bad design choices... or at least make it a bit more difficult. I must agree. As such, an updated module is on it's way to CPAN - which uses 'crypted' as the default. The documentation has been adjusted to reflect this. You can still use a password_type of 'clear' by setting it explicitly, but you _will_ get warned in your logs that it is an insecure password storage mechanism. (There's always a dissenter.) If I explicitly override the default, by explicitly requesting 'clear', because my requirements explicitly need this ability, then I must change the code to get rid of the warning? Ahh, but it's for the 'simple', who must be guided, and can't be bothered to read the warnings in the text so bonk'em repeatedly in the logs till they mind what you say. Which is to explicitly not use the feature which you've explicitly provided? (sigh) How about adding 'clear_please_please' ? (Just because I like simple doesn't mean I _am_ 'simple' - and I really do appreciate the simplicity enablers, really) Jay On Oct 27, 2008, at 5:18 PM, Matt S Trout wrote: On Mon, Oct 27, 2008 at 03:51:49PM -0700, Darren Duncan wrote: Zbigniew Lukasiak wrote: * Your passwords are stored in the 'password' field in your users table and are not encrypted. This is always a bad idea. If someone ever gets direct database access, they now know each user's mindset as to how they choose passwords This is the catalyst list, not the stating the fucking obvious list. -- 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/
[Catalyst] Logo collision?
Hope this hasn't been discussed before, the similarities of the Catalyst logo to others. Look at http://www.geektools.com/ about two-thirds down the page, or more specifically http://www.geektools.com/images/udnsreseller.gif Strangely, I haven't yet found this logo at the Neustar UltraDNS site http://www.ultradns.com/ I suppose everyone has a powered by ... icon, and limited imagination for such pictures for network thingies, but this looks remarkably like the Catalyst icon file that I've got, dated 2005/07/31. I jus' worrying... -- I'm a pessimist about probabilities; I'm an optimist about possibilities. Lewis Mumford (1895-1990) ___ 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] Book
At 08:09 AM 2/25/2008, you wrote: Hi, I am considering getting the Catalyst book and had a question or 2. Should it be bought from the Packt publishing site as opposed to anywhere else? Does buying it there help the catalyst project in some way more than buying it at another site that perhaps I am already registered on? I have been working my way though the sample chapter (3). I found it easier to follow then the tutorial that comes with the documentation. However the reviews at http://Amazon.co.ukAmazon.co.uk are a little negative. What does the list think about the books. Thanx, Dp. Whoa, just read those. Rough. Does fast to print meant skipping some steps? I'm still going to buy the book, after the previous posters question is answered (how _best_ to buy). I wish I knew more about publishing, because I've been intrigued by, evidently, how hard it is to get right. Even my most recent purchase, RESTful Web Services (O'Reilly) had irritating glitches. Is it the case that, along with every other industry shifting more and more responsibilities onto the lowest levels, that now the author has to do it all? Not only write and organize perfectly, but arrange their own set of editors, reviewers, and proof-readers? If so, can they ask for volunteers? I fix Wikipedia stuff for free, and helping on something like this would actually benefit me... -- I'm a pessimist about probabilities; I'm an optimist about possibilities. Lewis Mumford (1895-1990) ___ 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] REST - like uri design for CRUD
At 01:56 PM 1/20/2008, Zbigniew Lukasiak wrote: I know this has been discussed already - but I can't find it in the archives. What I conjured is: /class/search /class/id//view /class/id//update /class/create Update and create use really the same logic and templates - so I just forward to a create_or_update action from them. What are your opinions? -- Zbigniew Lukasiak spew register=pedant The book RESTful Web Services has been very useful to me in understanding the confusion about what REST means when it comes to 'verbs'. And that I'm interested in how close one can come to 'strict' REST design using Catalyst. One important topic in the book is that people mix 'verbs' into their URIs when they shouldn't, or at least when they don't _have_ to. Using the book's concepts your URIs would become 1) GET/class?pattern=breadbox 2) GET/class/id/ 3) PUT/class/id/ 4) POST /class 1) is your /class/search and says let me retrieve the representation/list of the items selected by searching for the given pattern, where the base URI would indicate the set/list of items, and the pattern is kept in the query parameters because it could be anything. Note that the idea is that GET /class references the list of all items, and you here are just qualifying that search with the pattern. 2) Your /class/id//view would be seen in strict REST as just a GET of /class/id/. The HTTP 'verb' GET already says give me a representation of the item. Done. 3) Your /class/id//update would become a PUT of /class/id/, where the new representation coming from the remote client would _replace_ the old representation/data for that item. This strict use of the HTTP 'PUT' verb is actually the hardest to accomplish, as it assumes that the remote client can receive and update a representation on the client, and then send it back using PUT. It is easiest to picture this usage when the client completely replaces the old representation held on the server. (see farther below for why) 4) Your /class/create becomes a POST to /class. This was another concept brought out by the book. The matter of who determines the item's 'id' is important. Here we assume that the _server_ will determine the id of the new added item. You do a POST to the base URI of the data area, and the server determines the new id, stores the data into the item, and does a redirect to tell the remote client where the new item is, that is, what is the new item's URI, for instance /class/id/1234. Why is who determines the id important? Because it says what HTTP verb you should use to create a new item. If the server, you use POST to add another item. (Much discussion of that most misunderstood of HTTP methods: POST in the book) But if the remote client were to determine the id, say because the id is a license plate number input at the client, then strict REST would say the client should do a PUT to /class/id/STRWBYP and the client would send the complete data for the item. The server would create the item using the id 'STRWBYP as requested by the client. Creation using POST would say create a new item and tell me (the client) where you (the server) put it. Creation using PUT defines where to put it to the server, because the client knows what the id should be. So under some designs it is possible that PUT will be used for both creation of new items and update (replacement) of existing items. In both these cases (under such a design) the client knows the correct id for the item. Anyway this spew was prompted by the new pedant seeing 'REST' in the subject and then no mention of 'PUT', etc. The book tries to be clear that it depends on both your design and the capabilities of the client whether you can implement using the strict REST HTTP verb set GET, PUT, and POST, or whether you must compromise on a REST-like set of GET and POST. The authors discuss how to overload POST to effect PUT-like usage, because we have to implement in the real world. But they are clear about the goals of RESTful design, the problems it solves, and the benefits it brings in the real world. It looks to be very useful to consider URI design with a view towards how would I accomplish this by splitting my data objects into URI addressable data that can be manipulated using the full set of HTTP verbs GET, PUT, POST and HEAD. (And not putting verbs into URIs that might be cached) /spew ___ 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] REST - like uri design for CRUD
At 04:06 PM 1/20/2008, =?KOI8-R?B?88XSx8XKIO3B0tTZzs/X?= wrote: One important topic in the book is that people mix 'verbs' into their URIs when they shouldn't, or at least when they don't _have_ to. Using the book's concepts your URIs would become 1) GET/class?pattern=breadbox 2) GET/class/id/ 3) PUT/class/id/ 4) POST /class Nice clarification, thank you! But is the /id/ part of url required? In most cases class would have only one primary identifier, so we can shrink it to GET /class/ - can't we? Oh definitely the naming URI's is very important, and can be intricate. The authors develop on a couple different example application cases illustrating how they would layout the URI namespace. And how they sometimes have to go back and redo the layout to eliminate conflicts. Their essential criteria are that each URI specify one 'thing', and that every 'thing' have (at least) one URI. That doesn't mean that a less-specific URI is not meaningful. If /class/ is one item, you might still allow GET /class to mean get me the list of all items under /class. And concerning case 3 - I think that rarely used PUT method could be replaced with common POST to avoid possible problems with proxies, etc. -- ó Õ×ÁÖÅÎÉÅÍ, óÅÒÇÅÊ íÁÒÔÙÎÏ×. The authors do take care not to be so rigid we can't _try_ to approach the one true way of REST. :-) They specifically allow that when PUT is not available or impracticable (clients, firewalls, and proxies can get in the way), you could 'overload' POST by, for example, adding a query parameter _method=PUT to pass-thru the real request method. The idea is that the handler would pick off this parameter and dispatch as though the HTTP method had really been PUT. But you try to use this request like you would a 'real' PUT, in what the data contains and how it is used. But this is a question I have, whether the REST dispatching modules have an capability like this, interpreting overloaded POSTs? ___ 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] REST - like uri design for CRUD
At 04:11 PM 1/20/2008, Ashley wrote: On Jan 20, 2008, at 1:33 PM, Thomas L. Shinnick wrote: At 01:56 PM 1/20/2008, Zbigniew Lukasiak wrote: /class/search /class/id//view /class/id//update /class/create spew register=pedant One important topic in the book is that people mix 'verbs' into their URIs when they shouldn't, or at least when they don't _have_ to. Using the book's concepts your URIs would become 1) GET/class?pattern=breadbox 2) GET/class/id/ 3) PUT/class/id/ 4) POST /class /spew Clipped a bunch. This is great food for thought. I am missing in this scheme how you would know to serve the form for updating. That seems to be the real point of /class/id//update. I suppose that should be /class/id//edit instead and it would, if it could, properly PUT the form to /class/id/, yes? -Ashley Rats, I can't pinpoint the area where they talk about this (serving forms) in the book. Two points of departure: First, there is a difference when talking about how you go about implementing RESTful interactions where both the client/server are programmed, that is, where data is exchanged directly and people aren't involved. When you instead want to make accommodations for allowing more classical (non-Javascript) interactions it _does_ get cloudy. And if you want to serve _both_ programmed and human interactions it gets positively foggy. You don't want to start having alternate URIs just to specify what 'kind' of representations to serve. So... Second, if there are multiple representations for an item, how do we specify which representation is being requested? The authors ask that you try to use something like the Accept: header, so that a Javascript program can specify that it wants an XML or JSON representation, _rather_ than an HTML form representation. If you want to allow plain unenhanced browsers you could serve the form in HTML by default. But if the request specifically said give me straight data, the server would see the Accept: application/json (I think that's right) and respond with Content-type: application/xml. Program or person - the HTTP headers tell you which. Now they again mention real-world hiccups, where some component might not pass-thru or pay attention to headers like Accept. They offer that you could (if forced) specify the desired content type in either the query parameters or even the URI itself, where they suggest an extension. Thus GET /class/1234.xml would be what a program might request, rather than a plain GET /class/1234 which might default to HTML. Basically they keep coming back to the same theme: use HTTP to its fullest, both headers and methods (e.g. PUT), and much becomes possible that otherwise seems clumsy. (Didn't say 'easy'... :-) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst, REST and Firefox
At 12:03 PM 1/17/2008, Christopher H. Laco wrote:
Jonas Alves wrote:
On Jan 17, 2008 2:32 PM, Christopher H. Laco [EMAIL PROTECTED] wrote:
I've touched on this before, and posted about it on UP:
http://use.perl.org/~jk2addict/journal/35411
In a nutshell, Firefox 2.x Accept header totaly screws with the REST
controller when you use it as a base for View negotiations. If you have
a default type of text/html pointed to a View::TT, REST will see
text/xml from Firefox and try and send that instead, based on this header:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
What does everyone think about a config option/toggle to tell REST to
ignore the Accept header, allowing it to fall back to the default
content-type in config when no Cntent-Type header or content-type params
are specified?
-=Chris
I have a subclass of Action::Serialize that does this:
my $default = $controller-config-{serialize}{default};
my $pcontent_type = $c-req-preferred_content_type;
my $content_types = $c-req-accepted_content_types_qvalue;
my $ordered_content_types = $c-req-accepted_content_types;
my $max_qvalue = $content_types-{$pcontent_type};
my %max_qvalue_content_types = map {
$content_types-{$_} eq $max_qvalue ? ($_ = $default) : ()
} keys %$content_types;
my $content_type = $max_qvalue_content_types{$default}
|| $pcontent_type
|| $c-req-content_type;
And in a subclass of Request::REST mixed with Plugin::Flavour:
sub preferred_content_type {
my $self = shift;
if ($self-flavour) {
my $type = $self-{ext_map}{$self-flavour}
|| $self-_ext_to_type($self-flavour);
return $type;
}
$self-accepted_content_types-[0];
}
sub accepted_content_types_qvalue {
my $self = shift;
return $self-{content_types_qvalue} if $self-{content_types_qvalue};
my %types;
if ($self-method eq GET $self-param('content-type')) {
$types{ $self-param('content-type') } = 2;
}
# This is taken from chansen's Apache2::UploadProgress.
if ( $self-header('Accept') ) {
$self-accept_only(1) unless keys %types;
my $accept_header = $self-header('Accept');
my $counter = 0;
foreach my $pair ( split_header_words($accept_header) ) {
my ( $type, $qvalue ) = @{$pair}[ 0, 3 ];
next if $types{$type};
$qvalue = 1 unless defined $qvalue;
$types{$type} = sprintf '%.3f', $qvalue;
}
}
return $self-{content_types_qvalue} = \%types;
}
That way all works fine. If you add an extension to the uri (like
.json or .xml), it serves that content-type. Else it tries to find the
greater qvalue on the Accept Header and tries to serve that. If it has
more than one content-type with the same max qvalue it tries to find
the default content-type in that list and serve it. If it isn't in the
max qvalue list than it serves the first content-type on that list.
I think that is a sane approach.
Well volunteered! I can't speak for the flavour stuff, but I'd think
the q value logic would be well served in the REST package. :-)
I'd personally like the flavour stuff in there as well. In my case,
I'm half way there. I have a type= that takes a friendly name (atom,
rss, json) ... along wieh adding some of those content types to
MIME::Types since it's missing a few of them for type-extension mapping.
-=Chris
Just wanted to note that using extensions on URIs to select
content_type is a technique mentioned in the RESTful Web Services
book. I think it was touted as a way to be sure the right type was
returned. I hadn't gotten to seeing if it'd work with REST stuff
here. Color me interested ___
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/
