[okfn-help] CKAN/Microfacts questions
rufus.pollock at okfn.org
Thu Feb 14 21:21:02 GMT 2008
John Bywater wrote:
> Hi Rufus,
> I've basically finished CKAN things. Three questions:
Sorry for the delay in reply but it took me longer to get things working
than I imagined (on the new machine etc). Part of this was my own fault
in that I installed Genshi 0.4 and then had to work out why it wasn't
working. The good side of this is that a) I've removed the dependency on
markdown (markdown is in webhelpers) b) ckan now works with genshi 0.4
c) I have found one genuine bug.
Hope I haven't broken anything and all the gory details in the log messages:
As detailed in this 2nd message there is one genuine bug: package create
action returns 201 but also returns content which is apparently illegal
for http spec (using my version of paste fixture i get an assertion error).
> Firstly, have you seen/tried the package tag autocompletion function?
> It's very like the full-screen version of delicious's edit page (ie you
> get a horizontal list that starts hard-left). Only thing is that editing
> mid-list doesn't autocomplete, but I haven't tried to address that.
Looks really nice. Great stuff :)
> Secondly, I fixed up the package controller error handling and HTTP
> response status codes. The REST thing also just clicked, so I wrote
> about it here, here, and here:
> Following that general conception and CKAN-specific analysis, I wrote
> this piece of documentation:
Again this all looks really good.
> Basically, I wanted to ask you whether you understand Routes/Pylons/CKAN
> enough to match the 'api/rest' path and set a request param (or context
> attribute?) called 'format' to 'json'. I didn't look into this cos I
> thought you might just know. If we can just map the URLs I wrote in that
> document to the same controllers but with the request param set that
> would be very nice.
There are two obvious ways to do this:
a) Mess around with routes so that it does this. This would mean messing
around with the setup of config/routing.py
b) create a new controller controllers/api.py with a method called rest
whose job is to strip off the rest of the url and then redispatch based
on that adding format=json to the request
However personally I think we should not bother with this and just have
an extra query parameter named 'format' (which perhaps we can just
extract out in the BaseController). This then determines what is
returned out (html/json at this point defaulting to html). If this
seems a bit repetitive in that each controller has to extract the
parameter and then act on it we could move to the decorator model where
every action returns a dict which is either converted to json or to
> BTW I think it makes a lot of sense to distinguish the locations of your
> web browser interface and your machine client interfaces. This is how
> many of the more famous web services (esp. flickr.com) have been done.
I see that but is it worth the added complexity at this point in time?
> Thirdly, what's the state of microfacts? Should I be able to do pretty
> much the same as I can with CKAN? I notice there is no microfacts-admin,
> so am I correct to infer there no special test data?
No, not at present. Everything is setup in the (one current) test
itself. There is some json data in demo/ but that is not yet used by the
> Also, might I ask you to check that you have no uncommitted changes
> (that I need) on your machines?
No. Everything committed.
> Other than that, what did you think about AJAX-style aspects to
> microfacts thread view? Shall we start without any for now? (Is there
> already a thread view?? I didn't get it running yet....)
There is no WUI at all at present (i.e. no controllers, no templates etc
etc). Just a bare-bones model. First step is probably to copy and paste
ckan css (and js if necessary) and start on thread/factlet views.
More information about the okfn-help