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

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.

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

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::Foogenerating 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]