[Zope3-Users] So, there is going to be no Zope4... how to handle maintenance a couple of years from now?

[Milind Khadilkar]

Hi,
Seems there will be no Zope4. Puts a fond hope to rest.

I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4)
project, two medium sized Grok projects, one GAE project, allof them need
to be maintained beyond two years.
I would like, if possible, to redevelop them using ONE single framework.
While some of the original developers are available, most work would need
to be done through people who need to be trained from the ground up.

My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML and programming
in ZCA-shackles. But I am speaking without any real experience of it.
(Negative press ensured that I did not go for it...)

Any suggestions?

Thanks and regards
Milind Khadilkar

[Thierry Florac]

Content preview: Hi, Le Sun, 7 Sep 2014 09:26:43 +0530, Milind Khadilkar <***@gmail.com>
a écrit: > Seems there will be no Zope4. Puts a fond hope to rest. > > I
have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4) > project,
two medium sized Grok projects, one GAE project, allof them > need to be
maintained beyond two years. > I would like, if possible, to redevelop them
using ONE single > framework. While some of the original developers are available,
most > work would need to be done through people who need to be trained from

the ground up. > > My first choice (mainly because I have a complex Zope3

project to > redevelop) would be Bluebream, even if it means using ZCML and

programming in ZCA-shackles. But I am speaking without any real > experience

of it. (Negative press ensured that I did not go for it...) > > Any suggestions?
[...]

Content analysis details: (-2.7 points, 4.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain
Cc: "zope3-***@zope.org" <zope3-***@zope.org>
Subject: Re: [Zope3-Users] So,
there is going to be no Zope4... how to handle maintenance a couple
of years from now?
X-BeenThere: zope3-***@zope.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Users of Zope 3 <zope3-users.zope.org>
List-Unsubscribe: <https://mail.zope.org/mailman/options/zope3-users>,
<mailto:zope3-users-***@zope.org?subject=unsubscribe>
List-Archive: <http://mail.zope.org/pipermail/zope3-users/>
List-Post: <mailto:zope3-***@zope.org>
List-Help: <mailto:zope3-users-***@zope.org?subject=help>
List-Subscribe: <https://mail.zope.org/mailman/listinfo/zope3-users>,
<mailto:zope3-users-***@zope.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Sep 2014 06:13:33 -0000


Hi,

Le Sun, 7 Sep 2014 09:26:43 +0530,

Seems there will be no Zope4. Puts a fond hope to rest.
I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4)
project, two medium sized Grok projects, one GAE project, allof them
need to be maintained beyond two years.
I would like, if possible, to redevelop them using ONE single
framework. While some of the original developers are available, most
work would need to be done through people who need to be trained from
the ground up.
My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML and
programming in ZCA-shackles. But I am speaking without any real
experience of it. (Negative press ensured that I did not go for it...)
Any suggestions?

If you are considering a complete re-development, maybe you should have
a look at Pyramid.
It allows you to reuse a lot of Zope related technologies, including
ZODB, traversing and even ZCA ! ;-)

I use and develop ZTFY which is based on Bluebream (with updated
packages based on ZTK) and which is used in many of my own projects
with great success, but which is probably condamned to death in a
relatively near future...

Regards,
Thierry


P.S.: by the way, I don't really understand where is the real problem
with ZCA (which is so powerful, and not so complicated!) and with ZCML
(which is nothing in XML files terms compared to any "serious" Java
server development environment...)

[Milind Khadilkar]

Thanks, Thierry.
I think the real problem with ZCA and ZCML is "bad press". We did not face
any ZCML problem when we worked on the Zope3 projects. It was later,
thankfully, that we came across the negative opinion. ZCA did require a
mindset change for some, but more often than not it has helped them in
their future work on other platforms too.
But that was 10 years ago... Don't know about now.

Regards,
Milind

Post by Thierry Florac
Hi,
Le Sun, 7 Sep 2014 09:26:43 +0530,

Post by Milind Khadilkar
Seems there will be no Zope4. Puts a fond hope to rest.
I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4)
project, two medium sized Grok projects, one GAE project, allof them
need to be maintained beyond two years.
I would like, if possible, to redevelop them using ONE single
framework. While some of the original developers are available, most
work would need to be done through people who need to be trained from
the ground up.
My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML and
programming in ZCA-shackles. But I am speaking without any real
experience of it. (Negative press ensured that I did not go for it...)
Any suggestions?

If you are considering a complete re-development, maybe you should have
a look at Pyramid.
It allows you to reuse a lot of Zope related technologies, including
ZODB, traversing and even ZCA ! ;-)
I use and develop ZTFY which is based on Bluebream (with updated
packages based on ZTK) and which is used in many of my own projects
with great success, but which is probably condamned to death in a
relatively near future...
Regards,
Thierry
P.S.: by the way, I don't really understand where is the real problem
with ZCA (which is so powerful, and not so complicated!) and with ZCML
(which is nothing in XML files terms compared to any "serious" Java
server development environment...)

[Thierry Florac]

Hi,

I think ZCA doesn't do "so much more" than implement a few object design
patterns and provide a very flexible components registry framework.
I'm working mainly on developing new framework-like packages and I just
can't work without it except by re-inventing it!

Many users blame ZCML just because it's XML !
But it's just configuration, and separating configuration from
Python code is one of the greatest benefits of ZCML, mainly while
working on huge projects. The XML format is just a detail and is
probably not so worse than many INI-like or text based configuration
format; and at least it's a de-facto standard.

Regards,
Thierry


Le Sun, 7 Sep 2014 14:14:14 +0530,

Post by Milind Khadilkar
Thanks, Thierry.
I think the real problem with ZCA and ZCML is "bad press". We did not
face any ZCML problem when we worked on the Zope3 projects. It was
later, thankfully, that we came across the negative opinion. ZCA did
require a mindset change for some, but more often than not it has
helped them in their future work on other platforms too.
But that was 10 years ago... Don't know about now.
Regards,
Milind

Post by Thierry Florac
Hi,
Le Sun, 7 Sep 2014 09:26:43 +0530,

Post by Milind Khadilkar
Seems there will be no Zope4. Puts a fond hope to rest.
I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope
3.4) project, two medium sized Grok projects, one GAE project,
allof them need to be maintained beyond two years.
I would like, if possible, to redevelop them using ONE single
framework. While some of the original developers are available,
most work would need to be done through people who need to be
trained from the ground up.
My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML and
programming in ZCA-shackles. But I am speaking without any real
experience of it. (Negative press ensured that I did not go for it...)
Any suggestions?

If you are considering a complete re-development, maybe you should
have a look at Pyramid.
It allows you to reuse a lot of Zope related technologies, including
ZODB, traversing and even ZCA ! ;-)
I use and develop ZTFY which is based on Bluebream (with updated
packages based on ZTK) and which is used in many of my own projects
with great success, but which is probably condamned to death in a
relatively near future...
Regards,
Thierry
P.S.: by the way, I don't really understand where is the real
problem with ZCA (which is so powerful, and not so complicated!)
and with ZCML (which is nothing in XML files terms compared to any
"serious" Java server development environment...)

[Jim Fulton]

Post by Thierry Florac
Hi,
I think ZCA doesn't do "so much more" than implement a few object design
patterns and provide a very flexible components registry framework.
I'm working mainly on developing new framework-like packages and I just
can't work without it except by re-inventing it!
Many users blame ZCML just because it's XML !

As well they should! 0.5 ;)

Post by Thierry Florac
But it's just configuration, and separating configuration from
Python code is one of the greatest benefits of ZCML, mainly while
working on huge projects. The XML format is just a detail and is
probably not so worse than many INI-like or text based configuration
format; and at least it's a de-facto standard.

When I started working on zcml, it used a very light-weight but custom
syntax. I was talked in to using XML by someone who later complained
about it. :) I regret not sticking with the lighter weight syntax.

Jim

P.S. ZCML uses a pretty lightweight style of XML, relying more on
attributes than on nested elements. Ironically/typically I was
criticized for this by XML purists.

[Jim Fulton]

Post by Milind Khadilkar
Thanks, Thierry.
I think the real problem with ZCA and ZCML is "bad press". We did not face
any ZCML problem when we worked on the Zope3 projects. It was later,
thankfully, that we came across the negative opinion. ZCA did require a
mindset change for some, but more often than not it has helped them in their
future work on other platforms too.
But that was 10 years ago... Don't know about now.

I'm proud of the ZCA in many ways, but:

- ZCA was designed for problems that most people don't or shouldn't have,
which is making a complex application pluggable.

If your application is complex, that's a problem

http://legacy.python.org/dev/peps/pep-0020/

- In the Zope 3 project, we used the CA way more than we should
have. Initially, this was to prove that we could. Once we were
convinced that every (damn) thing could be pluggable we should
have stopped and simplified, using the ZCA only where needed.
Instead, we'd established a culture of crazy levels of indirection.

- Outrageous indirection in the base system made starting new projects
either super difficult, an exercise in cargo-cult-programming, or both.

I've come to the conclusion that any framework that requires or
encourages its users to use project-templates or project-setup
wizards isn't something I want to use.

I stopped using Zope 3 several years ago when I realized that the
weight of the framework wasn't justified by it's benefits, at least for
me.

I've decided that I'd rather use decoupled frameworks that, ideally,
are simple to learn and use individually. That's why I use bobo now,
http://bobo.digicool.com. A more conventional choice along the same
lines would be Flask, although I think bobo is simpler. (Of course, I'm
biased. :)

I still use the ZCA, especially zope.event, but in a wildly lighter-weight
fashion than I did in Zope 3.

Part of the reason I prefer simpler server frameworks today is that
Web applications are far more client centered today than they were
when I worked on Zope 2 and even Zope 3. Today, for applications
(as opposed to content *sites*), UI logic, including templating, mostly
happens on the client, and web servers are largely REST/RPC/Database
servers.

Jim

P.S. If you find the ZCA interesting, you should check out Scala and it's
implicits and type-level programming. It does many of the same
things as the ZCA at compile time. It's crazy beautiful and evil all
at the same time. :)

[Milind Khadilkar]

Thanks, Jim, for your responses!
These thoughts from you deserve a larger readership than this thread
provides.
I think I will restart thinking on this from scratch.
Thanks, again.

-Milind

Post by Jim Fulton

Post by Milind Khadilkar
Thanks, Thierry.
I think the real problem with ZCA and ZCML is "bad press". We did not

face

Post by Milind Khadilkar
any ZCML problem when we worked on the Zope3 projects. It was later,
thankfully, that we came across the negative opinion. ZCA did require a
mindset change for some, but more often than not it has helped them in

their

Post by Milind Khadilkar
future work on other platforms too.
But that was 10 years ago... Don't know about now.

- ZCA was designed for problems that most people don't or shouldn't have,
which is making a complex application pluggable.
If your application is complex, that's a problem
http://legacy.python.org/dev/peps/pep-0020/
- In the Zope 3 project, we used the CA way more than we should
have. Initially, this was to prove that we could. Once we were
convinced that every (damn) thing could be pluggable we should
have stopped and simplified, using the ZCA only where needed.
Instead, we'd established a culture of crazy levels of indirection.
- Outrageous indirection in the base system made starting new projects
either super difficult, an exercise in cargo-cult-programming, or both.
I've come to the conclusion that any framework that requires or
encourages its users to use project-templates or project-setup
wizards isn't something I want to use.
I stopped using Zope 3 several years ago when I realized that the
weight of the framework wasn't justified by it's benefits, at least for
me.
I've decided that I'd rather use decoupled frameworks that, ideally,
are simple to learn and use individually. That's why I use bobo now,
http://bobo.digicool.com. A more conventional choice along the same
lines would be Flask, although I think bobo is simpler. (Of course, I'm
biased. :)
I still use the ZCA, especially zope.event, but in a wildly lighter-weight
fashion than I did in Zope 3.
Part of the reason I prefer simpler server frameworks today is that
Web applications are far more client centered today than they were
when I worked on Zope 2 and even Zope 3. Today, for applications
(as opposed to content *sites*), UI logic, including templating, mostly
happens on the client, and web servers are largely REST/RPC/Database
servers.
Jim
P.S. If you find the ZCA interesting, you should check out Scala and it's
implicits and type-level programming. It does many of the same
things as the ZCA at compile time. It's crazy beautiful and evil all
at the same time. :)
--
Jim Fulton
http://www.linkedin.com/in/jimfulton

[Christopher Lozinski]

Post by Milind Khadilkar
Hi,
I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4)
project, two medium sized Grok projects, one GAE project, allof them
need to... be redeveloped using ONE single framework.

Any suggestions?

In general the following guidelines apply. If it is heavily relational
database/ URL dispatch dependent, go with Pyramid. If it is pure file
system python with traversal, go with the simpler Grok. if you are
doing a lot of TTW work, acquisition and Zope 2 Security interface, then
your best option is Zopache on top of Grok. Of course real world
situations are not so clear. An informed choice would take the
following factors into account.

How many lines of code/classes are there in each application? What
security model are you using in each case? View based or traversal
based? Do you need the Zope 2 user interface for configuring security?
How much code is done Through The Web, (TTW), and how much on the files
system. Are you using Acquisition? For TTW code, which classes are
you using? DTML? Zclasses? How is the GAE application architected?
Is it even Zope compatible, or is it a relational database and URL
dispatch kind of application?

Given the answers to those questions, it should be quite clear what your
best strategy will be.

My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML

If you are going to start with BlueBream, better to start with the
ZTFY.org. and wiki.ztfy,org. I wrote most of that wiki. It is a much
more modern and up to date than the most recent bluebream distribution.

Better yet, hire Thierry the author of ZTFY. Let him work from Paris.
He indicated that his current project is coming to an end. My highest
respect for that man and all he has accomplished. His tech support was
brilliant. I kid you not, he would be at lest 10 times more
productive than any Indian developer you might hire and try to train. It
would take a few years to train someone to replace him. The man
thinks in Interfaces.

So ZTFY is better than BlueBream. But using Grok is better than
straight ZTFY. Why?

While you and Thierry have had good experience with ZCML, let me assure
you I have tried bluebream, ZTFY, and Grok, and Grok is way way easier.
Ask anyone who has done both approaches. ChrisM the author of Pyramid
wrote an excellent analysis of the difficulty with ZCML in the top part
of defense of Pyramid
http://docs.pylonsproject.org/docs/pyramid/en/latest/designdefense.html

Do read it. Particularly in your case, where you talk about hiring new
developers and training them. Grok hugely simplifies application
configuration. It feels just like writing regular python code. And
reducing the conceptual burden on new developers is a huge issue in this
Zope world. Of course if you go with a senior developer like Thierry,
then starting with ZTFY is acceptable. Although I would argue that
even seasoned zope developers would be more productive in Grok.

Now what about your Zope 2 application?

You said your largest application is the Zope 2 application. Are you
using acquisition? Lots of TTW stuff? Clicking on tables to define
security. Then Zopache.com with Grok is the tool for you. Zopache is
the cultural inheritor of those software approaches.

Anyhow I was quite serious about my questions at the top of this email.
A bit more information about your applications and how they are
architected would help enormously in figuring out what you should be doing.


Hope that helps.
Chris

[Milind Khadilkar]

Thanks, Chris
I agree with you on most counts!
I will add that in my limited interaction with it, I found grok "beautiful".
I need to rethink on this from scratch. Fortunately I have time till the
end of the year to help ourselves decide.
I was not aware of Thierry's ZTFY. I will definitely look at it.... and
take one more at Grok. I have just read about Zopache a few days ago.
-----
One of our largest applications is in Zope3, and another is in Zope2.
However, in both cases the domain modelling complexity and SVG based UIs
(and the need to thwart screen-scrapers from getting at the raw data)
outweighed the architectural issues. Yes, for the Zope2 project we did use
TTW a lot, used DTML and ZPT in tandem, and acquisition too. The GAE
project is straighforward, with Google's object database, ZPT... partly it
was ported from Grok. But I will have to dig up the old documentation
before I can answer your questions with confidence.

Thanks, again.
Regards,
Milind.

On Sun, Sep 7, 2014 at 6:45 PM, Christopher Lozinski <

Post by Milind Khadilkar
Hi,
I have one large Zope2 (Zope 2.6) project, one large Zope3 (Zope 3.4)
project, two medium sized Grok projects, one GAE project, allof them need
to... be redeveloped using ONE single framework.
Any suggestions?
In general the following guidelines apply. If it is heavily relational
database/ URL dispatch dependent, go with Pyramid. If it is pure file
system python with traversal, go with the simpler Grok. if you are doing a
lot of TTW work, acquisition and Zope 2 Security interface, then your best
option is Zopache on top of Grok. Of course real world situations are not
so clear. An informed choice would take the following factors into
account.
How many lines of code/classes are there in each application? What
security model are you using in each case? View based or traversal based?
Do you need the Zope 2 user interface for configuring security? How much
code is done Through The Web, (TTW), and how much on the files system.
Are you using Acquisition? For TTW code, which classes are you using?
DTML? Zclasses? How is the GAE application architected? Is it even Zope
compatible, or is it a relational database and URL dispatch kind of
application?
Given the answers to those questions, it should be quite clear what your
best strategy will be.
My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML
If you are going to start with BlueBream, better to start with the
ZTFY.org. and wiki.ztfy,org. I wrote most of that wiki. It is a much
more modern and up to date than the most recent bluebream distribution.
Better yet, hire Thierry the author of ZTFY. Let him work from Paris. He
indicated that his current project is coming to an end. My highest
respect for that man and all he has accomplished. His tech support was
brilliant. I kid you not, he would be at lest 10 times more productive
than any Indian developer you might hire and try to train. It would take a
few years to train someone to replace him. The man thinks in
Interfaces.
So ZTFY is better than BlueBream. But using Grok is better than straight
ZTFY. Why?
While you and Thierry have had good experience with ZCML, let me assure
you I have tried bluebream, ZTFY, and Grok, and Grok is way way easier.
Ask anyone who has done both approaches. ChrisM the author of Pyramid
wrote an excellent analysis of the difficulty with ZCML in the top part of
defense of Pyramid
http://docs.pylonsproject.org/docs/pyramid/en/latest/designdefense.html
Do read it. Particularly in your case, where you talk about hiring new
developers and training them. Grok hugely simplifies application
configuration. It feels just like writing regular python code. And
reducing the conceptual burden on new developers is a huge issue in this
Zope world. Of course if you go with a senior developer like Thierry, then
starting with ZTFY is acceptable. Although I would argue that even
seasoned zope developers would be more productive in Grok.
Now what about your Zope 2 application?
You said your largest application is the Zope 2 application. Are you
using acquisition? Lots of TTW stuff? Clicking on tables to define
security. Then Zopache.com with Grok is the tool for you. Zopache is
the cultural inheritor of those software approaches.
Anyhow I was quite serious about my questions at the top of this email. A
bit more information about your applications and how they are architected
would help enormously in figuring out what you should be doing.
Hope that helps.
Chris