Hi, I haven''t stepped in here since RoR 0.6, so please be gentle... :) I got the following internal email this morning; and because I''ve only dabbled in Camping, Rails, and web aps in general--I''m a floating-point number cruncher guy--I thought I''d run it pass you before responding: I''m working on archiving [..] data for [a] project, and [the Principal Investigator] mentioned using Ruby as opposed to straight perl cgi. I am a "data modeler" and have just branched into the perl cgi arena, due to [staffing issues]. (Basically, they don''t have web programmers that can do anything other than ColdFusion). Anyway, I would like to meet with you to talk about Ruby and it''s pros/cons in general, and possibly in relation to the project [mentioned above]. I have heard that Ruby on Rails is only "easy" if your data model/schema is simple, and you only present one table''s worth of info on a form. I''ll bring a copy of the E-R diagram to discuss, if that will help in determining in Ruby is the right language to use for this application. I also have the forms defined in html (used these for working with [the PI] in determining what metadata to capture). It looks like I would have to "redo" all the html to use Ruby methods? I''m also interested in the "security" aspects of using Ruby. PHP (as opposed to ColdFusion) has been identified as having too many security issues and therefore not encouraged here, so I''m curious about Ruby/Ruby on Rails.... Oh, and the database is implemented in Postgres. Thanks in advance for any light you can shed. Regards, -- Bil Kleb http://fun3d.larc.nasa.gov --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Bil Kleb wrote:> > I have heard that Ruby on Rails is only "easy" if your > data model/schema is simple,We have 83 tables in our application, fully normalized, with a few de-normalized views. It is a very complex data model. It was based on an existing data model, so many of the tables have non-integer, non-autonumbering primary key columns, and we also have many join tables with composite primary keys made up of the parent foreign keys. BTW, we did have to write about 8 lines of custom code (in a plugin) to get the non-integer, non-autonumbering PKs to work with ActiveRecord''s existing methods.> and you only present one > table''s worth of info on a form.Not true, you can display as much or little information on a form as you want. We have several forms that display and allow entry of data from 6 or more tables. With transactions, we can update all or none, and we correctly display error messages for each field.> I also have the forms defined in html (used these for working > with [the PI] in determining what metadata to capture). It > looks like I would have to "redo" all the html to use Ruby > methods?Well, the best way would probably be to edit the HTML forms to insert embedded Ruby code to handle the dynamic aspects of the forms. This would convert them to ''RHTML'' forms, the standard way of writing Ruby forms. If it was very important to keep fully HTML forms, you can use other templating languages (like Cerise I think?) that use plain HTML and then substitute various DOM elements to put dynamic content in.> I''m also interested in the "security" aspects of using Ruby. > PHP (as opposed to ColdFusion) has been identified as having > too many security issues and therefore not encouraged here, > so I''m curious about Ruby/Ruby on Rails....No issues so far for us.> Oh, and the database is implemented in Postgres.We''re running Postgres 8.1.4 -- 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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
It''s hard to imagine that anyone who sees the kind of apps -- say, Basecamp? -- that are built with RoR could believe that Rails can''t work with data from more than one *table* per form. That particular rant aside, the ActiveRecord pattern has been around a long while (read: it''s had a while to evolve into an extremely useful design/architectural pattern), and it has rich support for joins and all the other SQL stuff you''d rather not write again and again. If there''s an edge case where Rails'' ActiveRecord implementation does not naturally cover the query you want, just use find_by_sql and write SQL to your heart''s desire. There is no law that says you shouldn''t have more than one kind of object per form or page. Master/detail forms often do this. Perhaps I misunderstood the comment. Regarding the HTML, Rails does essentially the same thing ASP.Net, PHP/Smarty and a number of other frameworks do: It uses a decorated HTML template that contains a certain amount of code. In Rails'' case, it RHTML. Will you have to redo your HTML completely? No. Will you want to redo it some? Probably. Rails provides form helpers that afford a good deal of consistency and predictability that raw HTML coding might not. By the way, you''d be faced with the same hurdle with any templating language. As an aside, why are you writing HTML prior to choosing a platform? Finally, regarding security, the biggest security risk I know of is at the application design level. There is no hack-proof platform, but most successful ones are relatively mindful of security. As the application architect, it''s up to you to specify your security requirements and devise a plan that proves that you have met those requirements. The beauty of open source is that should you encounter a hole, you can plug it. Pronto. HTH Bil Kleb-2 wrote:> > Hi, > > I haven''t stepped in here since RoR 0.6, so please > be gentle... :) > > I got the following internal email this morning; and > because I''ve only dabbled in Camping, Rails, and web aps > in general--I''m a floating-point number cruncher guy--I > thought I''d run it pass you before responding: > > I''m working on archiving [..] data for [a] project, > and [the Principal Investigator] mentioned using Ruby > as opposed to straight perl cgi. I am a "data modeler" > and have just branched into the perl cgi arena, due > to [staffing issues]. (Basically, they don''t have web > programmers that can do anything other than ColdFusion). > > Anyway, I would like to meet with you to talk about Ruby > and it''s pros/cons in general, and possibly in relation > to the project [mentioned above]. > > I have heard that Ruby on Rails is only "easy" if your > data model/schema is simple, and you only present one > table''s worth of info on a form. I''ll bring a copy of > the E-R diagram to discuss, if that will help in determining > in Ruby is the right language to use for this application. > > I also have the forms defined in html (used these for working > with [the PI] in determining what metadata to capture). It > looks like I would have to "redo" all the html to use Ruby > methods? > > I''m also interested in the "security" aspects of using Ruby. > PHP (as opposed to ColdFusion) has been identified as having > too many security issues and therefore not encouraged here, > so I''m curious about Ruby/Ruby on Rails.... > > Oh, and the database is implemented in Postgres. > > Thanks in advance for any light you can shed. > > Regards, > -- > Bil Kleb > http://fun3d.larc.nasa.gov > > > > >-- View this message in context: http://www.nabble.com/Ruby-web-ap-FUD-tf2419247.html#a6748040 Sent from the RubyOnRails Users mailing list archive at Nabble.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 rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---