<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 9/7/14, 6:56 AM, Milind Khadilkar
wrote:<br>
</div>
<blockquote
cite="mid:CAPDr7zEZa6wAt_XgJWcoAtOvMU5VUEQXM=OtBbjv41ajAGLowg@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi, <br>
</div>
<br>
<br>
</div>
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.<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
Any suggestions?<br>
<br>
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. <br>
<br>
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?<br>
<br>
Given the answers to those questions, it should be quite clear what
your best strategy will be. <br>
<br>
My first choice (mainly because I have a complex Zope3 project to
redevelop) would be Bluebream, even if it means using ZCML <br>
<br>
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. <br>
<br>
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. <br>
<br>
So ZTFY is better than BlueBream. But using Grok is better than
straight ZTFY. Why?<br>
<br>
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<br>
<a class="moz-txt-link-freetext" href="http://docs.pylonsproject.org/docs/pyramid/en/latest/designdefense.html">http://docs.pylonsproject.org/docs/pyramid/en/latest/designdefense.html</a><br>
<br>
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. <br>
<br>
Now what about your Zope 2 application?<br>
<br>
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.<br>
<br>
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. <br>
<br>
<br>
Hope that helps. <br>
Chris<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>