[Zope3-Users] how to handle Zope maintenance a couple of years from now?

Milind Khadilkar zedobject at gmail.com
Sun Sep 7 19:35:00 CEST 2014


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 <
lozinski at freerecruiting.com> wrote:

>
> On 9/7/14, 6:56 AM, Milind Khadilkar wrote:
>
>    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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/zope3-users/attachments/20140907/b08520c4/attachment-0001.html>


More information about the Zope3-users mailing list