Decorator Plugin System about cortex HOT 3 CLOSED

What I'd sketched out earlier with @MKwenhua was the following addition to the Wizard spec, which would be an object within the fields array:

{
  "cell": {
    "name": "asset_info",
    "method": "alternative_cell_render_method",
    "config": {
      "data_field_id": 2,
      "display": {
        "grid_width": 12,
        "styles": {
          "height": "500px"
        }
      }
    }
  }
}

The only issue with this is this concept of 'cells' now conflicts with the naming of the 'fields' array in the spec - this doesn't make much sense. Perhaps we can come up with a better name for 'fields', but that might require restructuring/renaming of stuff in our app/cells directory.

from cortex.

Why not just refer to what was once fields: as data: - it is directly referring to the implementation of low level data for the fields / methods on the ContentItem

Additionally - I was thinking that we could structure it in a way that would lend itself directly to the cell it would be creating, since we know all of the view plugins in cells: would be...well...cells...
I would counter propose a structure like this:

{ 
   ...other stuff...
   data: [
       cell: {
           location: "Plugins::EmployerBlog::SpecificPluginModuleCellName",
           render_method:  "alternative_cell_render_method",
           context: { ...specifics for the context object to go into the cell... },
           model: 2,
           display: {
              classes: "class_one class_two just_like_haml",
              id: "same as classes"
           }
       }
    ]
}

Just a few things to note:

1. We are already tracking display information like the grid_width and whatnot when we create the column in the decorator, which we would still be doing prior to the fields (or whatever we rename it) array - however we are continuing to track display specific to the field, cell, or model, just like in the rest of the decorator
2. method has been renamed to render_method for consistency
3. context is, quite obviously, any context necessary to the cell that the User would need in their cell, since this is just a detached implementation of the cell system
4. location would directly reference the location of the User's cell plugin, just like we're doing with Plugins::Core::SpecificFieldCell in ./app/cells/wizard/fields/show.haml. This approach would allow a User to insert and easily reference their own Plugin cells which would always stem out of Plugins::
5. model needs some work admittedly, but I can't think of a better way to pass information along...any thoughts?

from cortex.

As per our discussion, here is the proposed final object:

{
  "columns":
    [
      {
        "elements": [
          {
            "cell": {
              "class_name": "Plugins::EmployerBlog::SpecificPluginModuleCellName",
              "render_method": "alternative_cell_render_method",
              "config": {
                "thumbnail": "large"
              },
              "data": {
                "field_id": 2,
                "field_method": "dynamic_method"
              },
              "display": {
                "classes": ["class_one", "class_two", "just_like_haml"],
                "id": ["same", "as", "classes"]
              }
            }
          }
        ]
      }
    ]
}

from cortex.