[pmwiki-users] Blog proposal
Hans
design at softflow.co.uk
Wed Jan 11 13:14:11 CST 2006
Wednesday, January 11, 2006, 5:11:17 PM, Patrick wrote:
> I never intended that blog entries could only exist on one trail page.
> I've always been of the opinion that pages can exist on multiple
> trails. Even though it wasn't explicitly mentioned in my proposal,
I am glad I just misunderstood your intentions.
> ... And the admin could set
> $BlogTrailFmt = array('{$Group}.BlogTrail', 'BlogArchive.2005-03', ...);
> to have "(:blog:)" automatically populate to several pages.
It would be good if it is possible to have
'BlogArchive.{$CurrentMonth}' in the array, so the blog page gets
added to the current monthly archive. But I think this is very
easy to achieve.
But it leads to the interesting question of having a series of special
purpose blog page variables defined.
for my blog setup I defined so far:
{$Today} - returns today's date in form of yyyy-mm-dd, used as a name
prefix in the newpagebox
{$BlogTitle} - returns the name of a page without any leading date prefix,
if it has a name part at all.
{$BlogDate} - returns the page creation date in a friendly format
(I use dd mmm yyyy European fashion)
{$LastModifiedDate} - returns the date of last modified time without
the hour and minutes part, in a friendly
format for sidebar lists of recent comments
{$BlogMonth} - returns month and year in long format from a page
name using yyyy-mm format (used for monthly archive
pages)
and i am playing right now with
{$Revisions} - returns the page rev number, to be used as a crude
counter for the number of comments posted to the comments page
> But the idea of making it easier to create trails has lots of
> merit. But I'm wondering if this means that the generic form of
> trails becomes the new way to handle categories as well -- i.e.,
> a page with category markup automatically adds itself to the
> corresponding category trail.
Yes I would have thought so.
> I'm not a great fan of trying to have trail pages specify their
> own format -- that becomes a real pain to manage, especially as
> they're being created automatically. Better is to have the
> trail page simply contain a bullet list of pages, and then use
> (:pagelist:) to specify alternate formatting options.
This is a good approach and better than the one I was thinking of.
We can have admin or system defined defaults if needed of various
formats, like the $RecentChangesFmt. And we can build special
formatted pages with pagelist using pagelist templates. We can do that
already now, like an alternative formatted RecentPage2 page
> We might also come up with a (:traillist:) version of pagelist
> that reads (and removes) a trail from the current page and replaces
> it with the formatted version of that trail. Thus the trail can
> continue to be a simple bullet list, but can be formatted on display
> using any pagelist format.
This may be a little hard to maintain and unpredictable in output.
To keep an auto-trail page of a simple list and a separate page for
formatted output using pagelist is simpler and more robust I guess.
This also solves a problem with an auto-generated trail page like
RecentChanges, which is the difficulty in changing the format of the
page later on. Having a raw list of page links on one page and a
formatted list generated through pagelist one can easily change the
format and indeed the info supplied in the list, using various page
variables, and one can hand-edit the raw list to remove unwanted
intrusions etc. So it combines both benefits of a trail page and of
a pagelist using templates for formatting.
And I suppose a pagelist generated from a trailpage should be quick
and easy on the system.
Best,
~Hans
More information about the pmwiki-users
mailing list