trollfot at gmail.com
Thu Mar 9 19:08:31 CET 2017
All the packages have READMEs and tests.
But yes... Most of the work was done by myself and given the amount of work
needed in the code, the documentation always came last sadly.
Given the lack of interest initially for the project in the community, It
failed to gain more attention from people
Cromlech uses some ZTK packages, if they are detached enough from the whole
stack. The idea is to have something you build from bricks, one at a time,
not to start with more code than you can understand.
Having a complete understanding from the request creation to the final
response was key to produce quick and quality code, for problematics I
could never resolve with Grok itself.
Having less overhead and more direct compatibility with generic python
packages (base WSGI ones especially) is very appreciable.
It's incredibly satisfying to be able to intervene at the right level in
the stack, when you need it, without having to rely on a ton of adapters,
events and subscriptions.
Historically, the starting point was to remove zope.publisher. It's so
entangled in the rest that we ended up stripping down everything, piece by
Martijn and myself coded "dawnlight", that is the base publisher here and
Crom/Grokker to use Venusian and more a flexible registration system for
These ideas were at the base of Morepath, I took a more grokkish approach
Finally, a lot of effort was put into making the "framework" agnostic,
regarding the DB and the request/response objects.
The security system is very light and flexible, allowing a very simple
security or a very complex one.
In term of productivity, it's very hard to assess.
What I can definitly say is that we gained a lot of flexibility while
stripping down the base code to a minimal.
It's faster, easier to maintain, easier to understand and is a solid base
to build on.
Too often, Grok/Zope2/Plone feels like you're fighting against it or
bending it to fit your needs.
I think it's profitable to actually code what you need, starting from a
simple base instead of having to deal with a lot of decisions already made
for you that may cripple your project.
i hope I make sense in this mail. I can sound confusing as it's difficult
to summarize years of decisions, code and try to sparkle an interest at the
There is a simple demo here : https://github.com/Cromlech/CromlechCromDemo,
that does a few things.
It's interesting to dissect the anatomy of an application, here :
The focus of my work was to have concise, fast and explicit code , i hope
it speaks for itself.
Thank you for your interest so far.
2017-03-09 18:36 GMT+01:00 Christopher Lozinski <lozinski at freerecruiting.com
> On Mar 9, 2017, at 6:10 PM, Souheil CHELFOUH <trollfot at gmail.com> wrote:
> Well I took a look at it.
> Many of the package names looked familiar. They all had a one line
> description of what they do.
> Sadly more documentation was lacking.
> But I linked to it anyhow, from Pylang.info.
> I wonder if your company is similarly much more productive than your
> competitors? It would make very good anecdotal evidence.
> The problem is that there are not that many users. I share Paul’s belief
> of staying close to ZTK users.
> But maybe we can take a step in your direction. If we could remove one
> library from Grok/ZTK, and replace it with your stuff, what would it be?
> My biggest unhappiness is with zope.publisher. Just massive and hugely
> confused. Grok views are confused and tangled up with it. It even calls
> zope.app stuff.
> Grok guys contorted things to work with the ZTK model. I would love to
> rip it out and throw it out.
> I have my own traversal.
> I have thought of grabbing the Pyramid Publishing software. Maybe yours
> would be better. That would be one or two packages I could take from you.
> Good for both of us.
> What do you think?
> Warm Regards
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Grok-dev