Ali Imran wrote: > <% > > @obj= params[:category] > > @cat...@obj["catid"] > > @newrec= Category.new(:catid=>@catid) > @newrec.save > > %>
As far a I see it there are two primary patterns that you may not be accustomed to coming from the PHP world. Plus one principal you may be struggling against. Patterns: 1. Model-View-Controller (MVC) 2. Object Relational Mapping (ORM). 1. Rails conforms, rather strictly, to the Model-View-Controller (MVC) design pattern. There are many articles available on MVC. Learn it, live it, & love it. Otherwise, you'll continue to struggle with Rails, and it will seem to fight against you. 2. ActiveRecord implements the Object Relational Mapping (ORM) design pattern. ORM is designed to abstract away SQL generation from higher level business logic. There are a few distinct advantages to this abstraction: a) Business and application logic are written a single language syntax, Ruby. b) SQL generation is handled by database adaptors, which hide (abstract) business logic from database implementation details. The underlying database can be easily replaced with an entirely different database engine without having to rewrite application and/or business logic. Principals: 1. Convention Over Configuration Convention Over Configuration was one of the primary principals that drew my interest to Ruby on Rails. For example, I notice that you mentioned a column named "catid." It appears that this column may be serving as the primary key of the "categories" table, which would be represented by the "Category" class. The Rails convention would suggest that the primary key of this, and any other, table should be named "id." The idea put forth by Convention Over Configuration is to make certain "default" assumptions as follows: A model named "Category" would expect a database table named "categories" containing a primary key named "id." In nearly all cases these "defaults" can be overridden, but learning and following the convention can greatly ease the burden of development and provide consistency both within a project and across projects. The sheer lack of convention, and the hundreds of configuration files that weigh down the development process of most Java based web frameworks led me to investigate alternative languages and frameworks for building web applications. My discovery of Ruby on Rails was a delightful surprise. It is a framework that "thinks" the way I think. I was hooked from the start. Programming in Ruby reminded me of why I got into computer programming in the first place. I've had more fun learning Ruby on Rails, and developing applications with the framework than in the entirety of my relatively long Java career. I'm still mostly stuck in the Java world for my day job, but at least I can enjoy the joys of RoR for my personal projects. I say all this for one primary reason, which is to say, "Approach learning Ruby on Rails on its terms, not on your own. Don't fight against its patterns simply because you did things a different way in other languages or frameworks." I hope you are soon able to embrace of beauty, consistency, and solid foundation that Ruby on Rails provides. Good luck and have fun. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
