[deepamehta-devel] a blog post on how to create a plugin and a question

[Jörg Richter]

On Dec 27, 2013, at 20:51, carolina wrote:

> I've written a post explaining the steps of how to create a very simple plugin in DM
> 
> http://abriraqui.net/2013/12/27/creating-a-plugin-in-deepamehta-hackership/
> 
> [...]
> pd: any feedback on the post is also very welcome :))


Hi Carolina,

thank you very much for the blog post!
I just posted a comment there but line wrapping is kind of odd and XML elements (<name>, <groupId>, ...) are omitted.
So I post my comment here as well.

Cheers,
Jörg

-------------------

Thank you for this great article! It provides a good help in making DM approachable for new developers! I appreciate the clear language and structure as well as the handcrafted illustrations.

While our personal "hackership", which I enjoyed very much, I was not always as clear/complete as I could have been. So here I like to fill some of my gaps resp., relating to your article, suggest some improvements:

- Before the introducing quote you could say that DeepaMehta is both, a *Webclient*, and an application development platform. (Most of the quote relates to the Webclient while the remainder of the article refers to the development platform).

- The plugin directory name must not necessarily match the Maven artifact ID. You're free to choose any name. Anyway, it's not a bad idea to let these names match.

- A migration does not only define the database schema. In general a migration transforms the DB to ensure its structure and content is compatible with your code.

- For better readability the pom.xml contents could be indented.

- I would not say the project <name> is a description of the project (which would be more verbose) but just, exactly as you said, "the human readable name of the plugin".

- The <groupId> must not actually be a valid URL, but a globally unique name under which you collect the project's artifacts. To fulfill the "globally unique" requirement it is best practice to begin the name with a reversed domain name (as you've described). You could use e.g. "net.abriraqui.cgc-calendar" as the group ID.

- Generally in Maven the <artifactId> is the name of the generated .jar file (the Java binary). Within the group this name must be unique. Your choice ("cgc-calendar") is a good one. (So, with the group ID suggested above "cgc-calendar" appears twice, which is fine. That's because your project consist of only 1 artifact, but in general there may be many). Remember: the artifact ID must not necessarily match the plugin's directory name.
http://maven.apache.org/guides/mini/guide-naming-conventions.html

- I would not say relationships in DeepaMehta are *hypergraph* relationships. In a hypergraph a relationship can have more than 2 ends. In DM it has always 2. Although one thing is special with the DM data model: at a relationship's end there can be both: a node (as usual), or a relationship (!). Anyway, if this structure is equivalent to a hypergraph is an ongoing discussion (Jürgen says yes, I say no :-)

- It is a convention in DM to use underscores in URIs instead of dashes. So it should be e.g. "cgc.calendar.start_date". (While our hackership I told differently.)

- A type's "value" property is its (human readable) *name*, not actually a "description" (which would possibly more verbose).

- I would talk about "Event", "Start Date", and "End Date" as *Topic Types* (instead of Topics). The distinction is like in OO: a type is like a *class* while a topic is like an *instance* of a class. However, it is technically correct to talk of DM Types as Topics, because in DM Type is derived from Topic. But the more specific term might make things more clear for the reader (especially if she is familiar with OO).

- The plugin.properties file should contain a 2nd line:
	importModels=de.deepamehta.webclient
This declares your plugin makes use of the DM Webclient data model (namely its type dm4.webclient.view_config). DM then takes care the Webclient is installed *before* the Calendar plugin. However, this is only of importance if Calendar is installed along with DM (e.g. when you publish a custom DM distro). While our hackership I omitted that setting.

- In the latter code examples indentation is a bit out of place.

- At the article end: you should say that this configuration goes to DM's "global" pom.xml. This is found at the top-level of its home directory.

Hmh, I feel little like a rigid schoolmaster now ;-)
Your article is great!