On Wed, Jun 12, 2002 at 12:04:56PM -0700, Bill Moseley wrote: > But I guess that's the wrong way since it's placing HTML in the model.
It's good that the warning bells are ringing, but remember that separating model and view isn't always as simple as separate Perl from HTML. The view should concern itself with the presentation. Usually that means HTML, but there's nothing to stop you from embedding Perl that does a presentation task without feeling too guilty. Similary, you also have to consider that sometimes HTML is performing an application controlling task. In this case, the URL that you generate is effectively a computed goto and as such, should be handled by the model or controller. > It's also bad because other models can't add info to that link, such as > advanced/standard search form to use, "skin", brief/full view, etc. And there's the rub. A URL can include application control parameters and also presentation parameters. http://example.com/product?action=add&style=compact > Now, it's nice to be able to have template variables like > [% search.navigation.next_page %] > > So, should the controller or the templates (view) build those links? Why not have the model define, or a controller build, a hash of URL plugins. my $urls = { product => { # first arg to plugin is context, but we can leave this undef list => Template::Plugin::URL->new(undef, '/product', { action => 'list' }), edit => Template::Plugin::URL->new(undef, '/product', { action => 'edit' }), ...etc... } } And then in the template, you can: [% url.product.list %] or [% url.product.list(style='compact') %] Instead of using the URL plugin, you could just as easily define your own URL builder, based on the URL plugin code (constructor returns a closure sub), which adds your state information, etc. HTH A
