You can add a filters.prop in an entry, containing a list of filters to
apply which will be pulled out of the guts of wrt. I'm not sure if this
is a good idea or not, to be honest. It's elegant enough, but it feels
a bit obscure.
I'm also not sure if it should accommodate the user writing custom filters
that can sit in the wrt repo, but it kind of feels like that would be
more in the spirit of things...
This stashes the HTML version of every entry in memory and uses
Mojo::DOM to extract headers from the markup for use as titles.
Titles are displayed in $self->{page_navigation}, now available
inside templates as ${page_navigation}.
In order to keep Mojo::DOM from choking on other input, it uses the open
pragma to open everything as UTF-8 by default, which also eliminates a
whole class of character encoding bugs and removes some fiddling with
Encode::decode() from feed_print().
This is all obviously a more memory-intensive, but caching the markup
turns out to have the side effect of making it much faster to render
even a large site, probably as much as anything because the HTML in
question is only getting generated once per entry instead of
(potentially) 2-3 times.
This commit isn't very atomic. In the process of roughing it out and
testing it, I made a small pile of minor but potentially breaking
changes:
- Removed entry_map from settings and hardcoded handling of various
types of entry as some if-statements instead.
- Removed embedded_perl flag in settings - was always turned on in
practice, and wasn't very coherent since templating would have
broken without it.
- bin/wrt-display - now handles the "feed" alias correctly
- EntryStore: now supports retrieving values for properties with
prop_value() - this isn't currently used, but it seems like a
reasonable extension of the property idea.
- Added `wrt ls --with-titles`.
- Added dependency versions to Build.PL.
- Refactored Markup's line_parse() a little.
- Refactored some tests to give cleaner / more useful output.
- Renamed default template file to "default".
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.