[Grok-dev] megrok.rdb

[Souheil CHELFOUH]

I hear you, Paul, and there's no debate from my end about what you said.
I'm very well aware of the needs and expectations of users.
That's why, in my description, I said it's mainly a toolkit for developpers.
It was coded with a goal in mind : being my work tool for the years to come.
I do not complain that I don't have "users", i merely expose what I have
done, hoping it can be of use to people who faced the same problems and
limitations.
The code is not useless, since I've been using it for more than 5 years.

"Sure, Zope certainly did not get everything right, and it's not perfect"
It did some things right and sure, it's not perfect. Thing is, the concepts
are what interested me.
The promises were, in zope3, to be flexible, to have the possibility to
exchange any component using the interface, and so on.
The truth is : it's not nearly as flexible as advertized.
i had my fair share of zope projects and contributed to the core of the ZTK
myself, i have a quite clear visions of said limitations.
At some point, they just became a hindrance in my projects and productivity.
There is no perfect tool that can tackle all tasks. So instead of trying to
fit every usecases in something somewhat rigid, i took a step back.
it doesn't mean it's perfect, it doesn't mean it's meant for everyone.

"*zope.publisher* is core to the whole idea behind Zope"
That is not true. It's an historical piece of code that grew out of
proportion.
The software was built around it, on top of it and this foundation was left
alone, in fear it would make the whole thing collapse.
zope.publisher blurs the frontiers between too many concepts and steps you
need to be able to control, in some projects.

"Sorry, Souheil,  but speaking as a User, we LIKE magic.  The more magic
the better!"
Magic is good, until it makes you lose days of work chasing a bug you'll
never understand by lack of explicit.

It's nice to have feedbacks and opinions, I hope it will nourish many more
debates
Regards

2017-03-10 8:10 GMT+01:00 Paul Sephton <prsephton at gmail.com>:

>
> From what you say, your take away from Grok was "Too often,
> Grok/Zope2/Plone feels like you're fighting against it or bending it to fit
> your needs".  I find that very descriptive, and to some probably lesser
> extent I have experienced the same thing.
>
> For simple folks like me though, having no desire to actually rewrite
> frameworks to bend them to our will, we are what folks like you end up
> complaining about having a lack of.  *Users*.
>
> It sounds to me as if Cromplech is a remarkable technical achievement
> capable of running large sites.  However, as a *User*, when evaluating
> potential frameworks to use, I would start by looking at the following
> needs:
>
>
>    - Is it supported?  How long does it take for bugs to be fixed?  This
>    impacts development time.
>    - Does it have adequate documentation or Internet resources that can
>    guide me as to how to solve problems?
>    - Is it in widespread use by others?  This helps in risk assessment.
>    - Is the API in flux? or has it matured and settled to a constant.
>    This impacts my risk and technical debt.
>    - How easy is it to maintain code that uses the framework?  This
>    impacts my costs and ROI.
>    - How does the framework help me solve real world problems?
>       - Interfacing with data sources
>       - Session Management
>       - Access control, Authentication methods etc
>       - Scalability - factors like efficiency, threading, deployment
>       across servers and so forth
>       - Extensiblity - ability to add features without breaking existing
>       code
>    - How affordable and available are development resources?
>
>
> You see, *Users* like me are what make those technical masterpieces
> valuable.  Without people to actually USE the code you write, the code
> itself is, by definition,  useless.  Unless your framework can provide the
> things *Users* like me are looking for in a framework, you will continue
> to have a shortage of *Users*.
>
> I am more than willing as a *User* to contribute my bit to the pot.  I
> don't expect everything to be freely given to me.  In case in point, I have
> written an extensive users guide to using Grok <http://gfn.aptrackers.com>,
> and made it available on the Internet together with the code.
>
> However, as a *User*, the one thing that will drive me away to join the
> throngs supporting *AngularJS *and other such perversions, are statements
> like: *"zope.publisher.   Just massive and hugely confused.*" or "*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 piece*".  And,
> horror of horrors: "*...I would love to rip it out and throw it out*".
>
> As a developer and software architect, I understand the burning desire to
> simplify.  However, surely you realise that *zope.publisher* is core to
> the whole idea behind Zope, and that you cannot fundamentally change the
> core of something without changing the very nature of what lies behind it?
>
> Next I hear "*...without having to rely on a ton of adapters, events and
> subscriptions*", which speaks to the heart of what gives the ZTK its
> value in the first place;  the fact that it is entirely component based and
> everything is part of a pluggable coherent architecture.  Sure, Zope
> certainly did not get everything right, and it's not perfect.  I understand
> that.  But dismantling "*piece by piece*" the bits upon which the house
> of cards rests can only result in the whole thing coming crashing down
> around your ears.
>
> You cannot erode the foundation of a house without compromising the entire
> structure.
>
> Indeed, in your case you ended up with something a lot less magical.  In
> your own words "*It's just a little more DIY, because i've always wanted
> less magic.*"
>
> Sorry, Souheil,  but speaking as a User, we LIKE magic.  The more magic
> the better!
>
> We also like *stability*- not stagnation, stability.  We like to believe
> that if we write code today, that code will still operate and have value
> tomorrow.  The bug report that started off this whole thread is a clear
> example of some person who decided that a method called "*on_link*" was
> not following some or other naming convention (quite probably that abortion
> called PEP8) and renamed it to just "*link*" possibly to get rid of some
> of the warnings cluttering up his IDE, and ridiculously far reaching
> impacts such utterly stupid and unsubstantiated changes can have to
> dependent projects.
>
> Regards
>
> On Thu, Mar 9, 2017 at 8:08 PM, Souheil CHELFOUH <trollfot at gmail.com>
> wrote:
>
>> 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
>> piece.
>> Martijn and myself coded "dawnlight", that is the base publisher here and
>> Crom/Grokker to use Venusian and more a flexible registration system for
>> components.
>> These ideas were at the base of Morepath, I took a more grokkish approach
>> with Cromlech.
>>
>> 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
>> same time.
>> There is a simple demo here : https://github.com/Cromlech/Cr
>> omlechCromDemo, that does a few things.
>> It's interesting to dissect the anatomy of an application, here :
>> https://github.com/Cromlech/CromlechCromDemo/blob/master/src
>> /cromdemo/src/cromdemo/wsgi.py
>> 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.
>> - Souheil
>>
>>
>> 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:
>>>
>>>
>>> https://github.com/Cromlech
>>>
>>>
>>> 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
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/grok-dev/attachments/20170310/09dd83e8/attachment-0001.html>