wrt-ls is a provisional interface to the tools in WRT::EntryStore. It
should do more, but work is needed that I'm not going to put in before
releasing v5.0.0.
This seems like a good point to call things stable for this major release.
I have a bunch of ideas that I'd like to implement for a v6, which might
well break the API and underlying data structures.
This is all pretty academic since no one else actually uses this thing.
- uses file_get_contents() for include processing
- adds cache_includes setting
- uses include_cache on wrt instance to stash file contents in memory
I didn't expect that this would be substantially faster than just letting
the kernel worry about it, but on a large set of files with includes in
the template, it shaves about 100ms off a render.
I'm not actually sure this is worth it.
- give absolute paths to imgsize() so it chills out on Cwd::getcwd() calls
- rip out App::WRT::MethodSpit's convenience accessors and just access
elements of $self directly
- kill local_path()
- stop using a() in entry_markup()
- cache get_date_entries_by_depth() results
- swap out state vars for stashing things on $self in
get_all_source_files()
This gets rendering the whole p1k3 repo back down in the neighborhood of
2.1 seconds, which is a lot more tolerable than 5 or 6.
It also kinda technically breaks the API, maybe, so I guess this'll be a
v5.0.0 after a while.
I went and read:
https://pause.perl.org/pause/authenquery?ACTION=pause_namingmodules
Realized I should probably not name this something with an inscrutable
top-level namespace. WRT is still inscrutable, I guess, but at least
it's now under App.
- Renames all modules, fixes tests (such as they are)
- Zaps old t/validate/ stuff
- adds include_process() in WRT::Markup
- moves eval_perl() into WRT::Markup. The way object instances are
composed (and instance methods called) here still feels pretty janky,
and this does nothing to help the situation.
- changes all existing $root_dir instances to $entry_dir; adds a $root_dir
which represents the root of the archive (top-level folder containing
the wrt.json file)
I'd be worried about the $root_dir change if I thought this module had a
single other user in the wild, but I strongly doubt that it does. If I
am wrong and you are that user, I apologize sincerely in advance.
The include feature still has fairly unsettled semantics, but it gets the
whole thing much closer to a usable site generator.