Feature RFC: uri_for in templates
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.
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. Flavio. On Sat, Nov 6, 2010 at 9:44 AM, sawyer x <xsawyerx@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@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
participants (2)
-
Flavio Poletti -
sawyer x