Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Non-semantic forms for editors #62
I've just had a long conversation with @bendetat about this and this is the first step in a series of steps to get nice "partial"-style support (as well as the ability to use Chameleon to generate portions of a form's HTML for things like SPAs).
The main thing to note here is this is the most basic possible implementation and relies on the developer to use it correctly - the documentation will need to reflect this.
Ben is going to make a couple of tweaks then I'll merge in.
So I've been pondering this and I'm not convinced this is a good solution. I've come up with an alternative that should be easy to implement but would be a breaking change if this PR is accepted so kill this please :-/
My thinking is that the partial or editor doesn't care about the form or section or whatever. All it cares about is getting the context that applies to it.
So what I've done with this PR is a hacky way to let the editor make something that looks like a context but is actually just a limited form.
I'm coming aroung to not using
which creates a
Then the editor's entry point into CF is
which pulls out the context.
I'm thinking that with editor templates you might want to specify it:
The other thing to consider is whether or not to use the editor template for the whole thing or just for generating the Field Element (or possibly allowing the configuration of both). re: partials - cool: perhaps that's the difference - if it's a partial it's the whole thing if it's an editor template then it's just generating the field html (dead easy to add a field generator handler that delegates to Html.EditorFor).
Then after we decide on all that (or a logical subset) we need to figure out the MVP so we can do a small thing first and build up from there.