[Dancer-users] Feature RFC: uri_for in templates

Flavio Poletti polettix at gmail.com
Sat Nov 6 12:28:34 CET 2010

On a general note, why not Plugin AND Core? Dancer::Plugin::Ajax is in Core
but it is a plugin.

In the specific, this has two steps imho. On the one hand Dancer should
expose this functionality in a clean way, on the other we have that the
different templating systems have their differences in terms of weight and
power, so I'd leave to the template-specific adaptation layers the job of
making it possible to access this functionality or not.

I guess I have missed the whole point of it all, of course, but hey! these
are just my 2c.


On Sat, Nov 6, 2010 at 9:44 AM, sawyer x <xsawyerx at gmail.com> wrote:

> Hi!
> We've been asked a few times about uri_for() functionality in Dancer's
> templates.
> Since Dancer doesn't throw context object variables in your templates, you
> cannot run uri_for() there. We do have a uri_for() keyword in our main
> Dancer framework but not in templates. I reckon one of the obvious reasons
> we don't provide context objects is because it deludes the purpose of a
> declarative, micro web framework. Also, it's not very portable since some
> template engines don't support it.
> Even though, following the growing myth ("if you mention it, one might
> exist when you wake up tomorrow") - which (David Precious)++ has been
> feeding lately, I've written this morning a one-liner that provides you with
> uri_for in your templates.
> I implemented it with a coderef in a way that is still not very portable.
> However, I could implement it with tie which will probably make it very
> portable but uses magic which is considered "unadvised".
> Should I use tie to provide full portability (in HAML, Template::Tiny and
> even Dancer::Template::Simple) or should I stay with a clean implementation
> that will work for some?
> Do you think it should this go into Dancer core or should this be reserved
> for a plugin?
> Core:
> - It's common functionality for most frameworks.
> - It would be easier for people to find and use it instead of having to
> search for a plugin they don't know exists.
> Plugin:
> - It could support both a clean non-portable interface and an ugly portable
> interface using a parameter.
> - Dancer doesn't shove anything in your templates on purpose. This
> functionality breaks it, so maybe it should be a plugin.
> - It could be listed on Dancer::Plugins to indicate to users that it
> exists.
> Thoughts?
> Sawyer.
> _______________________________________________
> Dancer-users mailing list
> Dancer-users at perldancer.org
> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.backup-manager.org/pipermail/dancer-users/attachments/20101106/4da1a2b6/attachment.htm>

More information about the Dancer-users mailing list