Re: [Catalyst] Development environments and performance
Charlie Garrison <[EMAIL PROTECTED]> writes: > It IS possible to run multiple apache/mod_perl processes on one > machine to support different catalyst apps/versions. It requires use > of a frontend proxy server but it's easy to setup and works well. > > I use that technique for both staging and productions apps on the one > machine. I'd like to point out that this is really the only way to run mod_perl apps. If you are using the same Apache process for more than one web app, You're Doing It Wrong (tm). This is why people like FastCGI; it's much easier to setup and maintain than multiple Apaches and mod_perls. However, if you use backend mod_perl Apaches (instead of FastCGI), you can use Perlbal as the frontend (without another Apache in the way), which I find to be enticing. (However, you can also just point Perlbal at the "dev server", which is pretty convenient.) Regards, Jonathan Rockway ___ 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] Development environments and performance
Good afternoon, On 16/1/08 at 10:03 PM -, Ian Docherty <[EMAIL PROTECTED]> wrote: The other reason was that I eventually was hoping to serve several clients from the same machine, running multiple copies of the same application (but perhaps different versions) and knew I could not do this with Apache mod-perl but could do so with fast-cgi, hence my reason for going down that path. Been away for a week so catching up on old threads and wanted to clarify this point for the archives. It IS possible to run multiple apache/mod_perl processes on one machine to support different catalyst apps/versions. It requires use of a frontend proxy server but it's easy to setup and works well. I use that technique for both staging and productions apps on the one machine. Charlie -- Charlie Garrison <[EMAIL PROTECTED]> PO Box 141, Windsor, NSW 2756, Australia O< ascii ribbon campaign - stop html mail - www.asciiribbon.org http://www.ietf.org/rfc/rfc1855.txt ___ 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] LDAP
>> Externally in your organisation? > > No to an external organisation that has been contracted by us to provide and > host a web application. This application needs to share a single sign-on with applications built in-house using Catalyst. Ah, ok. What Directory server are you using btw? > >> For configuration, why don't you have one set and reference it from both *::LDAP ?? >> >> Or I am being dumb here? > > No you're right that I can combine some of the configuration and reference it accordingly. However I don't have a single obvious place to add an extra > method (although J Rockway may have a hack around that). Sounds good. > >> You're pulling LDAP users into your RDBMS? Why not keep them there? If you >> are using PostgreSQL you can use dblink-ldap as a function. Might be handy. > > No I've got data in my RDBMS that has a relationship to the data in my LDAP > directory. For example "comments" are added by users, therefore the comments > in the database have a submitter for which the details are held in LDAP. > > dblink-ldap is interesting but we're a MySQL shop. I'm also taking a look at > DBD::LDAP on CPAN which does a similar thing in perl-land. Understood. > > Carl > > > ___ > 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] REST - like uri design for CRUD
On 26 Jan 2008, at 18:57, Ian Docherty wrote: Now, this means that the client system will have a http response returned with 'status' '302' and 'location' '/class/id/1234' which I presume they will have to parse to determine the ID of the newly created item? Not if they follow the redirect and the representation contains the ID. Cheers Jonathan ___ 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
Thomas L. Shinnick 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 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". I am just doing this now. The way I have implemented it is that an item is created by doing a POST to /class/create and the item is saved in the database. Then the browser is redirected to GET /class/id/1234 (for example) where the newly created item (with id 1234) can be read. Now, this means that the client system will have a http response returned with 'status' '302' and 'location' '/class/id/1234' which I presume they will have to parse to determine the ID of the newly created item? Is this correct? 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)" ___ 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
Re: [Catalyst] $c->req->body oddity
Jonathan Rockway wrote:
* Ian Docherty <[EMAIL PROTECTED]> writes:
I am sending a POST to a Catalyst app and according to the documention
I expected the request body to
contain the data I sent. Instead it holds a filename in the tmp
directory which contains the document. Is
this an expected behaviour?
e.g. in my test script
my $request = HTTP::Request->new(POST => 'http://linux:3000/svc/to/1001');
$request->content_type('text/text');
$request->content('THIS IS THE STRING');
my $response = $ua->request($request);
Basically, HTTP::Body assumes you are sending your content as
application/octet-stream, since it's not multipart/form-data or
application/x-www-form-urlencoded (the two cases that it treats
specially).
Since file uploads are application/octet-stream, we put the data into
a file. Maybe it would be better to keep it in memory unless
Content-Length exceeds a certain length, but the current behavior is
consistent and reliable, so I don't see why we should change it. It's
really not that confusing.
Finally, the "string" that you see in $c->req->body is actually an
IO::File object, so you can easily suck the file in if the need
arises.
Regards,
Jonathan Rockway
Thank you for that explanation. In the light of this does the following
seem reasonable.
I am creating a web service (xml over http) so the POST method would
present an xml
document to the controller using content-type text/xml and the
controller would read it
and parse it.
Regards
Ian
___
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] $c->req->body oddity
* Ian Docherty <[EMAIL PROTECTED]> writes:
> I am sending a POST to a Catalyst app and according to the documention
> I expected the request body to
> contain the data I sent. Instead it holds a filename in the tmp
> directory which contains the document. Is
> this an expected behaviour?
>
> e.g. in my test script
>
> my $request = HTTP::Request->new(POST => 'http://linux:3000/svc/to/1001');
> $request->content_type('text/text');
> $request->content('THIS IS THE STRING');
> my $response = $ua->request($request);
Basically, HTTP::Body assumes you are sending your content as
application/octet-stream, since it's not multipart/form-data or
application/x-www-form-urlencoded (the two cases that it treats
specially).
Since file uploads are application/octet-stream, we put the data into
a file. Maybe it would be better to keep it in memory unless
Content-Length exceeds a certain length, but the current behavior is
consistent and reliable, so I don't see why we should change it. It's
really not that confusing.
Finally, the "string" that you see in $c->req->body is actually an
IO::File object, so you can easily suck the file in if the need
arises.
Regards,
Jonathan Rockway
___
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] $c->req->body oddity
I am sending a POST to a Catalyst app and according to the documention I
expected the request body to
contain the data I sent. Instead it holds a filename in the tmp
directory which contains the document. Is
this an expected behaviour?
e.g. in my test script
my $request = HTTP::Request->new(POST => 'http://linux:3000/svc/to/1001');
$request->content_type('text/text');
$request->content('THIS IS THE STRING');
my $response = $ua->request($request);
If I look at the value in $c->request->body in my controller I get
something
like '/tmp/LEVo4ciz1g'
And if I look at the content of the temp file I find my 'THIS IS THE
STRING'
text.
Is this a document problem or something else?
Regards
Ian
___
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] How to return a 401 from Catalyst
Related to my earlier thread about basic authentication, what do I have
to do to return a 401 error from within Catalyst?
I have tried to understand the documentation at
http://www.ietf.org/rfc/rfc2617.txt but it does not help me in a
practical manner.
My understanding is that when the Catalyst app refuses the credentials
given it must return a 401 with a 'realm' that is
just a string used to identify the service.
For example, when I create a test script for my Controller using LWP as
follows
my $ua = LWP::UserAgent->new;
$ua->credentials('linux:8001','some_realm_or_other','sage_1001','sage');
Then my script fails because I have not set a 'realm' correctly in my
Catalyst controller. All I have done so far is as follows.
if ($login_success) ) {
# do something
}
else {
$c->response->status(401);
return 0;
}
Obviously I need to do more to return the realm, but what exactly?
Regards
Ian
p.s. I note that there is nothing in Test::WWW (that I can find) that
tests return status's such as 200, 401 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/
Re: [Catalyst] Automated testing of Captcha?
On Fri, 2008-01-25 at 06:53 +, Matt S Trout wrote: > If you're outside, then either forcing the captcha to a particular string or > disabling it entirely are probably your only options - but that wasn't the > case here if you read carefully :) > For me, it was important to test whether the same captcha could be used twice, as I forgot to clear the captcha for the session after using it (as far as I remember, Catalyst::Plugin::Captcha does not enforce you to do so, neither does it encourage you to do so in the example) You cannot automatically test for this exploit with a static string for the captcha. As I am running all my test cases over fastcgi (for various reasons), I have a test action which returns the captcha of the current session. This action is of course only defined if some environment variable is set. Sébastien ___ 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] OT: YUI v Ext JS
I've visited, but I saw that it doesn't create an html table, but just some data arranged to look like a table. So it is not very accessible for those who use screen readers. The World Wide Web Consortium recommends not to use a table for layout, but to use a table for tabular data, and not other ways. Octavian - Original Message - From: "Moritz Onken" <[EMAIL PROTECTED]> To: "The elegant MVC web framework" Sent: Saturday, January 26, 2008 12:25 PM Subject: Re: [Catalyst] OT: YUI v Ext JS If you have a big table to display i'd recommend the ext extension live grid. You can see an example here: http://www.siteartwork.de/livegrid_demo/ it only retrieves the data you are seeing. Just scroll through the example and you'll see. I like ext pretty much. There are some issues with scrollbars on a mac with firefox, but thats a firefox bug and not ext. So I guess YUI might have the same problem on macs. -- Moritz Onken [EMAIL PROTECTED] Schützenstraße 81 76137 Karlsruhe Festnetz: +49 (721) 2048842 Mobil:+49 (176) 24436493 Am 26.01.2008 um 03:14 schrieb Ashley: On Jan 25, 2008, at 6:07 PM, Peter Karman wrote: Ashley wrote on 1/25/08 6:44 PM: * Does Ext JS's grid have all the same goodies as YUI's DataTable? I haven't used Ext yet. But have you looked at: http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html ? Yes. Unless I'm missing something those changes are purely client- side. It took *a lot* of searching to discover someone asking on a YUI list the same basic question about server-side data updates and being told, you have to update your own data store however you feel like. * Is Ext JS completely stable across IE, FF, and Safari (Opera is sort of out of scope for this). * Do YUI's considerable other offerings (I'm looking for a site- wide library, not just grids) outweigh the positive aspects of Ext JS? * Would anyone, knowing *both*, pick YUI over Ext JS? I have used the YUI history manager to good effect (see http://catalyst.perl.org/calendar/2007/7) so if Ext had some widget I really wanted, I would just use both together. This is good advice. My only dilemma in the choosing for this part of the app is that the manager might say, WTF? I thought we were gonna use YUI? :) ___ 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] OT: YUI v Ext JS
If you have a big table to display i'd recommend the ext extension live grid. You can see an example here: http://www.siteartwork.de/livegrid_demo/ it only retrieves the data you are seeing. Just scroll through the example and you'll see. I like ext pretty much. There are some issues with scrollbars on a mac with firefox, but thats a firefox bug and not ext. So I guess YUI might have the same problem on macs. -- Moritz Onken [EMAIL PROTECTED] Schützenstraße 81 76137 Karlsruhe Festnetz: +49 (721) 2048842 Mobil:+49 (176) 24436493 Am 26.01.2008 um 03:14 schrieb Ashley: On Jan 25, 2008, at 6:07 PM, Peter Karman wrote: Ashley wrote on 1/25/08 6:44 PM: * Does Ext JS's grid have all the same goodies as YUI's DataTable? I haven't used Ext yet. But have you looked at: http://developer.yahoo.com/yui/examples/datatable/dt_cellediting.html ? Yes. Unless I'm missing something those changes are purely client- side. It took *a lot* of searching to discover someone asking on a YUI list the same basic question about server-side data updates and being told, you have to update your own data store however you feel like. * Is Ext JS completely stable across IE, FF, and Safari (Opera is sort of out of scope for this). * Do YUI's considerable other offerings (I'm looking for a site- wide library, not just grids) outweigh the positive aspects of Ext JS? * Would anyone, knowing *both*, pick YUI over Ext JS? I have used the YUI history manager to good effect (see http://catalyst.perl.org/calendar/2007/7) so if Ext had some widget I really wanted, I would just use both together. This is good advice. My only dilemma in the choosing for this part of the app is that the manager might say, WTF? I thought we were gonna use YUI? :) ___ 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/
