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

[will <wi...@bl...>]

On Wed, 5 Feb 2003, Blake Winton wrote:
> 
> 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?

Mmm...  I'm thinking that the url handling functions are mostly there to
assemble things--I don't think they should be doing lots of stuff on their
own.  They would examine the url (and it's interesting that you brought up
REQUEST_METHOD because that's not part of the url and I hadn't factored
that in--so I may have to backpedal on some of my thoughts at some point)
and handle it according to what they do where "handle" would mostly 
involve calling functions in tools.py to do most of the work.  The thing 
that the url handler does is figures out what the data to work on would 
be.  Is this a url for looking at a specific category of entries?  Is this 
a url for looking at a date of entries?  Is this url for posting a 
comment?  Is this a url for viewing plugin information? ...

[As a side point, it's unclear as to whether we should take our existing
functionality and split it into a series of handlers (one for categories,
one for entries, and one for dates) or not.  I vote yes but we can do that
refactoring later.]

So then I'd take the existing handling of urls and dump it into a function 
that would:

 1. examine the url
 2. figure out which entries need to be displayed
 3. call the tools.py function that takes an entrylist and a py dict
    and generates story portion of the page
 4. call the tools.py function to wrap the story portion of the page
    in a head/foot set


Steps 3 and 4 involve functions that don't exist yet in tools.py, but the 
code is in pyblosxom.py.


Wari and I were talking about how to handle comments a while back and he's 
thinking it's essentially another entrylist.  So then comment viewing (and 
possibly posting) would be entry oriented and could use the same 
mechanisms described above.

I'm not seeing these url handling functions as being all that long.  I 
would think it'd take a few lines to figure out whether it's going to 
handle the url or not, then maybe 10 to 20 lines to call all the functions 
in tools.py to actually generate the page.

It's interesting to note that we could adjust your plugin-info module so 
that it just generates its own story portion and then calls the tools.py 
function to wrap it into a head/foot block.

Incidentally, that might require some adjustments to some of the plugins 
we currently have.  I know the pycalendar one looks at entrylist data for 
initialization.

 
> > 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?

If the flavour is part of the url, then yes, it could.

Ok.  If we implement it as a transform, then the rules change a bit.  A 
url handling function could:

 1. not do anything and just return the unadjusted url
 2. adjust the url and return the adjusted url
 3. handle the url and return some value that indicates that the
    url has been handled

In executeTransform, there's no "stop processing" kind of thing--so we 
pass the data through all of the registered functions.  We would need 
something to indicate to the function that the url has been handled, so if 
it's going to do page generation kind of handling, it shouldn't bother.

 
> > 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?

Why should it be a plugin?  I was thinking these sorts of general
functions would be in tools.py and available to everyone.  The nature of
plugins is that they may or may not be installed and therefore may or may
not be available.

 
> > to do the actual work based on querystring attributes.
> 
> And some other pieces of data, like REQUEST_METHOD.

Hmmm...  I'm going to have to toss this around.  I'm wondering if we
should build a HTTP request object of some sort and pass that around
instead.  That changes this whole discussion from a "url handler" to a
"http request handler".  Mmm...  That actually makes more sense to do.

Though that might be overkill--those variables are already available in 
the os.environ dict which everything can see.

 
> >  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?

Yes.  But the function doesn't exist yet.  I think it's part of the code 
in pyblosxom.py.


I think what I'll do is whip this together and send a diff.  Then people 
can see the sorts of things I've changed without me having to commit to 
the repository.

If it looks decent, then we can commit it and augment it there.  If it 
looks like a terrible approach, then we can try another one.

I'm actually going to California tomorrow for a few days, so I may wait 
until Monday to do changes.  Then I won't potentially do something that 
causes issues and then skip town causing everyone to be irritated for a 
few days.

It also gives us more time to toss more ideas around.

Also, I can write things down into a specification, if you guys like.  It 
might help as it'd be a coherent document instead of a series of replies 
spread out across several email threads.

/will