I wanted to build an awesome place for people to discuss module specific issues, but I don't have any more time for this, and there are much better places to discuss Perl-related issues. I'd recommend asking your question on Stack Overflow or on Perl Monks.
If you are looking for a Perl tutorial or Perl-related news, I hope these links will serve you well.
MasonX-Maypole
Posted on 2005-02-17 16:48:37-08 by mreece
overriding factory templates
if i mkdir /Public/apache/beerdb/beer/ and cp /Public/apache/maypole/factory/view_related there, and do the same for /Public/apache/beerdb/brewery, and make a slight change to each (such as adding THIS IS BEER VIEW_RELATED and THIS IS BREWERY VIEW_RELATED), then the first one that gets requested gets compiled and saved as {mason_dir}/obj/table/view_related, and is then used for both tables. if i rm {mason_dir}/obj/table/view_related, then view the other type first, that one gets stored in obj/table/ and is used for both.

shouldn't i be able to override the view_related template for each table? why are they stored in and retrieved from "obj/table/" instead of "obj/beer/" and "obj/brewery/"?
Direct Responses: 135 | Write a response
Posted on 2005-02-19 01:16:19-08 by mreece in response to 132
Re: overriding factory templates
changing line 263 (or near there, i've added and removed so many debugging statements that my line numbers may be slightly off) from

$m->prefix_comp_root( "table=>$table_comp_root" ) if -d $table_comp_root;

to

$m->prefix_comp_root( $self->table . "=>$table_comp_root" ) if -d $table_comp_root;

seems to fix this. now compiled components get written to and retrieved from {data_dir}/obj/{table_name}/ instead of "obj/table/"
Direct Responses: 136 | 137 | Write a response
Posted on 2005-02-19 01:18:01-08 by mreece in response to 135
Re: overriding factory templates
sorry, that is in the file MasonX/Maypole.pm (sub send_output).
Direct Responses: Write a response
Posted on 2005-02-19 20:57:44-08 by davebaird in response to 135
Re: overriding factory templates

Strange, I've never come across the problem, but I can see from the patch that you're right. I'll fix this in a release tomorrow, and see if I can figure out why it hasn't affected me yet. By the way, I'm changing this method to derive the comp_root from the model class rather than the table, to keep closer to the paths() method in Maypole::View::Base. Should be a transparent change. Ideally I'd find a way of using the paths() method directly, but I think it spits out the comp roots in the wrong order for Mason.

d.

Direct Responses: Write a response