more question regarding my plugin development
Torsten Ziegler
my plugin is almost ready now,
it implements a connection to a mysql database
and loads topics and relations from the database
into a dm3 server including updating the topics
from the mysql server to dm3 (only one way)
I think next week it will be ready to show around ;-)
I have got some more questions,
i hope they are relevant for other plugin developers
so I am posting them here on the list.
1. uris: (topic_type_uri, datafield_uri etc)
what is best practice for creating new uris?
Right now all the plugins you provided use uris that start like:
de/deepamehta/core/topictype
de/deepamehta/core/property
How should plugin developers name their uris
to not create name clashes ?
2. using uris in datafields:
I get errors if I redefine properties in a datafield
but still use the same uri: e.g. for a read-only
topic i used the standard title datafield with the uri:
de/deepamehta/core/property/Title
and set the property "editable: false" but this throws me
some errors.
So whenever I use different properties I have to
use a new uri?
3. Is it possible that the time plugin creates its two
datafields even if the topictype as these fields already?
I am copying an existent topic type and change the uri
and store it in the server, afterwards I get errors like:
Graph inconsistency for topic type ... there are 9 nodes in data field
sequence but 6 meta property nodes
I still have to debug what really is going on there (as there are 3 more
data fields as expected).
4. adding properties to relations
Is there already a mechanism to do this ?
(I found the x,y, visibility setting but am still unsure how this works in
the topicmap context)
There are two things I would like to do:
a) add a text to either the middle ore both sides of a (directed) relation
possibly this text should be possible to be revealed only on single
topicmaps
b) add a relation to a relation, so the relation itself gets related to
another topic
The only way I see right now to do both things is to create topics that are
related to both endpoints of the relation with zero size icons and a custom
implementation that positions them on the canvas right on the relation.
I hope there is some nicer way to do this.
All questions are still regarding v0.4.3 as I cant get the v0.4.4 to work
and am happy to use the stable version.
Thanks,
Torsten
--
Torsten Ziegler
tor...@ziegi.de
Torsten Ziegler
The "js_renderer_class" of a datafield is global right now.
While I like partly this behaviour (I did overwrite the tinyMCE
with the much nicer aloha editor) this is also dangerous not
to break other plugins' renderers.
Maybe also a "best practice" for the renderer_class namespace
would be usefull.
Thanks again,
Malte Reißig
Now that sounds interesting! Cool!
It sounds somehow like you're actively implementing some kind of deepamehta3-core functionality (data sources) but just customized for your relational database model. How you described it to me, this works for your database with the deepametha3-client like it worked for everyone with deepaMehta2 already, you are able to browse your values stored in a mysql-database-table after wrapping their custom structures in a deepamehta-client, right!? Have you planned it that way so that we can re-use your plugin!? I am just curious, it sounds great! I am very interested in your work. For sure i can wait a week longer for more infos, there is certainly no hurry. Below i wrote some infos about my experience with putting properties to relations, maybe its helpful for you.
On Mon, 2010-11-01 at 11:25 +0100, Malte Reißig wrote:
I don't know when the concept of a DataSource, in which i am also interested, will be available for plugin developers. I just saw that Jri started to develop the deepamehta3-accesscontrol plugin which will i would estimate into the blue, approximately up to 3months, but i haven't asked him yet about his time plan.
Maybe you, dear jri, could just briefly introduce us to your next steps and/or provide some information on necessities for a developing the idea of DataSources a bit further?
Here are some infos about properties on relation's i used it for relating a "Note" to a "File" with a property called something like "Ellapsed Time". I think that currently those properties cannot be indexed by the lucene search engine coupled with neo4j but with this, i am not completely sure. But as far as i know:
You can add any kind of property (without the need to define it in before usage and in the same format as for topic-properties) through calling through the REST-API any type of instance of any kind of association type:
On Tue, 2011-02-22 at 18:23 +0100, Torsten Ziegler wrote:
4. adding properties to relations
Is there already a mechanism to do this ?
(I found the x,y, visibility setting but am still unsure how this works in
the topicmap context)
To create a complete new relation send a POST to the "/core/relation"-Resource
To update or create new properties just send a PUT with the following content the to "/core/relation/<relationId>"-Resource
json-body in a java string: "{\"x\": 2, \"y\": 3}"
Hope this helps. Nice greetings!
Malte
-- -- --- Maintain your head and share it --- -- - http://blog.deepamehta.de - skype: einseinsnull - jabber: mre at newthinking.de - mail: mre at deepamehta.de - fax: 01803-663388-72229 - tel: 030-42800182 |
Jörg Richter
On Feb 22, 2011, at 18:23, Torsten Ziegler wrote:
> my plugin is almost ready now,
> it implements a connection to a mysql database
> and loads topics and relations from the database
> into a dm3 server including updating the topics
> from the mysql server to dm3 (only one way)
> I think next week it will be ready to show around ;-)
That's great!
I'm looking forward to see your plugin in action.
Let me start to respond to your questions in this first posting.
> I have got some more questions,
> i hope they are relevant for other plugin developers
> so I am posting them here on the list.
>
> 1. uris: (topic_type_uri, datafield_uri etc)
> what is best practice for creating new uris?
> Right now all the plugins you provided use uris that start like:
> de/deepamehta/core/topictype
> de/deepamehta/core/property
> How should plugin developers name their uris
> to not create name clashes ?
You could include your domain and a plugin shortname in the URIs, e.g.
de/ziegi/myplugin/topictype/...
de/ziegi/myplugin/property/...
The de/deepamehta/ Namespace is designated for plugins that are part of the DM standard distribution.
In fact, there is no strict format behind these URIs. They act as globally unique identifiers to prevent name clashes (as you said) and to transport semantics to the human. Internally DM identifies entities (like properties and topictypes) by these URIs.
> 2. using uris in datafields:
> I get errors if I redefine properties in a datafield
> but still use the same uri: e.g. for a read-only
> topic i used the standard title datafield with the uri:
> de/deepamehta/core/property/Title
> and set the property "editable: false" but this throws me
> some errors.
> So whenever I use different properties I have to
> use a new uri?
Unfortunately, for the moment: Yes!
Conceptually DM encourages sharing properties between topictypes, also for sake of semantics. If one plugin defines e.g. a property "Geo Coordinate" another plugins who needs that particular semantics can re-use this property.
But for the moment DM unfortunately doesn't separate the semantics (URI) from application-specific settings (e.g. "editable") properly. So, effectively you can only share properties when all its settings (like "editable") match the original definition. If you would change a setting it would affect all the topictypes the property is shared to. Thats the reason for the warnings you encounter.
In the future the DM datamodel will be revised in that respect.
> 3. Is it possible that the time plugin creates its two
> datafields even if the topictype as these fields already?
> I am copying an existent topic type and change the uri
> and store it in the server, afterwards I get errors like:
> Graph inconsistency for topic type ... there are 9 nodes in data field sequence but 6 meta property nodes
> I still have to debug what really is going on there (as there are 3 more data fields as expected).
Ooh, thats a tricky one.
There is a inconsistency in a type-definition stored in the DB. Probably this is an error in DM that occurs when you delete a shared property. There is an issue filed in this regard:
https://github.com/jri/deepamehta3/issues#issue/5
Try to reset the DB (exit Felix and then delete the deepamehta-db folder) and see if the error still occurs.
The time plugin itself is probably not the origin of the problem. It adds its 2 timestamp fields to each topictype exactly once. That is ensured by DM's migration facility. But in conjunction with shared properties (as described above), the problem might occur when you delete a timestamp field as it is shared between all the topictypes.
Consider to deactivate the time-plugin if you don't need the timestamp fields.
Regarding migrations in general: All your model-definitions and model-changes should be put in migrations to ensure there are clearly defined transitions when updating the DB model.
> 4. adding properties to relations
> Is there already a mechanism to do this ?
> (I found the x,y, visibility setting but am still unsure how this works in
> the topicmap context)
You can set relation properties by the DM core service's setRelationProperties call. Just like with topics.
In your (Java) plugin you access the DM core service via the dms object ("DeepaMehta service").
In contrast to topic properties with relations no model is enforced. In fact, for the time being there is no such thing like "association type" exposed to the DM core service. That is, you are free to set any properties you like to any relation. The property format of association properties is the same as with topic properties.
For the time being relation properties are not indexed and you can't search for them directly. However, by the means of the providePropertiesHook(Relation relation) hook you can include the relation properties in the response of core service calls.
If you're outside the Java world you can set relation properties via the REST interface, be PUTing properties at the /core/relation resource.
> There are two things I would like to do:
> a) add a text to either the middle ore both sides of a (directed) relation
> possibly this text should be possible to be revealed only on single topicmaps
> b) add a relation to a relation, so the relation itself gets related to another topic
>
> The only way I see right now to do both things is to create topics that are
> related to both endpoints of the relation with zero size icons and a custom
> implementation that positions them on the canvas right on the relation.
> I hope there is some nicer way to do this.
>
> All questions are still regarding v0.4.3 as I cant get the v0.4.4 to work
> and am happy to use the stable version.
I will respond to that and to your other question in my next posting.
Cheers,
Jörg