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 _______________________________________________ jifty-devel mailing list jifty-devel@lists.jifty.org http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
