Re: pod to template -- treating data as templates -- avoid it

yeah, generating a template out of your pod document is something I would avoid

request.uri_base gotta come from somewhere, so just give it to Pod::Simple::XHTML directly

Or, you can always use Template::Plugin::Class ... or create your own plugin, and add it to your template ..

Doesn't matter how many passes you make -- it takes as many as it takes

Comment on Re: pod to template -- treating data as templates -- avoid it

Replies are listed 'Best First'.
Re^2: pod to template -- treating data as templates -- avoid it by pokki (Monk) on Jan 29, 2015 at 12:29 UTC
request.uri_base gotta come from somewhere, so just give it to Pod::Simple::XHTML directly So, generate the rendered POD dynamically? Right now it's pregenerated earlier (when the indexer, which is another process, notices that the package index has changed). That means I need to keep the distribution tarballs around though. I'll give it a try and see if that works.	[reply]
Re^3: pod to template -- treating data as templates -- avoid it by Anonymous Monk on Jan 30, 2015 at 00:12 UTC
So, generate the rendered POD dynamically? Sure, why not :) If you want to have absolute urls like `http://localhost:5000/mirror/integration/module/Acme::Foo`generating this stuff on demand makes sense to me:) But I don't see why you can't have relative urls like `Acme::Foo` so that when `http://localhost:5000/mirror/integration/module/Acme::Foo` serves Acme::Foo, all the links that are relative and correct and then you don't need to know the prefix `http://localhost:5000/mirror/integration/module/` in advance	[reply] [d/l] [select]