[jifty-devel] Template::Declare Updates

Ruslan Zakirov ruslan.zakirov at gmail.com
Mon Sep 7 23:20:21 EDT 2009

On Tue, Sep 8, 2009 at 1:39 AM, David E. Wheeler<david at kineticode.com> wrote:
> Fellow Templaters,
> Jesse was foolish enough to give me a commit bit a few days ago, and
> I've been going to town on the Template::Declare documentation. See
> the [archives][] for what I've been about. A partial overview:
> * Various whitespace fixes.
> * Documented `alias`. I also updated `t/alias.t` as I read it, trying to
>   understand how aliasing works.
> * Reformatted the POD, moving things around, fixed some broken examples,
>   and separated example outputs from the scripts that generate them.
> * Fixed the TODO utf8 tests. I am not a fan of HTML::Lint.
> * Switched from 'Template::Declare' to __PACKAGE__ where possible.
> * Documented `import_templates`, updating the tests as I read them to
>   understand how it worked.
> * Fixed a regression in `import_templates` that I discovered while
>   fooling around with an idea (more below on that idea).
> * Made example code and example output indentation consistent.
> * Fixed some more bugs in the examples.
> * Added a proper SYNOPSIS section to the Template::Declare POD.
> * Cleaned up the POD in Template::Declare::Tags,
> Template::Declare::TagSet,
>   and Template::Declare::TagSet::*.
> * Re-instated the pod-coverage test, which now passes.
> [archives](http://lists.jifty.org/pipermail/jifty-commit/2009-September/subject.html
> )
> Now, I was doing all this in order to better understand
> Template::Declare, towards improving the Catalyst view for it. I have
> a few questions, though, and would appreciate some feedback:
> * Is my documentation for `alias` and `import_templates` correct?
> * Why do we have both `alias` and `import_templates`? The latter
>   seems superfluous.

At first I thought that imported templates dispatch relative paths
differently, but a test showed that it's not true. I can not answer this
question. I see absence of package variables, some crazy path_for function
that is broken when a class imported many times and performance
difference (imported templates are installed at compile-time)

> * What are the `new_buffer_frame()` and `end_buffer_fram()` methods
>   for? They were not documented, but I see that the catalyst view
>   uses them.

The way to catch any output. In some cases it's used to allow code
inside templates influence output before the current text. For example
in Jifty's plugin ViewDeclarePage I use it to allow people define
title and add additional links into head of the page inside templates.

As far as I can see Catalyst plugin can avoid using buffers.

> * `package_variables()` had a bug that made it useless. It also was
>   not previously documented. Should I remove it?

Don't know.

> * What is the `append_attr()` function for, and how does it work?

Real append_attr is set to a closure when you are inside a tag. So
calls like attr { foo => 'x' } and foo is 'x' work as expected and
don't work outside a tag.

> * Can `get_current_attr()` be removed, since it's deprecated?

Not sure, it can be undocumented.

> * How does `show_page()` differ from `show()`?

show_page don't dispatch to private templates. show dispatches via
show_page if we're not in a template allready, otherwise dispatches to
any templates including private.

> * How are roots supposed to work? They don't seem to be searched
>   for more packages to load. Why call them roots if it's really
>   just a list of packages that define templates?

roots overlay each other. Terminology probably is from mason. A
template from first root wins.

> * What is the meaning of paths? Is there one by convention among
>   Jifty users, perhaps?

I don't understand the question. Paths are paths, like everywhere.

> And finally, I have a couple of ideas I'd like to run by the group,
> for new featuers:
> * I'd like to add a `move` method. It would work just like
>   `import_templates`, except that the original template name
>   would be removed. Basically, it would move all templates in
>   the named subclass under the given path:
>     move MyApp::Templates under '/here';

Can you describe it a little bit more?

> * I'm thinking of adding a `wrap()` function like `show()` that
>   would invoke the named wrapper. So if you'd created a wrapper
>   function using `create_wrapper foo => sub { ... }`, you could
>   then call it like so:
>     wrap( foo => show('bar') )
>   This will allow a (public) wrapper to easily be used in namespaces
>   outside of which it was defined. Thoughts?

Real life sexy usage?

> Thanks for your thoughts. As I said, I'm doing this all towards
> improving the Catalyst view for Template::Declare. Specifically, I'm
> looking at using the `move` method to move all the templates defined
> in a Catalyst template package under a path. for example, if I have
> MyApp::View::TD, and all the templates were under it, there might be:
>   MyApp::View::TD::Root
>   MyApp::View::TD::Lookup
>   MyApp::View::TD::List
> My thought is to make it s that the templates in the latter two
> packages are moved to be under /lookup/ and /list/, which would make
> them better parallel Catalyst controller and action names. Thoughts?

As far as I can see Catalyst::View::Template::Declare defines all
classes in MyApp::View::TD::* namespace as TD roots, dosn't it? It's
just misuse of the feature and similar to saying "let's alias all
those classes under /". What makes aliasing and importing useless and
force you to type full names of your templates all the time.

> Best,
> David
> _______________________________________________
> jifty-devel mailing list
> jifty-devel at lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel

Best regards, Ruslan.

More information about the jifty-devel mailing list