Ticket #282 (closed Enhancement: fixed)
Namespaces for page renderers and field renderers
Reported by: | jri | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 4.1 |
Component: | DeepaMehta Standard Distribution | Version: | 4.0.11 |
Keywords: | Cc: | dgf | |
Complexity: | 3 | Area: | Application Framework / API |
Module: | deepamehta-webclient |
Change History
comment:3 Changed 12 years ago by Jörg Richter
Core: namespace field renderers (#282).
IMPORTANT: plugin developers must adapt their field renderers.
Old code:
function NumberFieldRenderer(field_model) { this.field_model = field_model } NumberFieldRenderer.prototype.render_field = function(parent_element) { ... } NumberFieldRenderer.prototype.render_form_element = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.number_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: function(field_model, parent_element) { ... } })
No constructor is required anymore.
No prototype definition is required anymore.
Instead a field renderer is an object with 2 dedicated function properties ("render_field", "render_form_element").
To both functions the field model is passed. Inside the functions "this" is not required to reference the field model.
The field renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: field renderers are not instantiated anymore. Instead the renderer functions are called directly.
"Subclassing" a field renderer is still possible (although this term is not reasonable anymore).
Example: the TitleRenderer? "derives" the render_form_element() method from the TextFieldRenderer?:
Old code:
function TitleRenderer(field_model) { this.field_model = field_model } TitleRenderer.prototype = new TextFieldRenderer() TitleRenderer.prototype.render_field = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.title_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: dm4c.get_field_renderer("dm4.webclient.text_renderer").render_form_element })
New view config setting
"Field Renderer URI" (dm4.webclient.field_renderer_uri)
replaces
"JavaScript? Field Renderer Class" (dm4.webclient.js_field_renderer_class)
IMPORTANT: for the new view configs to take effect you must reset the DB.
Plugins of standard distro are adapted.
This branch is fully functional.
See ticket 282.
comment:4 Changed 12 years ago by Jörg Richter
- Status changed from accepted to closed
- Resolution set to fixed
Core: namespace page renderers (#282).
IMPORTANT: plugin developers must adapt their page renderers.
Old code:
function WebpageRenderer() { this.render_page = function(topic) { ... } this.render_form = function(topic) { ... } this.page_css = function() { return {overflow: "visible"} } }
New code:
dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { ... }, render_form: function(topic) { ... }, page_css: {overflow: "visible"} })
A page renderer is now an object (instead a function) with 3 dedicated properties:
- "render_page" (function), semantics like before
- "render_form" (function), semantics like before, optional (not needed for non-editable types)
- "page_css" (object), not a function anymore but an object, optional (default: {overflow: "auto"})
The page renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: page renderers are not instantiated anymore. Instead the renderer functions are called directly.
In order to make renderer-local context (functions and variables) available to the 2 render functions use the JavaScript? "module" pattern:
(function() { // define context var v1, v2 function f(...) { ... } dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { // context (v1, v2, f) is accessible here }, render_form: function(topic) { // context (v1, v2, f) is accessible here }, page_css: {...} }) })()
(If you prefer to define the context *below* the dm4c.add_page_renderer() call you can do so. It makes no difference.)
In order to make renderer-specific methods globally accessible add them to the renderer object. They can be accessed by
dm4c.get_page_renderer("dm4.webbrowser.webpage_renderer").my_method_here()
New view config setting
"Page Renderer URI" (dm4.webclient.page_renderer_uri)
replaces
"JavaScript? Page Renderer Class" (dm4.webclient.js_page_renderer_class)
4 methods are dropped from js_utils.js
instantiate()
new_object()
to_camel_case()
basename()
TopicRenderer?: inactive auto-complete code is dropped.
Plugins of standard distro are adapted.
This branch is fully functional.
IMPORTANT: for the new view configs to take effect you must reset the DB.
Close ticket 282.
comment:5 Changed 12 years ago by Jörg Richter
Core: namespace field renderers (#282).
IMPORTANT: plugin developers must adapt their field renderers.
Old code:
function NumberFieldRenderer(field_model) { this.field_model = field_model } NumberFieldRenderer.prototype.render_field = function(parent_element) { ... } NumberFieldRenderer.prototype.render_form_element = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.number_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: function(field_model, parent_element) { ... } })
No constructor is required anymore.
No prototype definition is required anymore.
Instead a field renderer is an object with 2 dedicated function properties ("render_field", "render_form_element").
To both functions the field model is passed. Inside the functions "this" is not required to reference the field model.
The field renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: field renderers are not instantiated anymore. Instead the renderer functions are called directly.
"Subclassing" a field renderer is still possible (although this term is not reasonable anymore).
Example: the TitleRenderer? "derives" the render_form_element() method from the TextFieldRenderer?:
Old code:
function TitleRenderer(field_model) { this.field_model = field_model } TitleRenderer.prototype = new TextFieldRenderer() TitleRenderer.prototype.render_field = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.title_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: dm4c.get_field_renderer("dm4.webclient.text_renderer").render_form_element })
New view config setting
"Field Renderer URI" (dm4.webclient.field_renderer_uri)
replaces
"JavaScript? Field Renderer Class" (dm4.webclient.js_field_renderer_class)
IMPORTANT: for the new view configs to take effect you must reset the DB.
Plugins of standard distro are adapted.
This branch is fully functional.
See ticket 282.
comment:6 Changed 12 years ago by Jörg Richter
Core: namespace page renderers (#282).
IMPORTANT: plugin developers must adapt their page renderers.
Old code:
function WebpageRenderer() { this.render_page = function(topic) { ... } this.render_form = function(topic) { ... } this.page_css = function() { return {overflow: "visible"} } }
New code:
dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { ... }, render_form: function(topic) { ... }, page_css: {overflow: "visible"} })
A page renderer is now an object (instead a function) with 3 dedicated properties:
- "render_page" (function), semantics like before
- "render_form" (function), semantics like before, optional (not needed for non-editable types)
- "page_css" (object), not a function anymore but an object, optional (default: {overflow: "auto"})
The page renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: page renderers are not instantiated anymore. Instead the renderer functions are called directly.
In order to make renderer-local context (functions and variables) available to the 2 render functions use the JavaScript? "module" pattern:
(function() { // define context var v1, v2 function f(...) { ... } dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { // context (v1, v2, f) is accessible here }, render_form: function(topic) { // context (v1, v2, f) is accessible here }, page_css: {...} }) })()
(If you prefer to define the context *below* the dm4c.add_page_renderer() call you can do so. It makes no difference.)
In order to make renderer-specific methods globally accessible add them to the renderer object. They can be accessed by
dm4c.get_page_renderer("dm4.webbrowser.webpage_renderer").my_method_here()
New view config setting
"Page Renderer URI" (dm4.webclient.page_renderer_uri)
replaces
"JavaScript? Page Renderer Class" (dm4.webclient.js_page_renderer_class)
4 methods are dropped from js_utils.js
instantiate()
new_object()
to_camel_case()
basename()
TopicRenderer?: inactive auto-complete code is dropped.
Plugins of standard distro are adapted.
This branch is fully functional.
IMPORTANT: for the new view configs to take effect you must reset the DB.
Close ticket 282.
comment:7 Changed 12 years ago by Jörg Richter
Core: namespace field renderers (#282).
IMPORTANT: plugin developers must adapt their field renderers.
Old code:
function NumberFieldRenderer(field_model) { this.field_model = field_model } NumberFieldRenderer.prototype.render_field = function(parent_element) { ... } NumberFieldRenderer.prototype.render_form_element = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.number_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: function(field_model, parent_element) { ... } })
No constructor is required anymore.
No prototype definition is required anymore.
Instead a field renderer is an object with 2 dedicated function properties ("render_field", "render_form_element").
To both functions the field model is passed. Inside the functions "this" is not required to reference the field model.
The field renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: field renderers are not instantiated anymore. Instead the renderer functions are called directly.
"Subclassing" a field renderer is still possible (although this term is not reasonable anymore).
Example: the TitleRenderer? "derives" the render_form_element() method from the TextFieldRenderer?:
Old code:
function TitleRenderer(field_model) { this.field_model = field_model } TitleRenderer.prototype = new TextFieldRenderer() TitleRenderer.prototype.render_field = function(parent_element) { ... }
New code:
dm4c.add_field_renderer("dm4.webclient.title_renderer", { render_field: function(field_model, parent_element) { ... }, render_form_element: dm4c.get_field_renderer("dm4.webclient.text_renderer").render_form_element })
New view config setting
"Field Renderer URI" (dm4.webclient.field_renderer_uri)
replaces
"JavaScript? Field Renderer Class" (dm4.webclient.js_field_renderer_class)
IMPORTANT: for the new view configs to take effect you must reset the DB.
Plugins of standard distro are adapted.
This branch is fully functional.
See ticket 282.
comment:8 Changed 12 years ago by Jörg Richter
Core: namespace page renderers (#282).
IMPORTANT: plugin developers must adapt their page renderers.
Old code:
function WebpageRenderer() { this.render_page = function(topic) { ... } this.render_form = function(topic) { ... } this.page_css = function() { return {overflow: "visible"} } }
New code:
dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { ... }, render_form: function(topic) { ... }, page_css: {overflow: "visible"} })
A page renderer is now an object (instead a function) with 3 dedicated properties:
- "render_page" (function), semantics like before
- "render_form" (function), semantics like before, optional (not needed for non-editable types)
- "page_css" (object), not a function anymore but an object, optional (default: {overflow: "auto"})
The page renderer URI should use the same namespace as used in the plugin's migrations (if any).
Implementation note: page renderers are not instantiated anymore. Instead the renderer functions are called directly.
In order to make renderer-local context (functions and variables) available to the 2 render functions use the JavaScript? "module" pattern:
(function() { // define context var v1, v2 function f(...) { ... } dm4c.add_page_renderer("dm4.webbrowser.webpage_renderer", { render_page: function(topic) { // context (v1, v2, f) is accessible here }, render_form: function(topic) { // context (v1, v2, f) is accessible here }, page_css: {...} }) })()
(If you prefer to define the context *below* the dm4c.add_page_renderer() call you can do so. It makes no difference.)
In order to make renderer-specific methods globally accessible add them to the renderer object. They can be accessed by
dm4c.get_page_renderer("dm4.webbrowser.webpage_renderer").my_method_here()
New view config setting
"Page Renderer URI" (dm4.webclient.page_renderer_uri)
replaces
"JavaScript? Page Renderer Class" (dm4.webclient.js_page_renderer_class)
4 methods are dropped from js_utils.js
instantiate()
new_object()
to_camel_case()
basename()
TopicRenderer?: inactive auto-complete code is dropped.
Plugins of standard distro are adapted.
This branch is fully functional.
IMPORTANT: for the new view configs to take effect you must reset the DB.
Close ticket 282.