[Grok-dev] Fwd: Zopache

[Paul Sephton]

Dear Christopher,

>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.

I actually used Zope-2 for some really trivial stuff many moons ago.

Comments interspersed:

On Wed, Aug 20, 2014 at 4:18 PM, Christopher Lozinski <
lozinski at freerecruiting.com> wrote:

>  I took the liberty of attaching your reply to the end of this email.
>
> >I think what you are completely missing is the power of marker interfaces;
>
> 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.
>

...and here I was thinking that page templates and marker interfaces were
the simplest possible constructs!

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.

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.


>
> <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>...
>

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.

>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.

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.

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?

 <snip>...  Did you see how much code you had to write for all those
> Content objects. And then adding them all to the application?
>

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.

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.


> 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.
>

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.



>   <snip>...  And so many projects start off small and then grow.
>

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.


>
> It is not just beginners.  Even for the seasoned developer we have way too
> much complexity overload.
> Whatever can be done to simplify our computational models of the world,
> helps the seasoned developer as much as the novice developer.  Maybe more.
>

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.

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.

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.


>
> Thanks for the dialogue.
>
Always good,

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/grok-dev/attachments/20140821/0e866eff/attachment-0001.html>