Remove dependency to sf-schema.

[vicary]

I found myself building user forms with bare minimal schema like this,

{
  "type": "object",
  "properties": {"":""}
}

I think it is good to remove this requirement and allow users to build a form with only sf-form, it creates some new use cases and dynamic form play styles in angular.

[davidlgj]

Interesting! And probably doable.

So you want to get rid of the sf-schema directive all together, or are you fine having it on the form but just without any value? Something like <form sf-schema sf-form="form">

I think there are a couple of places where we assume that since the form definition has a key then it should have a schema as well.

[vicary]

<form sf-form="form"> would be great, but <form sf-schema sf-form="form"> is just fine with a few more characters.

This idea is very much the reverse of x-schema-form, this way around makes much more sense when working with complex forms when sections and conditions are heavily used.

[nicklasb]

It could lead to an interesting modularization of the project. Could a separation possibly make it less complicated?

Can't one also go the other way around? To drop the form and connect arbitrary dom objects (and ASF add-ons) to just schema validation? Would one end up with some kind of pluggable model-management framework, a thin abstraction layer that could basically live in any JS-framework?

[vicary]

ASF so far has some layers of functionalities to me, namely

1. sf-schema translates into validation
2. sf-schema generates a default form
3. sf-form modifies the generated form
4. bootstrap-decorator applies a theme to the form

IMO all of these can be chopped down into separate repos, keeping each of them very, very thin.

Each of those can focus on a limited set of feature, it's healthy and more manageable.

[nicklasb]

The cool thing would be if each of them could be made separately usable to base other things on. Then they could be the base of other things and basically live their own lives.
One packaged end product could be ASF.

[nicklasb]

For example:

1. sf-form+bootstrap decorator+X could become a kind of report generator.
2. sf-schema + X could validate any set of DOM input controls against a JSON schema(or XML validator, there are huge legal frameworks that are defined in XML schema)
3. bootstrap generator could apply a theme to something else(I don't know).

[davidlgj]

I've been thinking and planning for the same thing. One of the objectives of the new builder was to decouple the form building from external dependencies.

So right now there are a couple of services that with some easy modifications could be moved to a "core" repo with no dependencies what so ever.

services/schema-form.js -- This has the merge function that takes a schema and a form definition (can be just ["*"] so really its optional) and spits out a "canonical" form definition that the builder can use.
services/builder.js -- Has the function build that takes a decorator (i.e. a bunch of html templates) and builds up the DOM.

What's lacking is decoupling of the validation from Angular's ng-model. It's sort of decoupled since we use the tv4 library, but a lot of logic around type casting, form state (pristine) etc is handled by the directive schema-validate and the sfValidator service and is has a hard dependency on how ng-model works etc.

I want this decoupling from angular for several reasons, but one is to easier incorporate it in Angular 2 in the future. But the the React port could probably also benefit from it. The things that stops me from doing this right now (except time, as usual) is that we don't have enough tests to guarantee stability during such a large refactoring.

[nicklasb]

Another thing with this is that it feels kind of difficult to contribute as it is now. I have actually considered it a couple of times, but backed away since it is hard to see all the consequences of what I am doing.

Given a more modularized and clear architecture, I would think that more people would contribute. If you'd need another reason.

[vicary]

I shares the same thought, had some ideas but it triggers too much of reworking / refactoring.