Re: Ruby on Rails?

>> But the overall concept is the same as in WOF and other frameworks.
>
> Or in other words: the overall concept is NOT the same as in WOF.

I was talking about sessions, not components. The session concept is 
the same in both frameworks, the implementation certainly isn't.

> RoR has no nested component processing at all.

Maybe because it doesn't have (WO-style) components at all ;-) Rails 
uses partials to facilitate reusable templates. Partials can be nested.

> "Rails developers don't repeat themselves" - where do you repeat 
> yourself in WO?

If you define an attribute for an entity, for example? Let's see...

Defining the attribute name (1) and the column name (2) in the EOModel. 
Adding a getter to your business class (3), adding a setter to your 
business class (4). Creating the actual column in the database (5).

That's four repetitions, assuming that the attribute name and the 
column name match (which is usually the case). I also assume that you 
prefer real accessors over storedValueForKey() typecasting orgies. The 
fact that you can auto-generate both the business code and the schema 
is a neat automation, but it doesn't eliminate the duplication.

> Why is configuration a good thing? Because configuration can be 
> processed (/read) by tools. Whether those are D2W rules, WO component 
> bindings or EOModel mapping.

Configuration files are a good thing because they can be read by 
tools?? LOL. Rails eliminates the need of configuration files in favour 
of smart conventions. You only need to write minimal configuration if 
you break the convention (for a good reason, hopefully).

> In contrary, with the latter he gets plenty of additional modeling 
> feature w/o resorting to code and probably most important: database 
> independence and redeployment.

Most of the modelling features in EOF are available in ActiveRecord as 
well, plus some more (e.g. aggregation, ordered list and tree 
relationships). The fact that the model is expressed in code has no 
disadvantages over an external mapping. Database reflection is a smart 
technique and it's independent of the underlying RDBMS.

> Now why is RoR popular? I think those things play into that:
> a) hype. hype. and again: hype.

What you mistakenly call a hype is the fact that Rails is extremely 
well received by many acknowledged developers around the world. They 
learn about it, they love it and they tell others about it.

> b) Prototype/Scriptaculous

Go find me another framework that integrates AJAX that well.

> c) nice web design / good documentation

Q: Why do so many great software projects never get the attention they 
deserve?
A: They sit on an ugly sourceforge page and nobody bothers to write 
documentation.

> d) scripted language

Having an interactive Ruby console to your application is simply 
priceless :-)

> IMHO RoR is a nice framework and well suited for doing simple CRUD 
> apps quickly. It just doesn't provide anything new and hardly what is 
> already available in other frameworks. This doesn't make it worse but 
> it doesn't make it better either :-)

I seriously doubt your opinion is based on actual research. I'm sure 
that, if you examined Rails in more detail, you'd find tons of cool 
stuff not available in other frameworks...

> Eg I find RoR URL mapping _extremely_ disappointing compared to 
> ZPublisher.

...and while you're at it, you might want to take a look at the 
possibilities of defining custom routes.

> Also I'm really tired of the anti-XML attitude in RoR.

The few configuration files in Rails are either plain Ruby scripts or 
YAML. Both is by far more readable than XML and fits better into the 
overall concept of RoR. If you need to generate or parse XML there are 
Ruby libraries readily available for this purpose.

WO doesn't make extensive use of XML either. (EOModel, WOD files, D2W 
rules...)

--

Andreas