perak/kitchen-cli

SimpleSchema definitions in separate json element/join plugins [ER]

Opened this issue · 0 comments

The idea for this came while hacking around #16, and because I use some custom SimpleSchema fields and validators

Is it possible to have the the field definition as a perfect SimpleSchema definition, such that it is possible to add custom field definitions to it?

Consider a Contacts table like this

Contacts = new SimpleSchema(
  name:
    label: 'Name'
    type: String
 friends:
    label:"Friends"
    type:"array"
 friends.$.type:
    label:"Relationship"
    type:"string"
 friends.$.link:
    label:"Friend"
    type:"string"
    join_collection: "contacts"

which would generated by

/collections/[name="contacts"]/fields=[
{
  "name": "name",
  "title": "Name",
  "type": "string",
  "required": true
},
{
  "name": "friends",
  "title": "Friends",
  "type": "[Object]"
  children:[
   {name: "type", label: "Relationship",  type: "string"},
   {name: "link", label: "Friend", type: "string" , join={collection="contacts"}}
}
{
  "name": "friends",
  "title": "Friends",
  "type": "array"
}
]

Proposals

So looking at the example above i would have some proposals

  • Change all the join_X parameters into a SimpleSchema extension join which accepts all definitions regarding joins
  • Make the usage of the perak:join optional on a per application and per join basis
    • add join.implementation='perak.joins' which would default to application.join_implementation, which in turn defaults to perak:joins
    • let perak:join take all it's arguments from the schema as opposed to monkey_patching the collection implementation with _joins and replace the find/findOne patches with a transformation function call 'perak_joins.create_accessor.call( doc, accessor_property, fk_property, f_collection, query)'
    • [This is more a perak:joins ER ]: let perak:join offer a function to access the joined object , instead of adding it directly to the result as in many cases the context accessing the join might be different from the one accessing the referee, and thus two contexts would only be reactive to their concerns
  • single out the 'label_'X parameters into an input_spec SimpleSchema extension in a similar way
  • The SimpleSchema denormalisation '[field].[children].[subfield]' -> [field.$.subfield] is necessary, but IMHO this is a SimpleSchema legacy flaw (which might be ironed out in v2?)

What I am proposing is is a clean separation of schema definition and join implementation, such that any join implementation (e.g. reywood:publish-composite) could be used. I am almost sure that join implementations will evolve in many packages and making an effort to keep it simple to adopt other packages would benefit kitchen a lot.

help?

If you are interested I would also invest some time to

  • create a package for transform-steps which only monkey_patches once allowing for multiple transformations with dependencies
  • create a forms:templates [EDIT: and reywood:publish-composite server-side] dependent package to generate forms based on the SimpleSchema extensions.

My time restrictions only allow me around the 1st of April to start extracting the functionality for a package, but ATM i am implementing it for my current project. This enhancement request is born out of the desire to do away with multiple schema tweaks and merge_schema custom method calls 😄