Good afternoon, I have been developing in mod_perl for many years, and my livelihood is based on being productive with it. I've spent the past week reading and testing RoR and it does look good. But before I take the plunge for my next project, I was hoping to hear from other mod_perl switchers. One of the main reasons I like mod_perl is code flexibility. I like being able to insert code into any of Apache's request phases. I like the code base available through CPAN. I like the execution speed of registry scripts and mod_perl handlers. And maybe most importantly, I like my comfort in working with a 'known' entity and refined coding style (iow, I've been using it for so many years it has become an old & dear friend). (For small apps, I generally use CGI::Application and HTML::Template along with DBI/DBD::mysql. For larger projects, I use whatever I feel is appropriate, probably not CGI::App.) I'm concerned I might lose to much of what I'm used to in switching to RoR. I can see what I would gain by switching, but what would I lose? For example, I haven't yet worked out the flow from page to another (in RoR) when there are validation errors. I have a well-tested methodology when using CGI::App's run modes (along with Data::FormValidator). RoR also seems to make a lot of DBI calls when creating (& populating) ActiveRecord objects. And that seems to be compounded when multiple components are called in one request cycle. Eg. if I have a LoginUser object; it seems to get re-created when I redirect from one page/component to another. Any comments or pointers to documentation for switchers would be greatly appreciated. I have looked at alternative languages many times over the years, and I've never gotten even close to switching from mod_perl. So getting this close with RoR is sort of exciting. Thanks, Charlie
on 2005-12-29 08:42
on 2005-12-29 10:28
Hello Charlie. I've written several major apps in mod_perl. The most notable one was over 60,000 lines of OO Perl. I *love* Perl and everything about it. I've used mod_perl for the reasons that you've stated. Changing the way that Apache works is quite heady, and sometimes quite useful. The reason that I'm a RoR switcher (and I'm converting a mod_perl app to RoR as my first project as we exchange emails) is for all the reasons that you've stated! :-) From my perspective, the "problem" with Perl, Python, PHP, or basically any and all historical web development environments is that they came to us piece by piece, generally made useful by cobbled together modules (CPAN) of competing designs and implementations of templating systems (HTML::Template, Text::Template, Template Toolkit, Roll your own) application structures (Mason, CGI::App, Roll your own) session handlers (Apache::Session, CGI::App::Session, Roll your own), and object-relational mappers (Alzabo, Class::DBI, Roll your own). RoR is a coherent snapshot of a single person's vision of how web apps should be written. Most things are different, many things are strange (particularly at first) but *everything* is included, and works together, and *hangs* together due to that single vision. It's this single mindedness that makes RoR brilliant, and it seeps out in so many ways that you've already noticed. Imagine rewinding your many years of mod_perl experience, knowing then what you know now, and having everyone else in the mod_perl community in agreement on all subsystems from session, object-relational mapping, form validation, application structure (MVC). Imagine how easy it would be to maintain those years worth of apps, and to get people to help with those old apps, and new ones too. That's my future with RoR, I'm absolutely certain of it. RoR isn't about Ruby. It's about the big picture, and the powerful opinions that DHH has loosed on the world. I'm glad he picked Ruby, because if he had implemented on something else, the message would have been diluted because it would have been just another cog in the machine. -- -- Tom M.
on 2005-12-29 16:24
Good morning, On 29/12/05 at 12:25 AM -0800, Tom M. <firstname.lastname@example.org> wrote: >The reason that I'm a RoR switcher (and I'm converting a mod_perl app >to RoR as my first project as we exchange emails) is for all the >reasons that you've stated! :-) I still haven't decided yet whether to take the plunge, but I will decide within the next 24 hours. Your description of (& experience with) mod_perl sounds very familiar to me. And your explanation of why RoR is so good also makes sense. My eyes are blurry from another long day of reading & experimenting; I guess I'll sleep on it (one more time) and get started with my next project tomorrow, hopefully with RoR. One stumbling block I had was choice of text editor. My testing so far was using TextMate, and I can see why people like it. But giving up BBEdit really is not an option for me, and I just found the Ruby language module for BBEdit (yay). Thanks for your feedback on both mod_perl and RoR; it has helped me feel more comfortable with my decision-making process. If anyone else has any mod_perl comments/comparisons, I'd love to hear them. Thanks, Charlie
on 2005-12-29 18:04
On Dec 29, 2005, at 6:20 AM, Charlie Garrison wrote: > far was using > TextMate, and I can see why people like it. But giving up BBEdit > really is not > an option for me, and I just found the Ruby language module for > BBEdit (yay). Funny. I was a huge BBEdit guy, but after using TextMate there's no going back for me. TextMate has more key commands, better Services integration, better replacement macros, more key commands, costs less, tastes better, etc. Heck, a new version of TextMate costs less than a BBEdit upgrade! What makes BBEdit irreplaceable for you? All the things that I thought were missing at first ended up being there, just hiding a bit. Oh, the file drawer rocks, BTW. :-) -- -- Tom M.
on 2005-12-30 06:24
Good afternoon, On 29/12/05 at 8:03 AM -0800, Tom M. <email@example.com> wrote: >Funny. I was a huge BBEdit guy, but after using TextMate there's no >going back for me. TextMate has more key commands, better Services >integration, better replacement macros, more key commands, costs less, >tastes better, etc. What sort of extra key commands, since all the menu items in BBEdit can be customised. I never (or almost never) use services. What are replacement macros? Are they the same as snippets? If so, what do they offer that is better than BBEdit glossary items? >Heck, a new version of TextMate costs less than a BBEdit upgrade! Cost doesn't bother me too much since it's only a small part of 'computing' expenses. But if cost was an important factor, then I choose BBEdit since I've already paid for it. >What makes BBEdit irreplaceable for you? All the things that I thought >were missing at first ended up being there, just hiding a bit. I have so much of my muscle memory, AppleScripts, etc tied to BBEdit. Also, having features (such as toggle comments) hidden in TextMate doesn't make it easy to switch. It took me days before I could figure out how to do something as simple as toggle comments (no apparent menu command for it). I still haven't worked out dragging text; it keeps ending up somewhere other than where I want it. I don't like the tabbed browsing; I much prefer the document drawer. I can't find anything close to the HTML editing tools that BBEdit supplies. But primarily, I'm very happy with BBEdit and see no reason to learn another text editor if I don't need to. The only thing I've seen with TextMate that I would like to see in BBEdit is code folding, and I can live without that. >Oh, the file drawer rocks, BTW. :-) I like the file drawer, but not enough to prefer it over the document drawer of BBEdit. I could probably be convinced to switch, but right now I'm not even close to being willing to give up BBEdit. Charlie