There seem to be some misconceptions regarding RoR If we are going to seriously discuss which development platform to use, we have to stop spreading unfunded FUD first
1.) RoR does *not* constrain in any way. This myth probably came up from RoR's "scaffolding" feature - sort of a web application generator. It creates you a working starting point which you can either modify to your heart's content or replace completely. You can mix and match any valid HTML, ruby and Javascript code. I know for sure because I just did in my Addressbook experiment. 2.) RoR's object-relational layer does not constrain in any way either - you still can use whatever SQL statements you want directly, any time. Just pointless doing so. Again, I know from doing. There is a good introduction called "4 days on Rails". http://www.rails4days.pwp.blueyonder.co.uk/Rails4Days.pdf I did it this afternoon in about three hours, modifying it to create an "Address Book" for patients - anybody with just a little previous web programming experience can realistically do it in a single afternoon (3-4 hours) We know by now what we want I think: a practice / EHR software package that will run on anybody's platform of choice, installable without any hassles, with good performance, slick and responsive user interface, easy to maintain and update Our experience so far with desktop apps and UI toolkits was that at least installation and deployment will be a major headache. Some parts (e.g. WYSIWYG text processing) have been found wanting with the available toolkits, and using 3rd party external software just adds more trouble to the installation/maintenance/updating headache The argument against web interfaces has become obsolete since web apps like gmail have demonstrated that it can be done (and how it is done) - and they would even provide the missing widgets (TinyMCE or FCKEditor are good enough to type referral letters etc. and allow even progress notes with pictures integrated into the text) Development tool documentation has been another headache in previous attempts - while Python documentation as such is excellent, this is not the case for the 3rd party libraries we used. RoR is as good as Python in this aspect - the copious free online documentation is complemented by fantastic books available (eg "Pragmatic Programmers" series, and the usual excellent quality publications from O'Reilly's or Mannig or APress - why, there is even a "Ruby on Rails for Dummies" available now. That in itself is already an indicator to take it serious - or, Tim: have you seen any O'Reilly (or similar) books on Turbogears or Django? Other issues I noted when comparing Ruby and Python: - Regular expressions are easier and more intuitive to use in Ruby - and we'll need lots and lots of them (and other forms of text processing) to let an EHR system do what we want it to do (= making our lives easier) - Ruby is better integrated into the net: starting with the "gem" online code / module repository, svn integration etc: this will make software maintenance much easier without having to reinvent the wheel Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
