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

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

>
> 2 What does a manager look for when choosing a web development  
> framework?

Managers are strange and unknowable creatures ... :P

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

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

   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 :(


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20070515/38e638de/attachment.htm