[Grok-dev] Re: Me Grok Play Chess!

Maurits van Rees m.van.rees at zestsoftware.nl
Sun Apr 15 18:43:36 EDT 2007

Philipp von Weitershausen, on 2007-04-15:
> I have a few comments that are mostly motivated by aesthetics, but do 
> represent some of the common patterns that we're trying to promote with 
> Grok:

Thanks for your feedback.

> * It looks like you're (ab)using relative imports to get to the
>    chessmind package which in itself seems like an independent library.
>    It's your code so you can do whatever you want with it, but I would've
>    split this up:
>    - a top-level 'chessmind' package that's independently reusable
>    - a top-level 'grokchess' package that requires the installation of
>      'chessmind' (e.g. via setuptools dependencies).

That was my intention.  It was just slightly easier to put it all in
one package in the beginning so one svn checkout would suffice for me.
I will see to it.

Hm, I thought it would be a simple matter of moving that subdirectory
chessmind to its own directory in src/.  That gave some import
problems, pointing to less than optimal use of imports on my part.
Fixed.  The code is now split:


> * I saw you added a lot of methods on the Index view for access from the
>    template.
>    Some of them are a bit non-sensical because they only publish
>    attributes of the view itself:
>    - start_square
>    - target_square
>    - errors,

I somehow got the idea that this was necessary, that you could not
simply get the attributes.  Ah, in my daily Plone work I am used to
defining an interface that says which methods/attributes are allowed
to be used in a template.  But that is not needed here, so I can get
rid of some methods yes.

>    - promotion (that one is even faulty, I believe, since it returns the
>      method object itself)

It might seem faulty, but it works. :)  It returns True or False just
like I want.

Sigh.  I put a pdb in there to check what happens.  The pdb is never
executed.  So the method is never called. :)

Okay, I removed those methods.

>    Other methodsexpose data from the context object. This is good because
>    it keeps templates simple since they don't have to reach into content
>    space. Writing lots of methods for that if the data is needed either
>    seems like a lot of work and a lot of typing. It also significantly
>    adds to the lenght of the module, making it harder to grasp at first.
>    Why not set attributes in update() that you can then access from the
>    template? E.g.::
>      def update(self):
>          ...
>          self.checkmate = self.context.game.board.isCheckMate()
>          self.stalemate = self.context.game.board.isStaleMate()
>          etc.

That is cleaner yes.  But that would make the update method larger and
it is rather large already.  And not all those attributes are needed
with every move.  And some of those methods/attributes need to be
calculated after the board has been changed.  And after that change
has been made (e.g. a move) we currently return from update()

Oh well, I can refactor that. :)  Done.

The view now only has:

    def update(self):
    def do_requested_actions(self):
    def promotion_row(self):
    def board(self):

where do_requested_actions() is called almost at the beginning of
update().  The other two methods could also be set as attributes in
update(), but that would make that method too long.

>> The Grok part of the application is basically just a browser view.  It
>> has no tests whatsoever.  Sorry.  When I was building the chess engine
>> I wondered what a good way would be to make a user interface.  Since I
>> am working daily with Zope and Plone I thought it would be nice to try
>> out Grok for this.  I was right! :-D
> This is a nice perception. I had hoped Grok made an good platform for 
> writing web UIs for Python libraries. It's good to see it worked well 
> for you.

Yes.  In this case I just had to make a very simple Application/Model:

class ChessMinder(grok.Application, grok.Model):
    def __init__(self):

    def reset(self):
        self.game = ChessGame()

and a View class that provides hooks into the functionality of that
python library.  And a zope page template (and some images taken from
openclipart.org and a css file) that talks to the view class.  The
idea is pretty easy.

A big thank you to you and other Grokkers who made this possible!

Maurits van Rees | http://maurits.vanrees.org/ [NL]
            Work | http://zestsoftware.nl/
"Do not worry about your difficulties in computers,
 I can assure you mine are still greater."

More information about the Grok-dev mailing list