[jifty-devel] RFC: New Template::Declare Mixin Interface
David E. Wheeler
david at kineticode.com
Wed Oct 7 17:31:57 EDT 2009
On Oct 6, 2009, at 2:17 PM, David E. Wheeler wrote:
> Before I document these methods, I'd like to propose a new interface
> that incorporates the features of both importing and aliasing, but
> gives template authors and users a log more control over composition.
> It's simpler, too. I propose a new method: mix.
I've gone ahead and done this in [a branch](http://svn.jifty.org/svn/jifty.org/Template-Declare/branches/mixmaster
), just to be safe. The new `mix()` method looks pretty much like
`alias()`, but with a little more (optional) sugar:
mix Some::Clever::Mixin under '/mixin';
mix Some::Other::Mixin under '/otmix', set { name =>
'Larry' };
mix My::Mixin into My::View, under '/mymix';
Note the use of `into`, so that one does not have to be in the scope
of the package that one wants to mix into. This will prove useful for
a new Catalyst view implementation I have in mind, but I suspect that
it will be useful for other folks, too: it allows one to compose
templates into all sorts of mixtures, if you will.
I can take or leave the use of `set`, but I thought it kind of went
along with other sugary keywords. If it's hated for any reason, I can
kill it off; it's entirely optional.
Of course, you can omit the sugar altogether if you like:
Some::Clver::Mixin->mix( '/mixin' );
Some::Other::Mixin->mix( '/otmix', { name => 'Larry' } );
My::Mixin->mix('My::View', '/mymix');
Here's what I've done in the mixmaster branch:
* Converted the implementation of `alias()` to be the same as that
used for `import_templates()`.
Side-effects:
+ Aliasing a class with super classes now passes the class in which
each template is defined as the invocant to the alias templates. For
example, if Foo defines the template `hello` and Bar inherits from
Foo, and you alias Bar under /here, it used to be that "Bar" would be
passed to /here/hello, but now Foo is passed to /here/hello. This is
how `import_templates` worked, so I suspect that the previously
inconsistent behavior was an oversight.
+ The `aliases` and `alias_metadata` class accessors are gone, as
is `_has_aliased_template()`. The latter method was private, and the
two accessors were undocumented. Were they ever used anywhere, perhaps
in Jifty?
* Added `mix` as described above. No side-effects. I moved the and
updated the documentation for `alias` under `mix` and updated the
documentation for `alias` and `import_templates` to say that they were
deprecated in favor of `mix`.
That's about it. If the changes to `alias` break existing code, I can
revert those changes -- or mock up a compatible interface. But I
suspect that they will have no effect. I'd appreciate some testing.
Assuming that I get buy-in from the interested parties, I'll merge
these changes into trunk and finally fill in the documentation for
mixins. After that, the only other issue I know of is with `path_for()
`, mentioned in another thread. I can fix that after the merge.
Best,
David
More information about the jifty-devel
mailing list