Found a blog post where someone was trying out Rails and PHP. (I don''t think he was using a MVC framework in PHP.) He liked Rails for CRUD, but doesn''t care for the limiting the Object-SQL metaphor pushed him into: http://rubyurl.com/BauCj This does bring up a good question that I''ve encounted with frameworks: how do you deal with an application where you may have data you need to extract from a database and toss on to a page, especially in cases where you deal with lots of aggregates. If you have a ''Users'' class but you need to generate ''Stats'' based on when users are logging in or how much the average user is paying for ''Candy'' or how many times he''s posted in the ''Forum'' this week, where is the logical class to add these aggregate type functionality to? Toss it in User? Forum? Candy? or do you breakout additional classes: UserStats? UserForum? UserForumStats? ForumStats? CandyStats? At what point do people get lazy and just start tossing it into a base class like User and call it close enough? I''d love to hear how you guys deal with this type of thing -- Ben
Its the user's stats right? Add a method to user called .compute_stats and call it using script/runner from cron once a day. Even easier then that, make the stats update real time by creating observers for Candy and Forum which update the corresponding fields in the users model. Cheers. About the blog post: Keep in mind that rails has certain requirements on the experience level of the user. As a rule of thumb the more advanced you are in your programming career the more likely you are to appreciate rails (with a few exceptions). This is evident by the daily adoption of rails by high profile people from the programming community. i quote: "I think that the answer has to do with the fact that web applications — whether producing HTML for people or XML for machines — are really about views, not objects. In anything but the most trivial cases, the views involve information from many different types of objects merged together to create a new object type" yikes> This does bring up a good question that I've encounted with > frameworks: how do you deal with an application where you may have > data you need to extract from a database and toss on to a page, > especially in cases where you deal with lots of aggregates. > > If you have a 'Users' class but you need to generate 'Stats' based on > when users are logging in or how much the average user is paying for > 'Candy' or how many times he's posted in the 'Forum' this week, where > is the logical class to add these aggregate type functionality to? > > Toss it in User? Forum? Candy? or do you breakout additional classes: > UserStats? UserForum? UserForumStats? ForumStats? CandyStats? At what > point do people get lazy and just start tossing it into a base class > like User and call it close enough? > > I'd love to hear how you guys deal with this type of thing -- > > Ben > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don't suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Jun 12, 2005, at 9:02 PM, Tobias Luetke wrote:> Its the user''s stats right? > > Add a method to user called .compute_stats and call it using > script/runner from cron once a day. > Even easier then that, make the stats update real time by creating > observers for Candy and Forum which update the corresponding fields in > the users model. >There''s some sort of assumption you''ve made here that I''m not quite getting. In the scenario above, is there a ''stats'' table in the database where you would store the results of compute_stats? I''m trying to accomplish a similar task in my application, so I''m curious about this. If there is such a table, why would you choose a table over generating the stats via a query? (That is, why duplicate information, even if the duplication is automated, via an observer?) And in the case of generating stats via a query, how do you deal with what the author of the blog calls "results that do not involve full objects" ?> Cheers. >Thanks for sharing your way of thinking in Rails. I often find your idioms to be very useful :) Duane Johnson (canadaduane) _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 6/13/05, Tobias Luetke <tobias.luetke@gmail.com> wrote:> Its the user's stats right? > > Add a method to user called .compute_stats and call it using > script/runner from cron once a day. > Even easier then that, make the stats update real time by creating > observers for Candy and Forum which update the corresponding fields in > the users model. > > Cheers. > > About the blog post: Keep in mind that rails has certain requirements > on the experience level of the user. As a rule of thumb the more > advanced you are in your programming career the more likely you are to > appreciate rails (with a few exceptions). This is evident by the daily > adoption of rails by high profile people from the programming > community. > > i quote: > "I think that the answer has to do with the fact that web applications > — whether producing HTML for people or XML for machines — are really > about views, not objects. In anything but the most trivial cases, the > views involve information from many different types of objects merged > together to create a new object type" > > yikesAlso bear in mind that this is David Megginson, Creator of SAX. I'm pretty sure he knows what he's doing, however he's definitely a *low level* kind of guy.> > This does bring up a good question that I've encounted with > > frameworks: how do you deal with an application where you may have > > data you need to extract from a database and toss on to a page, > > especially in cases where you deal with lots of aggregates. > > > > If you have a 'Users' class but you need to generate 'Stats' based on > > when users are logging in or how much the average user is paying for > > 'Candy' or how many times he's posted in the 'Forum' this week, where > > is the logical class to add these aggregate type functionality to? > > > > Toss it in User? Forum? Candy? or do you breakout additional classes: > > UserStats? UserForum? UserForumStats? ForumStats? CandyStats? At what > > point do people get lazy and just start tossing it into a base class > > like User and call it close enough? > > > > I'd love to hear how you guys deal with this type of thing -- > > > > Ben > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > -- > Tobi > http://www.snowdevil.ca - Snowboards that don't suck > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- Cheers Koz _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails