From: David Vallner Date: 2006-12-19T03:38:56+09:00 Subject: Re: does Ruby generate WINDOWS and dialog boxes? --------------enigF84D23D031060A235C56E769 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Richard wrote: > The app structure I outlined, Firefox+Ruby+Rails+WEBrick+MySQL, all > runs on the client's machine (except for the database server). The > user machine(s) need not be connected to the Internet, though it/they > needs a LAN connection to a database server. So everything except the > data-store is "client-side". Do you agree? >=20 Yes. However, there's still the HTTP request divisor in the middle, with no / hacked push in the WEBrick -> Firefox direction. At least as far as I know, prototype.js, the Javascript library Rails uses for Ajax support, doesn't try to support any form of pub/sub messaging or anything close to sane event support in the push direction. Of course, it might be possible your application only needs to pull data. > Secondly, the kind of apps I've worked on (and plan to continue working= > on) all need robust user interfaces. Raw HTML is no doubt inferior to,= > say, Microsoft's MFC or Java's Swing. However, Rails code is run > through Extended Ruby (erb) which programmatically generates repetitive= > HTML, so it's pretty nice to use even absent a drag-n-drop GUI > builder. >=20 I don't actually find Swing superior to setup a UI, HTML, while flawed, mirrors the UI layout in its structure, which is a good thing. However, for me that is offset by having fine-grained data binding - for complex UIs, it rubs me in a better way than bending my code to be essentially request / (partial) response. >> or even deliver it cross-platform >> easily because of the dependency on native extensions. >=20 > Rails is based on Ruby. Ruby is based on C. And C is widely viewed as= > a hardware abstraction layer. So that stuff is already ported anywhere= > I'm likely to want to go. >=20 I didn't mean work in the first place. I meant keeping an up-to-date version on all the users' machines. Last time there was a thread on the subject of distributing whole applications with rubygems, I think there were quite a few gotchas mentioned. But you might want to search the archives for that to see if the approach is viable / what you'd have to work around. >> I'm not very sure how Rails would be suitable to make desktop >> applications, the framework doesn't seem to have a discernable core fo= r >> action processing >=20 > It implements an MVC architecture in a very neat way. The model > house/enforces the business logic. The views present data from the > models to the client, and pass back client actions as appropriate. The > controllers oversee the traffic between those layers. I haven't done > much of this yet, so it remains for me to see how well that works. >=20 No / weak / coarse-grained push from the model to the view would be a showstopper for me for the sort of problems where'd I use a rich GUI. >> that would be unaware of web idiosyncracies. I might >> be wrong. >=20 > That's a good point to consider. What sort of idiosynchrasies might > adversely affect this scheme, noting that we're planning for apps on > isolated machines (except for the dataset connection)? >=20 Nothing that's really a showstopper from this point of view, just the request / response / sessions clutter that's not really essential to the way I would model a rich GUI application. For me, it would involve working around those, maybe you have an architectyre / model in mind where the mapping is straightforward. >> Ruby is fine if you can juggle the complexity, but it requires more >> programmer competence and diligence for the software to be robust - a >> quality that grows with importance the closer to end users you get. >=20 > Isn't that true regardless of the language? >=20 Not on a quantitative level. Easily accessible metaprogramming facilities are a potential complexity explosion, and need competence and / or restraint to avoid abstraction leak between modules. (For example introducing a method to a class at a scope where it clutters in modules that probably won't use the functionality "because it's convenient that way".) >> ActiveRecord is just way too basic as an ORM >> solution and not much simpler to use once enough of its assumptions on= >> the data model and physical DB schema don't hold. >=20 > If you use Active Record Migration, the SQL database schema would > always be in synch, wouldn't it? And don't you value that Rails > automatically maintains a history of migrations so you can easily back > up to an earlier version if necessary; likewise for matching back up > with the program code so long as version control, e.g. Subversion that > Rubyists like. >=20 If creating a database schema from scratch, unless you hit some of the more obscure deficiencies of AR (2PC and the like), in your scenario it's probably fine. While migrations are indeed sexy, using them means you pretty much eschew the magic of AR, at which point it becomes only incrementally more convenient as an ORM solution rather than revolutionary. > An important service Rails provides, and that I love, is in generating > single and two-way linkages for one-to-many and many-to-many > relationships with one-liners and simple column-name standards for > keys. This I consider unforgivable brain-damage, AR should have supported database metadata investigation and looking at foreign key constraints out of the box. Same goes for migrations-generated schemas (I haven't really seen those, I admit.). >> As for MySQL, I more or less share the attitude of Austin Ziegler on i= t. >> Most of MySQL users are mentally stuck with v3.x and make data schemas= >> that would make an onion cry. >=20 > I've been using ver. 5 and the schemas Rails generates from migrations > seem OK to me. I particularly like the fact that this version supports= > transactions .. IMHO a "must" for app relying on database support. >=20 And only decades after all the competition. Currently, I don't see much of a reason why not to use MySQL in a general scenario (before concurrency handling considerations and load tests come into play), however I also don't see much of a reason to do so - I'll stay with religious opinions and stick to the featurefullness of Postgres. David Vallner --------------enigF84D23D031060A235C56E769 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) iD4DBQFFhuA9y6MhrS8astoRAjarAJ9PyzTvTaOVLI+PIsuvA2YQrFy6ggCXcDYC Ux7Zd76b9RTrm95gjCVCfw== =m9jl -----END PGP SIGNATURE----- --------------enigF84D23D031060A235C56E769--