[Grok-dev] is automatic context detection harmful?

[Luciano Ramalho]

I agree with Brandon that grok.context should become mandatory, so
that we'd have one canonical way of doing that.

The main reason for me would be to make grok easier to explain.

I think for small web apps it's not bad at all to put the model and
view code in the same module, at least initially. In fact, for small
apps it's natural to put several models and views in the same module,
which then requires the use of grok.context anyway.

Regards,

Luciano


On 8/24/07, Brandon Craig Rhodes <brandon at rhodesmill.org> wrote:
> The current rule, as I understand it, is that a grok.View without an
> explicit grok.context() will take as its default context the
> grok.Model declared in the same module, if one exists.
>
> This makes it easy and natural to define a Model and its corresponding
> View in the same module.  It is then harder to place a Model and View
> in different files, since not only will the View's module have to
> "import" the Model (the normal cost of placing things in two different
> modules), but it will then have to declare the relationship through
> grok.context().
>
> I wonder whether this will make newcomers think that it is somehow
> dirty, or unnatural, or odd to place a model and view in different
> modules - won't it make them feel that putting a Model and View in
> different modules is something bad and un-Grok-like, since it "breaks
> the Grok magic", and makes them declare relationships "by hand"?
>
> I fear, therefore, that magic context detection will discourage good
> application design among new developers, because it makes normal and
> good what is actually a fairly poor development practice.  The Zope 3
> book states very clearly how good applications are organized:
>
>    "It is a Zope convention to separate components that are specific
>     to a certain type of representation into different modules or,
>     when the amount of code is substantial, into different packages."
>     (Page 97)
>
> This would mean declaring Models in one module and Views in another
> module - exactly what Grok makes abnormal!
>
> Furthermore - and this is really what makes me ask this old question
> over again - it means that new developers reading the tutorials have
> to learn "two ways" to associate Models and Views.  And it means that
> some Grok applications will be written one way, with each module
> holding one Model and its Views without any grok.context() calls, and
> some Grok applications will be written another way, with Models and
> Views split into different modules and grok.context() calls all over
> the place.
>
> I find, as I write my first tutorial (yes, it's coming, but I am a
> slow writer!), that I am very tempted to simply use grok.context()
> everywhere, because it just seems to make everything simpler and more
> readable.  When grok.context() is always used, there is just One Way
> to do things, and whether someone choses to place Models and Views in
> the same module, or split them apart into several modules, the actual
> code will read the same in each case.  There are no exceptions to
> learn, and - in my opinion! - code becomes far more self-documenting
> and obvious because you can always "see" the context of every View
> without learning magic rules.
>
> I understand that this issue was probably settled long ago, that lots
> of example and real code would break with such a change, and that the
> tutorials will have to be re-written.  But if the choice were mine, I
> would go ahead and remove the magic!  It would make Grok much simpler
> to explain, code would become more consistent, and Grok applications
> would be easier to read.  It seems better to me that everyone go ahead
> and throw grok.context() calls into their code and tutorials for 0.12
> than for us to reach 1.0 with two entirely different ways for Views to
> find their Model, especially since the "magic way" encourages poor
> application design and makes a more normal Zope-3-style organization
> of code look suspicious to the newcomer.
>
> --
> Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>