Hi, as you know I use Plastic to create Fantom types on the fly. It is this technique that powers the templating engines efan and Slim. Only, after I've used Plastic to compile some types, it seems impossible to then read files from pods. I get:

sys::Err: Not backed by pod file: afPlastic031
  fan.sys.Pod.loadFiles (Pod.java:337)
  fan.sys.Pod.file (Pod.java:320)

This is when I try to read any pod resource, such as fan://afBedSheet/doc/pod.fandoc which clearly has nothing to do with any generated pods and their types. It doesn't matter if I set checked to false or not.

Looking at the Java source, it seems sys::Pod.files and sys::Pod.file first call loadFiles() which indiscriminately throws an Err if a pod store is found to be null.

Given it is now quite common (for me at least!) to create pods on the fly, could this Err condition be overlooked?

Pods you compile on the fly don't have any file based backing store. They are just compiled into bytecode and Java classes on the fly. So you can't read files from them, because there is no file(s).

But you mentioned that when compiling pods on the fly that you can't access resources from file based pods. If that is true, that would be a bad bug. I played around with a few minutes and don't see that problem. But if you a reproducible test case maybe you can email me.

Ah, typical. I can't reproduce it myself now either! :(

Yeah, I understood why the file based backing store would be null; it's just, when I looked at Pod.java it seemed to cache all the pod files on the first call to loadFiles(), throwing an Err should any pod not have a backing store.

My hypothesis was, if I compiled a new pod before any pod resource was looked up, then when loadFiles() was called for the first time, my compiled pod would exist without a backing store, and loadFiles() would Err.

I was running the Bed Nap App at the time, trying to load pod.fandoc to render on the page.

Anyhow, if it happens again I'll email over the details - thanks for looking / trying!