Johari Me

http://kevan.org/johari?name=JohanC

Something I tried too avoid...

I always been a strong Zope advocate, but I find myself willing to step of the band-wagon because Zope isn't developing in the direction that I like. It's starting to become something that I was trying to avoid when I "joined up" (that would be J2EE like mastodont frameworks).

As you might have notice I'm not a big fan of Zope 3, and I see Zope 3 (and CMF) as technologies that are blocking Zope from evolving into that I would like to have.
Also the key feature of Zope, the Object Database (ZODB) is starting to get in the way, it just hasn't evolved enough to battle the competition from the rising of the ORMs.

The main benefit of having an transparent object database in the bottom is that persistent isn't an issue, it's handled automatically. Well you get that with an ORM too, and you don't have to rely on the database to handle version, your don't get a rigid object hierarchy (in fact you can have high dimensional object hierarchies if you'd like), you have index and fast query facilities from scratch without having to define your model twice (once for the objects and once for the ZCatalog).

Conclusion, Zope was great when it came, it was new it was object-originated, it was dynamic typing and dynamic data models, it was fresh.

Now it grown out of proportion and does seem to keep up, it's heavy, it's a dinosaur.

Flexibility vs. Productivity

I've always been a fan of flexibility in the framework, it's something that attracted me with the Zope framework from the beginning (you could add a property to any object at any time without having to change your application model, the AM was in a sense real-time changeable.

Again quoting David Heinemeier Hansson:

"I often find I want to trade flexibility for productivity. i am fine with saying, I could just do it this way, or I could do it 10 times faster."

Now, David isn't just good looking and smart, he's "hyper cool".

I find that I now days also want to trade flexibility for productivity. I don't have the time configuring Zope 3 apps, I just want the damn thing on the net with a minimums of effort.

Ok, so I'm starting to compare Zope 3 and Rails. Not have had a particularly close look at Rails (yet) I'm starting to get the feeling that both Zope 3 and Rails try to do aspect-originated stuff.
The main difference is that Rails stay true to the philosophy of the language (Ruby) where Zope 3 stray of into different non Pythonic creations, adding the flexibility but with the cost of bad usablility. Rails stray for beauty in code, and I believe code is the best way to make programs, not configurations (which Zope 3 relies on heavily).

For where I am now Rails seems to lack the co-location problems (which IMO is one of the largest problems with Zope 3). Rails also seems more true to the MCV pattern, even though Zope 3 has that pattern, it's not very well constituted to the user (calling controllers view classes for instance, it's just confusing).

Ruby on rails Partials!!!

We do it right (when Zope doesn't).
Ruby on rrails have partial which are sub-template that ar like includes but like subrutins at the sametime, os you can pass arguments.

Well, that just kicks TAL macros in the ...

I rebember how surpriced I was when I realized that METALs didn't compile to "module like" objects ith sub-routines. Haven't use TAL since then (the system I made was just over complicated and ugle, and no I didn't put business logic in the templates).

More excellent quote from the creator of Ruby on Rails framework David Heinemeier Hansson:

"... because javascript is, what's the word, Horrible!"

Finally someone that can "think"!!!

"I like Ruby so much I want to use Ruby everywhere (in Ruby-on-rails), in the model, in the controllers, in the confituation, and in the VIEWS.
And now some of you who has been burned badly before by using a real programing language in the templates are screeming "NOOOO, you can not do this. If you do that the end of the world is coming, people will flood their views with logic and conditions, and it will be a mess and you never recover."
Ah, No! Because there is no such thing as taking the logic out of the view. The view will always have logic, it will always have loops it will always have conditions. You just call them something else if that make you feel good. your still putting logic in the view, and the key realization is that that's not a bad thing. Logic belong in view because we are making dynamic web applications not just this static things. So logic in views good!" -- David Heinemeier Hansson, creator of Ruby on Rails framework (freely quoted by me :-)
Told ya!