Horst Herb wrote: > On Saturday 23 September 2006 21:49, Tim Churches wrote: >> well-written and rather Pythonic MochiKit Javascript library (by >> contrast RoR uses the Dojo Javascript library, which although capable of >> some slick client-side browser tricks and effects, is more than a bit >> horrifying when you start to examine the source code for it and the >> unspeakably horrible abuses of the browser document object models to > > I think you need to urgently revisit RoR. > > It does *not* use the Dojo Javascript library at all - AFAIK there have been > a > few proposals to use it for it's WYSIWYG editor, but that's all. > > Ajax in RoR is currently implemented by using the "Prototype" JS framework ( > http://script.aculo.us/ )
Sorry, my mistake. we've looked at dozens of Javascript libraries over the last few months and I mixed them up. As an aside, there is a useful overview of some the leading (relatively sane) Javascript open source libraries here: http://www.sitepoint.com/print/javascript-library > I am trying to implement an Addressbook in RoR, Django, Trax (PHP Rail like > framework) and Turbogears just for getting more familiar with the tools. > > What I'll explore is: > - lines of code for a simple CRUD interface > - ease of reading and understanding undocumented code (by presenting it to my > son who has only a very rough idea of Ruby and PHP but reasonable > understanding of Python) > - lines of code for text autocompletion boxes > - performance > - ease of installation and configuration > - ease of customization and expansion > > So far, in the first stage, RoR beats all others hands down in terms of > - ease of installation > - availability of documentation > - quality of documentation > - Ajax integration > > Tonight, with about of luck (and not too much demands on my time by my > family) > I might have implemented a few prototypes and I'll know more > > Proof of the pudding is in the eating, and as always I am really only > interested in a proof of concept solution and will leave the nasty footwork > to others I think this sort of test driving of frameworks - ideally a fairly extended test drive, is essential, but we should not collectively rely solely on Horst's opinion of the vehicle. > Like you, Tim, I'd prefer a Python solution. But I gather re-implementing a > framework of the quality and functionality of RoR just for the sake of > sticking to a closely related programming language is more work than the > other way round. Sure, but a) opinions of people I trust tell me that: a) Django and/or Turbogears are very nearly as good if not better than RoR; b) that RoR can end up being rather constraining and that breaking out of its framework model (when that inevitably becomes necessary) can be very tricky and c) one quickly misses the wide range of resources (both human and software) available for Python. However, I have not confirmed any of these opinions for myself - maybe in 2007 when I hope to have a bit more time for such things. Tim C _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
