Re: [Zope] Zope 3 and Rails - a pragmatic and agile comparation (put the hype aside)

2008-02-26 Thread Tim Nash
Here is a follow up I wrote that fell off the list. The original
poster probably thought he was posting to the zope@zope.org but I
leave his id off just in case he didn't. I am reposting it here mainly
because he makes several good points.
-Tim


  I find zope's through the web editing it's worst aspect. It would make a
  great optional add-on, but to make the root of the site only editable
  through the web is just a disaster.

I could vote for an optional add-on. BTW I meant to say google
gadgets. The point is that there is always far more innovation outside
your company than inside and companies are looking for software that
helps them tap into that talent.

   2. object database. Perfect for web services with changing schemas.

  It's great, but I wish it wasn't mapped directly to URLs. There should
  be an abstraction, like the controller in MVC systems.

I could also vote for this but apache does a lot of this for you.

  DTML is horrible because it looks like XML but isn't. It should either
  be XML, like TAL, which I think is great, or be nothing like it, like
  django's templating language.

If you are talking about reading dtml  I share your pain, but if you
are talking about writing it then you have a built in filter. When
your page starts to look ugly rethink your problem. For example, these
days you can program tabs with secondary menus using just two dtml-in
loops if you start with tabs that only require css
http://labs.silverorange.com/images/tabsupdate/about.html


   5. a ZMI which allows zope to be an easy to administer database. Easy
   enough for distribution to powerusers.

  Useful, but should be turn-off-able.

I can vote for this as well


  I want to be able to have a zope site entirely in the file system with
  no ZODB, so I can keep it in subversion, and use normal things like
  grep, patch and sed to apply changes to the whole codebase.

You can do this with zope 2 but you can also allow user customization
that you can later migrate in to the filesystem code.

If I want it in the site to do a CMS type
  application, I want to put it inside my File System Site code, not put a
  file system site object into it.

Not sure what you mean here. You aren't forced to put filesystem
objects into the ZODB. The folders/tree structure of zope is a natural
navigational device that is very useful. Check out the book Don't
make me think.

Zope 3 has great ideas (components, interfaces, views, maybe PAU) but
zope 2 (dtml, TTW, Plone) is what pulls them in the door. And you have
to get them in the door before they will buy.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


Re: [Zope] Zope 3 and Rails - a pragmatic and agile comparation (put the hype aside)

2008-02-24 Thread Tim Nash
Marcelo,
   I share your excitement about zope 3 but let me speak about zope 2
. I am also fairly new to zope and came from a java/python background.
I have built Rail's tutorial applications but came back to zope 2.
Here is my reasons.

1. Through the web editing.  Brilliant. Yes it is problematic but it
is a game changer. Can zope compete on java or php or asp's territory?
No. But nobody else has TTW development and many are now adding
something like it (google gears, facebook api,  smalltalk's seaside).
I just wish more books would discuss how easy it is to take a 'Script
Python' and bring it 'inside' to a python product.

2. object database. Perfect for web services with changing schemas.

3. DTML. I know the old timers were smoking way too much dtml in the
days before CSS, but I love DTML! It is fast to develop with, it works
well with javascript and css (try dynamic css and javascript ) and it
has excellent execution speed. It is the IDEs that should change, not
dtml. :)

4.  REST supporting architecture.

5. a ZMI which allows zope to be an easy to administer database. Easy
enough for distribution to powerusers.

6. A well developed catalog/search.

7. A well developed security framework.

And finally, there is one other thing I really like about Zope 2.

8. A fairly well defined future. (zope 3). I think the developers of
zope 2 were 5-10 years ahead of the curve. If the zope team can
continue to appreciate what made zope special while they incorporate
the new ideas I think zope will stay ahead of the curve.

A toast to all of the zope (2 and 3) developers!

Thank you.
Tim





 I can't speak for Zope 2 though :)

 What do you think? Would you mind sharing your experiences and ideas
 regarding this subject?
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )


[Zope] Zope 3 and Rails - a pragmatic and agile comparation (put the hype aside)

2008-02-23 Thread Marcelo de Moraes Serpa
Hello,

I come from a Rails background, been working with Rails for about 1 year and
a half, it has been a great experience but my last project required me to
use Plone as a base framework for the portal/application.

I then started deeply studying Plone 3. Bought and read Martin's excellent
book Professional Plone Development from cover to cover. Struggled with Zope
concepts but almost always could grasp them by reading the other books from
the Zope/Plone bookshelf or online articles/tutorials.

It has been 3 months already. The project is almost done and I've learned to
like Plone and Zope 2. However, what attracted me the most was Zope 3 and
its elegant concepts and OOP patterns and this led me to question some
things:

 * The differences in the approaches taken by Rails and Zope 3 to provide
developer productivity, scalability and application maintability.
Rails is productive, no doubt regarding this. However, I feel that it
restricts me in the OOP side of things, hiding much of the OOP patterns from
the developer. The put there it will just work philosophy often makes it
hard (at least harder than if it were being implemented on Zope 3) to make
more advanced, complex and specific things.

I do believe in the agile methodology and I always follow it whatever I am
working with Java, python, C or Rails. Rails just happens to be an
out-of-the-box solution that has attract millions of developers becouse of
its magic promises and easy learning-curve.

I feel however, that Zope 3 with its Component Architecture is much more
elegant and can be as productive as Rails AND provide better application
scalability and maintability than Rails if you know what you are doing.

I can't speak for Zope 2 though :)

What do you think? Would you mind sharing your experiences and ideas
regarding this subject?

Cheers,

Marcelo.
___
Zope maillist  -  Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope-dev )