× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




On Aug 21, 2006, at 10:02 AM, Joe Pluta wrote:

From: Jerome Hughes

The scaffold is a basic one table editor, and most real views require
data from more than one table. This is handled in the model with
relationships, and then controllers use the relationships to load
variables that are passed out to the views for rendering. Just
methods on objects, no SQL written, all of it generated based on the
model. Believe there are better paging alternatives available or on
the way, need to get more info on that.

I understand. EGL does the same thing, except that you explicitly define the fields in the record, which is nice when you are only accessing a few
fields from the file.

Not yet sure if the generated SQL always gets all fields or not, will watch for that, can see the SQL statements in the console as the app runs.

Ruby is a "meta-language" which allows the creation of
domain specific sub-languages for handling these sorts of issues, the
sub-language code is still in Ruby syntax, but with established
conventions for handling the problem domain.

See, this is where I get off the bandwagon. While I'm sure there are a lot of valid academic reasons to use phrases like "domain-specific language", Ruby isn't doing anything we don't do when we write Java classes or even ILE
subroutines.  I can (and often do) define "conventions" when writing
applications: type 3 objects don't get inventory allocated, warehouse one is used for dropships, and so on. In fact when the name of something magically determines what it does, I tend to call that "hardcoding", not convention.

Personally, I'm not a big fan of magic, either in applications or in
languages.  I prefer my rules spelled out where I can see them.

OK, sounds like didn't explain that as well as intended.

Rails is using the meta-language capabilities of Ruby when faced with these sorts of challenges instead of going to an XML config file, so everything stays in one language.

Have seen this mostly thus far in migrations and in fixtures but sure they are also in other places.

Migrations are for creating and adjusting table structures, these provide up and down methods that contain Ruby statements defining columns to get from present schema state to desired schema state and back in the other direction.

Fixtures are for auto-loading sample test data used in automated tests each time those tests are run, which is each time rake is run.

So these are not things that developers using Rails are creating, necessarily, though they can, too, once understanding is in place, but things that they are using because the developers creating Rails have used them and they are now the way to go to get the development tasks done easily. Part of the structure, if you will.

But that won't stop me from taking a look at RoR to see where it does well.
Ror seems to have a bit more traction than Python, so we'll see if it
continues.

Glad to see you're continuing to look at it, think you'll be pleasantly surprised as you get deeper.

Really don't know much about Python beyond the significant white space thing so many love to hate, but have an image that it's sort of like PHP, in that it's a nice enough scripting language, but sort of general purpose, and so leaving many more architectural decisions to the developer than RoR does, which can lead to a much wider range of bad to good implementations. If the developer is experienced, expect a good structure and understandable code, otherwise it could be anything.

One of the advantages of Rails' opinionated approach may be that even beginners are guided toward a long-term maintainable structure.

thx & hth,

--Jerome


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.