From: Richard Date: 2006-12-19T11:35:05+09:00 Subject: Re: does Ruby generate WINDOWS and dialog boxes? Hi David, I think we're converging to a solution. > > The app structure I outlined ... Do you agree? > > Yes. However, there's still the HTTP request divisor in the middle, with > no / hacked push in the WEBrick -> Firefox direction. ...Of course, > it might be possible your application only needs to pull data. OK, we'll have to wait and see on that, 'cause I don't know. > > Secondly, the kind of apps I've worked on (and plan to continue working > > on) all need robust user interfaces. ... > > ... 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. OK, another thing to wait on. > > ... So that stuff is already ported anywhere > > I'm likely to want to go. > 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. Gotcha. I just posed the question about handling upgrades to the app. I didn't think about Ruby gems. I thought I'd make the database server machine server as the developer machine as well as the config. mgmt machine. So when a database schema change is required, I thought I'd shutdown access to users and: - run "rake migrate" only on this machine - update the Rails app to relating to the changes in the database - update my test suite to test those changes (or write the tests first to satisfy some purists) - run my entire test suite until all tests pass - submit my Rails app to the version control system - broadcast a message to all users that the should update their version of app by getting the latest and greatest version? What do you think of that? > ... 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. I don't understand. I think this process works this way: The controller tells the model to cook up some data, suitably filtered and ordered, and keep it available for access by the appropriate view. Then the contoller tells the appropriate view to do its thing with the data, namely produce HTML with the data suitable tagged plus embedded Ruby and send that amalgam to the web-server. The web-server invokes Extended Ruby to process the "enriched" HTML and send the resulting vanilla HTML to the browser. Is my description of the process OK? Does "push" refer to the "web-server to browser" step? > > That's a good point to consider. What sort of idiosynchrasies might > > adversely affect this scheme ... > 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. Gotcha. But all the request/response stuff is on a single box, so the processing time should be a few milliseconds, don't you think? > For me, it would involve > working around those, maybe you have an architectyre / model in mind > where the mapping is straightforward. I've anticipating a dozen, maybe two dozen, tables with lots of one-to-many and many-to-many relations, somewhat complex updates which would be unpleasant to program were it not for transaction service for the DBMS. However, the amount of data in any transaction will be small. And the data transfers for display will be small, too, because all tables will be paged. > >> Ruby is fine if you can juggle the complexity ... > > Isn't that true regardless of the language? > 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".) I don't plan to intoduce that kind of complexity myself. I'm sure Rails itself employs some metaprogramming, but I'm confident that works well, requiring no meddling by me. > >> ActiveRecord is just way too basic as an ORM ... > > If you use Active Record Migration, the SQL database schema would > > always be in synch, wouldn't it? ... > 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. Cool! > 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. I plan to use mostly generated screens funtil I've got concept approval from clients. So I can use AR to painlessly regenerate any of them affected by DB changes. However, I also anticipate a number of screens with one or more tables with column-by-column table-sorting and filtering functionality. But most of that involves passing parameters in links that invoke a package that produces the required effect. I've got a demo of that working -- I just need to figure out how to package it. > > 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. Yea, but its only a few lines here and there. To me, it's really painless, especially considering what I've had to do with Oracle and SQL Sever using VC++. > > I've been using ver. 5 and the schemas Rails generates from migrations > > seem OK to me. ... > 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. I'm planning to look into the final choice of DBMS in the final stage of my current project. Concurrency handling and response times are certainly issues I'll want to address. Thanks for your ideas. Best wishes, Richard