<div dir="ltr">Dear Christopher,<br><div class="gmail_quote"><div dir="ltr"><div><div class="gmail_extra"><br></div><div class="gmail_extra">From the comments on your site it would seem what you are trying to accomplish is something similar to Zope-2 but based upon Grok and Zope toolkit?  That would explain your need for enabling an acquisition mechanism.  I assume you are aware of the historic debate about acquisition, and the conclusion that the idea left much to be desired?  Personally I never had much of a problem with it, but then again I never did anything beyond the trivial with Zope-2.<br>

<br></div>I actually used Zope-2 for some really trivial stuff many moons ago.  <br><div class="gmail_extra"><br><div class="gmail_quote"><div class="gmail_extra">Comments interspersed:<br></div><div class=""><div class="gmail_extra">
<br>
</div>On Wed, Aug 20, 2014 at 4:18 PM, Christopher Lozinski <span dir="ltr"><<a href="mailto:lozinski@freerecruiting.com" target="_blank">lozinski@freerecruiting.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I took the liberty of attaching your reply to the end of this email.
    <br>
    <br>
    >I think what you are completely missing is the power of marker
    interfaces;<br>
    <br>
    Oh I think marker interfaces are brilliant, just what is needed for
    larger projects, particularly for mult-developer projects.  But they
    add way too much complexity for the simple projects.  Much like page
    templates are brilliant if you are working with graphics designers,
    but again too much complexity for the stand alone developer. <br></div></blockquote><div><br></div></div><div>...and here I was thinking that page templates and marker interfaces were the simplest possible constructs!<br>
<br>
</div><div>In software design, flexibility and power quite often has a cost in complexity.  The component oriented approach to design is actually a way of reducing complexity while at the same time providing a flexible framework.<br>

</div><div><br></div><div>In the ZCA, the idea is to provide all the pluggability that one might achieve through abstract base classes and inheritence, but without actually having to use inheritence.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div text="#000000" bgcolor="#FFFFFF">
    <br>
    <snip>...  The Zopache computatinoal model is different from the Grok
    computational model.  No marker interfaces.  Very little python. 
    Mostly a ZMI where you add objects and fill in some fields.<snip>...</div></blockquote><div><br></div><div>Pyramid also has this idea that the ZCA is best hidden from the developer who clearly has insufficient grey matter to grasp the idea of a component architecture and put it to good use.  They wrap the ZCA behind yet another API layer to try to present a simpler and more palatable view while trying to retain the power of the ZCA.  <br>

<br>From my perspective, wrapping an API in another API achieves little other than there now being two API's to learn rather than just the original one.<br><br></div><div>Perhaps Pyramid is the right approach; I cannot really say.  It certainly is winning the popularity contest.  OTOH, PostgreSQL has been miles ahead of MySQL ITO database design for over a decade and is only now starting to see an increase in popularity.  Not because it is better, but because of politics.<br>

<br></div><div>For TTW development, Zope-2 remains an option, but has a strong competitor in Web2Py.  Are you sure there's a need for  another TTW Python framework?<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<div text="#000000" bgcolor="#FFFFFF">
    <snip>... 
    Did you see how much code you had to write for all those Content
    objects. And then adding them all to the application?   </div></blockquote><div><br></div><div>Including all the comments, 70 lines of completely unoptimised code, produced entirely for demonstration purposes, much of which was cut & paste.  Really no big effort.<br>

<br></div><div>You stated that you needed to use acquisition to accomplish the rendering of the index in the root of your site map, and I knocked together my example in about 10 minutes to demonstrate that you did not need acquisition to do so.<br>

</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">In Zopache,
    just use a GUI the ZMI, add a folder, add an HTML object, and type
    up the content.  Or use some other kind of template for the content,
    like a mark up object.</div></blockquote><div><br></div></div><div>This is one way to do things, but not the only way. When apps developed TTW like this start getting more beefy, the visual design approach starts breaking down.  I spent whole months looking at the implementation of Plone-3 on Zope-2, and the complexity left me feeling battered and inadequate.<br>

<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">  <snip>...  And so many
    projects start off small and then grow.  <br></div></blockquote><div><br></div><div>True enough.  OTOH, my experience is to discard the POC once it has proven viability, and immediately re-architect for scalability and extensibility.  In other words, projects which start small and grow are seldom future-proof.<br>

</div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    It is not just beginners.  Even for the seasoned developer we have
    way too much complexity overload. <br>
    Whatever can be done to simplify our computational models of the
    world, helps the seasoned developer as much as the novice
    developer.  Maybe more.<br></div></blockquote><div><br></div></div><div>I agree with your sentiment.  I suspect however that what you see as a simplification, and what I see as simplification may not be wholly in agreement.  I see the use of marker interfaces to be an unbelievably simple way to specify what should be rendered for a model.  Your opinion is apparently that this approach involves too much typing.<br>

<br></div><div>Handling complexity is the bane of large projects.  Component architectures are one approach to managing complexity.  If these happen to be visual components (as with Zope 2, or what you envisage) or non-visual components (as in Grok), the result may be, in my opinion, quite similar.<br>

<br>My own preference is to handle the organisation of complex large projects through modularisation, and handling interfaces between components by using the ZCA.  I am obviously willing to entertain the idea that in principle my preferences are not universally shared.<br>

 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Thanks for the dialogue.  </div></blockquote><div>Always good,<br><br></div><div>Paul <br></div></div><br></div></div></div>
</div></div>