Webclient: pick up renderers automatically

[jri]

The plugin developer should not required to load the plugin's renderers manually.
The framework could pick them up automatically by the means of naming conventions.

[Jörg Richter]

Core: include renderer info in PluginInfo? (#284).

Get a list of installed plugins:

localhost:8080/core/plugin

Client-side processing is pending.

See ticket 284.

• Changeset: 5b245bdd6f8ef4f63db1c864cc5aa321b2ad208f
• URL: ​https://github.com/jri/deepamehta/commit/5b245bdd6f8ef4f63db1c864cc5aa321b2ad208f

[Jörg Richter]

Core: pick up renderers automatically (#284).

A plugin's renderers are picked up automatically:

• page renderers
• simple renderers
• multi renderers

So, the plugin developer must no longer load hers renderers manually by calling these methods:

• dm4c.load_page_renderer(...)
• dm4c.load_simple_renderer(...)
• dm4c.load_multi_renderer(...)

These methods are dropped.

Instead the plugin developer must respect the fixed file structure (as mentioned previously):

script/

renderers/

page_renderers/
simple_renderers/
multi_renderers/
canvas_renderers/

IMPORTANT: plugin developers must adapt the plugins which provide renderers accordingly.

Picking up canvas renderers is pending.

See ticket 284.

• Changeset: 19aca819a50de7314dc38c937f433b83a1cd4a94
• URL: ​https://github.com/jri/deepamehta/commit/19aca819a50de7314dc38c937f433b83a1cd4a94

[dgf]

nice idea, just a little to much renderers renderers renderer

$ head -1 renderers/simple_renderers/title_renderer.js
dm4c.add_simple_renderer("dm4.webclient.title_renderer", {

In my opinion a name like renderers/simple/title.js looks adequate

[jri]

Yes, it's the same wording issue you commented in conjunction with the listeners a while ago (ticket:261#comment:8). I like the brevity of your style but don't feel good with the ontological and linguistic clash involved here.

When I have a "coffee" folder with "milk coffee" in it, I would not name the latter just "milk". I guess you would still consider it properly named because of the existence of the coffee context. But I wouldn't like it because "milk coffee" is *not* "milk".

This determinator-determinant wording pervades the entire DM codebase. There is e.g. a model package which contains a TopicModel class (almost all classes in the model package ends with Model). According to your scheme just Topic would be a proper name for it. But it's *not* a Topic it is a TopicModel. (As you know there is also a Topic interface and its meaning is different from TopicModel).

Regarding the listeners the very same rule is applied. Because a class-instance relationship represents an is-a relationship it is consequent to name a class according to a substantive. Thus, you can always say/know: an instance of X *is* an X. I feel that wording supports the API understanding. I don't want say "obj1 is a PluginServiceGone". No, it is a PluginServiceGoneListener. That's the very naming scheme also used e.g. in the java.awt.event package. (BTW: should we rename our listeners package to event?)

As you said before, it's a matter of taste.
Anyway, as a compromise I could make friends with simple, multi, page, canvas folders (but I would stick to the title_renderer wording).

[Jörg Richter]

Core: include renderer info in PluginInfo? (#284).

Get a list of installed plugins:

localhost:8080/core/plugin

Client-side processing is pending.

See ticket 284.

• Changeset: 5b245bdd6f8ef4f63db1c864cc5aa321b2ad208f
• URL: ​https://github.com/jri/deepamehta/commit/5b245bdd6f8ef4f63db1c864cc5aa321b2ad208f

[Jörg Richter]

Core: pick up renderers automatically (#284).

A plugin's renderers are picked up automatically:

• page renderers
• simple renderers
• multi renderers

So, the plugin developer must no longer load hers renderers manually by calling these methods:

• dm4c.load_page_renderer(...)
• dm4c.load_simple_renderer(...)
• dm4c.load_multi_renderer(...)

These methods are dropped.

Instead the plugin developer must respect the fixed file structure (as mentioned previously):

script/

renderers/

page_renderers/
simple_renderers/
multi_renderers/
canvas_renderers/

IMPORTANT: plugin developers must adapt the plugins which provide renderers accordingly.

Picking up canvas renderers is pending.

See ticket 284.

• Changeset: 19aca819a50de7314dc38c937f433b83a1cd4a94
• URL: ​https://github.com/jri/deepamehta/commit/19aca819a50de7314dc38c937f433b83a1cd4a94