[ckan-dev] Search functions in CKAN; custom schema.

[David Raznick]

On Wed, May 30, 2012 at 7:16 PM, Mark Wainwright
<mark.wainwright at okfn.org> wrote:
> I'd like to add some gentle support to Friedrich here. I was
> interested in the possibilities of configuring metadata, but gave up
> the idea when I discovered what it entailed.

Please do not give up it is not all *that* hard and it will be good to
get some feedback to help make the process simpler.


When someone says a schema will be good enough for their needs my mind
always races with the complexity of it and I have played with many
form libraries before.

So what validation do you want for those fields? how are we going to
allow people to write code for this if its non standard?
How big do you want the input boxes?
What type are they?
Where do they go? How do you define order?
Do you want a dropdown box instead of a input box?
How should we describe what values go in the dropdown box.?
What should the default value be?
Are they the same default value in all circumstances?
Do you allow single or multiple values for that field?
Do you want the name stored in the database to be different from the
textual name.
Do you want a description to say what goes in that field.  How do you
want that to look? Does a long description look a bit funny in this
situation?
...

Maybe there is a finite list of things to cater for here, but it never
completely feels like it and most people will look at the resulting
json schema and think they could do a better job writing the html
themselves.  An RDF schema may be possible (if not still inaccessible
to most) and covers most points but it does no really cater for the
look an feel aspects and if even one field looks slightly wonky the
whole thing is a waste of effort.

The other worry is that once you tried the schema way and it did not
fulfill your needs then you would have to back to the manual way and
you would loose your work, to mix an match once you have overridden
the form would be very messy.

I am not saying its not doable but it would be good make sure that we
are not missing anything if we go ahead.    Once everything is more
settled with the templating we may be worth giving it a shot.

There are other ways to do this as well...

Personally I prefer an extension point per extra field (vocabulary) or
whatever giving a position number, a field type, a possible validation
function, a fieldset name and an HTML fragment which would be much
simpler then we have currently got, but giving almost all the
flexibility.  This way you could also place it anywhere in the current
form or even override existing stuff.

@ Friedrich.

Currently, very sadly, as mentioned in the other thread the resource
form itself lies outside this customization as it is implemented
currently wholly in JavaScript, so your case would be even more
involved to do, even though possible.

Anyway I have thought about this a lot before.  First we needed make
sure everything is possible, then we need to work on making the simple
things simple.

David