Comments on: Rails With Calendar Date Select http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/ Burning Down People's Dreams Since That One Day ... Sat, 21 Jan 2012 07:19:59 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Liam http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32441 Liam Sat, 18 Apr 2009 15:20:17 +0000 http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32441 Awesome. That's even better, I was considering a few different methods to format the date, but now I can pass it straight to the model. Awesome. That’s even better, I was considering a few different methods to format the date, but now I can pass it straight to the model.

]]> By: Wyatt http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32439 Wyatt Sat, 18 Apr 2009 14:11:40 +0000 http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32439 Also, for anyone else out there using <a href="http://code.google.com/p/calendardateselect/" rel="nofollow">Calendar Date Select</a>, the author has rolled my changes into his plugin so you shouldn't need to add your own JavaScript ISO date formatting. Also, for anyone else out there using Calendar Date Select, the author has rolled my changes into his plugin so you shouldn’t need to add your own JavaScript ISO date formatting.

]]> By: Liam http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32406 Liam Fri, 17 Apr 2009 18:34:24 +0000 http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-32406 Thanks a lot for that. You've just made someones life a hell of a lot easier! Thanks a lot for that. You’ve just made someones life a hell of a lot easier!

]]> By: Mike http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-24792 Mike Sun, 30 Mar 2008 13:05:02 +0000 http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-24792 @wyatt: Agreed about the docs. The recipes book may be more what you're looking for. @rick: Mongrel cluster behind Apache mod_proxy FTW. @wyatt: Agreed about the docs. The recipes book may be more what you’re looking for.

@rick: Mongrel cluster behind Apache mod_proxy FTW.

]]> By: Rick Altherr http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-24787 Rick Altherr Sun, 30 Mar 2008 00:45:05 +0000 http://blog.hackerforhire.org/2008/03/29/rails-with-calendar-date-select/#comment-24787 Yes, I went down this same path when writing my first Rails app. After getting all of the site functional, but ugly as sin, I gave up. If you read enough guides and stumble onto the correct functions, Rails can be easy. The main problem is that there is no definitive guide for what everything does. The documentation is designed as a reference which means you need to know what you want to use before you can see what it does. Then I started looking at what happens on the server side. Running CGIs directly from apache is generally a poor performer. There was a mod_ruby project similar to mod_perl, but they decided this was a bad direction and subsequently stopped development. FastCGI is purported to be a great savior for performance, but when I was playing with Rails, Apache 2.0 had no FastCGI support and it didn't look like it was going to happen anytime soon. So, if you don't mind a few seconds between pages, Rails is fine. I'm now headed in a direction designed more around having a dynamic backend that generates static pages. For things like blogs, calendars, etc, that puts the dynamic portion in the correct place, at the time of change, not on every view. Clearly for some types of sites, you still need all the dynamic pages for every view. I'm not sure what the best option there is, but I doubt I would choose Rails, PHP, or Perl ever again. Yes, I went down this same path when writing my first Rails app. After getting all of the site functional, but ugly as sin, I gave up. If you read enough guides and stumble onto the correct functions, Rails can be easy. The main problem is that there is no definitive guide for what everything does. The documentation is designed as a reference which means you need to know what you want to use before you can see what it does.

Then I started looking at what happens on the server side. Running CGIs directly from apache is generally a poor performer. There was a mod_ruby project similar to mod_perl, but they decided this was a bad direction and subsequently stopped development. FastCGI is purported to be a great savior for performance, but when I was playing with Rails, Apache 2.0 had no FastCGI support and it didn’t look like it was going to happen anytime soon. So, if you don’t mind a few seconds between pages, Rails is fine. I’m now headed in a direction designed more around having a dynamic backend that generates static pages. For things like blogs, calendars, etc, that puts the dynamic portion in the correct place, at the time of change, not on every view. Clearly for some types of sites, you still need all the dynamic pages for every view. I’m not sure what the best option there is, but I doubt I would choose Rails, PHP, or Perl ever again.

]]>