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

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

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.

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.

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?

Any thoughts on that?

/will


On Wed, 5 Feb 2003, will wrote:

> On Wed, 5 Feb 2003, Blake Winton wrote:
> > 
> > > I think when a function handles the url, it's building the whole page
> > > and that's the end of our run.  I can't think of a use case where we'd
> > > want two different functions to handle the url and do different
> > > things.
> > 
> > No?  How about moving logstats.py to the url handler as well? It would
> > log the url and referrer, and then pass it off to the actual page
> > handler (which would then call it to stuff the referrer information into
> > the py dict.
> 
> That's not a handler.  That would be event notification.  I think the
> issue here is less that what I'm planning on doing is problematic and 
> doesn't solve our existing use cases and more that we're not using the 
> same vocabulary the same way.
> 
> Maybe handler is the wrong word, but if you look in api.py, the 
> documentation for executeHandler is:
> 
>         Each function tries to see if it can handle the data being
>         passed in as input.  If it can handle the data, then it does
>         so and returns api.HANDLED.  We continue through the list of
>         registered functions until we hit the end (none of them
>         handled it) or one of the functions has handled the data
>         and we don't need to proceed further.
> 
> 
> 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?
> 
> 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.
> 
> 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 so 
> that the ones that want to build a page like we have now (url handling for 
> dates, specific entries, categories, ...) can do so without too many 
> issues and ones that have almost nothing to do with our existing layout 
> (head, story/story/story/story, foot) can do as they like (this could be a 
> way to implement a MoinMoin plugin).
> 
> 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.
> 
> I don't think that the querystring should get parsed by separate url 
> handlers.  Though maybe we should do that and it can modify the py dict 
> (assuming we make it global).  I think that's more trouble than it's worth 
> though.  I think we're better off letting url handlers work at a higher 
> scope and then they can use functions in tools.py (some of which we'll 
> have to extract from pyblosxom.py) to do the actual work based on 
> querystring attributes.
> 
> Anyhow, I don't see any showstopper issues yet.  What I'm planning on
> doing handles everything that's been mentioned so far.  The basic 
> implementation steps would be:
> 
>  1. break out the page generation code into a tools function
>  2. create a url_handler callback chain in api.py
>  3. change the run method so that it calls the url handler
>  4. build a function for handling all the urls we handle now
>     that generate entry lists and generate a page
>  5. add a function for generating /plugin-info
> 
> 
> Step 5 will be really primitive at the moment and only really exists so
> that we can have two different url handling functions in the callback
> chain.  Blake can fill in the rest with the code he's written.
> 
> Any other thoughts/issues/concerns?
> 
> /will
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
> 

-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.