Nick - I've done quite a bit of zope work for the past few years, so see
below for a [long!] brain dump of some things to consider.

[the situation you describe of a zope shop considering possible move to
rails is a pending issue for the company i'm working with right now, so i've
been thinking about some of these issues anyway]

Are they also looking at other python frameworks?  e.g., TurboGears or
Django seem to be the two main web frameworks currently evolving in the
python world

~ Deb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

First, depends on lot on what their app is, what aspects of zope/plone are
important to them, what add-on zproducts they depend on.  If they're heavily
into content management or custom content types that's a bit different
problem than if they're just using zope as their web site platform.

Other factors:  how much of their app is file-system based code vs. zope
objects.  What version of zope are they on and how much if any of the new
zope3 technologies/rearchitecture are they using?  How sophisticated is ther
DB usage; are they just using ZSQL or are they using any of the python sql
packages?

Zope's user management and security model is very well done.  This is IMO
still an immature/evolving area in the Rails world (and yes, I know there
are various plugins etc  - of widely varying degrees of capability and
maturity).  If they make extensive use of these features this area would
need some thought/investigation of how they'd replicate.

Acquisition in Zope is amazingly cool and not something I've really seen
anywhere else.  Depending on the extent to which they exploit acquisition
this could be a challenging aspect to rework.  On the other hand, the Rails
controller/helper facilities + inheritance + the routing mechanism provides
some clean solutions and might cover what they do.

Zope page templates are really nice. [if they're still using DHTML, well...
anything is progress from there]  I personally don't like .rhtml; I
generally want to be able to work on my view templates as well-formed, valid
(x)html documents that I can use std editing tools to work with but with
notation that allows me to express the dynamic content that the runtime
system provides.  The ZPT approach using an attribute markup language is a
nice way to solve this.

[shameless plug: MasterView template engine - my solution to "ZPT for
Rails".  http://masterview.org, rubyforge project 'masterview'.  I'm
co-developer of this project; it's still evolving, call it say beta-level,
but the core mechanism is fairly solid.  Lets me do my templates s.t. erb is
expressed w/in a complete, legal xhmtl document]

That said, while I keep wanting to really like Zope, it's somehow just not
quite... right.  It too often seems to be a  struggle to do things that seem
like they should be simple.  My initial experience with moving some simple
sites to Rails has been that I get much better velocity in my work than I
ever seem to get with Zope.

Language issues: learning Ruby shouldn't be a big deal for a python
programmer.  The languages are very similar in a lot of ways.  Ruby's syntax
and conceptual space is a bit more "cluttered" than python's, but it's not
that difficult an adjustment.

Standard libraries: again, a lot of similarities, both provide pretty good
coverage of a broad range of standard capabilities.  Python libraries are
probably generally more mature and perhaps support a broader range of
add-ons (e.g., quite a bit of scientific stuff is done in python), but
Ruby's core libs seem to be pretty solid as well.

Rake and gems are quite fine; the python world is playing catchup there.

Community and future prospects: zope just never quite caught on here in the
US, it's got little niches but is generally much stronger in Europe.  The
Zope world is in the midst of a big shakeup in the fundamental system
architecture (Zope 2 vs. Zope 3 redesign); most of the energy is more in the
CMS and Plone areas, I think.  Ruby and Rails has a lot of momentum and
activity right now and the foundations being laid seem promising to support
that going forward.  

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick Zadrozny
Sent: Friday, September 08, 2006 9:45 PM
To: San Diego Ruby User Group
Subject: [Sdruby] selling Ruby on Rails...

So I'm putting together an email to sell a Python/Zope/Plone team on moving
to Ruby on Rails. (I might be working with said team in the near future.)

They're a small team, pretty agile and open to new technologies, but I don't
have enough (read: any) experience with Zope and Plone to do much of a
compare and contrast and build a list of pros and cons.

Anyone here have any ideas or articles to share?

--
Nick Zadrozny
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby


_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby

Reply via email to