<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>I hear you, Paul, and there's no debate from my end about what you said.<br></div>I'm very well aware of the needs and expectations of users.<br></div>That's why, in my description, I said it's mainly a toolkit for developpers.<br></div>It was coded with a goal in mind : being my work tool for the years to come.<br></div>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.<br></div>The code is not useless, since I've been using it for more than 5 years. <br><br>"Sure, Zope certainly did not get everything right, and it's not perfect"<br></div>It did some things right and sure, it's not perfect. Thing is, the concepts are what interested me.<br></div>The promises were, in zope3, to be flexible, to have the possibility to exchange any component using the interface, and so on.<br></div>The truth is : it's not nearly as flexible as advertized. <br></div>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.<br></div>At some point, they just became a hindrance in my projects and productivity.<br></div>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.<br></div>it doesn't mean it's perfect, it doesn't mean it's meant for everyone.<br><br>"<i>zope.publisher</i> is core to the whole idea behind Zope"<br></div>That is not true. It's an historical piece of code that grew out of proportion.<br></div>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.<br></div>zope.publisher blurs the frontiers between too many concepts and steps you need to be able to control, in some projects.<br><br>"Sorry, Souheil, but speaking as a User, we LIKE magic. The more magic the better!"<br></div>Magic is good, until it makes you lose days of work chasing a bug you'll never understand by lack of explicit.<br></div><br></div>It's nice to have feedbacks and opinions, I hope it will nourish many more debates<br></div>Regards<br></div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-10 8:10 GMT+01:00 Paul Sephton <span dir="ltr"><<a href="mailto:prsephton@gmail.com" target="_blank">prsephton@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>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.<br><br>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. <b>Users</b>.<br><br>It sounds to me as if Cromplech is a remarkable technical achievement capable of running large sites. However, as a <b>User</b>, when evaluating potential frameworks to use, I would start by looking at the following needs:<br><br><ul><li>Is it supported? How long does it take for bugs to be fixed? This impacts development time.<br></li><li>Does it have adequate documentation or Internet resources that can guide me as to how to solve problems?</li><li>Is it in widespread use by others? This helps in risk assessment.<br></li><li>Is the API in flux? or has it matured and settled to a constant. This impacts my risk and technical debt.<br></li><li>How easy is it to maintain code that uses the framework? This impacts my costs and ROI.<br></li><li>How does the framework help me solve real world problems?</li><ul><li>Interfacing with data sources</li><li>Session Management</li><li>Access control, Authentication methods etc</li><li>Scalability - factors like efficiency, threading, deployment across servers and so forth</li><li>Extensiblity - ability to add features without breaking existing code</li></ul><li>How affordable and available are development resources?</li></ul><br>You see, <b>Users</b> 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 <b>Users</b> like me are looking for in a framework, you will continue to have a shortage of <b>Users</b>.<br><br>I am more than willing as a <b>User</b> 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 <a href="http://gfn.aptrackers.com" target="_blank">extensive users guide to using Grok</a>, and made it available on the Internet together with the code.<br><br>However, as a <b>User</b>, the one thing that will drive me away to join the throngs supporting <i>AngularJS </i>and other such perversions, are statements like: <i>"zope.publisher. Just massive and hugely confused.</i>" or "<i>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</i>". And, horror of horrors: "<i>...I would love to rip it out and throw it out</i>".<br><br>As a developer and software architect, I understand the burning desire to simplify. However, surely you realise that <i>zope.publisher</i> 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?<br><br>Next I hear "<i>...without having to rely on a ton of adapters, events and subscriptions</i>", 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 "<i>piece by piece</i>" the bits upon which the house of cards rests can only result in the whole thing coming crashing down around your ears. <br><br></div>You cannot erode the foundation of a house without compromising the entire structure.<br><div><br>Indeed, in your case you ended up with something a lot less magical. In your own words "<i>It's just a little more DIY, because i've always wanted less magic.</i>"<br><br>Sorry, Souheil, but speaking as a User, we LIKE magic. The more magic the better! <br><br>We also like <u>stability</u>- 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 "<i>on_link</i>" was not following some or other naming convention (quite probably that abortion called PEP8) and renamed it to just "<i>link</i>" 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.<br><br>Regards<br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 8:08 PM, Souheil CHELFOUH <span dir="ltr"><<a href="mailto:trollfot@gmail.com" target="_blank">trollfot@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div>All the packages have READMEs and tests.<br></div><div>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.<br>Given the lack of interest initially for the project in the community, It failed to gain more attention from people</div><br></div>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.<br></div>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.<br></div>Having less overhead and more direct compatibility with generic python packages (base WSGI ones especially) is very appreciable.<br></div><div>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.<br></div><div><br></div>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.<br></div>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.<br></div>These ideas were at the base of Morepath, I took a more grokkish approach with Cromlech.<br><br><div><div>Finally, a lot of effort was put into making the "framework" agnostic, regarding the DB and the request/response objects.<br></div><div>The security system is very light and flexible, allowing a very simple security or a very complex one.<br><br></div><div>In term of productivity, it's very hard to assess.<br></div><div>What I can definitly say is that we gained a lot of flexibility while stripping down the base code to a minimal.<br></div><div>It's faster, easier to maintain, easier to understand and is a solid base to build on.<br></div><div>Too often, Grok/Zope2/Plone feels like you're fighting against it or bending it to fit your needs.<br></div><div>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.<br><br></div><div>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.<br></div><div>There is a simple demo here : <a href="https://github.com/Cromlech/CromlechCromDemo" target="_blank">https://github.com/Cromlech/Cr<wbr>omlechCromDemo</a>, that does a few things.<br></div><div>It's interesting to dissect the anatomy of an application, here : <a href="https://github.com/Cromlech/CromlechCromDemo/blob/master/src/cromdemo/src/cromdemo/wsgi.py" target="_blank">https://github.com/Cromlech/Cr<wbr>omlechCromDemo/blob/master/src<wbr>/cromdemo/src/cromdemo/wsgi.py</a><br></div><div>The focus of my work was to have concise, fast and explicit code , i hope it speaks for itself.<br><br></div><div>Thank you for your interest so far.<span class="m_6906666700390327804HOEnZb"><font color="#888888"><br></font></span></div><span class="m_6906666700390327804HOEnZb"><font color="#888888"><div>- Souheil<br></div><div><br></div></font></span></div></div><div class="m_6906666700390327804HOEnZb"><div class="m_6906666700390327804h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-03-09 18:36 GMT+01:00 Christopher Lozinski <span dir="ltr"><<a href="mailto:lozinski@freerecruiting.com" target="_blank">lozinski@freerecruiting.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"> <div><div><blockquote type="cite"><div>On Mar 9, 2017, at 6:10 PM, Souheil CHELFOUH <<a href="mailto:trollfot@gmail.com" target="_blank">trollfot@gmail.com</a>> wrote:</div><br class="m_6906666700390327804m_642584856027285182m_3381690873866443408Apple-interchange-newline"><div><br><a href="https://github.com/Cromlech" target="_blank">https://github.com/Cromlech</a><br><br class="m_6906666700390327804m_642584856027285182m_3381690873866443408Apple-interchange-newline"></div></blockquote><br></div><div>Well I took a look at it. </div><div><br></div><div>Many of the package names looked familiar. They all had a one line description of what they do. </div><div><br></div><div>Sadly more documentation was lacking. </div><div><br></div><div>But I linked to it anyhow, from Pylang.info. </div><div><br></div><div>I wonder if your company is similarly much more productive than your competitors? It would make very good anecdotal evidence.</div><div><br></div><div>The problem is that there are not that many users. I share Paul’s belief of staying close to ZTK users. </div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Grok guys contorted things to work with the ZTK model. I would love to rip it out and throw it out. </div><div><br></div><div>I have my own traversal. </div><div><br></div><div>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. </div><div><br></div><div>What do you think? </div><div> </div><div>Warm Regards</div><div>Chris</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>