On Apr 5, 9:36 am, Tim Black <[email protected]> wrote:
> I'm beginning to think that when I write controllers named things like
> getTaskHTML() or setTaskHTML() when I have a model.Task object but it
> doesn't have an attribute named HTML, I should refactor those methods to
> this form: model.Task.HTML where HTML is a Python property or is
> accessible via __setattr__ and __getattribute__
> <http://www.builderau.com.au/program/python/soa/Less-painful-getters-a...>.
> In general, if I'm writing controller methods that are merely basic
> manipulations of model objects, I'm thinking I should put those methods
> into the model rather than the controller. Is that correct?
I started experimenting with inner classes on this current project
which is what made me wonder what other people were doing. I'm having
a slight issue with the inner class accessing a private function
defined in the outer class, but, I think overloading a base class
actually makes the code less readable in my case.
I have a class that communicates with a distributed management
system. Tasks are passed with encrypted XMLRPC. I could have done
something like:
class Tool(object):
def _communicate(self, params):
class Hammer(Tool):
class Saw(Tool):
But, that seemed less logical than:
class Tool(object):
def _communicate(self, params):
class Hammer(object):
class Saw(object):
Grouping the tasks within the main class seemed less intuitive to me.
If I used Hammer, I wouldn't know it was overloading Tool using the
first method, but, if I used inner classes, Tool().Hammer()
immediately told me that Hammer was a Tool. From a readability
standpoint, I've inferred more information. The only real issue I've
had with inner classes is calling private methods from the parent
class and that is probably something I'm doing wrong.
As for the initial question, what I've been doing is putting the code
in the controller that does the actual work. Any form or schema goes
into the model (this becomes a bit odd when dealing with callables),
and classes/functions go into lib. Last night I was debating whether
to move callables to a library because two different controllers might
use the same callable. The alternative I thought of was having
generic callables since they are populated from the controller and are
somewhat agnostic to the value that they pass to the form. That does
introduce some readability concerns, but, I haven't figured out which
way to go there.
MVC was fairly well defined by Smalltalk, but, the lines are somewhat
blurred. A strict MVC would never put code in a template, but, there
are many instances where I've broken that, and, Mako makes it
extremely easy to do so. I try not to do things that will impact
maintainability down the road and am trying to do things 'the right
way' before refactoring a ton of code.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
