Hi Jean-Michel,
> Sorry i do not participate to the IRC chats.
np, it is actually a mixed blessing to have most discussions
(only) on the irc channel. On one hand feedback/speed process of
opinion-gathering is very fast, on the other hand we lose a lot
of valuable input. :-/
> Any insight on the "options system provided by the backend itself"
> thingy that dev checked in early this week?
> What is the "plan" about this one?
the idea is that each backend should provide information about
its accepted options, so that a configuration UI can provide
the necessary input fields to the user, without having to know
about the specific backend details in advance.
The options are dictionaries, stored in a list, so the backend
has some impact on their presentation order.
So far we've selected these these key-value pairs for the dicts:
option: name of that option
type: string,int or bool
default: default value, should be of type type (optional)
enum: a tuple/list of possible values (optional)
range: a dict with min and max elements (optional)
help: a (short) text describing this option (optional)
level: the level of this option - normal or advance (optional)
group: fieldset title, for grouped options (optional) ???
These lists can be easily accessed by either iterating over
all available backends in the dict-like Plugins class or
directly using the backend identifier as the key.
>>> from coherence.base import Plugins
>>> p = Plugins()
>>> p['FSStore'].options
[{'default': 'my media', 'type': 'string', 'option': 'name'}, ...]
Or as a second option via the REST/JSON interface which I'm currently
working on. That especially will allow a very easy access from any
kind of JavaScript frontend.
> And, off-topic, how did Sprint 2 go?
great, already-overdue dedicated email will follow soon.
Regards,
Frank
_______________________________________________
coherence-dev mailing list
[hidden email]
http://lists.beebits.net/cgi-bin/mailman/listinfo/coherence-dev
