[Grok-dev] Benefits of Grok -- please contribute

[Sebastian Ware]

Hi Kevin!

Thanks for some fresh thoughts on the matter.

16 maj 2007 kl. 06.42 skrev Kevin Teague:

>
>> 1 What does a developer look for when choosing a web development  
>> framework?
>
> I usually evaluate web frameworks on the conciseness and cleanly- 
> ness of applications built on the framework.
>

Can I interpret this as that you want to see code?

>>
>> 2 What does a manager look for when choosing a web development  
>> framework?
>
> Managers are strange and unknowable creatures ... :P

I am sure we can make them grok Grok... ;)

>
>>
>> 3 Which frameworks are direct competitors to Grok?
>
> All of them. Which sounds like a cop-out, but I think Grok is  
> applicable to a wide variety application development use cases.
>
>>
>> 4 What are the benefits of choosing Grok (over "competing"  
>> frameworks)?
>
> * Model inheritance: The ZODB provides a very natural, very simple  
> way of storing your data. It also makes it *much* easier to use  
> advanced data modeling techniques such as model inheritance.
>
> * Security: grok.require and grok.define_permission is already well  
> ahead of many other frameworks.
>
> * Maintainability and Code Reuse: Components, Interfaces and Adapters
>
> * Architecture: It doesn't force your application into a MVC-like  
> system. Grok has an MVC-like system, but it's not bending over  
> itself to force everything into just those three categories of  
> components.
>
>  * Grokking: By introspecting the code, Grok lets you put different  
> components within a single file. Sometimes you have a single model  
> with just two views. I really like having just one file for this  
> rather than dancing around between a model file and two view files.
>
>  * Python Web Framework Synergy: All web frameworks provide an  
> opinion on how applications should be developed. Sometimes your  
> application is very similar to the type of application that the  
> original authors of the framework were trying to create, and you  
> are a happy developer. Other times your application ends up  
> becoming quite a different creature and you find yourself "fighting  
> the framework" . For me, there are certain web sites/apps where  
> Grok is an obvious choice, other times I find that using Plone is  
> the obvious choice, and sometimes the app sits somewhere in the  
> middle and either framework could provide a good solution. While  
> Plone and Grok are two quite different creatures, since they are  
> both from the world of Python and Zope, it is relatively easy to  
> "choose the right tool for the job". It's also easy, and getting  
> easier, to find good functionality in the other Python web  
> frameworks and apply that code to your own Python web project.

With "Python web-framework synergi" did I understand you correctly  
that you mean "several specialised frameworks built on the same  
platform (Zope). Learning one gives you knowledge of the others and  
you can chose whichever suits your project the best."

>
>>
>> 5 What might be considered drawbacks with Grok compared to  
>> "competing" frameworks?
>
> * Relational databases, relational databases and relational  
> databases. There are so much data already out there in relational  
> databases, and many existing systems where you just want to provide  
> a view or window into just a subset of that database.

 From what I understand, there is support for relational databases,  
but in what state are these? There is also discussion about  
SQLAlchemy (which looks very promising).

>
>   In addition, while relational databases lock you into a more  
> rigid way of thinking about your data, the constraints imposed by  
> them open up other ways of working with data. Rails has script/ 
> generate for creating new CRUD boilerplate, and Django has the  
> lovely Django Admin interface. Neither of these could port cleanly  
> to a ZODB-based system without forcing the ZODB to act more like a  
> relational database.
>
> * Grokking: By introspecting the code, grok lets you put different  
> components within a single file. This means there is less  
> convention 'baked in' to the framework, and you sometimes have to  
> think, "Where should I put this component" - this is more of a  
> hurdle when you are just learning Grok. To the brand new Rails  
> developer, looking at some folders called Model, View and  
> Controller, running script/generate, and then starting to edit the  
> generated boilerplate provides a very strong message of positive  
> reinforcement, as you feel like you are using Rails in "The Right  
> Way".
>
>>
>>
>> 6 If someone explained Grok in an article or review in a single  
>> paragraph, what would we want it to say?
>
> Lots of irrational hype that might not be 100% true but would  
> convince people to give Grok a try :)
>
>>
>> 7 If I described a "beginner" Grok newbie, what features in Grok  
>> would interest him the most?
>
> Templating, Views and Models.
>
>>
>> 8 If I described an "advanced" Grok newbie, what features in Grok  
>> would interest him the most?
>
> Components, Adapters, Interfaces, and Schemas.
>
>>
>> 9a Is there a silver bullet? (Something that if one gets it, just  
>> puts Grok in a class of itself with regards to competitors)
>
> The Zope Component architecture. Grok provides a very strong story  
> for code reuse and maintainability. So often I see/hear the debate  
> of Strong Typing versus Dynamic Typing - Java proponents who find  
> Python and Ruby messy because you need to peek into the  
> implementation to deduce the intent of some code. Python and Ruby  
> advocates who are horrified by the reams of code generated by Java  
> and it's IDEs. zope.interface addresses many of the concerns of a  
> typical Java developer, namely, "How do I use this object, what  
> does it's methods expect, what do they return and what attributes  
> does it have? Be specific.", while still staying within the  
> wonderful realm of the best dynamically typed language out there.
>
>> 9b Is the silver bullet easy to explain?
>
> No. And trying to explain interfaces and adapters to a web dev  
> newbie just makes them feel like the silver bullet is pointed at  
> them :(
>
>