Re: "pybloxsom"??

Good eyes! That's definitely a typo on my part. I'm sorry about that.

I'm hoping to do a 1.5rc3 in the near future. So we'll have to do with
the typo for a while.

On 01/25/2011 09:09 PM, ky wrote:

> Hi, my name is sacrada, Japanese pyblosxom beginner.
>
> I was anxious very very few from before...
>
> When I extracted pyblosxom-1.5rc2.tar.gz, folder name was
> pyblo'xs'om-1.5rc2.
>
> typo?
>
> If there are some mistakes in English, I'd like to apologize.
>
> sacrada

Re: "pybloxsom"??

So there are two things I don't like about pyblosxom:

One of them is my mild screwup where the repository is "pyblosxom", the
package is "Pyblosxom", the module is "pyblosxom" and the class is
"PyBlosxom". I mean, seriously, wtf? I'm almost positive this is a
problem I caused, but I did it so many years ago that I'm going to
pretend it was an evil doppleganger.

The second thing is that I don't particularly care for "pyblosxom" as a
name. It's a mouthful. I keep misspelling it, too.

One of the things we've been talking about is switching renderers
because the current one is pretty hacky and generally a poor renderer.

I think if we decided to ditch the blosxom renderer for something sane,
then at that point, we'll have shed most of our blosxom roots. At that
point it doesn't make sense to continue to emulate blosxom. And at that
point, we could change the names and kick off a new project. We could
probably spend some time fixing up other legacy problems that I created
like the total debacle that is entries.

Anyhow, it's not something I want to do today, but maybe something that,
if enough people were interested, we could think about doing in the future.

Re: "pybloxsom"??

On Wed, Jan 26, 2011 at 05:39:15AM -0500, will kahn-greene wrote:
> The second thing is that I don't particularly care for "pyblosxom" as a
> name. It's a mouthful. I keep misspelling it, too.

Yeah, it's a bit ugly. But it's nice to have a name that references the
blosxom roots. I always liked the idea of "posxum" because I like animal
names and I think it's funny, but it's ugly too. I think the osx in
blosxom is for OS X, but PyBlosxom seems more like a linux thing (or is
it just me?), so maybe it should have a name with li or ux or nux or
something in it.

> One of the things we've been talking about is switching renderers
> because the current one is pretty hacky and generally a poor renderer.

Yeah. I think Jinja is pretty cool.

> I think if we decided to ditch the blosxom renderer for something sane,
> then at that point, we'll have shed most of our blosxom roots. At that
> point it doesn't make sense to continue to emulate blosxom. And at that
> point, we could change the names and kick off a new project. We could
> probably spend some time fixing up other legacy problems that I created
> like the total debacle that is entries.

Sounds exciting! What I really like about PyBlosxom is the ease of
posting to it because posts are just plain text files. There are many
blog, wiki and website engines that use text files for posts or pages
now but most of them, e.g. Jekyll, have a more awkward file syntax than
PyBlosxom. They make you put a YAML document at the top of the file with
certain fields, something like:

---
title: My Blog Post
layout: default
---

Content here...

PyBlosxom's fiist line = title is just a lot nicer than this, there's
nothing to remember. Perhaps it's because I don't post often and don't
want to memorise a syntax for it.

I also think that the plugin pipeline where it's easy to write plugins
to modify things at each different stage is really neat.

The rendering engine is really what I don't like about pyblosxom.
Whenever I try to do something with pyblosxom I end up fighting against
it. It just wants me to have a blog where the front page shows the n
most recent posts in full and then there are archive pages for each
year/month/day showing all those posts in full. But that's just not the
kind of blog format that I want. There are lots of different ways that
people do their blog front pages and archive pages. So it needs more
flexibility.

I think what you want is to use a proper template language like jinja
that can have loops and conditionals and stuff, and to be able to do
custom queries against the 'database' of posts such as: get the n most
recent posts, get the titles only of all posts, get all posts tagged
something, etc, and then loop over the resulting posts and spit them out
into the page.

What I'd suggest is that each file in a flavour directory corresponds to
a URL:

You can put whatever template files you want in the flavour, they don't
have to be head, foot and story, etc. If a visitor requests the root URL
then index.jinja will be rendered, and it might render the most recent
posts, or do whatever the template code inside index.jinja wants to do.
If the /archive URL is requested them archive.jinja would be rendered,
and so on.

post, category, year and month would be treated specially by pyblosxom.
For example, if a post permalink URL like /posts/my-blog-post is
requested then post.jinja would be rendered, and pyblosxom would pass
the requested entry object corresponding to my-blog-post to the template
code so it knows which post is being requested. Similarly,
category.jinja woud be called to render category URLs and passed the
name of the requested category, and so on.

So although flavours are not restricted to a set of mandatory template
files like head, foot, story etc. and can define whatever URLs they
want, some URLs/template files are treated specially by pyblosxom.

I guess this sort of thing can probably be written as a renderer plugin
for pyblosxom?

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev_______________________________________________
pyblosxom-users mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/pyblosxom-users

Re: "pybloxsom"??

On 02/23/2011 02:45 PM, seanh wrote:

> On Wed, Jan 26, 2011 at 05:39:15AM -0500, will kahn-greene wrote:
>
>> I think if we decided to ditch the blosxom renderer for something sane,
>> then at that point, we'll have shed most of our blosxom roots. At that
>> point it doesn't make sense to continue to emulate blosxom. And at that
>> point, we could change the names and kick off a new project. We could
>> probably spend some time fixing up other legacy problems that I created
>> like the total debacle that is entries.
>
> The rendering engine is really what I don't like about pyblosxom.
> Whenever I try to do something with pyblosxom I end up fighting against
> it. It just wants me to have a blog where the front page shows the n
> most recent posts in full and then there are archive pages for each
> year/month/day showing all those posts in full. But that's just not the
> kind of blog format that I want. There are lots of different ways that
> people do their blog front pages and archive pages. So it needs more
> flexibility.
>
> [snip]
>
> I guess this sort of thing can probably be written as a renderer plugin
> for pyblosxom?

I think that's a good start. I suspect the big problem you're going to
run into is that the existing plugins expect the existing renderer and
might not work well with the new renderer.

Regardless, I think the only way we're going to figure that out and move
forward is if someone takes the plunge and starts identifying issues.

/will

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev_______________________________________________
pyblosxom-users mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/pyblosxom-users

Re: "pybloxsom"??

> What I'd suggest is that each file in a flavour directory corresponds to
> a URL:
>
> myflavour/
> index.jinja
> archive.jinja
> some_other_page.jinja
> post.jinja
> category.jinja
> year.jinja
> month.jinja
>
> You can put whatever template files you want in the flavour, they don't
> have to be head, foot and story, etc. If a visitor requests the root URL
> then index.jinja will be rendered, and it might render the most recent
> posts, or do whatever the template code inside index.jinja wants to do.
> If the /archive URL is requested them archive.jinja would be rendered,
> and so on.
>
> post, category, year and month would be treated specially by pyblosxom.
> For example, if a post permalink URL like /posts/my-blog-post is
> requested then post.jinja would be rendered, and pyblosxom would pass
> the requested entry object corresponding to my-blog-post to the template
> code so it knows which post is being requested. Similarly,
> category.jinja woud be called to render category URLs and passed the
> name of the requested category, and so on.
>
> So although flavours are not restricted to a set of mandatory template
> files like head, foot, story etc. and can define whatever URLs they
> want, some URLs/template files are treated specially by pyblosxom.

Wait! This is dumb. The pyblosxom core should just have a simple
algorithm to decide which template file to render based on the URL
requested, then it should render the template code passing the requested
URL into it.

User requests /foo, /foo.jinja template is rendered and the URL request
"/foo" is passed to the template code as argument. Users requests
/foo/bar, /foo.jinja template is rendered and "/foo/bar" is the
argument. Unless the flavourdir actually contains a subdir foo with a
bar.jinja template in it, in which case that template file would be
rendered instead.

So for example a year.jinja template would get rendered for a URL like
/year/2011. The template code inside year.jinja could parse the
"/year/2011" string it gets as its argument and make a request to
pyblosom for all entries from 2011 and render them.

So pyblosxom core would know nothing about front page, archive page,
permalink page, category page etc templates. It only knows that there
are template files, it has an algorithm for deciding which template file
to render based on the requested URL, and it passes the URL string into
the template code.

But this breaks the current feature where the path to the file for an
entry is the permalink URL to that entry.

Would be fun to work on a plugin. I'll add it to my list of things to
maybe do in the future.

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev_______________________________________________
pyblosxom-users mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/pyblosxom-users

Re: "pybloxsom"??

> The pyblosxom core should just have a simple
> algorithm to decide which template file to render based on the URL
> requested, then it should render the template code passing the requested
> URL into it.
>
> User requests /foo, /foo.jinja template is rendered and the URL request
> "/foo" is passed to the template code as argument. Users requests
> /foo/bar, /foo.jinja template is rendered and "/foo/bar" is the
> argument. Unless the flavourdir actually contains a subdir foo with a
> bar.jinja template in it, in which case that template file would be
> rendered instead.
>
> So for example a year.jinja template would get rendered for a URL like
> /year/2011. The template code inside year.jinja could parse the
> "/year/2011" string it gets as its argument and make a request to
> pyblosom for all entries from 2011 and render them.
>
> So pyblosxom core would know nothing about front page, archive page,
> permalink page, category page etc templates. It only knows that there
> are template files, it has an algorithm for deciding which template file
> to render based on the requested URL, and it passes the URL string into
> the template code.

interesting. reminds me a bit of the routing feature in CakePHP/RoR, but using the filesystem instead of a config file.

> But this breaks the current feature where the path to the file for an
> entry is the permalink URL to that entry.

not if you reintroduce it with a plugin.

I'm all in favor of making the core more generic and giving more power to plugins.
However, I wonder how such an approach affects the interfaces between plugins. if more and more of the main functionality goes into plugins, that might mean compatibility between plugins becomes tricky/complicated.

Dieter

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev_______________________________________________
pyblosxom-users mailing list
[hidden email]https://lists.sourceforge.net/lists/listinfo/pyblosxom-users