Menu
▾
▴
pyblosxom-devel
|
From: will <wi...@bl...> - 2003-01-25 20:51:55
|
There's already a max config parameter. I'm wondering if we shouldn't have an override via the url. I don't know how we want to handle ignoring certaing directories in pyblosxom. I would think this is the sort of thing we want to do globally somehow. Maybe tools.Walk should know about ignored directories and not recurse through them? /will On Sat, 25 Jan 2003, Theodore W. Leung wrote: > A max seems like a good idea -- the question is is it a form argument or a > config parameter. > Also, I hacked my local copy of pycategories.py to test whether there are > CVS directories present. I'm version controlling my data directory, so that > I can check out a copy on my laptop and blog disconnected. > > Ted > > > -----Original Message----- > > From: pyb...@li... > > [mailto:pyb...@li...] On Behalf Of will > > Sent: Saturday, January 25, 2003 8:40 AM > > To: pyb...@li... > > Subject: [Pyblosxom-devel] category listings > > > > > > > > I fixed up categories so it's all pretty now. When doing > > that I noticed > > that if you browse by category, you only get the max number > > of entries as > > specified in the ini file. I was wondering if it'd be a good > > thing to add > > a max override on the url like the flavour. Something like this: > > > http://www.bluesock.org/~willg/cgi-bin/pyblosxom.cgi/dev?max=26 > > In this case, we would show 26 entries. Would that be a good idea, or > not? My concern is that old entries won't be viewable if we spill over > the max. Of course, I guess it prevents people from pulling _all_ your > entries. I don't know if that's good or bad, though. How do other > *blosxom things handle this? > > /will > > > -- whatever it is, you can find it at http://www.bluesock.org/~willg/ except Will--you can only see him in real life. |
|
From: Wari W. <wa...@ce...> - 2003-01-27 02:03:51
|
* will <wi...@bl...> [030126 04:49]: > There's already a max config parameter. I'm wondering if we shouldn't > have an override via the url. Yeah, that max parameter is called num_entries in py dict. > I don't know how we want to handle ignoring certaing directories in > pyblosxom. I would think this is the sort of thing we want to do > globally somehow. Maybe tools.Walk should know about ignored > directories and not recurse through them? This is a limitation that should be addressed by a template (it's the template problem domain). But the only thing is that blosxom templates are not that powerful to do such things. Why templates, well if you expect a large number of entries, you will need to do an index template, for an index template, it'll be light on the bandwidth. Another thing we could consider is to have a <prev and a next> page thingy. First time you'll see an entry overflow, you'll have something like pyblosxom.cgi/category?page=n, which then causes pyblosxom to display (num_entries * n) to (num_entries * n + (num_entries - 1)) What do you think? Of course, this would need a page plugin thingy that takes in an entryList, and modifies it to display the proper entries. -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ |
|
From: will <wi...@bl...> - 2003-01-27 05:51:34
|
On Mon, 27 Jan 2003, Wari Wahab wrote: > > > I don't know how we want to handle ignoring certaing directories in > > pyblosxom. I would think this is the sort of thing we want to do > > globally somehow. Maybe tools.Walk should know about ignored > > directories and not recurse through them? > > This is a limitation that should be addressed by a template (it's the > template problem domain). But the only thing is that blosxom templates > are not that powerful to do such things. Mmmm... Perhaps we should have template entries in the ini file that dictate properties for those templates? In regards to ignoring things globally, I would think that there are a series of directories (and files) that would want to be ignored by everything--regardless of the template. So then maybe we shoudl add something like this to the ini file: ignore = CVS *.tmp and then tools.Walk would naturally never return those kinds of files. /will ps. I didn't notice I was doing a reply-all on all of the previous emails until just now. My apologies to those who just got duplicates and triplicates of some of them. |
|
From: Wari W. <wa...@ce...> - 2003-01-27 06:44:20
|
* will <wi...@bl...> [030127 13:49]: > > This is a limitation that should be addressed by a template (it's > > the template problem domain). But the only thing is that blosxom > > templates are not that powerful to do such things. > Mmmm... Perhaps we should have template entries in the ini file that > dictate properties for those templates? Too many places to do things, I was thinking of something like feature.flavour files that override certain pyblosxom variables. A feature.index (for example in my indexes) could contain things like: num_entries all foo bar etc etc blog_title My Little Foo Blog :) Let me think about this, and see how useful can this be. > In regards to ignoring things globally, I would think that there are a > series of directories (and files) that would want to be ignored by > everything--regardless of the template. So then maybe we shoudl add > something like this to the ini file: > ignore = CVS *.tmp > and then tools.Walk would naturally never return those kinds of files. You know, the more I see tools.Walk, the more I agree to myself that we shouldn't use it. A better way is to have an entry object of some sort, pass it some parameters when we instantiate it, and it fills itself up with entry dicts and have methods like getBody or something so that plugins can use it, the entry object should also probably know about it's 'neighbours' like the comments for example. I don't know how that can happen though. Right now, plugins can't do anything with the contents. This means changing pyblosxom's architecture, and related plugins. I need to think about how to get this done. > ps. I didn't notice I was doing a reply-all on all of the previous > emails until just now. My apologies to those who just got duplicates > and triplicates of some of them. I have a remove duplicate script in my procmail, so it's okay by me, but how would you know if someone is or is not in the mailing lists (ok, this list for now is just you me and Theodore :) -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ vim: syntax=mail tw=72 |
|
From: will <wi...@bl...> - 2003-01-27 14:56:39
|
On Mon, 27 Jan 2003, Wari Wahab wrote: > > In regards to ignoring things globally, I would think that there are a > > series of directories (and files) that would want to be ignored by > > everything--regardless of the template. So then maybe we shoudl add > > something like this to the ini file: > > ignore = CVS *.tmp > > and then tools.Walk would naturally never return those kinds of files. > > You know, the more I see tools.Walk, the more I agree to myself that we > shouldn't use it. A better way is to have an entry object of some sort, > pass it some parameters when we instantiate it, and it fills itself up > with entry dicts and have methods like getBody or something so that > plugins can use it, the entry object should also probably know about > it's 'neighbours' like the comments for example. I don't know how that > can happen though. Right now, plugins can't do anything with the > contents. This means changing pyblosxom's architecture, and related > plugins. I need to think about how to get this done. Actually, that bit about plugins can't do anything with the contents--that's not true. Before anything gets printed out, it goes through an executeTransform call in printTemplate. So every plugin can adjust the contents of a given entry if it registers with the parseitem callback chain. That's what I implemented when I did the pyfortune plugin. I think you had some issues with it, but it hasn't been removed yet. /will |
|
From: Wari W. <wa...@ho...> - 2003-01-27 15:19:47
|
will wrote: >Actually, that bit about plugins can't do anything with the >contents--that's not true. Before anything gets printed out, it goes >through an executeTransform call in printTemplate. So every plugin can >adjust the contents of a given entry if it registers with the parseitem >callback chain. > Ah, I forgot about that at the moment of writing this, ignore my ramble :) But I did have something I wanted to do that sort of replace tools.Walk(). I'm not sure, but I think it's got to do with the entry abstraction that Abe was talking about (he's on holidays now though), but yeah, once that happens, tools.Walk will only happen in blosxom type entries. >That's what I implemented when I did the pyfortune plugin. I think you >had some issues with it, but it hasn't been removed yet. > > The only issue was the dynamic stuff that pyfortune created, but there is a use for this type too, like I mentioned before, the acronym expansion.. I need to get out of my butt and create something with this. |
|
From: Wari W. <wa...@ho...> - 2003-01-28 11:48:39
|
Wari Wahab wrote: >* will <wi...@bl...> [030127 13:49]: > > >>>This is a limitation that should be addressed by a template (it's >>>the template problem domain). But the only thing is that blosxom >>>templates are not that powerful to do such things. >>> >>> >>Mmmm... Perhaps we should have template entries in the ini file that >>dictate properties for those templates? >> >> >Too many places to do things, I was thinking of something like >feature.flavour files that override certain pyblosxom variables. > >A feature.index (for example in my indexes) could contain things like: > >num_entries all >foo bar >etc etc >blog_title My Little Foo Blog :) > >Let me think about this, and see how useful can this be. > I've done this already, if you were to check out http://roughingit.subtlehints.net/pyblosxom/weblogs?flav=index you'll see that 41 entries are listed. I've got the index template for this to show the data, in addition to that, I used a config.index flavour file, which now contains two lines of configuration data: ------------------------ num_entries 999 blog_title Indexes, indexes my friend ------------------------ You'll see the data reflected nicely, the change is basically in getFlavours() code. My question is this: 1. Do we agree on this? 2. Can this be a plugin instead? Here's the diff for you to try out on your installations: ------------------------------------------------ diff -u -r1.12 pyblosxom.py --- pyblosxom.py 22 Jan 2003 14:27:43 -0000 1.12 +++ pyblosxom.py 28 Jan 2003 11:36:14 -0000 @@ -94,7 +94,7 @@ # End of ugly portion! Yucks :) # Look for flavours in datadir - pattern = re.compile(r'(content_type|head|date_head|date_foot|foot|story)\.' + taste) + pattern = re.compile(r'(config|content_type|head|date_head|date_foot|foot|story)\.' + taste) flavourlist = tools.Walk(self.py['root_datadir'], 1, pattern) if not flavourlist: flavourlist = tools.Walk(self.py['datadir'], 1, pattern) @@ -108,6 +108,15 @@ if not flavours.has_key(taste): taste = 'error' + + if flavours[taste].has_key('config'): + for line in flavours[taste]['config'].split('\n'): + s = line.strip(); + if s != '': + match = re.match(r'(\w+)\s+(.*)', line) + if match: + self.py[match.groups()[0]] = match.groups()[1].strip() + return flavours[taste] def getProperties(self, filename, root): |
|
From: Wari W. <wa...@ho...> - 2003-01-28 11:52:26
|
Wari Wahab wrote: > Here's the diff for you to try out on your installations: Sheesh, this is the ugliest copy and pasted diff I've ever seen :) Adjust accordingly. |
|
From: will <wi...@bl...> - 2003-01-28 14:36:47
|
I like the idea and I think the implementation should definitely get checked in. That solves my use case in a nicely general way that's tied to the flavors themselves. I wouldn't make it a plugin though. I think that's a necessary element of pyblosxom configuration and as such shouldn't be a plugin. Nice! /will On Tue, 28 Jan 2003, Wari Wahab wrote: > > I've done this already, if you were to check out > http://roughingit.subtlehints.net/pyblosxom/weblogs?flav=index you'll > see that 41 entries are listed. I've got the index template for this to > show the data, in addition to that, I used a config.index flavour file, > which now contains two lines of configuration data: > ------------------------ > num_entries 999 > blog_title Indexes, indexes my friend > ------------------------ > You'll see the data reflected nicely, the change is basically in > getFlavours() code. My question is this: > 1. Do we agree on this? > 2. Can this be a plugin instead? > > Here's the diff for you to try out on your installations: > ------------------------------------------------ > diff -u -r1.12 pyblosxom.py > --- pyblosxom.py 22 Jan 2003 14:27:43 -0000 1.12 > +++ pyblosxom.py 28 Jan 2003 11:36:14 -0000 > @@ -94,7 +94,7 @@ > # End of ugly portion! Yucks :) > # Look for flavours in datadir > > - pattern = > re.compile(r'(content_type|head|date_head|date_foot|foot|story)\.' + taste) > + pattern = > re.compile(r'(config|content_type|head|date_head|date_foot|foot|story)\.' > + taste) > flavourlist = tools.Walk(self.py['root_datadir'], 1, pattern) > if not flavourlist: > flavourlist = tools.Walk(self.py['datadir'], 1, pattern) > @@ -108,6 +108,15 @@ > > if not flavours.has_key(taste): > taste = 'error' > + > + if flavours[taste].has_key('config'): > + for line in flavours[taste]['config'].split('\n'): > + s = > line.strip(); > + if s != > '': > + match = re.match(r'(\w+)\s+(.*)', line) > + if match: > + self.py[match.groups()[0]] = > match.groups()[1].strip() > + > return flavours[taste] > > def getProperties(self, filename, root): |
|
From: Wari W. <wa...@ho...> - 2003-01-28 15:11:39
|
will wrote: >I like the idea and I think the implementation should definitely get >checked in. That solves my use case in a nicely general way that's tied >to the flavors themselves. > > So let it be written, so let it be done. :) |
Thanks for helping keep SourceForge clean.
X