RE: url handling (was RE: [Pyblosxom-devel] Egads! Bugs?)

[Blake W. <bl...@ph...>]

> We could toss logstats.py in the the url handler chain and 
> it'd work as you've suggested.  But it should be noted that
> it's not handling the url--it's using the executeHandler
> mechanism as event notification.  That's fine, but that's
> not really what I was asking for.  I'll try to put it
> another way.  My issue is are there any use cases where we 
> want to have two functions that generate an entire page from
> the same url?

Okay, I see the difference.  Hmmm...

If you insist on having the word "entire" in there, then
I can't imagine how we would want two functions to be called,
both handling the same url.

If you modify your last sentence to read:
> My issue is are there any use cases where we want to have
> two functions that generate parts of a page from the same
> url?
Then I would suggest that the comment plugin could only display
the comments, and leave the displaying of the actual body of
a post to the default pageview plugin.  We could have the comment
plugin call the base template stuff, but if there's already a
plugin that does that, why not just have it run first, and
append our stuff on the end?

> It's interesting to note that the executeHandler chain
> can't modify the url.  I don't know if we want to have
> a transformation process in here too.  So then functions
> can modify the url they get passed based on whatever it
> is that they do.

I'ld like it, but more in a geeky sort of way than in a
I-can-think-of-a-use-for-it sort of way.  At best it would
be like a poor-man's redirect.

The executeHandler chain can change the flavour, can't they?

> Going to what Wari was saying, I really think that the
> mechanism for taking an entrylist, parsing/formatting it,
> and wrapping it in head/foot templates should be a mechanism
> that's available to all url handlers
> 
> It would probably take an entry list and a py dict.  We might 
> even have it now, but I think it's in pyblosxom.py.

Could we make it a well-defined plugin with a method that other
bits of code could use?

> to do the actual work based on querystring attributes.

And some other pieces of data, like REQUEST_METHOD.

>  1. break out the page generation code into a tools function
[snip...]
>  4. build a function for handling all the urls we handle now
>     that generate entry lists and generate a page

Wouldn't this just call the tools function?

> Any other thoughts/issues/concerns?

Sounds okay to me...
And now the next reply.

> Just for the record, I don't mean to imply that this conversation
> is stupid in any way.  The more use cases that we can come up
> with, the more confident we'll be that the new mechanisms handle
> it and future ideas.  So it's all good.

Yeah, I figured that.

> One possibility is that I could create a will branch or something
> like that and experiment with things there.  Then you guys can
> adopt the pieces you're interested in adopting and we can discuss
> the pieces that need discussing without it affecting the repository.

Sounds like a good idea, but branches kind of scare me.  I never
know which branch I should work off of, and it doubles the amount
of stuff I have to look through.  I think I'ld come down on the
get it working in a simple form on your local box, and then check
it in to the main branch, and we can discuss it when we all see it
running.

If it's something that we really think we're not going to use, then
why spend time on it.  If it's something that we will want to merge
in to the base, then why not stick it there to begin with?

> I should warn you, though, that I've never played with branches in
> CVS.  But I have in other version control systems, so I can't
> imagine that it's that hard.  CVS has branches right?

Yup.

Later,
Blake.