|
If you're just testing why not use the absolute path? Or an environmental variable if for some reason you want to deploy it to stage or production.
|
#
¿
Nov 11, 2007 15:28
|
|
|
|
| # ¿ Apr 19, 2024 09:06 |
|
|
zigb posted:The Bad: Maybe I'm missing something, but why are you running FastCGI for your development server? If nothing else, it's why you were having to reload after changing code in your lib directory. I mean, the whole point of FastCGI is that it doesn't have to reload libraries for every request.
|
|
#
¿
Nov 20, 2007 14:57
|
|
). Under Apache/FastCGI/RoR there are too many times we need to restart Apache. Changed something in environment.rb? Restart Apache. Added/Edited something in the /lib path? Restart Apache. This makes any sort of iterative development of libs/mixins a huge pain in the rear end. Particularly since I have to go beg the sysadmin to restart Apache.. How is this even considered acceptable? Is it just assumed that one server will run only one RoR app? There are live apps being taken offline every time I need to update a library.
|
skidooer posted:I suppose it might be a little daunting for the first time user. Honestly, I prefer to just read the source code anyway. Why bother with someone's english interpretation when you've got perfectly good source code to go by? Why read source code when you have a perfectly good English explanation to go by? Of course in Rails you almost never do, but that's just a weakness of Rails more than anything else.
|
|
#
¿
Nov 20, 2007 19:38
|
|
|
zigb posted:Taking your second statement first, is a controller's initialize method not the best place to put code that I want executed for each action? It seems DRYer than making a separate method and calling that from each action. Sucks about your development environment, that's ridiculous. Anyway, what you're looking for here is before_filter. http://api.rubyonrails.com/classes/ActionController/Filters/ClassMethods.html In Rails tradition the docs are lovely, but essentially you can do: code:code:
|
|
#
¿
Nov 20, 2007 23:15
|
|
|
skidooer posted:I'm not convinced it's better, but I do like some of the aspects of it. Thoughts? I can definitely see where it would be helpful if you have a different group of people creating the application logic and the actual page design. Right now the view is where they sort of collide, but by separating views and templates out even further this way you can keep them at least a little bit more separated. On the other hand if your designers are like mine, they just tell you what it should look like and you code the whole thing. I think if this is the case it's taking separation of logic and design a little bit too far. Basically too much complication for not enough gain.
|
|
#
¿
Nov 28, 2007 14:40
|
|
|
Pardot is right about it not being RESTful, but it's usually OK to put it on the Users controller if you have a small site. To do that:code:The named path for that will be login_users and the URI will be '/users/login'. The path is different than you said but that way it's clearer that login is a method that applies to a collection of users.
|
|
#
¿
Aug 2, 2008 19:54
|
|
|
luminalflux posted:I'm starting out with a project in Rails, and have a couple questions: The Rails folks don't believe in foreign keys so you probably won't ever see support for them in core. It's stupid, but one of the many downsides to Rails being "opinionated software" is when their opinion is wrong. There's a bunch of plugins you can get that will do it, though, try Foreign Key Migrations. quote:- How do I create functions like 'edit_thingies_path' used in link_to in my view for other controller methods? I spent a 3 hour train ride trying to figure this out but all I got were stack traces and I reverted to specifying the action and arguments manually. Depending on how these are routed they should be created automatically. If you use named routes you just refer to them by the name (no controller or anything), or if you use the :member or :collection options to map.resources it should be, for example, do_something_thingies_path. See: http://api.rubyonrails.org/classes/ActionController/Resources.html for mapping resources and http://api.rubyonrails.org/classes/ActionController/Routing.html for named routes (among other things). You can run "rake routes" to see a pretty good list of all your routes, including the named methods. Carabus posted:So another noob question here, but more open-ended. I'd like to know if the method I have been using for constructing hashes from queries is particularly bad. It varies with the circumstances but here is a representative example: Is there any reason you're not using relationships to do this? wunderbread384 fucked around with this message at 03:06 on Aug 5, 2008 |
|
#
¿
Aug 5, 2008 02:52
|
|
|
So here's the thing about ActiveRecord and foreign keys. I completely buy the argument that ActiveRecord should be handling your referential integrity. That's something that should be handled at the model layer, not in your lower level data layer. But here's what I don't get. ActiveRecord wraps database transactions and all kinds of queries, treating the SQL (and the database) not as the final goal but as a means to an end. They need to store an object, so they use a SQL INSERT and throw it in the database. They need an atomic operation, so they wrap it in database transactions. For whatever reason though they draw the line at foreign keys. Why not wrap foreign keys to perform referential integrity just like you wrap database transactions to perform atomic operations? I think what happened is they get caught up in treating foreign keys as an end in themselves and forget that they're really just a tool for getting the job done. Probably this is because a lot of database people TREAT foreign keys as an end rather than a means, but that doesn't make it true. So rather than using foreign keys as a tool they explicitly re-invent the wheel and re-implement referential integrity checks in their code because they (probably correctly) assume that RDMSs are going out of favor for storing objects. And that's all fine, it certainly works OK most of the time, except the problem is that we DO use RDBMSs underneath, at least for now. And by rewriting referential integrity checks in ActiveRecord rather than just wrapping the existing database functionality they miss out on all the very real benefits that foreign keys give you in an RDBMS environment. Plus you'd think they of all people should understand DRY and the advantages of using a heavily tested codebase rather than rewriting it. Of course the real tragedy of all this is that they're forcing people who either need or want foreign keys to either give up on ActiveRecord or explicitly set foreign keys through plugins or vanilla SQL. And that's the OPPOSITE of what they intended, which was for model layers to be agnostic to whether it's using an RDBMS. Instead of ActiveRecord implicitly detecting whether to use foreign keys and making the code future proof they're forcing people to explicitly declare their keys and locking them in to an RDBMS. To me it just seems like they're trying to make a statement (which is probably correct) about which way storing objects is headed, but doing it in such a misguided way that they're actually going to move many codebases backwards. I do love opinionated software most of the time...I think it's what kept Rails from swallowing the XML/WS-* pill. Carabus posted:You mean :include and such? I started off just using select and haven't had any use for anything else until joins were called for when displaying informative results like names efficiently. Running calculations on the hash only requires the ids (foreign keys) which the favorites table provides kindly. I don't know if you saw what skidooer posted above you but that's essentially what I was getting at (except he said it in a way more understandable way). wunderbread384 fucked around with this message at 02:35 on Aug 6, 2008 |
|
#
¿
Aug 6, 2008 02:32
|
|
|
That route looks like it should work, what do the logs say when you make the request? It should have the name of the action and controller that was called in there, plus the parameters. Edit: Also, is the method private maybe? I would imagine Rails should throw an error if that happens but many things in Rails don't happen the way I imagine. wunderbread384 fucked around with this message at 01:30 on Dec 20, 2008 |
|
#
¿
Dec 20, 2008 01:19
|
|
|
Bathroompants posted:I'm really new to rails, so please don't take it too hard on me if I'm trying to do something really dumb. If you're just running migrations (rake db:migrate) then you can do this to the production environment, which I assume is your webserver's database, by doing "rake db:migrate RAILS_ENV=production". This will run any migrations on your local computer but connect to the production database. Edit: Just realized that might be confusing. Your database.yml file probably has 3 different environments in it, production, test, and development. Development is probably set to your local machine, and rake will use development by default unless you tell it not to. wunderbread384 fucked around with this message at 02:30 on Apr 28, 2009 |
|
#
¿
Apr 28, 2009 00:42
|
|
|
Speaking of GitHub, am I the only one who thinks it being so easy to fork repositories might be a bad thing? I wanted to use the couchrest gem, and it turns out there's like 3 or 4 different versions that have different features that would be nice. But they're pulled so infrequently that I had to merge a lot of it myself...and of course if I post it to GitHub that's yet another project and yet another pull request. It's almost too cheap to fork a repository compared to submitting a patch or bug report. I guess this isn't really a RoR question but...GitHub runs RoR so technically...
|
|
#
¿
Apr 30, 2009 01:50
|
|
|
|
| # ¿ Apr 19, 2024 09:06 |
|
|
NotShadowStar posted:Some use JRuby for production servers and I guess it'd be neat to latch onto existing Java libraries if you have the need, but the startup time is atrocious being the JVM and all. It would not be fun to develop on. Also when you're using JRuby there needs to be JRuby specific gems versions if the original gem is C-based. I've been using JRuby for both production and development and the startup time isn't as terrible as you think. Running tests is definitely slower than on MRI, but autotest makes it pretty bearable by skipping the double startup you need to run the rake test tasks. Also with JRuby 1.3.0 Nailgun is integrated, which means that you run one JVM persistently in the background and any time you use JRuby it'll just farm out to that, nearly eliminating the startup speed problem. To be honest I haven't found the slower startup speed enough of an issue to try it, but it seems pretty sweet. My biggest problem with JRuby has been the gem incompatibilities you mentioned. And it isn't so much just the native gems, it's also any gems that have dependencies on native gems, which can branch out way farther than you think. Depending on what you're doing this could be more trouble than it's worth, but on the other hand using existing Java libraries is pretty awesome (I'm using CXF for SOAP, some XML parsers, Apache POI, and a graphing library at the moment).
|
|
#
¿
Jul 25, 2009 17:14
|
|