Re: overriding on Rails: tables, foreign keys

[Jerome Hughes <jromeh@xxxxxxx>]

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