<div dir="ltr"><div><div><div><div>Thanks, Jim, for your responses!<br></div>These thoughts from you deserve a larger readership than this thread provides.<br></div>I think I will restart thinking on this from scratch.<br></div>Thanks, again.<br><br></div>-Milind<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 7, 2014 at 8:12 PM, Jim Fulton <span dir="ltr"><<a href="mailto:jim@zope.com" target="_blank">jim@zope.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Sep 7, 2014 at 4:44 AM, Milind Khadilkar <<a href="mailto:zedobject@gmail.com">zedobject@gmail.com</a>> wrote:<br>
> Thanks, Thierry.<br>
> I think the real problem with ZCA and ZCML is "bad press". We did not face<br>
> any ZCML problem when we worked on the Zope3 projects. It was later,<br>
> thankfully, that we came across the negative opinion. ZCA did require a<br>
> mindset change for some, but more often than not it has helped them in their<br>
> future work on other platforms too.<br>
> But that was 10 years ago... Don't know about now.<br>
<br>
</span>I'm proud of the ZCA in many ways, but:<br>
<br>
- ZCA was designed for problems that most people don't or shouldn't have,<br>
which is making a complex application pluggable.<br>
<br>
If your application is complex, that's a problem<br>
<br>
<a href="http://legacy.python.org/dev/peps/pep-0020/" target="_blank">http://legacy.python.org/dev/peps/pep-0020/</a><br>
<br>
- In the Zope 3 project, we used the CA way more than we should<br>
have. Initially, this was to prove that we could. Once we were<br>
convinced that every (damn) thing could be pluggable we should<br>
have stopped and simplified, using the ZCA only where needed.<br>
Instead, we'd established a culture of crazy levels of indirection.<br>
<br>
- Outrageous indirection in the base system made starting new projects<br>
either super difficult, an exercise in cargo-cult-programming, or both.<br>
<br>
I've come to the conclusion that any framework that requires or<br>
encourages its users to use project-templates or project-setup<br>
wizards isn't something I want to use.<br>
<br>
I stopped using Zope 3 several years ago when I realized that the<br>
weight of the framework wasn't justified by it's benefits, at least for<br>
me.<br>
<br>
I've decided that I'd rather use decoupled frameworks that, ideally,<br>
are simple to learn and use individually. That's why I use bobo now,<br>
<a href="http://bobo.digicool.com" target="_blank">http://bobo.digicool.com</a>. A more conventional choice along the same<br>
lines would be Flask, although I think bobo is simpler. (Of course, I'm<br>
biased. :)<br>
<br>
I still use the ZCA, especially zope.event, but in a wildly lighter-weight<br>
fashion than I did in Zope 3.<br>
<br>
Part of the reason I prefer simpler server frameworks today is that<br>
Web applications are far more client centered today than they were<br>
when I worked on Zope 2 and even Zope 3. Today, for applications<br>
(as opposed to content *sites*), UI logic, including templating, mostly<br>
happens on the client, and web servers are largely REST/RPC/Database<br>
servers.<br>
<br>
Jim<br>
<br>
P.S. If you find the ZCA interesting, you should check out Scala and it's<br>
implicits and type-level programming. It does many of the same<br>
things as the ZCA at compile time. It's crazy beautiful and evil all<br>
at the same time. :)<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Jim Fulton<br>
<a href="http://www.linkedin.com/in/jimfulton" target="_blank">http://www.linkedin.com/in/jimfulton</a><br>
</div></div></blockquote></div><br></div>