Ticket #282 (closed Enhancement: fixed)

Opened 12 years ago

Last modified 12 years ago

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

Description (last modified by jri) (diff)

This can be realized analoguous to the plugin functions (see #275).
Despite not a strict requirement it would be reasonable to do the namespacing before introducing further types of renderers (#270).

Change History

comment:1 Changed 12 years ago by jri

  • Description modified (diff)

comment:2 Changed 12 years ago by jri

  • Status changed from new to accepted

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.

Note: See TracTickets for help on using tickets.