On Saturday 30 November 2002 17:43, Matt Sergeant wrote: > On Saturday, Nov 30, 2002, at 13:27 Europe/London, Kjetil Kjernsmo > > > - Provider: Riccardo's HOWTO was nice, but leaves me with a couple > > of questions: When is writing a custom Provider going to be the > > Right Tool for the Job[tm], as opposed to just writing a taglib to > > retrieve the contents? Where does the Provider fit in the > > pipelines? Must it always return XML? > > My preferred way of thinking of it is to write a provider when the > URL represents the resource you're trying to get at. e.g. if the URL > points to a POD document, then the provider is the right thing. If > the URL points to a particular entry in your database, then it might > be the right thing
Yeah, that is pretty exactly what I'm doing. Eventually, my site will consist of a number of database-stored static articles, and a commentable blog, as well as a few minor things, such as forms to send orders and stuff like that. This means that the static articles and indices of them should probably be written as providers, whereas the blog and the rest should be provided with XSP. >(distinguish between the database containing the > resource and the the database containing a bunch of data you want to > search on). Basically, you need to follow the well practiced concept > of what goes at the end of a URL. I'd like my URLs for the static articles to be like this http://www.skepsis.no/articles/category/identifier Sensible, human-understandable URIs that are non-technology-dependent, without the kludge that query-parameters introduce are important, I feel (this in the spirit of http://www.w3.org/Provider/Style/URI ). Still not clear, however, can I process the output from the Provider with e.g. SAXMachines? > On the other hand, there's no hard and fast rule. Technically you can > make it look like a URL with XSP (e.g. the AxKit wiki uses XSP, but > it's all just plain URLs, no querystrings), so do that if you want to > and it makes sense. The reason I chose XSP for the wiki is that it's > just plain easier to develop for. You can make changes and have them > take effect without having to restart your server (well, you may have > to restart, or use Apache::Reload with taglib modules). Plus I find > writing taglibs easier than writing providers. Yeah... I'm in a hurry, so I should do things quickly, but OTOH, I'd like to do things well for a change.... :-) > > AxKit punts all of that stuff to Apache. Thats why I think Cocoon > doing all that stuff is a huge mistake - it merely adds confusing > layers onto an already capable system. You are probably right in that. However, it is a bit harder to get an overview of the capabilities of the combination of Apache and Axkit, when the docs are scattered around. A centralized collection of docs pointing out how to do certain common things would help many (I mean, many use PHP for nothing but aggregating content...), even if all they say are "this you'll do with Apache". > > - Is there some docs on the Auth taglib besides the POD and > > http://xml.sergeant.org/axkit/xsp/showsource.xsp?auth.xsp > > No, there isn't. I guess partly because the concepts themselves are > pretty straightforward - if you can write a perl module you can write > a taglib. Hehe, the problem is that what I'm doing should be really simple, so I don't want the whole chainsaw... :-) I just want to log the user in, check him against the user database and give him a single cookie that don't expire. Then use that cookie to check whether the user is authorized to access and/or edit some stuff. I find the Apache::AuthCookie POD pretty clear, and I guess that if I write a Provider, I could use that directly, but I think the other PODs was not equally clear on how to achieve just that, they were more abstract. That's why I asked. > However if you want, feel free to add docs to the wiki :-) Yup, I try to do that whenever I have gained enough understanding to have anything to contribute. That nobody has screamed over my DBI-example but rather added to it, I take as a good sign! :-) Best, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Homepage: http://www.kjetil.kjernsmo.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
