Skip to content

Adding proper extensibility to ChameleonForms #107

@robdmoore

Description

@robdmoore

There is currently an open PR at #104 that I can't merge because I want to figure out how extensibility and reusability will work in ChameleonForms going forward to make sure that the PR aligns with the direction. ChameleonForms has been 1.0 for a while now and I've used it a lot so I have a fair idea of all the scenarios where it didn't do something I wanted it to do now. Below is a list of URLs to ideas and discussions that have been documented in the past and below that is the list of features I think I want. I'm not sure on syntax yet, but some of the links below contain some ideas.

I'd like input from @MattDavies @Royce @joshka @zabulus @bendetat if you have any. I'm also going to ponder this and hopefully we can settle on some syntax ideas and a feature list to drive the future direction of this project and allow willing contributors like @zabulus (thanks so much for being so keen dude - it's appreciated!) to be able to contribute while being informed of the direction of the project and allow Matt and I to provide quicker PR merging.

Context

The features I think I want

  • Ability to output a form using a view model type that is completely different from the model type of the page
  • Ability to output a form using a sub-property of the model type of the page and bind back to the type of the sub-property
  • Ability to output a form using a sub-property of the model type of the page and bind back to the page model type
  • Ability to output a section against a complex property of a type T using a partial view
  • Ability to output a field using a partial view
  • Ability to specify a partial view for a type by convention as well as inline in the page
  • ReSharper intellisense on partial view name
  • Ability to use Editor Templates to generate just the editor html - should be able to be used for complex types as well as simple types, should be able to specified via [UiHint], inline in the view, by convention and possibly for all unknown types as the default fallback?
  • Ability to modify / swap out handlers, template, field configuration based on conventions that can be applied globally

Would love feedback and ideas.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions