Menu
▾
▴
pyblosxom-users
|
From: Chris G <cl...@is...> - 2010-01-31 10:10:02
|
I know it's probably totally back to front for a blog but how easy would it be to get pyblosxom to display posts in increasing date order? Is the ordering set at just one place in the code? I'm quite happy to just patch my installed pyblosxom code as I realise this won't be a common requirement. For what it's worth I want to create a [not]blog where the story template will just display the date and title so one sees just a list of entries - in increasing date order. -- Chris Green |
|
From: Chris G <cl...@is...> - 2010-01-31 10:33:31
|
On Sun, Jan 31, 2010 at 10:09:54AM +0000, Chris G wrote:
> I know it's probably totally back to front for a blog but how easy
> would it be to get pyblosxom to display posts in increasing date
> order? Is the ordering set at just one place in the code? I'm quite
> happy to just patch my installed pyblosxom code as I realise this
> won't be a common requirement.
>
> For what it's worth I want to create a [not]blog where the story
> template will just display the date and title so one sees just a list
> of entries - in increasing date order.
>
Taking to myself - sign of madness - but still.....
Is this the relevant bit, from pyblosxom.py :-
entrylist = [(e._mtime, e) for e in entrylist]
entrylist.sort()
entrylist.reverse()
entrylist = [e[1] for e in entrylist]
If I take the entrylist.reverse() will I get what I want, with no
serious untoward consequences?
--
Chris Green
|
|
From: chombee <ch...@la...> - 2010-01-31 13:24:51
|
On Sun, Jan 31, 2010 at 10:09:54AM +0000, Chris G wrote: > I know it's probably totally back to front for a blog but how easy > would it be to get pyblosxom to display posts in increasing date > order? Is the ordering set at just one place in the code? I'm quite > happy to just patch my installed pyblosxom code as I realise this > won't be a common requirement. > > For what it's worth I want to create a [not]blog where the story > template will just display the date and title so one sees just a list > of entries - in increasing date order. Could you write a plugin to do this? Using the cb_filelist callback maybe: http://pyblosxom.sourceforge.net/1.5/dev_architecture.html#cb-filelist (love the new sphinx documentation). |
|
From: Chris G <cl...@is...> - 2010-01-31 14:28:00
|
On Sun, Jan 31, 2010 at 01:24:28PM +0000, chombee wrote: > On Sun, Jan 31, 2010 at 10:09:54AM +0000, Chris G wrote: > > I know it's probably totally back to front for a blog but how easy > > would it be to get pyblosxom to display posts in increasing date > > order? Is the ordering set at just one place in the code? I'm quite > > happy to just patch my installed pyblosxom code as I realise this > > won't be a common requirement. > > > > For what it's worth I want to create a [not]blog where the story > > template will just display the date and title so one sees just a list > > of entries - in increasing date order. > > Could you write a plugin to do this? Using the cb_filelist callback > maybe: > > http://pyblosxom.sourceforge.net/1.5/dev_architecture.html#cb-filelist > You could well be right! It would certainly be more elegant to do it with a plugin rather than by patching the code directly. I probably need to write a plugin anyway as I need to do things at cb_story() time to enable me to click on my list and view individual posts. > (love the new sphinx documentation). > Yes, quite agree, it looks good doesn't it. -- Chris Green |
|
From: chombee <ch...@la...> - 2010-01-31 15:40:53
|
On Sun, Jan 31, 2010 at 02:27:41PM +0000, Chris G wrote: > On Sun, Jan 31, 2010 at 01:24:28PM +0000, chombee wrote: > > On Sun, Jan 31, 2010 at 10:09:54AM +0000, Chris G wrote: > > > I know it's probably totally back to front for a blog but how easy > > > would it be to get pyblosxom to display posts in increasing date > > > order? Is the ordering set at just one place in the code? I'm quite > > > happy to just patch my installed pyblosxom code as I realise this > > > won't be a common requirement. > > > > > > For what it's worth I want to create a [not]blog where the story > > > template will just display the date and title so one sees just a list > > > of entries - in increasing date order. > > > > Could you write a plugin to do this? Using the cb_filelist callback > > maybe: > > > > http://pyblosxom.sourceforge.net/1.5/dev_architecture.html#cb-filelist > > > You could well be right! It would certainly be more elegant to do it > with a plugin rather than by patching the code directly. I probably > need to write a plugin anyway as I need to do things at cb_story() > time to enable me to click on my list and view individual posts. You shouldn't need a plugin to click on items in your list and view individual posts. Just make the items hyperlink to the permalink pages for each post. Take a look at the permalinks in the default flavour. I think your plugin needs to do two things (maybe two different plugins): 1. Reverse the sort order of items, maybe a cb_filelist plugin. 2. Make it so that on index pages (such as the front page) only the title of each item is displayed and not the full contents (I think this is what you want?). I think there are a lot of ways to achieve 2. You could do it easily by using one flavour for the index pages and having that flavour hyperlink to another flavour for the permalink pages. Probably there would be much shared code between the two flavours, differing only in the story template, so one flavour could consist mostly of symlinks to the other flavour's files but with its own story file. I've done this before and it works, but I feels a little inelegant. It might be more elegant to write a plugin. This could be a cb_story plugin that changes the 'body' field of a story to an empty string if the request is for an index view. This would be similar to the readmore plugin: http://bluesock.org/~willg/cgi-bin/devtrac.cgi/browser/trunk/pyblosxom/readmore.py#latest Or perhaps it could be a cb_entryparser plugin that changes the value of 'template_name' in the entrydata dict if the request is for an index view, using a different story template for index views and for permalink pages. See: http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-an-entryparser I'm a plugin-writing newbie, so my suggestions might not be the best or easiest way of doing things. Will would know better. |
|
From: will kahn-g. <wi...@bl...> - 2010-02-01 19:17:17
|
On 02/01/2010 02:04 PM, Chris G wrote: > It's supposed to return args (the incoming argument list) as that's > where the story content that gets displayed (the $body) comes from. > > That's how I'm changing from 'ordinary format' to 'index format' at > the moment, be setting the 'body' in the returned args to nothing. > > Looking at the code I'm pretty sure the key is 'template_name', it > refers to that quite a lot in the rendered. However, as I said, I > think the renderer looks for the alternative 'template_name' *before* > cb_story() is called. > > Just tried 'template' instead of 'template_name', no difference. I can't tell if the crux of the confusion in this thread is that there are two different template keys used or not. The "template" in the args dict in cb_head, cb_date_head, cb_story, cb_story_end and cb_foot callbacks is an actual template--it's not the name of a template. These callbacks are renderer callbacks. Prior to those callbacks getting called, you can override the template that gets used to render an entry with the "template_name" variable in the entry dict. This is the name of the template to use to render the entry. By default, it's "story". Changing "template_name" in the entry dict will have NO effect if you're doing it in one of the renderer callbacks because they're beyond template_name things and are working on the actual template. Hope that helps! /will |
|
From: Chris G <cl...@is...> - 2010-02-01 22:45:11
|
On Mon, Feb 01, 2010 at 02:17:08PM -0500, will kahn-greene wrote: > On 02/01/2010 02:04 PM, Chris G wrote: > > It's supposed to return args (the incoming argument list) as that's > > where the story content that gets displayed (the $body) comes from. > > > > That's how I'm changing from 'ordinary format' to 'index format' at > > the moment, be setting the 'body' in the returned args to nothing. > > > > Looking at the code I'm pretty sure the key is 'template_name', it > > refers to that quite a lot in the rendered. However, as I said, I > > think the renderer looks for the alternative 'template_name' *before* > > cb_story() is called. > > > > Just tried 'template' instead of 'template_name', no difference. > > I can't tell if the crux of the confusion in this thread is that there > are two different template keys used or not. > > The "template" in the args dict in cb_head, cb_date_head, cb_story, > cb_story_end and cb_foot callbacks is an actual template--it's not the > name of a template. These callbacks are renderer callbacks. > > Prior to those callbacks getting called, you can override the template > that gets used to render an entry with the "template_name" variable in > the entry dict. This is the name of the template to use to render the > entry. By default, it's "story". Changing "template_name" in the entry > dict will have NO effect if you're doing it in one of the renderer > callbacks because they're beyond template_name things and are working on > the actual template. > Yes, I think I'd sort of got this far. However I don't understand where one *can* change template_name so that it takes effect. -- Chris Green |
|
From: chombee <ch...@la...> - 2010-02-01 21:50:48
|
On Mon, Feb 01, 2010 at 02:17:08PM -0500, will kahn-greene wrote: > The "template" in the args dict in cb_head, cb_date_head, cb_story, > cb_story_end and cb_foot callbacks is an actual template--it's not the > name of a template. These callbacks are renderer callbacks. Then it sounds like we're using the wrong callback. What we want to do is change the template file that gets used, i.e. we want to change template_name. We need a callback that will allow us to change template_name, but only if the request is for a directory view not a file view, so the callback needs to be able to tell what kind of view was requested also. Our problem is just that we're still learning our way around the callbacks and the life cycle of a pyblosxom request. |
|
From: chombee <ch...@la...> - 2010-01-31 18:27:06
|
On Sun, Jan 31, 2010 at 06:12:53PM +0000, chombee wrote: > No, I'm talking about the entrydata dict that the parse method > implemented by a cb_entryparser plugin should return to pyblosxom. This > dict is not passed to your plugin from pyblosxom, your plugin creates > the dict from scratch and returns it to pyblosxom. Look at the parse > method in this example: > > http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-an-entryparser > > It constructs and returns a dict `entrydata` with the keys 'title' and > 'body'. You could also add any other keys you wanted to this dict, and > their values could be used by your flavours or your other plugins. And > you can add the 'template_name' key, which is used by pyblosxom: > > "You can also specify the template to use by setting the "template_name" > variable in the returned dict. If the template specified doesn’t exist, > PyBlosxom will use the story template for the specified flavour." > > So if you put 'template_name' = 'story-title-only' in the dict, then > pyblosxom will look for a template file called 'story-title-only' in > your flavour instead of using the default template file 'story'. Having said all this, cb_entryparser doesn't really seem like the right callback for what you want to do. You don't really want to change how the entry is parsed from file, just how the entry is rendered. Maybe a cb_postformat plugin that adds a 'template_name' key to the entry_data dict. cb_postformat gets an entry_data dict already parsed from file and the request object as its arguments, so it seems well placed to add or not add a 'template_name' key to entry_data based on the contents of the request. Also, if you write a cb_postformat plugin then you might be able to contribute something to the currently empty 'Writing a postformatter plugin' section in the docs! http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-a-postformatter Maybe there are some examples of postformatter plugins in the plugin registry, I'm not sure. |
|
From: chombee <ch...@la...> - 2010-01-31 18:58:38
|
On Sun, Jan 31, 2010 at 06:23:14PM +0000, chombee wrote:
> Having said all this, cb_entryparser doesn't really seem like the right
> callback for what you want to do. You don't really want to change how
> the entry is parsed from file, just how the entry is rendered. Maybe a
> cb_postformat plugin that adds a 'template_name' key to the entry_data
> dict.
No, wait! I think you want the cb_story callback, the same one that the
readmore plugin uses. Like the readmore plugin does, you can get the
entry dict with:
entry = args['entry']
then use 'bl_type' to see if we're dealing with an index or a permalink
page:
if entry['bl_type'] == 'file':
# This is a 'file' page, showing a single entry.
pass
else:
# This is an index page (front page or year, month, day, or
# category etc. page) showing multiple entries.
entry['template_name'] = 'story-index'
As a matter of fact, a 'use different story templates for file
pages and index pages' plugin would be much simpler and more flexible
than the readmore plugin. If you wanted to provide a preview or summary
text for each entry like the readmore plugin does, you could just use a
metadata field for that.
|
|
From: Chris G <cl...@is...> - 2010-01-31 22:20:55
|
On Sun, Jan 31, 2010 at 06:54:46PM +0000, chombee wrote: > On Sun, Jan 31, 2010 at 06:23:14PM +0000, chombee wrote: > > Having said all this, cb_entryparser doesn't really seem like the right > > callback for what you want to do. You don't really want to change how > > the entry is parsed from file, just how the entry is rendered. Maybe a > > cb_postformat plugin that adds a 'template_name' key to the entry_data > > dict. > > No, wait! I think you want the cb_story callback, the same one that the > readmore plugin uses. Like the readmore plugin does, you can get the > entry dict with: > > entry = args['entry'] > > then use 'bl_type' to see if we're dealing with an index or a permalink > page: > > if entry['bl_type'] == 'file': > # This is a 'file' page, showing a single entry. > pass > else: > # This is an index page (front page or year, month, day, or > # category etc. page) showing multiple entries. > entry['template_name'] = 'story-index' > > As a matter of fact, a 'use different story templates for file > pages and index pages' plugin would be much simpler and more flexible > than the readmore plugin. If you wanted to provide a preview or summary > text for each entry like the readmore plugin does, you could just use a > metadata field for that. > Thanks for all the thoughts, I'm just about off to bed now but I'll re-read tomorrow. I agree that switching templates makes more sense and is more flexible. -- Chris Green |
|
From: Chris G <cl...@is...> - 2010-02-01 16:19:21
|
On Sun, Jan 31, 2010 at 06:54:46PM +0000, chombee wrote:
> On Sun, Jan 31, 2010 at 06:23:14PM +0000, chombee wrote:
> > Having said all this, cb_entryparser doesn't really seem like the right
> > callback for what you want to do. You don't really want to change how
> > the entry is parsed from file, just how the entry is rendered. Maybe a
> > cb_postformat plugin that adds a 'template_name' key to the entry_data
> > dict.
>
> No, wait! I think you want the cb_story callback, the same one that the
> readmore plugin uses. Like the readmore plugin does, you can get the
> entry dict with:
>
> entry = args['entry']
>
> then use 'bl_type' to see if we're dealing with an index or a permalink
> page:
>
> if entry['bl_type'] == 'file':
> # This is a 'file' page, showing a single entry.
> pass
> else:
> # This is an index page (front page or year, month, day, or
> # category etc. page) showing multiple entries.
> entry['template_name'] = 'story-index'
>
> As a matter of fact, a 'use different story templates for file
> pages and index pages' plugin would be much simpler and more flexible
> than the readmore plugin. If you wanted to provide a preview or summary
> text for each entry like the readmore plugin does, you could just use a
> metadata field for that.
>
Well I've tried tha above and, so far, I can't get it to work. I'm
detecting the 'file' and 'dir' for single/multiple entries OK.
So my plugin looks like this:-
def cb_story(args):
logger = tools.get_logger()
e = args['entry']
if (e['bl_type'] == 'dir'):
logger.info("It's a 'dir' so set the template_name to 'story-index'")
e['template_name'] = 'story-index'
return args
I'm seeing the logger information in my log file but my template
(story-index.html) isn't being used instead of the default story.html.
I'll try adding some debug in the renderer to see if I can understand
what's going on.
--
Chris Green
|
|
From: Chris G <cl...@is...> - 2010-02-01 16:33:30
|
On Mon, Feb 01, 2010 at 04:19:10PM +0000, Chris G wrote:
> On Sun, Jan 31, 2010 at 06:54:46PM +0000, chombee wrote:
> > On Sun, Jan 31, 2010 at 06:23:14PM +0000, chombee wrote:
> > > Having said all this, cb_entryparser doesn't really seem like the right
> > > callback for what you want to do. You don't really want to change how
> > > the entry is parsed from file, just how the entry is rendered. Maybe a
> > > cb_postformat plugin that adds a 'template_name' key to the entry_data
> > > dict.
> >
> > No, wait! I think you want the cb_story callback, the same one that the
> > readmore plugin uses. Like the readmore plugin does, you can get the
> > entry dict with:
> >
> > entry = args['entry']
> >
> > then use 'bl_type' to see if we're dealing with an index or a permalink
> > page:
> >
> > if entry['bl_type'] == 'file':
> > # This is a 'file' page, showing a single entry.
> > pass
> > else:
> > # This is an index page (front page or year, month, day, or
> > # category etc. page) showing multiple entries.
> > entry['template_name'] = 'story-index'
> >
> > As a matter of fact, a 'use different story templates for file
> > pages and index pages' plugin would be much simpler and more flexible
> > than the readmore plugin. If you wanted to provide a preview or summary
> > text for each entry like the readmore plugin does, you could just use a
> > metadata field for that.
> >
> Well I've tried tha above and, so far, I can't get it to work. I'm
> detecting the 'file' and 'dir' for single/multiple entries OK.
> So my plugin looks like this:-
>
> def cb_story(args):
>
> logger = tools.get_logger()
>
> e = args['entry']
>
> if (e['bl_type'] == 'dir'):
> logger.info("It's a 'dir' so set the template_name to 'story-index'")
> e['template_name'] = 'story-index'
>
> return args
>
>
> I'm seeing the logger information in my log file but my template
> (story-index.html) isn't being used instead of the default story.html.
>
> I'll try adding some debug in the renderer to see if I can understand
> what's going on.
The code in the renderer that looks for the template_name is run
*before* the cb_story plugin, so the template doesn't get changed.
--
Chris Green
|
|
From: chombee <ch...@la...> - 2010-02-02 10:20:26
|
On Mon, Feb 01, 2010 at 06:14:50PM -0500, will kahn-greene wrote:
>
> Say I only wanted to do this if PyBlosxom is rendering a category index
> and not a specific entry. I'd do something like this:
>
> def cb_prepare(args):
> # only thing in the args dict is the request object
> request = args["request"]
>
> # the entry list is in the data section
> data = request.get_data()
>
> entrylist = data["entry_list"]
>
> if data["bl_type"] = "dir" and len(entrylist) > 0:
> first_entry = entrylist[0]
> first_entry["template_name"] = "story_big_size"
>
So it looks like to change the template for every entry that is about to
be rendered you'd have to iterate over entries, something like:
def cb_prepare(args):
request = args['request']
data = request.get_data()
if data['bl_type'] == 'dir':
entrylist = data['entry_list']
for entry in entrylist:
entry['template_name'] = 'story-index'
(Assuming the entries come as dictionaries like that, but you get the
idea.)
|
|
From: will kahn-g. <wi...@bl...> - 2010-02-02 14:42:33
|
On 02/02/2010 05:20 AM, chombee wrote: > > So it looks like to change the template for every entry that is about to > be rendered you'd have to iterate over entries, something like: > > def cb_prepare(args): > request = args['request'] > data = request.get_data() > if data['bl_type'] == 'dir': > entrylist = data['entry_list'] > for entry in entrylist: > entry['template_name'] = 'story-index' > > (Assuming the entries come as dictionaries like that, but you get the > idea.) Entries are not necessarily dicts, but they are dict-like! See Pyblosxom.entries.base and Pyblosxom.entries.fileentry. /will |
|
From: Chris G <cl...@is...> - 2010-02-03 10:12:33
|
On Tue, Feb 02, 2010 at 10:20:10AM +0000, chombee wrote:
> On Mon, Feb 01, 2010 at 06:14:50PM -0500, will kahn-greene wrote:
> >
> > Say I only wanted to do this if PyBlosxom is rendering a category index
> > and not a specific entry. I'd do something like this:
> >
> > def cb_prepare(args):
> > # only thing in the args dict is the request object
> > request = args["request"]
> >
> > # the entry list is in the data section
> > data = request.get_data()
> >
> > entrylist = data["entry_list"]
> >
> > if data["bl_type"] = "dir" and len(entrylist) > 0:
> > first_entry = entrylist[0]
> > first_entry["template_name"] = "story_big_size"
> >
>
> So it looks like to change the template for every entry that is about to
> be rendered you'd have to iterate over entries, something like:
>
> def cb_prepare(args):
> request = args['request']
> data = request.get_data()
> if data['bl_type'] == 'dir':
> entrylist = data['entry_list']
> for entry in entrylist:
> entry['template_name'] = 'story-index'
>
> (Assuming the entries come as dictionaries like that, but you get the
> idea.)
>
This is where I'm going.
I guess/suspect too that one can only change the story template this
way, having looked at the renderer code there's a strange variable
'override' which seems to apply the template_name only when it's
handling a story template.
Here's my actual code:-
def cb_prepare(args):
logger = tools.get_logger()
logger.info("In cb_prepare()")
request = args['request']
data = request.get_data()
entrylist = data['entry_list']
if len(entrylist) > 0:
logger.info("entrylist is > 0")
if data['bl_type'] == "dir":
logger.info("It's a 'dir' so set the template_name to 'story-index'")
for e in entrylist:
e["template_name"] = "story_index"
.... and, after fixing the name of my template so that it matched the
value I was putting into the entry above, it works! Hurrah!
Thanks for all the help everyone, I now have the basis of what I want.
--
Chris Green
|
|
From: will kahn-g. <wi...@bl...> - 2010-02-01 23:14:59
|
On 02/01/2010 05:47 PM, Chris G wrote:
> How can one change the template for just one thing though at that
> stage? I want to change just the story template when certain
> conditions are met.
The prepare callback gets the entire entry list. So when the certain
conditions that you want met are met, you make the change to the
template_name variable in the entry in the entry list.
For example, if I want the first entry that is going to be shown to use
a template story_big_size that I wrote that's just like my story
template, but the font size is bigger so that the entry is more
prominent at the top of the page, I'd do something like this:
def cb_prepare(args):
# only thing in the args dict is the request object
request = args["request"]
# the entry list is in the data section
data = request.get_data()
entrylist = data["entry_list"]
if len(entrylist) > 0:
first_entry = entrylist[0]
first_entry["template_name"] = "story_big_size"
Say I only wanted to do this if PyBlosxom is rendering a category index
and not a specific entry. I'd do something like this:
def cb_prepare(args):
# only thing in the args dict is the request object
request = args["request"]
# the entry list is in the data section
data = request.get_data()
entrylist = data["entry_list"]
if data["bl_type"] = "dir" and len(entrylist) > 0:
first_entry = entrylist[0]
first_entry["template_name"] = "story_big_size"
Does that make sense? This kicks off after PyBlosxom has figured out
what it's rendering, but before it actually gets rendered.
/will
|
|
From: will kahn-g. <wi...@bl...> - 2010-02-01 02:59:04
|
On 01/31/2010 11:16 AM, Chris G wrote:
> Yes, I've got this done, I have a cb_filelist which essentially
> duplicates blosxom_file_list_handler() but without the reverse of the
> sort order.
You could cheat and use the truncatelist callback which kicks of after
the entrylist is sorted in blosxom_file_list_handler.
It'd look something like this:
from Pyblosxom.pyblosxom import blosxom_truncate_list_handler
def cb_truncatelist(args):
entrylist = args["entry_list"]
entrylist.reverse()
args["entry_list"] = entrylist
return blosxom_truncate_list_handler(args)
This fails miserably if you have other plugins that implement the
truncatelist callback and want to do other things. For example, I have
a wbgpager plugin that implements truncatelist to provide paging and the
above cb_truncatelist would hose that.
I almost added a sort callback for 1.5. I'm pretty sure blosxom has
one. If any of you think it'd be useful to have, I can add it in a
jiffy for 1.5.
/will
|
|
From: chombee <ch...@la...> - 2010-02-01 17:39:58
|
On Mon, Feb 01, 2010 at 04:19:10PM +0000, Chris G wrote:
> On Sun, Jan 31, 2010 at 06:54:46PM +0000, chombee wrote:
> Well I've tried tha above and, so far, I can't get it to work. I'm
> detecting the 'file' and 'dir' for single/multiple entries OK.
> So my plugin looks like this:-
>
> def cb_story(args):
>
> logger = tools.get_logger()
>
> e = args['entry']
>
> if (e['bl_type'] == 'dir'):
> logger.info("It's a 'dir' so set the template_name to 'story-index'")
> e['template_name'] = 'story-index'
>
> return args
Sorry, I think the key is 'template' not 'template_name'. In another
callback it was definitely 'template_name', but the docs for cb_story
say:
"The template used is typically the story template, but we allow entries
to override this if they have a template property. If they have the
template property, then we’ll use the template of that name instead."
Funny, I notice that the docs also say: "Functions that implement this
callback must return the input args dict whether or not they adjust
anything in it." But the cb_story in the readmore plugin doesn't return
anything.
|
|
From: Chris G <cl...@is...> - 2010-01-31 16:16:38
|
On Sun, Jan 31, 2010 at 03:36:59PM +0000, chombee wrote: > On Sun, Jan 31, 2010 at 02:27:41PM +0000, Chris G wrote: > > On Sun, Jan 31, 2010 at 01:24:28PM +0000, chombee wrote: > > > On Sun, Jan 31, 2010 at 10:09:54AM +0000, Chris G wrote: > > > > I know it's probably totally back to front for a blog but how easy > > > > would it be to get pyblosxom to display posts in increasing date > > > > order? Is the ordering set at just one place in the code? I'm quite > > > > happy to just patch my installed pyblosxom code as I realise this > > > > won't be a common requirement. > > > > > > > > For what it's worth I want to create a [not]blog where the story > > > > template will just display the date and title so one sees just a list > > > > of entries - in increasing date order. > > > > > > Could you write a plugin to do this? Using the cb_filelist callback > > > maybe: > > > > > > http://pyblosxom.sourceforge.net/1.5/dev_architecture.html#cb-filelist > > > > > You could well be right! It would certainly be more elegant to do it > > with a plugin rather than by patching the code directly. I probably > > need to write a plugin anyway as I need to do things at cb_story() > > time to enable me to click on my list and view individual posts. > > You shouldn't need a plugin to click on items in your list and view > individual posts. Just make the items hyperlink to the permalink pages > for each post. Take a look at the permalinks in the default flavour. > > I think your plugin needs to do two things (maybe two different > plugins): > > 1. Reverse the sort order of items, maybe a cb_filelist plugin. > Yes, I've got this done, I have a cb_filelist which essentially duplicates blosxom_file_list_handler() but without the reverse of the sort order. > 2. Make it so that on index pages (such as the front page) only > the title of each item is displayed and not the full contents (I think > this is what you want?). > You have it in one! :-) > I think there are a lot of ways to achieve 2. You could do it easily by > using one flavour for the index pages and having that flavour hyperlink > to another flavour for the permalink pages. Probably there would be much > shared code between the two flavours, differing only in the story > template, so one flavour could consist mostly of symlinks to the other > flavour's files but with its own story file. I've done this before and > it works, but I feels a little inelegant. > > It might be more elegant to write a plugin. This could be a cb_story > plugin that changes the 'body' field of a story to an empty string if > the request is for an index view. This would be similar to the readmore > plugin: > This is the way I have done it. Fairly simple in the end after [re]learning various bits of python. > http://bluesock.org/~willg/cgi-bin/devtrac.cgi/browser/trunk/pyblosxom/readmore.py#latest > > Or perhaps it could be a cb_entryparser plugin that changes the value of > 'template_name' in the entrydata dict if the request is for an index > view, using a different story template for index views and for permalink > pages. See: > > http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-an-entryparser > > I'm a plugin-writing newbie, so my suggestions might not be the best or > easiest way of doing things. Will would know better. > Ah, it's 'template_name' in the 'entry' dictionary, I was looking for 'template' rather unsuccessfully. No, just tried that, there's no 'template name' in there either. I've just looked through the entry dictionary that you get in cb_story and there's no template, only the flavour. There is a 'template' argument but that's the actual template as a string, maybe one could modif that and return in in the args. It's just as easy to empty (or not) the 'body'. -- Chris Green |
|
From: chombee <ch...@la...> - 2010-01-31 18:16:46
|
On Sun, Jan 31, 2010 at 04:16:29PM +0000, Chris G wrote: > > Or perhaps it could be a cb_entryparser plugin that changes the value of > > 'template_name' in the entrydata dict if the request is for an index > > view, using a different story template for index views and for permalink > > pages. See: > > > > http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-an-entryparser > > Ah, it's 'template_name' in the 'entry' dictionary, I was looking for > 'template' rather unsuccessfully. No, just tried that, there's no > 'template name' in there either. I've just looked through the entry > dictionary that you get in cb_story and there's no template, only the > flavour. There is a 'template' argument but that's the actual > template as a string, maybe one could modif that and return in in the > args. No, I'm talking about the entrydata dict that the parse method implemented by a cb_entryparser plugin should return to pyblosxom. This dict is not passed to your plugin from pyblosxom, your plugin creates the dict from scratch and returns it to pyblosxom. Look at the parse method in this example: http://pyblosxom.sourceforge.net/1.5/dev_writing_plugins.html#writing-an-entryparser It constructs and returns a dict `entrydata` with the keys 'title' and 'body'. You could also add any other keys you wanted to this dict, and their values could be used by your flavours or your other plugins. And you can add the 'template_name' key, which is used by pyblosxom: "You can also specify the template to use by setting the "template_name" variable in the returned dict. If the template specified doesn’t exist, PyBlosxom will use the story template for the specified flavour." So if you put 'template_name' = 'story-title-only' in the dict, then pyblosxom will look for a template file called 'story-title-only' in your flavour instead of using the default template file 'story'. > It's just as easy to empty (or not) the 'body'. Yeah, but I consider this solution less optimal. You might want your items on your index views to appear different from how they look on their permalink pages in ways other than just not having a body. Using separate story templates for the two views is more flexible. |
|
From: will kahn-g. <wi...@bl...> - 2010-02-01 21:56:08
|
On 02/01/2010 04:50 PM, chombee wrote: > On Mon, Feb 01, 2010 at 02:17:08PM -0500, will kahn-greene wrote: >> The "template" in the args dict in cb_head, cb_date_head, cb_story, >> cb_story_end and cb_foot callbacks is an actual template--it's not the >> name of a template. These callbacks are renderer callbacks. > > Then it sounds like we're using the wrong callback. What we want to do > is change the template file that gets used, i.e. we want to change > template_name. We need a callback that will allow us to change > template_name, but only if the request is for a directory view not a > file view, so the callback needs to be able to tell what kind of view > was requested also. Our problem is just that we're still learning our > way around the callbacks and the life cycle of a pyblosxom request. You're probably looking for the prepare callback which allows you to change things just before rendering. The lifecycle section of teh dev_architecture page should cover this, but it seems to do so in a difficult to read fashion. That should probably get reworked. /will |
|
From: Chris G <cl...@is...> - 2010-02-01 22:47:52
|
On Mon, Feb 01, 2010 at 04:56:01PM -0500, will kahn-greene wrote: > On 02/01/2010 04:50 PM, chombee wrote: > > On Mon, Feb 01, 2010 at 02:17:08PM -0500, will kahn-greene wrote: > >> The "template" in the args dict in cb_head, cb_date_head, cb_story, > >> cb_story_end and cb_foot callbacks is an actual template--it's not the > >> name of a template. These callbacks are renderer callbacks. > > > > Then it sounds like we're using the wrong callback. What we want to do > > is change the template file that gets used, i.e. we want to change > > template_name. We need a callback that will allow us to change > > template_name, but only if the request is for a directory view not a > > file view, so the callback needs to be able to tell what kind of view > > was requested also. Our problem is just that we're still learning our > > way around the callbacks and the life cycle of a pyblosxom request. > > You're probably looking for the prepare callback which allows you to > change things just before rendering. > How can one change the template for just one thing though at that stage? I want to change just the story template when certain conditions are met. > The lifecycle section of teh dev_architecture page should cover this, > but it seems to do so in a difficult to read fashion. That should > probably get reworked. > I think it does, but cb_prepare sounded too early. -- Chris Green |
|
From: Chris G <cl...@is...> - 2010-02-01 11:24:52
|
On Sun, Jan 31, 2010 at 09:58:54PM -0500, will kahn-greene wrote: > On 01/31/2010 11:16 AM, Chris G wrote: > > Yes, I've got this done, I have a cb_filelist which essentially > > duplicates blosxom_file_list_handler() but without the reverse of the > > sort order. > > You could cheat and use the truncatelist callback which kicks of after > the entrylist is sorted in blosxom_file_list_handler. > I found this callback in the code when I was copying duplicates blosxom_file_list_handler() as I had to have a copy of the code which is called as the default truncatelist for blosxom_file_list_handler() to work. > It'd look something like this: > > from Pyblosxom.pyblosxom import blosxom_truncate_list_handler > > def cb_truncatelist(args): > entrylist = args["entry_list"] > entrylist.reverse() > args["entry_list"] = entrylist > > return blosxom_truncate_list_handler(args) > > > This fails miserably if you have other plugins that implement the > truncatelist callback and want to do other things. For example, I have > a wbgpager plugin that implements truncatelist to provide paging and the > above cb_truncatelist would hose that. > Should it be added to the documentation? (cb_truncatelist that is) Or is it too likely to cause problems? > I almost added a sort callback for 1.5. I'm pretty sure blosxom has > one. If any of you think it'd be useful to have, I can add it in a > jiffy for 1.5. > Well I do I suppose. :-) -- Chris Green |
|
From: Chris G <cl...@is...> - 2010-02-01 11:34:33
|
On Mon, Feb 01, 2010 at 11:24:45AM +0000, Chris G wrote: > On Sun, Jan 31, 2010 at 09:58:54PM -0500, will kahn-greene wrote: > > On 01/31/2010 11:16 AM, Chris G wrote: > > > Yes, I've got this done, I have a cb_filelist which essentially > > > duplicates blosxom_file_list_handler() but without the reverse of the > > > sort order. > > > > You could cheat and use the truncatelist callback which kicks of after > > the entrylist is sorted in blosxom_file_list_handler. > > > I found this callback in the code when I was copying duplicates Delete that 'duplicates'. > blosxom_file_list_handler() as I had to have a copy of the code which > is called as the default truncatelist for blosxom_file_list_handler() > to work. > > > It'd look something like this: > > > > from Pyblosxom.pyblosxom import blosxom_truncate_list_handler > > > > def cb_truncatelist(args): > > entrylist = args["entry_list"] > > entrylist.reverse() > > args["entry_list"] = entrylist > > > > return blosxom_truncate_list_handler(args) > > > > > > This fails miserably if you have other plugins that implement the > > truncatelist callback and want to do other things. For example, I have > > a wbgpager plugin that implements truncatelist to provide paging and the > > above cb_truncatelist would hose that. > > > Should it be added to the documentation? (cb_truncatelist that is) > Or is it too likely to cause problems? > > > > I almost added a sort callback for 1.5. I'm pretty sure blosxom has > > one. If any of you think it'd be useful to have, I can add it in a > > jiffy for 1.5. > > > Well I do I suppose. :-) > > -- > Chris Green > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > pyblosxom-users mailing list > pyb...@li... > https://lists.sourceforge.net/lists/listinfo/pyblosxom-users -- Chris Green |
Thanks for helping keep SourceForge clean.
X