Thanks buddy, This is great help for just starter. I spend a lot of time on just to understand this MVC. You are right this is a big difference between PHP and ROR.
On Jun 24, 8:01 am, Robert Walker <[email protected]> wrote: > 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 viahttp://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.
