[Grok-dev] Benefits of Grok -- please contribute
kevin at bud.ca
Wed May 16 00:42:58 EDT 2007
> 1 What does a developer look for when choosing a web development
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
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"
* 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...
More information about the Grok-dev