[Grok-dev] Problem with Annotations
paulalexwilson at gmail.com
Wed Sep 23 09:57:26 EDT 2009
2009/9/23 Souheil CHELFOUH <trollfot at gmail.com>:
> Paul, first of all, i'm glad to learn that you are building a
> framework/CMS for Grok
> I didn't hear about it and I'm also working on a similar project : Dolmen
It's a very domain-specific project and certainly not a general
purpose affair. It is more towards a framework that allows you to plug
in states as part of a statemachine (thanks martian!!) and have them
executed by some a runtime. It's very early but I'm having lots of fun
> About your problem, I'd rather use a namespace traverser as they are
> elegant and readable:
> But, your metadata issue sounds weird to me
> Can you explain in more details ?
Imagine a statemachine system that is constructed through the web, and
then executed later using a statemachine runtime. The states are the
"content" aspect, since uses can edit, version and manipulated these
according to permissions. The states are wired as plugins, stored in
the ZODB and serialized according to their interface schema into JSON.
The web client can view these states, but might want to additionally
store X,Y coordinates and other such metadata along with it for its
own purposes, whereas the runtime might want to track how many times
the state has been executed, and how many exceptions it has thrown (or
whatever) for statistics purposes. Both access the information
The states (and transitions) are in a nested hierarchy of containment
(which is a state diagram), which lends itself naturally to models and
containers. So the web client get a JSON representation of a state
something like this:
I've got this working nicely as it stands. But how to access meta
data? I don't want metadata to be an intrinsic part of the
statemachine code, rather it should be added through a series of
plugins. So when a client requests:
I want "positional" to map _somehow_ to IPositionalAnnotation, such
that I can adapt 'state1' to it, and then use it to serialize the
object and return it to the agent. Like wise with PUT. The important
thing here is that the rest code doesn't have hard coded knowledge of
what annotations it is to support, and should instead retrieve it
dynamically through plugged-in facilities.
There are two problems I can see with this;
1) How do I prevent traversal thinking that state1 is actually a
diagram, and that positional is a state in that diagram.
2) How do I get the interface from the "positional" string?
Actually this has just given me an idea regarding 2) ...does Grok
support named annotations? Looking at:
...it looks like it does.
Perhaps I could supply a custom traverser that does:
availables_ann = IAnnotations(self.context)
ann_class = availables_ann[name]
iface = list(providedBy(ann_class).flattened())
And then have the web client and runtime implement their own named
annotations.... I'll give it a try, see how it works.
More information about the Grok-dev