Re: [Catalyst] Swish-e
On Thu, Mar 22, 2007 at 03:48:11PM -0400, Christopher H. Laco wrote: And don't forget the new Lucene taking over for Kino... I had (as still have actually) various problems with locking when using Lucene with fastcgi. It is probably my mistake, but treat this as a friendly warning, because I was oblivious to that problem while developing against development server which is single process. -- Dobrica Pavlinusic 2share!2flame[EMAIL PROTECTED] Unix addict. Internet consultant. http://www.rot13.org/~dpavlin ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 22/03/07, Alejandro Imass [EMAIL PROTECTED] wrote: Hello, I wrote a complete backend in HTML::Widget a couple of months ago, and now I'm adding new functionallity to another part of the site. The question is: a - Stick with HTML::Widget and wait for FormFu ? b - use C::C::FormBuilder ? If you're just adding new functionality to the site, but not necessarily needing new features - I would suggest sticking with HTML-Widget, so it's at least consistent throughout the site. I'm currently using FormFu extensively in several projects, and am really happy with how simple it is to use, but also how extensible and powerful it is. As I've already said though, anything in it is still subject to change at this point - but once there's been a cpan release every effort will be made to maintain backward compatability. I see it being several weeks at the very least before a cpan release. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 22/03/07, Doran L. Barton [EMAIL PROTECTED] wrote: I am currently developing my first app using C:C:FormBuilder too, having done previous Catalyst projects with HTML::Widget. I think FormBuilder may become the de facto way to develop Catalyst apps in the future, especially seeing there is a DBIx::Class::FormBuilder module on the horizon that will marry FormBuilder to DBIx::Class like DBIx::Class::HTMLWidget does for HTML::Widget. Well, if mts has anything to say about it, it'll be Reaction that becomes the Cat de-facto ;) Have I missed something? What's FormFu? Discussion of FormFu has generally been limited to the html-widget mailing list so far. FormFu is similar to html-widget, but tries to get everything right this time ;) It's main selling points are: * You can define your forms using external config files (using any format supported by Config::Any) * Instead of having a simple idea of 'constraint' - it has several stages that can process each form field. Filters - Constraints - Inflators - Validators - Transformers. Filters are intended to do basic cleanup of data input, such as removing trailing whitespace, or removing spaces in a creditcard number. Constraints are low-level data validation, such as, is this an integer, is this in bounds, etc. Inflators are similar to DBIC's - they expand the input into an object of some sort, so there's one which creates a DateTime object, and there's one which turns a file upload into an Imager object. Validators are for 'business logic' - more complex validation, possibly relating multiple fields, which will usually require a custom class created for each check. The only validator written as of yet is Imager::Size which checks a picture's pixel size is within bounds. And Transformers are to manipulate the (possible inflated) input data before using it. The ony transformer written so far is Imager, to edit Imager objects (scale, crop, etc). There are also Deflators, so you can pass $field-default($value) an object and make sure its value is printed properly. * Instead of using HTML::Element to generate the xhtml, it uses TT templates. Every project will have it's own copy of the template files, so you can customise them if you wish. * It's gotten rid of html-widget's seperate $result object - simplifying usage greatly. * Integration with Catalst and DBIx::Class See `svn log` for more - there's lot's there! The code is currently available from: http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/DBIx-Class-FormFu/ http://html-formfu.googlecode.com/svn/trunk/Catalyst-Controller-HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Dojo/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Imager/ I've started adding some TODO's to the issue tracker: http://code.google.com/p/html-formfu/issues/list What would be most helpful though for anyone wishing to help, would be documentation, as what's there is quite out-of-date. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] fastcgi configuration problems
Ian Docherty wrote: FastCgiExternalServer /tmp/timesheet.fcgi -socket /tmp/timesheet.socket VirtualHost *:80 ServerName timesheet.mydomain.com Alias / /tmp/timesheet.fcgi /VirtualHost Just for kicks try: Alias / /tmp/timesheet.fcgi/ (note trailing slash) -Brian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] fastcgi configuration problems
VirtualHost *:80 ServerName timesheet.mydomain.com Alias / /tmp/timesheet.fcgi /VirtualHost I think your Alias should read like this: Alias / /path/to/script/timesheet_fastcgi.pl/ -- Radek ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Announce: Catalyst::Plugin::Authentication update
On Monday, February 26, 2007, Jay K wrote: Well, finally, there is a new Catalyst::Plugin::Authentication module available for general testing. http://search.cpan.org/~jayk/Catalyst-Plugin-Authentication-0. 0_01/ JayK et al: What's the status of this update? I'm starting a new project that could definitely use the realms functionality. Do you need help in any particular area at this point? I'll be glad to do what I can to help get this complete and stable. Jason ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Swish-e
On Mar 22, 2007, at 12:44 PM, Jim Spath wrote: What about Xapian? I noticed that it has some Catalyst support in the form of Catalyst::Model::Xapian. Xapian also seems like a possible long term solution as it can handle more documents that Swish-e or KinoSeach. I've done some Catalyst and Xapian work. There is a lot to like about Xapian: 1. It's quite fast 2. It has a fairly sane API 3. It scales for a long time 4. It's pretty easy to write your own query parser, if you need to. Things I don't like: 1. Perl integration is all XS, and the documentation is lacking. It's not such a big deal, because you can just use the C++ documentation.. but you have to do the translating yourself. 2. Updates to a Xapian index need to happen in a single thread. This sucks if you need to build/rebuild the corpus often, or insert millions of documents at a go. Adam ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Swish-e
Depending on your needs, I'd like to make a plug for using Solr as your search engine. Solr presents a nice XML front-end (and adds several fancy features) to Lucene. The developer communities for Solr and Lucene are large and active. These projects are used as production search engines on many sites. A number of large sites have recently replaced their legacy search engines with Solr and/or Lucene. We use Catalyst and an internally developed Net::Solr module for custom search applications. If you don't want to roll your own XML support, I can make Net::Solr available to interested parties. I would need some help getting it ready for community use, but I could also open source it. If you have serious, production search needs, I suggest at least familiarizing yourself with Solr's capabilities (including caching, faceted search, function queries, DisMax, etc.). There can be a short learning curve to setting it up, especially if you've never run a JVM before. If you want something quick and dirty, Kino or other systems may take less time in the short term. Hope this helps, -Graham ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Swish-e
This is perhaps a useless comment, but much of what I used Xapian for Solr does as well or better. Adam On Mar 23, 2007, at 9:25 AM, Graham Stead wrote: Depending on your needs, I'd like to make a plug for using Solr as your search engine. Solr presents a nice XML front-end (and adds several fancy features) to Lucene. The developer communities for Solr and Lucene are large and active. These projects are used as production search engines on many sites. A number of large sites have recently replaced their legacy search engines with Solr and/or Lucene. We use Catalyst and an internally developed Net::Solr module for custom search applications. If you don't want to roll your own XML support, I can make Net::Solr available to interested parties. I would need some help getting it ready for community use, but I could also open source it. If you have serious, production search needs, I suggest at least familiarizing yourself with Solr's capabilities (including caching, faceted search, function queries, DisMax, etc.). There can be a short learning curve to setting it up, especially if you've never run a JVM before. If you want something quick and dirty, Kino or other systems may take less time in the short term. Hope this helps, -Graham ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/ catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] fastcgi configuration problems
Brian. Excellent, that was it exactly (amazing what difference a single '/' can make!) (That puts pressure on me to recipricate and to update C-P-I18N-DBIC to help you now! I will see what I can do) Regards Ian Brian Cassidy wrote: Ian Docherty wrote: FastCgiExternalServer /tmp/timesheet.fcgi -socket /tmp/timesheet.socket VirtualHost *:80 ServerName timesheet.mydomain.com Alias / /tmp/timesheet.fcgi /VirtualHost Just for kicks try: Alias / /tmp/timesheet.fcgi/ (note trailing slash) -Brian ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
Hello!
When user post some form from Internet Explorer it tries to keep connection
alive
and for that reason after url-encoded data send additional CRLF which is
not
counted to Content-length header. Catalyst::Engine::HTTP ( as of version
5.7007 )
pass all data received to HTTP::Body, but parser of HTTP::Body::UrlEncoded
work only if to it passed exactly content-length bytes. So parameters and
body_parameters left empty. Keepalive hack (-k) does not help.
Is there any way around this problem?
'_body' = bless( {
'content_length' = 27,
'body' = undef,
'length' = 29,
'content_type' =
'application/x-www-form-urlencoded',
'upload' = {},
'buffer' =
'username=testpassword=test^M
',
'param' = {},
'state' = 'buffering'
}, 'HTTP::Body::UrlEncoded' ),
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 11:36 AM, Dmitry wrote: Hello! When user post some form from Internet Explorer it tries to keep connection alive and for that reason after url-encoded data send additional CRLF which is not counted to Content-length header. Catalyst::Engine::HTTP ( as of version 5.7007 ) pass all data received to HTTP::Body, but parser of HTTP::Body::UrlEncoded work only if to it passed exactly content-length bytes. So parameters and body_parameters left empty. Keepalive hack (-k) does not help. Is there any way around this problem? I'm working on this right now actually, sometimes IE adds CRLF to the POST body, and we aren't handling it properly. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
Thank you all for the valuable input to this thread. From the comments, my conclusion is that if you already developed with HTML::Widget it would probably be better to stick with it and wait for FormFu (or use FormFu from svn), because it's more backward compatible with legacy HTML::Widget code. For new developments, both FormFu and FormBuilder seem to be valid options, and if you have developed with FormBuilder in the past it, would probably make sense to use C::C::FormBuilder. Nevertheless, FormFu seems to be a fresh, KISS powerful alternative to C::C::FormBuilder, and probably be more effective for Catalyst developers because it has been thought to work with Catalyst from the start. Just MHO and interpretation. In my case, I will try both before deciding, and leave the back-end apps with HTML::Widget at the moment. I confess to be inclined for FormFu after Carl's comments because it seems that it would be easier to homologue the back-end apps to one standard in the near future. On the other hand, the little devil on left tells me that CGI::FormBuilder is a very powerful and proven system that would certainly have advantages over FormFu in certain scenarios. Again, IMHO. As to which one becomes the de-facto way, I will just say one thing: Hail TIMTOWTDI ! Best, Alejandro On 3/23/07, Carl Franks [EMAIL PROTECTED] wrote: On 22/03/07, Doran L. Barton [EMAIL PROTECTED] wrote: I am currently developing my first app using C:C:FormBuilder too, having done previous Catalyst projects with HTML::Widget. I think FormBuilder may become the de facto way to develop Catalyst apps in the future, especially seeing there is a DBIx::Class::FormBuilder module on the horizon that will marry FormBuilder to DBIx::Class like DBIx::Class::HTMLWidget does for HTML::Widget. Well, if mts has anything to say about it, it'll be Reaction that becomes the Cat de-facto ;) Have I missed something? What's FormFu? Discussion of FormFu has generally been limited to the html-widget mailing list so far. FormFu is similar to html-widget, but tries to get everything right this time ;) It's main selling points are: * You can define your forms using external config files (using any format supported by Config::Any) * Instead of having a simple idea of 'constraint' - it has several stages that can process each form field. Filters - Constraints - Inflators - Validators - Transformers. Filters are intended to do basic cleanup of data input, such as removing trailing whitespace, or removing spaces in a creditcard number. Constraints are low-level data validation, such as, is this an integer, is this in bounds, etc. Inflators are similar to DBIC's - they expand the input into an object of some sort, so there's one which creates a DateTime object, and there's one which turns a file upload into an Imager object. Validators are for 'business logic' - more complex validation, possibly relating multiple fields, which will usually require a custom class created for each check. The only validator written as of yet is Imager::Size which checks a picture's pixel size is within bounds. And Transformers are to manipulate the (possible inflated) input data before using it. The ony transformer written so far is Imager, to edit Imager objects (scale, crop, etc). There are also Deflators, so you can pass $field-default($value) an object and make sure its value is printed properly. * Instead of using HTML::Element to generate the xhtml, it uses TT templates. Every project will have it's own copy of the template files, so you can customise them if you wish. * It's gotten rid of html-widget's seperate $result object - simplifying usage greatly. * Integration with Catalst and DBIx::Class See `svn log` for more - there's lot's there! The code is currently available from: http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/DBIx-Class-FormFu/ http://html-formfu.googlecode.com/svn/trunk/Catalyst-Controller-HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Dojo/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Imager/ I've started adding some TODO's to the issue tracker: http://code.google.com/p/html-formfu/issues/list What would be most helpful though for anyone wishing to help, would be documentation, as what's there is quite out-of-date. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Order_by
-Original Message-
From: Doran L. Barton [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 4:00 PM
To: The elegant MVC web framework
Subject: Re: [Catalyst] Order_by
Not long ago, Doran L. Barton proclaimed...
This is really a DBIC question... but it's like this:
my @books = $c-model('My::AppDB::Book')-search(
{ num_pages = { '=', $pages }},
{ order_by = 'title'});
Basically, the order_by is the second argument to the
search() function.
Woops! I should have been more specific. The order_by
key-value pair is an
*option* - one of several - that can be enclosed in a hash of
options that can be passed as the second parameter to the
search() method.
Sorry I wasn't as clear the first go around.
Thanks for the help, Doran -- I need all the clarity I can acquire.
Cheers,
--
Michael Higgins
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Model::DBIC::Schema or not?
Jason Gottshall wrote:
Catalysters:
I'm developing a new app using Catalyst, with DBIC as the db persistence
layer. I intend to build Models that encapsulate the business logic and
that will use DBIC to interact with the database as necessary, instead
of using DBIC as a model itself.
So if I'm not using DBIC from the controller directly, is there any
reason for me to use Catalyst::Model::DBIC::Schema? It seems like I'm
just adding an unnecessary layer of code.
Comments from any of you who have a similar setup would be especially
welcome.
Jason
I only have Model classes for my business logic and have never had a problem
with that. A bonus is that it forces you to say:
$c-model('MyLogic')-_get_schema-resultset('Users')
instead of:
$c-model('Schema::Users')
and that makes you think about ugly hacks that circumvent your business logic.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Friday, Mar 23, 2007, at 12:34 US/Pacific, Andy Grundman wrote: This bug has been fixed in svn [1] and will be part of the HTTP::Body 0.7 release, coming soon. Just out of curiosity, will this make the test server work with Safari? -Ashley -- ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Model::DBIC::Schema or not?
It's valuable to have the model. You will get less redundant, easier to understand/follow DB interactions and you will, if you need it, have the DB exposed from templates and such. I don't recommend it but I was glad to be able to write some TT code a couple weeks ago that looked more like PHP than Perl. Having the Schema load config file stuff is another win. No hardcoded connection stuff anywhere. Except for a tiny performance gain, you might as well just have your model class inherit from your data logic class; that way you don't have to fire up Catalyst to use your data-logic-db from a command line script or a one-off or something. Plus, think of all the free tech support you'll get from MST. (Joking, Matt!) -Ashley -- On Friday, Mar 23, 2007, at 12:25 US/Pacific, Jason Gottshall wrote: Catalysters: I'm developing a new app using Catalyst, with DBIC as the db persistence layer. I intend to build Models that encapsulate the business logic and that will use DBIC to interact with the database as necessary, instead of using DBIC as a model itself. So if I'm not using DBIC from the controller directly, is there any reason for me to use Catalyst::Model::DBIC::Schema? It seems like I'm just adding an unnecessary layer of code. Comments from any of you who have a similar setup would be especially welcome. Jason ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 23/03/07, Alejandro Imass [EMAIL PROTECTED] wrote: From the comments, my conclusion is that if you already developed with HTML::Widget it would probably be better to stick with it and wait for FormFu (or use FormFu from svn), because it's more backward compatible with legacy HTML::Widget code. One last thing to keep in mind is though FormFu looks similar to html-widget, it isn't backwards compatible and html-widget code would definitely need syntax changes. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst::Model::DBIC::Schema or not?
Just my $.02
IMHO, the M is correctly defined as is in Catalyst, and you should
definitively keep the Model. Depending on which business logic you
are refering to, the code should go in any of Controller, Model (aka
the ORM layer) or the Database.
Furthermore, I think that ORM is just that: clean, powerful,
maintainable access to your database, in fact, anything that pushes
the ORM a bit too far should go IN the database. In practice, you will
find that many of the procedures stored in the model classes will
probably wind up in the databse for performance issues, so what I have
done is set the boundary right there from the beggining (the point
where you feel that you are pushing the ORM a bit too far). Any
complex business logic should always be in the DB (if you are using a
decent database such as PostgreSql, Oracle). The power, encapsulation
and performance gains of using views and rules on a RDBMS like
PostgreSql is without question. Unless you _really_, _really_ have
serious portability issues, and not willing to maintain several sets
of DB code, always consider programming the complex stuff in the DB.
Cheers,
Alejandro
On 3/23/07, Brian Kirkbride [EMAIL PROTECTED] wrote:
Jason Gottshall wrote:
Catalysters:
I'm developing a new app using Catalyst, with DBIC as the db persistence
layer. I intend to build Models that encapsulate the business logic and
that will use DBIC to interact with the database as necessary, instead
of using DBIC as a model itself.
So if I'm not using DBIC from the controller directly, is there any
reason for me to use Catalyst::Model::DBIC::Schema? It seems like I'm
just adding an unnecessary layer of code.
Comments from any of you who have a similar setup would be especially
welcome.
Jason
I only have Model classes for my business logic and have never had a problem
with that. A bonus is that it forces you to say:
$c-model('MyLogic')-_get_schema-resultset('Users')
instead of:
$c-model('Schema::Users')
and that makes you think about ugly hacks that circumvent your business logic.
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 2:51 PM, Ashley Pond V wrote: On Friday, Mar 23, 2007, at 12:34 US/Pacific, Andy Grundman wrote: This bug has been fixed in svn [1] and will be part of the HTTP::Body 0.7 release, coming soon. Just out of curiosity, will this make the test server work with Safari? I believe Safari is fine, it doesn't have the same bug IE does. Have you had problems with it? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Friday, Mar 23, 2007, at 13:47 US/Pacific, Andy Grundman wrote: I believe Safari is fine, it doesn't have the same bug IE does. Have you had problems with it? Yep. I think I brought this up like … over a year ago. I'll go fire up a clean test app to make sure it's still an issue and not something left over from older development I've done. Yep. Starting a clean App with the test server just hangs Safari: Safari can’t open the page. Safari could not open the page “http://localhost:3000/” because the server stopped responding. -k has no effect. The debug output never shows the request at all. I *think* IE for Mac (not to support development for it, I know it's abandon-ware) had the same problem with earlier versions of Cat's test server but it did not have any trouble just now. I had the same problem on Safari years ago with a socket level chat server and it had to do with knowing when to stop reading the incoming request (that's why I was guessing it might be related to the char counting, line ending issue). Sorry I don't have the code in front of me to compare. -Ashley -- ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 4:38 PM, Ashley Pond V wrote:
On Friday, Mar 23, 2007, at 13:47 US/Pacific, Andy Grundman wrote:
I believe Safari is fine, it doesn't have the same bug IE does.
Have you had problems with it?
Yep. I think I brought this up like … over a year ago. I'll go fire
up a clean test app to make sure it's still an issue and not
something left over from older development I've done.
Yep. Starting a clean App with the test server just hangs Safari:
Safari can’t open the page.
Safari could not open the page “http://localhost:3000/” because
the server stopped responding.
-k has no effect. The debug output never shows the request at all.
I *think* IE for Mac (not to support development for it, I know
it's abandon-ware) had the same problem with earlier versions of
Cat's test server but it did not have any trouble just now. I had
the same problem on Safari years ago with a socket level chat
server and it had to do with knowing when to stop reading the
incoming request (that's why I was guessing it might be related to
the char counting, line ending issue). Sorry I don't have the code
in front of me to compare.
It dies on a GET request? Can you run your server like this:
CATALYST_HTTP_DEBUG=1 perl script/myapp_server.pl -d
Then repeat the same thing and add -k.
Here's my output for reference (non-keepalive):
New connection
Read 239 bytes
Parsed request: GET / HTTP/1.1
Parsed headers: bless({
accept = */*,
accept-encoding = gzip, deflate,
accept-language = en,
connection = keep-alive,
host = localhost:3000,
user-agent = Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
AppleWebKit/419 (KHTML, like Gecko) Safari/419.3,
}, HTTP::Headers)
write: Wrote headers and first chunk (5807 bytes)
[info] *** Request 7 (0.123/s) [693] [Fri Mar 23 15:46:54 2007] ***
[debug] GET request for / from 127.0.0.1
[info] Request took 0.007717s (129.584/s)
.
+---.
| Action |
Time |
+
+---+
| /default |
0.000750s |
| /end |
0.000199s |
'
+---'
Request done
Closing connection
New connection
Read 303 bytes
Parsed request: GET /static/images/catalyst_logo.png HTTP/1.1
Parsed headers: bless({
accept = */*,
accept-encoding = gzip, deflate,
accept-language = en,
connection = keep-alive,
host = localhost:3000,
referer = http://localhost:3000/;,
user-agent = Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
AppleWebKit/419 (KHTML, like Gecko) Safari/419.3,
}, HTTP::Headers)
write: Wrote headers and first chunk (13912 bytes)
Request done
Closing connection
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
H…
---
[EMAIL PROTECTED]/MyAppsetenv CATALYST_HTTP_DEBUG 1
[EMAIL PROTECTED]/MyApp./script/myapp_server.pl -d
[debug] Debug messages enabled
[debug] Loaded plugins:
.---
-.
| Catalyst::Plugin::ConfigLoader
0.13 |
| Catalyst::Plugin::Static::Simple
0.15 |
'---
-'
[debug] Loaded dispatcher Catalyst::Dispatcher
[debug] Loaded engine Catalyst::Engine::HTTP
[debug] Found home /Users/jinx/MyApp
[debug] Loaded Config /Users/jinx/MyApp/myapp.yml
[debug] Loaded components:
.-
+--.
| Class |
Type |
+-
+--+
| MyApp::Controller::Root |
instance |
'-
+--'
[debug] Loaded Private actions:
.--+--
+--.
| Private | Class|
Method |
+--+--
+--+
| /default | MyApp::Controller::Root |
default |
| /end | MyApp::Controller::Root |
end |
'--+--
+--'
[info] MyApp powered by Catalyst 5.7007
You can connect to your server at http://jasper.local:3000
---
Same, nothing… tried with the -k too, as well as adding arbitrary
strings to the URI, like http://jasper.local:3000/asdf -- no trouble
with Firefox or IE.
OS 10.4.8, Safari 2.0.4 (419.3)
? Thanks for looking at it.
–Ashley
--
On Mar 23, 2007, at 3:48 PM, Andy Grundman wrote:
On Mar 23, 2007, at 4:38 PM, Ashley Pond V wrote:
On Friday, Mar 23, 2007, at 13:47 US/Pacific, Andy Grundman wrote:
I believe Safari is fine, it doesn't have the same bug IE does.
Have you had problems with it?
Yep. I think I brought this up like … over a year ago. I'll go
fire up a clean test app to make sure it's still an issue and not
something left over from older development I've done.
Yep. Starting a clean App with the test server just hangs Safari:
Safari can’t open the page.
Safari could not open the page “http://localhost:3000/” because
the server stopped responding.
-k has no effect. The debug output never shows the request at all.
I *think* IE for Mac (not to support development for it, I know
it's abandon-ware) had the same problem with earlier versions of
Cat's test server but it did not have any trouble just now. I had
the same problem on Safari years ago with a socket level chat
server and it had to do with knowing when to stop reading the
incoming request (that's why I was guessing it might be related to
the char counting, line ending issue). Sorry I don't have the code
in front of me to compare.
It dies on a GET request? Can you run your server like this:
CATALYST_HTTP_DEBUG=1 perl script/myapp_server.pl -d
Then repeat the same thing and add -k.
Here's my output for reference (non-keepalive):
New connection
Read 239 bytes
Parsed request: GET / HTTP/1.1
Parsed headers: bless({
accept = */*,
accept-encoding = gzip, deflate,
accept-language = en,
connection = keep-alive,
host = localhost:3000,
user-agent = Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
AppleWebKit/419 (KHTML, like Gecko) Safari/419.3,
}, HTTP::Headers)
write: Wrote headers and first chunk (5807 bytes)
[info] *** Request 7 (0.123/s) [693] [Fri Mar 23 15:46:54 2007] ***
[debug] GET request for / from 127.0.0.1
[info] Request took 0.007717s (129.584/s)
.
+---.
| Action |
Time |
+
+---+
| /default |
0.000750s |
| /end |
0.000199s |
'
+---'
Request done
Closing connection
New connection
Read 303 bytes
Parsed request: GET /static/images/catalyst_logo.png HTTP/1.1
Parsed headers: bless({
accept = */*,
accept-encoding = gzip, deflate,
accept-language = en,
connection = keep-alive,
host = localhost:3000,
referer = http://localhost:3000/;,
user-agent = Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en)
AppleWebKit/419 (KHTML, like Gecko) Safari/419.3,
}, HTTP::Headers)
write: Wrote headers and first chunk (13912 bytes)
Request done
Closing connection
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 4:22 PM, apv wrote: Same, nothing… tried with the -k too, as well as adding arbitrary strings to the URI, like http://jasper.local:3000/asdf -- no trouble with Firefox or IE. I think you need to update to Catalyst 5.7007. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 4:30 PM, Andy Grundman wrote: On Mar 23, 2007, at 4:22 PM, apv wrote: Same, nothing… tried with the -k too, as well as adding arbitrary strings to the URI, like http://jasper.local:3000/asdf -- no trouble with Firefox or IE. I think you need to update to Catalyst 5.7007. Err wait, sorry you are running 5.7007, I was just expecting to see debug output and didn't. I think the problem may be that you're using the weird Mac hostname 'jasper.local' instead of localhost. Maybe Safari resolves this differently than Firefox? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
Strangely enough, I was running an older Runtime but upgraded before double checking against your stuff. On Mar 23, 2007, at 4:32 PM, Andy Grundman wrote: I think the problem may be that you're using the weird Mac hostname 'jasper.local' instead of localhost. Maybe Safari resolves this differently than Firefox? Could be, and it's certainly not a big deal (especially if I'm the only one with the problem). Thanks a lot for looking at it. Seriously. -Ashley ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 6:27 PM, Ashley Pond V wrote: Oh, to add confusion upon confusion. It works fine across my Airport. Safari won't load it on the computer which is running the server, but Safari on the computer in the other room has no trouble at all with the test server at the exact same URI. And what if you manually use http://localhost:3000 or http:// 1.2.3.4:3000 where 1.2.3.4 is your IP address? ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with POST from IE and Catalyst::Engine::HTTP
On Mar 23, 2007, at 6:41 PM, Andy Grundman wrote: On Mar 23, 2007, at 6:27 PM, Ashley Pond V wrote: Oh, to add confusion upon confusion. It works fine across my Airport. Safari won't load it on the computer which is running the server, but Safari on the computer in the other room has no trouble at all with the test server at the exact same URI. And what if you manually use http://localhost:3000 or http:// 1.2.3.4:3000 where 1.2.3.4 is your IP address? Nice. You solved it after all. http://localhost:3000/ works fine on the box running the script. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
