> What I didn't like about this is I then had to adjust the so-called
> controller code that decoded the user input for my request object to
> include these new features.  But really that data was of only interest
to
> the model.  So a change in the model forced a change in the
controller.

No, a change in the user interface forced a change in the controller,
which is fine.  Your user interface now supports parameters of starting
page and page size, so the controller has to know how to handle those
parameters and translate them for the model.  (Incidentally, it's not
such a good idea to make page size a query arg.  Better to put it in
some config file on the server.)

For example, you might have controller code like this:
my $query = $apr->param('query');
my $page  = $apr->param('page');

my $search = Model::Search->new(
                                query => $query,
                                page  => $page,
                               );

The controller is tightly coupled to parsing and handling user input,
but knows nothing about what that model object will do with it.  It is
basically translating HTTP requests into sets of method calls on model
objects.

> So now I just have been passing in an object which has a param()
method
> (which, lately I've been using a CGI object instead of an
Apache::Request)
> so the model can have full access to all the user input.  It bugs me a
bit
> because it feels like the model now has intimate access to the user
input.

I agree, this is not good.  The controller is supposed to be parsing
that stuff and abstracting it from the model.  The model shouldn't care
if you decide to start encrypting some parameters, or getting them from
the user's session, or using different names for them on different
forms.

> My second, reasonably unrelated question is this: I often need to make
> links back to a page, such as a link for "page next".  I like to build
> links in the view, keeping the HTML out of the model if possible.  But
for
> something like a "page next" link that might contain a bunch of
parameters
> it would seem best to build href in the model that knows about all
those
> parameters.

I don't think it makes a huge difference, but I would probably assemble
these either in the controller or in the view.  The model would just
provide the data.  If they are simple links (i.e. same params always, no
logic) you should be able to use any templating system to build them.
Template Toolkit has a URL plugin for convenience:
http://www.template-toolkit.org/docs/default/Modules/Template/Plugin/URL
.html

- Perrin

Reply via email to