On Tue, Sep 8, 2009 at 1:39 AM, David E. Wheeler<da...@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@lists.jifty.org
> http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
>
--
Best regards, Ruslan.
_______________________________________________
jifty-devel mailing list
jifty-devel@lists.jifty.org
http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
